WTF is Cloud Native Enterprise Architecture?

There are many definitions of Enterprise Architecture (EA), but perhaps the simplest one is in the book “The Software Architect Elevator” by Gregor Hohpe, which describes enterprise architecture as “the glue between business and IT architecture.” Building on this with a CS client, we formulated the following value proposition.

EA is:

A bridge between Strategic Leadership and the Engineering teams.

Its role is to translate the business strategy into a clear engineering vision, facilitate high quality system design, ensure all the non-functional requirements are addressed and keep the information flowing in all directions.

It’s also a technical bridge for Risk and Compliance teams to ensure correct architecture and successful compliance assessments.

New ways of working and collaborating

These definitions of the EA function have existed for a long time, but the ways of working have changed as companies embraced both Agile and other related working practices.

In traditional organisations, all decisions flow top-down—from strategic planners to architects, who are responsible to create exhaustive designs ready to be handed over to engineering teams for execution. In such an environment, EA and a variety of other architectural and analytical functions are responsible for all the architectural choices. In this context, all the decisions must be taken prior to the start of the actual engineering work. This is visualised below, (based on an illustration in "The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment" by Svyatoslav Kotusev)This model doesn’t hold in an Agile environment, where information flows top-down, bottom-up and, through the use of tribes and communities of practice (COP), side-to-side. In this context, the EA team does some translation but it also takes the role of guide and storyteller.

In such a context, the EA team:

• Helps translate business strategy to technical strategy, forming an essential bridge between leadership and relevant engineering teams.
• Facilitates the software-design process followed by Dev teams making sure that non-functional requirements, from groups like Security, Compliance, and Risk, are met.
• Consults Dev teams on architectural choices, including scaling, security, compliance, tools, and languages.
• Curates and facilitates the exchange of information.

The image below reflects what happens in a modern set up:

Business strategy, on the left, passes through the organisation, where it is translated into technical strategies, which ultimately deliver business outcomes. However, there are clear feedback loops and space for groups to constantly improve the design of their systems through the use of continuous integration.

But, this model doesn't show how the EA team evolves over time, and in particular the changes that need to happen when a company moves to the cloud.

In early stages, the EA team is a partner and collaborator, helping Dev teams make the right choices and map the world. There are some typical humps to get over here, such as understanding that applications for the cloud have to be architected differently. As the organisation’s cloud capability matures and designs become consistent and repeatable, the EA team is expected to take a much more instructive position and enforce architectural principles more strictly. This change can be quite subtle, and a common mistake is to think that an EA team can take a “one size fits all” approach.

Next task — mapping the world

One of the biggest challenges, when becoming more Agile, is achieving speed at scale without sacrificing security or reliability. Cloud Native teaches us you don’t necessarily have to trade these things off anymore. Instead, you can achieve reliability through speed, rolling back changes or rolling forward with fixes, in a fully automated manner. This does not come “out of the box” however. Instead, there are three key—and related—building blocks:

• Easy Access to Information. It’s impossible to move forward if you can’t build on the lessons of the past. When you become Cloud Native, you learn from both failures and successes, which you then document. Easy access to these lessons is vital if you are to both move quickly and innovate at scale.
• Self-Service Everywhere. The general rule here is to never send a person to do a machine’s job. Documents are essential but automation is even better. Self-service portals not only help with labour-intensive work, they also let us do things in a repeatable and safe fashion, giving us standardisation across the organisation. Importantly, they reduce handovers, in many cases, to zero.
• Light-Touch Processes. Processes are vital but they have to be right-sized, neither too big or insufficient. In this way, you can move quickly but along guardrails that protect you. They also reduce bureaucracy and, in the case of Cloud Native at scale, let individual teams act autonomously.

So what is your first step?

Without a map, a cloud migration will be hard to navigate, and thus the first major task for the EA team is to create reliable and extensive maps of existing and future landscapes.

Transformation has to be holistic and cover all the relevant dimensions.

Change starts from the core, with a strong strategy and vision, where you design the future you want to create. Change then moves in increments as you build new systems, teams, and processes.

Because all the dimensions interact, they all have to be monitored in relation to each other. For this purpose, the EA team identifies the dimensions of change and should explicitly define the milestones for each to make sure stakeholders and leadership have a clear understanding of the current state of the migration.

Based on these dimensions of change, the EA team can create a partial view of the future cloud world and continues working on extending the map in all the dimensions by ongoing engagement with various leadership and engineering teams

How the EA team works

The EA team should be embedded as part of the core of the SDLC process. It should take as light a touch as possible, whilst making sure any regulator is satisfied. In addition to architecture and design reviews—and to reduce unnecessary bureaucratic burden—the process should coordinate additional in-depth reviews by Security and other non-functional teams.

Every new product, project, initiative, and tech policy should have to pass the EA review process. The process needs to be designed to help teams both clarify their thoughts and have an opportunity to consider the future impact of each solution. The process needs to enable and not hinder. A typical EA review process might be comprised of five steps:

Below, you can see we have documented how to engage with EA:

From the left, you can see the various major steps. All the development activities need to be supported by approved design documents and all major diversions from the approved designs may trigger additional incremental design reviews. The process works as self service and it lets people contribute asynchronously, which is essential for scale.