Executing Transformation with Solution Architecture - Best Practices in Agile Environments

The State of Enterprise Architecture

The conversation between Paul Estrach and Carlo Ercole starts with a brief discussion on the state of enterprise architecture. According to Carlo, enterprise architecture is becoming increasingly complex and there are three main reasons for this complexity.

“The first reason is that we work with a business to achieve value for the customer. This is not easy. We need to move between different business architectural topics. The business value, the customer journey, and business capabilities can change incredibly quickly.”

The second reason has to do with technology. Technology is changing rapidly, and enterprise architects need to continuously adapt to these changes.

The third reason for the increased complexity of enterprise architecture is the growing complexity of organizations themselves.

“Our organization is complex - like all organizations in our sector are. Right now, we are in a situation where we are highly regulated. Our internal organization is working in every way because we have on one side agile products and on the other side we have major initiatives, programs, and projects. So, we need to balance these two dimensions. I think that right now we are seeing a lot of organizations that are moving more and more in a situation where we have flexible humans inside an inflexible, fragile IT system. This is complex to manage.”

Critical Areas of Enterprise Architecture

Carlo Ercole believes that enterprise architecture is essentially how we model an enterprise’s landscape. There are areas enterprise architects need to concentrate on.

“Try to focus on the things that are hard to change or to remove. This can be an application, an application system, or a small detail in our architecture. I think that enterprise architects in general need to do this in at least four different ways. One of these is forecasting. This means that we know what will happen and we need to react in a good way.

The second one, I call ‘backcasting’. We know that we have an intentional architecture, we know our vision, and we need to define the steps to arrive there.

The third thing is essentially uncertainty planning. We need to plan for something that we don't know right now but that will happen. I’m thinking of the Covid period in general. We need to plan for situations that we don't expect. It about strategic agility. As business strategies can evolve very quickly, our architecture needs to be ready to change. One of the main architectural KPIs that we want to take into consideration is this changeability level.”

Achieving Strategic Agility

The point is how can we achieve this strategic agility?

“We need to collaborate with all the different roles that we have in our company. We call that federated architecture. This is what we try to concentrate on in the modelling part. We prefer modelling to documentation. One picture is better than a thousand words, so we need to focus on architectural decisions that are relevant and allow our architecture to be flexible and ready to change.

Another relevant aspect is to create a single source of truth at the end. Architecture should focus on the things that are going to change. In general, architecture needs to work to produce less architecture.

"This may sound strange…but when we start, we model everything in the company, then we realize that we need to model what is important because that will allow us to change in the future very quickly.”

The Importance of Modelling in Managing Transformation

One of the key success factors Carlo mentioned for federated architecture is related to models. Which models are mandatory for solution architecture, and which ones are recommended?

“Without the modelling part, we don't know what we have. The most relevant part is to know what the relationships with the things that are hard to change. In terms of modelling, what is mandatory is to know our application and how this relates to what need to change.

We also need to know the business process and the business capability part, i.e. where these components live in the business architectural part. I also think the data is important. We need to know the data, our data semantics, the modelling itself and the data lineage: where the data is moving in the enterprise landscape."

The third part is the architectural decision. We need to track all the architectural decisions that we take because this is the only part that allows enterprise architects to be ready for a new flexibility model in the IT landscape.

"In relation to the optional part, we have the product team. What we expect there is autonomous modelling, autonomous guidelines. We try to recommend at an enterprise level, but we don't force them to work in a synchronous, common way. We recommend having all the functionality and use cases, and to model data because they are an essential part of the business architecture.

We also ask to try to model the dynamics of the system: how the components interact together. We use, for example, a surface diagram or a similar model. It is also important to be ready when someone new joins the product team. They need to have documentation that will be relevant to the specific boundary context. In this way, they can try to approach what we call Architecture as a code.”

The New Challenges for Solution Architecture Modelling

According to Carlo, there are three major challenges for architectural modelling. The first one is cloud modelling.

“We have new cloud services, and we need to understand how to model those services in our applicational landscape. The second one is infrastructure as a code. This means that product teams need to know their architecture. They need to apply architectural modelling in this boundary context so they have a specific point of view. But at the enterprise level, we also have another objective. We want to have a helicopter view, i.e., having an overview of all the systems in the company. Balancing these two requirements is not easy."

The third challenge is how to model microservice architecture and real architecture. This part is very complex, it is important to concentrate on what is hard to change. This will be a major pain point we must solve.

Aligning Enterprise Architecture and Solution Architecture Practices

The last question discussed by Paul and Carlo is how to be sure that enterprise architecture and solution architecture practices are aligned. According to Carlo, federation is the key factor.

“We want to do the best architecture in the local dimension and the best architecture in the enterprise dimension. As for local architecture, solution architects in our company need to be responsible for application systems. So first, we need to have the application system clear in our minds.

Making sure that one Solution architect responsible for the application system is key. Their responsibility will be to make sure that the local architecture can evolve with the proper steps versus our target architecture. This is one of the critical points. Then they need to maintain the model because everything evolves inside the local team. They also need to find what will be very difficult to change because, essentially, this is our objective. Their responsibility is to find the architectural decision that we need to discuss.

At the enterprise level, it is a bit different because we need to follow our business strategy.

"We work together on a strategic review board. This is the next step in our intentional architecture. We need to plan our roadmap for the future. We try to provide guidelines for our solution market to work this way. And, of course, if we have a situation where we are not able to decide at the local level, we start the escalation process to move those decisions to the strategic review board and work together to try to find the best solution for the company.

"In this way, we can achieve flexibility and be ready if the business changes strategy. Using this approach, we can create a robust system that is good for continuity and security. We also try to focus on efficiency because we need to have a system that is good from a cost point of view in the dev ops practice. Having a flexible system makes it possible to be ready to change. Choosing models over documentation ease collaboration because one picture is better than a thousand words.”