Even if it seems like the right thing to do, just putting people to work is not always the most effective way of improving your systems. Can we start to understand the value of a more socially driven architecture?
Here’s a scenario.
The software architect is at work.
After reviewing the current state of the systems and looking at the upcoming roadmap, her boss asked her to come up with something to do this year. She picked something old that, in her opinion, needed reengineering and could provide the basis for new functionality for their customers.
She decided to redesign and augment this piece of architecture with a different technology. It might be something cloud native. Perhaps it is constructed from microservices. It could be a heap of monolithic C++ that builds into an infrequently released HPC application. She builds some of it, and then she demos it. When it is deemed acceptable by her bosses and/or peers, it is passed over the fence to the development teams. They come back with some questions and concerns, but eventually, it is planned in as work and becomes a new part of the new system.
Now, we have a new piece of architecture. But where did it really come from and what business purpose does it serve?
Architecture by Objective Setting
Do you recognise this pattern? Often, a straight technical architecture swap or enhancement is a nice standalone piece of work that an architect can rightly feel is a suitable size for an annual objective. And while the boss might be relieved to have found something reasonable for an architect to do, and the architect is happy that they have a substantial piece of work, how do the teams feel?
Armed with this work item, the architect is fully justified in creating their solution. The architect first owns this work, but then the rest of the organisation builds and has to live with these decisions.
And just like that, the architect has implicitly decided what is happening in the ‘next iteration’ of the product.
Let’s have a look at some of the problems that arise with this all-too-common approach:
- Firstly, the architect is not invested in the solution. They are there to develop a single idea and then move on to the next mission. They have no or little “skin in the game” at 3 a.m. when the pager goes off.
- Secondly, the approach is purely technical and based on an existing idea or piece of architecture. This can be, if anything, just a pure architectural refactoring of an existing piece of working technology in a new technology. This can mean prolonging existing technical debt.
- Thirdly, it views the system as a series of boxes with flows in between. This is a reductionist approach which is imperfect. See Barry O’Reilly and Residuality Theory for a vigorous explanation of why this isn’t a good idea.
- Fourthly and most importantly, because it is often a more technical approach, it usually fails to adequately consider the views of developers, operators, customers, and other internal stakeholders in the new approach.
- Finally, if not carefully managed, it could become a zombie solution, which is technically valid but not used because the legacy system is still in use.
So, while this architecture can be successful in technical terms, it doesn’t feel part of an overall architectural vision and it potentially only increases technical debt. Importantly, it doesn’t involve the teams supporting the final solution.
Therefore it’s bad not only for your systems and your customers but also for organisational morale. That’s not to say it doesn’t work and is always ineffective, but what is the alternative?
When does Architecture come to Life?
If we recognise this pattern, we should also recognise that the solution this builds will probably not be aligned with how the development teams might go about a re-architecture exercise. If you ask a dozen developers how they might approach a new architecture, it’s tempting to say you’ll get a dozen different replies, but in practice with experienced senior developers, you’ll probably find similarities in approaches, and a discussion might take place. You will gain a consensus, in other words.
When architects are tasked with building something new, they typically view it as their own creation and their opportunity to validate their existence. This is the opposite of a consensus approach – it’s command and control via stealth.
It is possible to use any architecture from a blueprint and implement it. However, if we consider the impact of Conway’s Law, we should be aware that architecture will always have to conform to our organisational model, no matter how carefully we design it.
Indeed, top-down design doesn’t necessarily fit cleanly into a Team Topologies universe where we implicitly acknowledge the influence of organisational structure on our architecture. So, where does the architect fit in this model? While it is possible to form an Architecture Modernisation Enabling Team (AMET), this is not designed to be long-lived. Enabling teams, by definition, are transformational. Eventually, the work will fall to the developers to build and maintain any new solution.
So, for me, the question is when does enabling stop and development begin? And who owns the architecture going forward? And where does the architect fit in?
Value-Driven Design
If we accept that our organisation is implicitly helping to design our architecture, then the logical conclusion is similar to the one made by Matthew Skelton in 2020 that HR are Accidental Architects.
And who is responsible for responding when Conway’s Law comes knocking? The team that owns the system is always the responsible one. Therefore it is the team itself that best understands the specific constraints under which their existing systems work. Therefore it is the team itself which is best-placed to make long-lasting decisions about the future of the existing functionality.
While an AMET can provide valuable insight and perspective, it can only assist and it will be a temporary transformational structure. Indeed in this post Eduardo and Nick mention that:
If the organization can handle that modernization, there is no need to create an AMET. Creating an AMET may be counterproductive since teams can self-organize to drive modernization efforts.
Most successful modernisations I’ve been involved with have been run by the domain team, with senior leaders’ support. If we are looking for a role for our architects in our architecture modernisation, then an AMET might be a good first step, but eventually, they need to work closely with the teams continuously.
If you look at some of the key points Matthew raises regarding Team Topologies in his Accidental Architects post:
- Organisation design is an enabling constraint on the “solution search space”.
- Improvement comes from rapid feedback from running systems.
- A team-first approach is essential.
- Co-design the organisation and system architecture simultaneously.
This points to architecture being a value-driven continuously evolving process owned by the (stream-aligned) team. Deeper understanding of the delivery of software to customers will drive knowledge which informs our system architecture.
When our team is continuously thinking and talking about our system architecture, it is no longer a static set of diagrams or words or intentions, it becomes alive:
Therefore we can conclude that:
- Architecture is a continuous, social activity driven by those with deep commitment and engagement to both the product and the customer.
- No single team or individual should be responsible for major architectural decisions. There needs to be an ongoing awareness of architecture across the entire organisation.
- Teams used to traditional top-down architectural design may not be used to making decisions for themselves.
- Support from an AMET, architects or senior technical leaders can be invaluable to upskill and support teams but their influence should be time-boxed.
- The goal of the AMET should be to democratise architectural decisions.
- Architecture is a decision-making process that a team must hold itself to account for every day.
- Architects need to decide where they can add the most value in the organisation.
For more about AMETs and Team Topologies please see the work of Eduardo de Silva and Nick Tune. In particular have a look at Nick’s book, Architecture Modernisation.