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.
