Formalizing governance: “Agile with architecture” (6/7)
Working with other people is at the core of every agile methodology. In the previous articles, I’ve explored the role of architecture in setting up this cooperation and how you, as an architect, can, in my opinion, successfully contribute. Cooperation alone is not sufficient however. Imagine that you need to work in a project or organisation where there is no form of documentation about anything that has been delivered, about how it works and that there are no plans for future development. I don’t think that the organisation or project would stay successful for very long.
The trick is to document the essential information and no more than that. To organize what is needed for people to be able to do their work and take decisions, but no more than that. Planning work to identify where bottlenecks are and to carry out a sensitivity analysis, but no more than that.
Architecture documents as a means of communication
Architecture documents help record which choices have been made, what the reasons for the choices were and to record references and assumptions, so that future developments can be assessed.
Architecture documents are a means of communication. They work as an aid to memory to avoid every day cares taking control and not having to hold the same discussion repeatedly.
There are various kinds of architecture documents which all belong to a different level of responsibility. According to ISO/IEC/IEEE 42010 the definition of architecture is:
“fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”
The logical consequence of this is that enterprise architecture describes this for the entire organisation, a domain architecture for a single business process or group of processes and a solution architecture for a specific solution within a domain.
Documentation as a measuring stick for change
If you work from the assumption that you only document the essentials and no more than that, then in the enterprise architecture you only record that what is essential to maintain the agility of the organisation. The same is true for the domains and the solutions.
You create a measuring stick to measure the extent of the impact of a change. With every change, you check whether this leads to necessary changes at an enterprise, domain or solution level. A change at the enterprise architecture level has far more fundamental consequences than changing a specific solution. A change of course on the evolutionary path is major when leading to change in the enterprise architecture and only a small correction at most or a small hitch in the road when leading to change in a solution.
The impacted level ensures a clear picture of which teams need to take part in discussions to carry out the change. Also, where you can lay the responsibility for absorbing the change.
If you are responsible as a team (or teams) for a solution working with standards, templates and design patterns, then you only need to record the changes to templates and design patterns during the implementation. This not only means a lot less work, it also makes changing or extending the functions in the solution much more transparent, leading to a faster and highly reliable evolution of the product. You are more agile during execution.
Agility is in your bones
As an architect, it is important not to want to do all the architecture documents yourself when recording ‘exactly enough’. Prescribing choices and checking afterwards if these have been carried out correctly is fatal for your agility. You then recreate the top down structure which the agile manifesto opposes.
Choices which are made and which fit within the scope of a domain or solution architecture are documented by the team themselves. It is only if a change requires an adaptation to the framework, that the team should ask the architect to act. Working alongside the team members or teams, you then go to work to explore alternatives using prototypes. Together you make the choice for changes to the framework. Implementing the consequences of the choice is then up to the team or teams.
Agility should get into the bones of the team; architecture thinking is more important than documentation. It is the responsibility of the architect to record a team’s thought processes, so that the team can build up its own memory. In this way, the team can take responsibility for determining the impact of change. Choices which are validated by a team ensure the future changeability of the solution which they are making. Using architecture documents as a way of limiting the room for choices means that a team can themselves signal when they need to have discussions with other teams. If each term works in this way, then you are an agile organisation, with architecture.