Agile projects, above all those with multiple Scrum teams, need a moderated
architecture process, in order to facilitate architectural decisions. It is
advantageous to decide as late as possible, nevertheless the correct point in
time should be chosen intentionally. If not, important architecture decisions
could be overlooked or made too late.
The promise
In the ideal agile world, architecture grows by evolution (“no big upfront
design”). An architecture will not be sketched out with great detail before
development starts, but it will be created instead step by step during the work
in the sprints. Decisions will be taken when triggered by work on a current
user story. Until then, the team has time to gather know-how which will come in
handy for evaluating architectural decisions. Since the “big upfront design”
doesn’t have to be adjusted along the way, requirements can be accepted more
easily und can be integrated into development more quickly. As a consequence,
risk will be lower and efforts will decrease – that’s the hope, at least. Even
the quality should increase, because decisions can be made with more
experience. All this is based on the implicit assumption, that all knowledge
needed to take the decision will be accessible for all persons involved at the
correct point in time.
The reality
This assumption is – as we will see – incorrect, which leads to some
negative effects. Some preliminary work on the architecture already helps with
the beginning of an agile project. The question, which part of the system the
scrum team should work on can only be addressed sensibly, when there is a rough
breakdown of the “system”.
Basically, it’s not so bad an idea to decide late. In fact, there are many
architecture questions which can be postponed. E.g. you don’t need to decide on
a browser, when you don’t work with browser specific functions. You don’t need
to talk about implementation details of microservices, which will be accessed
via webservice API. To decide late indeed means to decide with greater
knowledge and therefore, to decide with greater quality. Thus, the focus can be
shifted to the current and immediate problems.
Picture 1: Sleeping beauty phase
Yet, this also is the catch: the “immediate” problems tend to push the
postponed decisions from the agenda. They enter a “sleeping beauty” mode, and
waking them up is hard. Somewhere in the project wiki they are documented, but
who keeps track? All of a sudden the team faces the problem, that a new
component has to be implemented in the next sprint – but the decision about its
interior technology has not been taken. Important business information and
conceptual information is missing, which is necessary to make the decision, but
which does take some time to acquire. As we see, the assumption of the “always
available information” is not true.
Due to the „sleeping beauty“ effect, the project gets late and misses its
schedule – which could be prevented by some preliminary work. The same effect
also casts its shadow on the hopes for better quality, since decisions taken
under time pressure tend to be suboptimal. Furthermore, non-functional
requirements also fall prey to that effect, which can lead to even more ugly
consequences.
Best practices
But there is an effective method against the „sleeping beauty“-effect: somebody
has to watch the “sleeping” decisions and has to ensure, that necessary
knowledge is acquire early enough. To that end, architecture decisions must be
moderated with regard to all teams on the project. The moderating instance has
to take care for postponed decisions and is responsible to get them up on the
agenda right on time. That’s early enough, to carry out important preliminary
work, e.g. to clarify business relevant questions. Some decisions even
shouldn’t be postponed at all (e.g. because there are dependencies to other
topics). This weighing-up should also be done by the architecture instance (you
might call it a “guild”).
Sometimes, there are dependencies between various decisions, which may even
apply to different teams at first sight. Those overarching dependencies must be
identified, tracked and resolved, in order to achieve overall consistency.
Experience shows, that it’s a good idea to transfer that responsibility to a
dedicated group of people. This enables evolutionary development of the
architecture without taking the risk of the “sleeping beauty” effect.