Agile Enterprise Architecture Management
Rapid innovation ensures that the enterprise can remain competitive through innovative solutions that are delivered quickly and flexibly. The key is to align enterprise architecture management and agile working methodologies so that they are mutually enabling.
This blog shows approaches for decision-makers who want to make their company fit for the future and secure a competitive advantage. We focus on how enterprise architecture management can be strengthened in an agile environment to fundamentally improve digitisation in the company.
Enterprise Architecture Management as an enabler for rapid innovation
Enterprise Architecture Management (EAM) is an important pillar for companies to implement the digital transformation. It describes the interaction of the company's business processes and IT technology at the highest management level.
The Enterprise Architecture (EA) is supported and shaped by the enterprise architects of the company and creates a holistic view of the different architecture areas:
- The business process architecture, which shows the business process modelling.
- The information and data architecture with its relationships, which are required for the execution of the business processes and are recorded in the data model.
- The application architecture (also called software architecture), which manages the applications for the execution of the business processes and their interfaces.
- The technology architecture, which defines the structure and operation of the IT infrastructure.
- It makes sense to complement these basic architectures with the security architecture and the operational architecture.
Figuratively speaking, enterprise architecture is not only the blueprint, but also the highway to the construction site of digitalisation. Integrating innovations into the existing corporate landscape is cheaper, simpler, less risky and, above all, faster. The prerequisite for this is a well-functioning EAM.
Challenges in an agile environment
Enterprise architects are tasked with ensuring structure, stability, standards, methods and compliance. Recognising new technologies and trends plays just as relevant a role as digital roadmaps, pace layering or big-picture perspectives. This is a challenging task in view of technological change and the ever faster spiral of innovation.
With the advent of Scrum, Kanban and DevOps and the many agile interdisciplinary teams, the challenge for enterprise architects to maintain an overview and fulfil their mandate is growing in order to avoid uncontrolled growth and isolated solutions. From their traditional role, enterprise architects are more used to acting in the background and intervening when a solution or architecture does not correspond to the enterprise architecture. As a result, they are often even perceived as preventing solutions from the project and development point of view. Projects develop solutions and are then shortly before or already in implementation and then have to pause or adapt them because they do not fit into the big picture. In the agile context, the danger of losing the overview of the individual teams and thus the overall view increases greatly and leads to additional work and loss of time.
Agile teams have the need to remain as lean and autonomous as possible in order not to lose momentum in a multi-layered web of dependencies of micro-services and spaghetti API structures. It is increasingly difficult for them to implement complex changes, as work has to be done on several components at the same time. As time goes on, cross-project solutions take a back seat and framework conditions are sometimes forgotten. In addition, solution architectures do not exist at the beginning in the agile environment; due to requirements, they are only developed later and iteratively in the project.
Proposed solutions in the agile environment
The key is therefore to be able to accompany and coach the complexity in the company. For this, the discipline of enterprise architecture must be understood as a link that connects the various changes. The enterprise architects support these changes by helping to minimise the dependencies and thus maintain the dynamics of the agile teams.
The enterprise architects must adapt to the agile approach in the projects and also be agile. In concrete terms, this means that they must actively and iteratively support the agile teams in the course of the project in order to develop a solution architecture. They also always act in terms of the big picture and contribute their know-how and solution proposals constructively. To this end, the enterprise architects must perform their task more communicatively, i.e. convey the message of the enterprise architecture more actively in the form of models, architecture principles, and make it more comprehensible and communicable.
Consequently, the enterprise architects are integrated into the projects and agile teams. For larger projects, it is advisable to create a technical solution board (with EA, system engineering, security, development) in addition to the technical solution board (technical committee) according to the same principle, in which solution proposals are jointly exchanged and decided. This exchange is important for mutual understanding and a constructive approach. For smaller projects, this can also happen within the framework of an overarching Technical Solution Board. Actually, this could also be controlled via the requirements, but the important interactive exchange on the architecture is often lost, as the product owner is usually purely technically oriented and focused on business value.
Ensuring IT efficiency and business value
An important principle is that all IT projects must add value in both dimensions (i.e. both business and IT). On the one hand, the projects must have a business benefit, i.e. fulfil a certain business case from the company's point of view, but on the other hand, the project must also increase IT efficiency (operational optimisation, development efficiency, easier integration, etc.). From the IT point of view, this avoids projects with technical debts that later end up in time-consuming and expensive clean-up operations.
To ensure that the further development of the IT landscape is continuously increased in terms of IT efficiency and business benefit, the coordination model of managed evolution (see figure) can be used.
On the one hand, solutions that are too idealistic and therefore hardly realisable (to die in beauty) from the point of view of IT efficiency, which cause too high costs in implementation and thus ruin the business case, should be avoided. On the other hand, it is important to avoid solutions that are too pragmatic (quick and dirty), which promise a quick business benefit but are difficult to operate from an IT perspective or have to be replaced again shortly. The evolution channel should help to maintain a long-term balance between the two dimensions of IT efficiency and business benefit.
This is ensured in the project mandate by the projects. These must be able to demonstrate not only a business case, but also IT efficiency. The same applies to a technical solution board, which must argue in both dimensions.