Agile processes are a big trend today, and software architects are a big need. However, the two don't really fit well together unless you understand how to do it right. I will try to solve this puzzle here.
Let me put very basic statement for the beginning: no architecture - not accepted. That's true for any kind of software development process. You must have architecture in place. So, I will not cover here ways how to avoid having software architect in agile processes.
Traditionally, software architect is responsible for designing and diagramming overall picture of the software solution. Once we try to define "overall" picture, we think that everything should be planned in advance. Then, how do we benefit from Agile's flexibility to change anything at a later point?
The answer is architecturally obvious: software architecture must be extensible so that reasonable flexibility can be achieved if needed.
The sentence was easy to type, but the solution is not trivial. Software architect will face a challenge to correctly outline the boundaries of that reasonable flexibility throughout the software. Creating of a very generic solution is unacceptable since it would bring complications like maintenance headache and un-instructional code. Besides, software architecture should be limited to the domain, not to the whole world. If the architecture is very generic, it's on the way to becoming a framework, not really a software product. In particular, you can read about software architecture to recall how I define it.
Creating such architecture itself might happen in several agile iterations. For example, if an agile team has a goal to come up with extensible software architecture for particular reasons, it means the software architecture itself becomes a deliverable of the iteration. If this answers all your questions, you are good to go. In this topic, on the other hand, I am more concerned about situations when the deliverable is a software, and the architecture is evolving in parallel.
If the overall architecture is defined, then the software development team can be guided through the agile iterations. Let's figure out what it means to have overall architecture defined.
It's important to mention that defining a software architecture has nothing to do with the actual software code. Architectural skeleton (overall architecture plus its extensibility points) need to be defined before the software code starts existing, not the opposite. This reminds me of another topic that I have discussed recently about platform-independent and platform-specific models. Using terms from that topic, software architecture is a documented guide to creating platform independent model, as well as instructions for creating platform specific implementations.
Now, the definition of the overall architecture should be clear.
Agile iterations fit well into the software code writing tasks based on the pre-defined architecture. Emphasis here falls onto the fact that the overall, predefined architecture exposes extensibility points, which the agile iterations incorporate. In other words, agile iteration is an effort of implementing platform-independent model code, as well as platform-specific code by using the means of extensibility, provided by the architecture at hand.
One of architect's responsibilities throughout the agile iterations can be derived from the above statements, as follows: architect is a guard and guide to correctly implement the agile iteration's goals based on pre-defined extensibilities of the software architecture. Software architect sees a big picture, and helps the development team in assembling it.
Next concept that I want to bring to this topic is what I call "packaged architecting over componentized architecting".
When assembling smaller parts of the big picture, we don't need to be too microscopic by over-architecting the smallest pieces of the software. Don't forget that those small peaces belong to the limited boundary (such as bounded context) which needs architect's attention in the first place. Very often, small pieces (components) become designed very well, but the package (contextual boundary) is not well designed.
This situation is very typical in agile environments when architects try to be "agile" by concentrating on the components since the component is the deliverable of the current iteration; whereas the package (or the boundary containing this component) is the deliverable of several iterations, including those coming after the current one. Architect's responsibility is to design the boundary (both shape and inner works) properly first, and then concentrate on each component, not opposite. This is necessary to avoid over-designing the components, as well as to properly define relations between components in each context. If this is not done right, every component will require repetitive refactoring over time to achieve the final design goal.
Some architects will argue against my opinion by saying that, since the bounded context is not well defined yet (we are in Agile after all), they want to make sure that each component provides enough flexibility (bloated with millions of useless/possibly useful functionalities) for any of the expected ways that the bounded context can evolve. My answer to this argument is - how can you decide now, if you are not even sure where the value lies? maybe none of your imagined scenarios is going to happen? development overhead is one of the biggest enemies of the business allotted funds as well as high quality software. This is where Postponed Decision comes in handy.
So, the meaning of the last few paragraphs was to break down the overall big picture into smaller pictures, and start assembling those smaller pictures using several iterations each. Eventually, smaller pictures will form the overall picture by the end of the project that you are working on.
Lastly, software architect needs to become integral part of the agile team by organizing repetitive knowledge sharing sessions and group-based activities.
Since it's an Agile environment, software architect will go through the Agile lifecycle together with the Agile development team. But before starting this journey, it's worth setting up knowledge sharing sessions with the team and going through the architectural decisions (overall picture) which is about to become alive.
Next, when the actual iterations start implementing the overall architecture, keep discussing smaller pictures with the team. Each iteration should be based on both business requirements as well as architectural understanding of the software. And this can only be achieved by properly educating the team about the big picture as well as smaller pieces of it every now and then.
To stay an active and helpful as an architect, keep sharpening your skills and knowledge, and remain hands-on if at all possible. Also, don't forget to check out my training courses around software architecture.
The author of the above content is Tengiz Tutisani.
If you agree with the provided thoughts and want to learn more, here are a couple of suggestions: