In the past I’ve seen people present to me a list of technologies and tell me “Here’s the architecture of our solution.” But, in my opinion a solution architecture is no more a list of the technologies used than the architecture of a building is a list of the materials that it is made of.
Once I’ve expressed this opinion, I’m sometimes asked “So, what is an architecture?” Or, “What does an architecture look like?” Or, more pointedly “So, what do you think an architecture is?” My answer to this question has evolved over time (and continues to evolve). Here’s my current answer.
If I think about what we are trying to achieve with IT architecture it is a coherent, consistent and effective approach to the delivery of technology change. So, for me an architecture is the set of deliverables that help us achieve that.
When a building architect is explaining an architecture of a building they talk about the people who will use the building, and what they will use it for, the considerations (functional, structural and aesthetic) that determine or constrain the choice of materials, the arrangement of space. So, by analogy, an IT architecture needs to explicitly describe what the business is trying to achieve from its solution and then how the selected arrangement of technology capabilities (products etc.) delivers on that.
I find the IEC/IEEE standard on architecture (42010) quite helpful. It talks about an architecture including multiple views of an architecture which describe the system from the viewpoints of different stakeholders – taking into account their different concerns. The view of a system from a user’s perspective is often very different from that of a senior manager, or someone tasked with supporting and maintain that system. An architecture needs to take that into account and show how it is addressing these different concerns.
So, practically speaking, what do I think architecture documentation should include?
- It should include a description of the components of a solution and how they interact or integrate together. It needs to specify what each component contributes to the solution in terms of functionality that the solution needs (or put another which requirements the component delivers on).
- In the case of a solution that uses cloud platforms, it should include a description of which services are used and what those services are used for – the role they play in the solution.
- For me it is the choice, arrangement and integration of components – not the internals of the components.
- It should include a description of who interacts with the system – and what they see and interact with.
- It should describe the trade-offs made between the different stakeholder concerns – where we have compromised on the ease of maintaining the solution to improve the usability for example, or vice versa.
- I also want to understand how this solution contributes to (or hinders) attempts to increase consistency and coherence of the business and the technology landscape (by analogy think about how the architecture of a building is consistent with the character and planning restrictions of a zone, a district plan, a neighbourhood).
This is different of course to the question (and problem and answer) to what does an architect do? How do we produce one of these? More on this later…