Have you seen imbalanced architectures that are not fit for purpose, because they were created with siloed perspectives?
For example, we have witnessed an Information Architecture Organisation defining their own meta-model, design documents, own tools, including its own architecture governance setup based on “data ownership”, and finally expanding into covering elements such as business rules and definition of interfaces. The result being an architecture only fit for information and very hard, if not impossible to combine with other perspectives.
As another example, we have experienced that a Business Architecture Unit is established, while the Enterprise Architecture unit still exists and their job titles, roles and responsibilities are not changed. The same will often be the case when Information Architecture is split out of the Enterprise Architecture unit. The show goes on in its crazy misaligned way as if nothing had happened. Now you have 3 units (one Business Architecture, one Information Architecture, one Application Architecture & Technical Architecture), and each of them are competing to do Enterprise Architecture. The result is a lot of pseudo and misaligned architecture work which misses the opportunities to get real value from architecture.
So, what is the secret ingredient to create the most sustainable architectures out there?
There are several as we will cover in future articles, but firstly we believe “best architectures emerge from interdependent collaboration in cross-functional architecture teams – not from individuals, single disciplines or single organisational units”. Hence it is important to set up your operating model for architecture development with collaboration across architecture disciplines. The objective is to create interconnected and co-created architectures, where you focus on business problems and not architecture disciplines or perspectives.
Architecture disciplines need to complement each other for sustainable architecture outcomes.
- Business architecture scopes a logical system to suit the business purpose
- System architecture guides technology choices to suit the purpose of logical solution
- Information architecture creates a ubiquitous language with concise definitions and captures important business rules to ensure clarity within the purpose of the solution
Consequently, best architectures are not an accomplishment of “supermen”, but rather “super teams” with different skills that have learned how and why they need to work together to become successful. So, one of the most important competence for an architect is the ability to collaborate and understand the various perspectives. For example, if you are very good at technical architecture you need to collaborate with other architects to get the right perspective from the business side and ensure information is concise in context. On the other hand, if you are a clever business architect you must understand the perspectives from technical architects to ensure best possible technical choices to fulfil the business purpose.
So, in large organisations you need an architecture team with diverse competences and shared responsibility. The diverse competences ensure the various perspectives, while the shared responsibility drives focus on business outcome leading to a sustainable architecture. On the other hand, creating architecture from a single discipline with split responsibilities results in attempting to describe everything from one perspective. This results in a misaligned and biased architecture that will likely not stand the test of time. If your organisation is large enough, you may need more of these teams just like you need multiple developments team for larger solutions in order to ensure enough domain knowledge for the team to create the best quality.
Such an architecture team may risk becoming a self-sufficient group of people patting each other’s back, so to avoid this it is equally important to ensure that the architecture is realised in collaboration between architecture team and those realising the architecture. This is best done in an iterative manner to obtain the feedback as discussed in our next post.
This is not new idea. For example, it is similar to the 11th principle in the agile manifesto “The best architectures, requirements, and designs emerge from self-organizing teams”
- What is your experience in relation to this observation?
- How are you approaching architecture collaboration in your organization?
- What is the leader’s role in establishing an architecture operating model where cross-collaboration is promoted to produce best architecture outcomes?
Please share your experiences by commenting