Understanding the architecture layers are essential for a mature architecture practice

Having worked across various architecture practices, I am convinced that having clearly defined architecture layers and boundaries for each architecture discipline is crucial for driving successful outcomes. On many occasions, architects stray across these boundaries, making the accountability and decision-making lines unclear. This can lead to conflict and confusion where Enterprise Architects (EA) deep dive into too many solution level details and vice-versa, where Solution Architects (SA) make decisions that impact the enterprise as a whole. This can also occur at technical architecture levels, where the Technical Architects (TA) makes decisions solely based on individual preferences or project reasons that are not aligned to the company’s strategic direction. On most occasions, these decisions are only discovered when it’s too late. The outcome of these behaviors eventually leads to the organisation carrying a lot of architecture debt. This architecture debt creates an organisation that is less agile and more expensive in adapting to changing business needs.

THE ARCHITECTURE LAYERS AND BOUNDARIES

Enterprise Architecture Layer – This is the layer that the EA works within. Their viewpoint and focus should always be the organisation as a whole. The EA’s primary role is to ensure the organisation’s business strategy is achieved by aligning it to the IT strategy. The EA will define the target state for the organisation through enterprise architecture principals, roadmaps and standards. Considerations that are typically covered in this layer should be enterprise level decisions, such as:

  • What enterprise integration platform to adopt?
  • What ERP platform is the ideal fit for the organisation?
  • What level of cloud capabilities fit the organisations need?

Once these high-level boundaries are set, it is the responsibility of the Solution Architect to work within the next layer to define the solutions. It is also extremely important to define the enterprise direction correctly at this level, as any shortcomings at this layer will significantly impact the next two.

Solution Architecture Layer –  This is the layer that the SA works within. Once the EA has defined the high-level solution boundaries, it is the responsibility of the SA to define their solution within the boundaries outlined to achieve the desired business outcomes. They work within a viewpoint of a program or a project to define and guide their solutions. The SA is accountable for any solution level decision making within this layer and does not need to raise it at the EA level unless the decision impacts the enterprise. The SA is the owner for the solution architecture and is the conduit between the EA vision and what is delivered by the TA. Once the SA has a defined solution architecture, the EA (or forum representing each EA domain) is responsible for endorsing it and confirming the solution is aligned to the enterprise architecture.

Technical Architecture Layer –  This is the layer the TA works within. Typically, the TA specialises in various technology domains, which form the building blocks of the overall solution. They ultimately drive the final design that is physically implemented in-line to the solution architecture defined by the SA. The TA is the owner and is responsible for the detailed design. For example, if the solution architecture outlines a web portal for capturing business data, the inner workings on how the portal is designed, is the responsibility of the TA designing the web portal. However, the portal has to be designed within boundaries, such as solution patterns and standards defined by the SA. Once the TA has finalised their design, the SA will be responsible for endorsing it and confirming the design is aligned to the solution architecture.

IDENTIFYING WHEN YOUR DECISIONS HAVE CONSEQUENCES OUTSIDE THE LAYER

One problem that occurs too frequently is that the technical solutions actually implemented and overseen at the technical architecture level may be different to the enterprise vision. Normally, the EA does not have any visibility to this problem until it’s too late. Therefore, it is crucial all the architects identify decisions that impact the layers adjacent to their boundaries and highlight this in the appropriate architecture forums. It is also important to remember that the SA is the conduit between the enterprise architecture and technical architecture layers, thus identifying decisions and keeping lines of communication open to both sides of the boundaries. This is necessary to ensure overall architecture governance and moving towards a mature architecture practice.

In practice, staying within the architecture layers and boundaries require delegation and trusting that all architects are performing their roles diligently. Therefore, it’s important to ensure architects within the organisation understand their roles and responsibilities clearly within these layers to enable the architecture practice to leverage its full potential.