Here at Agile Architects, we’re obviously fans of the Open Agile Architecture (O-AA) standard: it is the very foundation of our company. However, we’ve noticed that it’s not always simple to understand O-AA for someone without a background in architecture. As the highest and most strategic layer of an enterprise’s IT infrastructure, architecture can sometimes seem a bit abstract. That’s why we use the expertise of Evert Deweer, one of our managing partners and member of The Open Group™, to explain some aspects of our favourite standard. On today’s menu: the building blocks of O-AA.
Building blocks 101
Let’s be clear from the start: these building blocks do not represent the different layers of a business. Instead, they represent different views on an organisation, which translate into the various strategic concerns architects and managers need to keep in mind. We’ll go into more detail below, but for now we can identify three building blocks: experience, the work system, and the technical system. At the heart of this is, of course, an Agile strategy.
The main point we’re trying to make here is that the technical and social systems of an enterprise should be developed concurrently. Business decisions impact all aspects of an organisation, even when they don’t seem directly linked at first glance. Let’s use an example to clear things up. A while ago Jeff Bezos, then head of Amazon, made a series of software architecture and business decisions for Amazon’s organisation and strategy. These affected Amazon’s business in several ways:
- Prohibiting any form of inter-process communication other than a service call led to the foundation of what we now call microservices (technical system).
- Reducing dependencies between teams created the conditions for increased team autonomy (work system).
- Ordering that all service interfaces should support being externalised encouraged the creation of a third-party vendor market. This helped Amazon compete against eBay by using a two-sided market business model.
The Building blocks diagram
The diagram below summarises the building blocks of the O-AA standard. These blocks are generic: we can apply them at different levels of granularity. The arrows represent preconditions. For example, the arrow linking customer research to product architecture represents that the outcome of customer research is a precondition to starting with product architecture.
Here’s a high-level overview of what this diagram means:
- An Agile strategy is deployed within an Agile organisation, which influences the strategy from the bottom up.
- Customer research is used as input for the product architecture.
- Customer research also creates experience maps, which are translated into journey maps.
- Value stream mapping models and improves the various value streams that deliver products. When value streams contain steps with customer interactions, they are mapped to the corresponding journey maps.
- The product architecture can require new operational capabilities, which are supplied by the operations architecture.
- The product architecture is developed concurrently with the software architecture and incorporates software functionalities.
- The same goes for the operations architecture.
- By applying the Inverse Conway Manoeuvre, the organisation is shaped to mirror the enterprise’s intentional architecture. If you aren’t familiar with the ICM yet, consult our previous blog on the 16 axioms of Agile architecture.
By now, you should already have a good idea what building blocks to use, to start your Agile Architects adventure. In what follows, we’ll go into three aspects of architecture decision-making that support the building blocks mentality: enterprise decomposition, the segmentation approach, and mental model shifts.
