Software Architecture in an agile Context

In agile process models like Scrum there is no role defined for an architect. There’s just the team (besides the Scrum Master and the Product Owner of course) and every team member shall be able to fulfill the different roles as needed. That means that even the system or software architecture is done by the whole team. This works great as long as the team is able to find a consensus on all problems arising from the requirements and concerning the software architecture. But what if the team cannot find a solution or someone disagrees on proposals made by other team members? This blog post introduces the concept of an architecture keeper and tries to define that role with all its rights and responsibilities.

In general it is a very good idea to let the software architecture emerge from the team itself. One of the twelve principles behind the agile manifesto states: “the best architectures, requirements and designs emerge from self-organizing teams”. But why is this a good idea? Think of your first little program you implemented completely for yourself. Weren’t you proud of it? Are you not still proud of ideas you have and solutions you build within complex environments? When everyone in a team is able to contribute to the overall software architecture they have a more positive attitude towards it. Chances are much greater the architecture gets accepted by all developers of the team and they will have more fun using it during development. Furthermore they will more likely stick to the initial architecture and do not want to break boundaries. They will also defend the architecture against others because it’s kind of their baby. So, in general it’s a good idea to have a “team architecture”. But what about the problem mentioned above? What if the team cannot reach a consensus on the architecture? For this case there needs to be an additional role that was not originally defined by Scrum. There are other authors who call that role Architecture Owner. I will not use this term because I think it implies that there is someone who owns the architecture. But as with agile methods were the code is owned by the team rather than a single developer the architecture also belongs to the whole team. So there is just no owner of the architecture. To better reflect the role I’d like to propose the term “Architecture Keeper”. The Keeper takes care of the software architecture and manages all the processes and meetings concerning the architecture. In order to describe the role there are three questions that need to be answered:

1.       Which skills constitute a good Keeper?

2.       How to become an Architecture Keeper?

3.       What are the rights and responsibilities of a Keeper?

Let’s start with the first question. What are the skills you need to bring along to be a good Architecture Keeper. The following listing shows an excerpt of the skills that are crucial for every software architect. Not only the ones who are acting in an agile environment.

Make decisions, document and defend them

It’s important to make decisions but it’s also not easy. As an architect you have to make decisions without knowing all the environmental influences to your system. So some of your decisions may not lead to the optimal solution but that’s okay. Philippe Kruchten said: “The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark.”  Document and defend your decisions. Architectural decisions mostly have a great impact on a system. These are decisions that cannot easily be undone or reverted. So you shouldn’t change your mind every day. Stick to your decisions, substantiate and explain them.

Review and present your architecture

A good architect will always review his own architectural decisions. A decision that well suited the requirements today may not be valid tomorrow when other requirements come into play. So always take a step back and reflect your architecture and the decisions you made.
Present your architecture. Explain it to the team, to stakeholders and to whoever is interested in it or just affected by it. Choose the correct level of detail and complexity for your presentations according to the audience.

Know the technologies and best practices

As an architect you need to know the technologies, libraries, frameworks and best practices you are working with. It’s not enough to be able to draw nice diagrams with a sophisticated architecture modeling tool. You need to make decisions for the use of certain technologies in your project. So you need to know their advantages and disadvantages. You need to know how to use the technologies and their pitfalls. It helps you in making better or at least not so bad decisions.

Talk to the team, to experts and stakeholders

Communicate! Don’t sit in your ivory tower drawing diagrams and providing them to the masses without comment. Explain your design to the team and demand feedback. Talk to experts if you’re not sure about a certain aspect of your design or a certain technology. Ask stakeholders about their expectations, their requirements and even their hopes and wishes for the new system. Take care of them and listen carefully to their needs.

Keep an eye on the project environment and its influences

Turn your focus not only to the project and the system itself. Look out for environmental changes, for changing influences and of course changing requirements. Try to anticipate them and plan for possible changings of the systems architecture.

For architects acting in an agile environment there are a few more requirements that need to be met:

Communicate even more

Nothing to explain here. Agile is all about people and interactions, so communication is the basis for a successful project.

Be part of the team

I think it is very important for a Scrum team that the Architecture Keeper is part of the team. This increases the feeling that the architecture itself belongs to the team. In addition it facilitates communication and it becomes easier for the keeper to actually take care of the architecture because he can see how it is used and if everybody is still developing inside the defined boundaries.

Design for change

This one is not new. It’s the battle cry of all modern architects around the world. For agile environments sticking to that statement is fundamental. It doesn’t mean that you should design your system to handle any possible speculative requirement. This will lead to complex and over-engineered architectures. Instead it requires the careful handling of dependencies by appropriate separation and modularization of the systems components. So choose an agile architecture and appropriate patterns to achieve the needed level of isolation and try to build your system as flexible and extendable as possible.

Make decisions as late as possible

In an agile process model it is crucial for the success of the project that you are able to defer architecture decisions as much as possible. The more degrees of freedom remain the better you are able to respond to changing requirements or environmental influences. In order to defer decisions you need to find the last responsible moment (LRM). That is the moment where you finally have to make a certain decision because it can no longer be deferred. Communicate these moments to others and explain them why you don’t make the decision right now.

Let’s have a look at the second question: How to become an Architecture Keeper? Scrum Masters can do a certification and can then take a corresponding position in the Scrum team. But what is someone supposed to do to become an Architecture Keeper. Well, I think there are two possibilities besides that you need to bring along the skills mentioned beforehand. First the Keeper may be elected by the team. This is the better approach because it increases the acceptance of the Keeper and her decisions later in the project. This approach works only if the team knows each other or is at least able to estimate who may be suited for that role. When this is not the case the Keeper needs to be appointed by the responsible authority which is the second possibility. This holds the danger that the Keeper and her decisions will not be accepted by the team. A careful selection process is needed in order to select the best person for the job.

The third question is an interesting one. What are the rights and responsibilities of a Keeper? The Keeper may act within the team or even outside of the team.

Within the team the keeper makes decisions concerning the systems architecture if the team is not able to find a common solution to a given problem. This is also a possibility to prevent unnecessary discussions about possible scenarios or solutions that may otherwise take too long. The Keeper plans and conducts meetings that are relevant to architecture, for example modeling meetings at the beginning of a sprint or architecture review meetings at the end of a sprint. He acts as a moderator and supports the team with his technical expertise. He is also responsible for the selection and use of appropriate modeling tools and he takes care about documenting architecture decisions and the architecture itself.

In addition to the Scrum Master the Architecture Keeper is also allowed to act outside of the team. This applies especially for the presentation and defense of the architecture against stakeholders. The Keeper is the first contact for the Product Owner or Scrum Master concerning the feasibility of a certain feature regarding the systems architecture.

The following picture shows all the aspects that were mentioned in the post above concerning the architecture keeper. It shows the different roles of the keeper, her rights and responsibilities and what it takes to be an architecture keeper.