The Agile manifesto states the following:
Working software over comprehensive documentation
The best architectures, requirements, and designs emerge from self-organizing teams
Some teams take this to mean that so long as they are building “working” software and they are self-organising they are doing architecture.
I, for one, don’t want to go back to the days when the architects created system designs in their ivory towers for months on end finally throwing it over the wall to the development team once it was “correct”. But neither do I want the chaos and disorder that can be created when the architecture of complex systems is purely left to chance or left to emerge. Emerging design is not a bad thing itself, it’s just that you need to know what you are letting yourself in for and what could go wrong.
This is an excellent article that describes what can go wrong with emerging design.
In summary your system changes over time – sometimes in ways you expect and sometimes in ways you don’t.
You might not be surprised to know that I do see the need for architecture in Agile projects but it is very different to the way it was done in the waterfall days.
Architecture is a Role not a Person
In the same way that testing is a shared responsibility in a good Agile team so is architecture. Again as with testing there may be an architecture specialist in the team but that doesn’t mean they do all the “architecting”. Instead they share their experience and mentor other members of the team to develop an appropriate architecture for the product or system.
I have seen architects trying to fit into the architecture owner role described in some scaled frameworks. They apply themselves to the role in the same way as a Product Owner, distancing themselves from the day to day delivery of user stories. Most teams will accept this way of working for the product owner, as they tend to come from the business and often don’t have the necessary skills to deliver software. The architecture owner, on the other hand is talking about technical subjects and trying to influence how the software is built rather than what the software needs to do. Some teams will resist this unless the architecture owner can put their money where their mouth is!
In order to be effective the architecture owner needs to be credible in a team full of technical people. What I mean by this is they need to be producing alongside their team members. By doing this they understand what it takes to develop the product. By contributing to the delivery of user stories the architecture owner is showing that they can apply the concepts they talk about. This can be hard for some architects, as their development skills may make them junior developers on the team but in my experience it is the best way to become accepted into the team.
The architecture owner defines the architecture vision. This is usually high level but provides the general direction for the product. Going back to the earlier article the vision defines how the system is expected to grow and how it may change over time. It might highlight key dependencies outside of the control of the product but which are key to its success. This leads to a set of prioritised technical activities that ensure the architecture of the product is fit for purpose at a given point in time. This is often given the name “Architecture Runway”. The name implies that if you don’t have enough runway the plane (product in this case) will crash!
The architecture runway does not assume that the complete architecture is in place from the start or even that the architecture could be classified as “correct” at any point in time. It simply allows the architecture to emerge and change in a just in time and controlled manner. For example, to get the product off the ground for a small number of customers it may be perfectly acceptable to spin up a single virtual machine hosted by a cloud provider such as Amazon or Google. But as the usage of the product grows and the impact of the system failing increases then the architecture may need to be more fault tolerant and recover from failure better. It is not good enough to do this when you find you have a problem – you need to be ready for the problem before it happens.
So how to you order the runway?
Ordering the runway is exactly the sort of thing architects are good at. It involves understanding and assessing the technical risks associated with the product. And those risks are derived from the architectural vision – how is the product going to be used in the future, what does it need to be integrated with. But it is not just a projection of what ifs and may bes. It should be based on actual use of the product. If the number of customers are increasing exponentially then you need to think about increasing the size of the infrastructure. If customers are asking for integration with a particular external system than you need to think about how that would work.
Essentially the architecture runway is driven by two things.
The first are the technical risks. These tend to be found in the “important things” or the “things that will be hard to change”. The important things depend on what the product does and the need to change is driven by the architectural vision.
The second driving force is what you are proving by delivering working software. It is the feedback you get by having people using it. No amount of architectural beard stroking will identify how your customers use your product. No architecture is correct in the face of continuous change and constant feedback.