Agile Enterprise Architecture Management

Agile Business

Digitalization is taking place in two main areas of companies: in the product development of "smart" products and in the company processes themselves. For example, in the optimization of production (the digital twin or Industry 4.0 send their regards) or in partnering, the cooperation with other companies to provide new services and products.

Products become "smart." By adding new technologies, drills and cordless screwdrivers are becoming intelligent, adapting their operating parameters to current conditions and reporting consumption values and wear and tear. Manufacturers are now offering services alongside the machines themselves, which promise to service the machines before they fail.

Cleaning machine manufacturer Kärcher, for example, plans to rent out machines and charge only for the square meters cleaned, which are measured directly by the machines. Another scenario is to offer the building cleaner usage information of the elevators of buildings processed, to forecast the soiling of the individual floors, so that it can be decided whether and with what expected effort individual building areas are to be cleaned.

The following characteristics of digitalization can be derived, which are essential for our consideration:

• The digitalization of products is significantly changing the skills required in a company. The manufacturer of cordless screwdrivers, which now builds "intelligence" into its products and offers new services with the help of the data from the devices, goes from being a pure machine tool manufacturer to a concrete IT service provider.
• The specialist departments are increasingly acting as technology drivers. Especially in product design, it is important not to lose the market connection through more innovative products and especially "smart" services. New technologies, new products and synergies with other companies want to be developed and evaluated. The times when the introduction of new technologies is planned and introduced by the enterprise architecture from long hand are over. For their part, the business side is now approaching the enterprise architecture and presenting it with new challenges. And not only that - they are increasingly knocking on the enterprise architects' door. Business units are thus influencing an ever greater share of IT spending. According to a study by PWC, it is already between 30% and 70%.
• The cycles in which products or services change or new technologies are introduced are becoming shorter and shorter. The desire for an agile way of working is, and this is not really surprising, also increasingly expressed by the business side. This new quality of change, especially coupled with its frequency, poses major challenges for IT. Processes are proving too cumbersome and inflexible. IT's production systems are often not designed for short release cycles. A good example are the provisioning systems of telecommunication service providers, also known as Operations Support Systems (OSS), which have grown over decades and are designed, operated and managed with the goal of the highest possible stability. To deliver products, these systems are often adapted, resulting in long lead times and release cycles.

Even if business departments and product management are able to design new products and bring them to market in record time, these advantages only take effect with a technical provision that can keep up with this speed.

"Stay in the race" und "Win the race"

The term "bi-modal" IT introduced by Gartner is thus an intermediate stage, but not an end state. IT currently has to maintain a balance between the stable operation of a company's most important infrastructure and systems (stay in the race) and the ability to respond promptly to the increasing demands from the business side and make them available productively (win the race). The target scenario and absolute dream of every product manager is a release-on-demand scenario in which new products and changes can be provided on an ad-hoc basis.

How do companies meet these challenges?

According to a study conducted by DETECON in cooperation with Bitkom, companies expect the main organizational changes to take place in the following areas in the future: IT, Service, Production, Sales, Logistics. In that order.

But organizational changes alone are not enough. The challenge lies in creating the agility that is now needed in the company and which allows the innovative power of the specialist sides to be brought onto the road in good time.

Agile IT

Without going into the details of agile methods in this article, it must be acknowledged that the benefits of agile methods have been recognized. With the help of agile methods, one moves away from the classic phase model of requirements conception-specification-development-test-acceptance.

The key driver here is the ability to know the status of the project in short cycles and to be able to make changes at short notice. The risk that the client only realizes at the end of the project that he is not getting what he needs is eliminated with the help of agile methods.

For IT, agile business has the following consequences:

• high rate of change from different areas of the company
• higher demand on the flexibility of systems and processes. a new or changed product will also be processed through the company's core systems (system of records) at some point in time
• the architecture function must be represented in the agile teams. if not in the form of constant presence, at least at key planning and review meetings
• an increasing degree of coexistence of agile and waterfall methodologies
• technical delivery must adapt to shorter delivery cycles. Release on Demand and Continuous Integration tend to have a significant impact on the way technical delivery is done. It is through them that agile approaches begin to have their desired impact on the company's bottom line.

The maturity level in enterprise architecture, as we notice in our TOGAF training courses, has grown strongly in recent years. Enterprise architecture management (EAM) has arrived in companies, tool-supported architecture management improves knowledge of systems and infrastructure and facilitates the planning of projects.

Reach is the key

However, a high level of maturity of enterprise architecture management practices does not necessarily lead to better impact. This can be achieved primarily by improving the reach of architecture management. By reach, we mean here the sphere of influence of enterprise architecture. Does architecture work take place only in a small, "illustrious" circle or is there a far-reaching possibly even collective understanding of enterprise architecture? It is assumed that the typical scope of architecture management is about 10%. As a basis for a decentralized decision culture, this is too little.

Besides acceptance, a large reach or scope is one of the main concerns of an EAM.

The classic enterprise architecture structures with their standards, committees, processes, and forms are intended to ensure that the right architecture for the respective context is applied everywhere in the company. All decisions - especially critical ones - are channeled and decided centrally.

The need to guide architecture decisions through central processes has the undesirable side effect that enterprise architecture is often perceived as an "impediment" or "brakeman" and accordingly has to do more convincing to achieve the "right" results.

For the business sides that proceed according to agile methods, direct access to the enterprise architecture is of high importance. Development in short cycles is ideally accompanied by representatives of the architecture, who set the technical guard rails and help to enable the feasibility of changes quickly and in a compliant manner.

However, it is not possible to provide every project with a suitable, dedicated architect. There is usually insufficient organizational strength to do so. In addition, the topics in the individual projects are too different and usually require special knowledge in the case of innovation projects. Nevertheless, in view of the aforementioned scope of enterprise architecture, it would be ideal if the teams had architectural expertise.

Feature of agile approach: decentralized decisions

An important feature of agile methods is the teams' own responsibility. They decide and prioritize the tasks themselves, which are carried out in the upcoming development cycle.

The fact that decisions are made where the necessary expertise is located speaks in favor of decision-making authority in the teams. Teams organize themselves and get access to the expertise they need. This is one of the reasons why the high availability of the role of the product owner is so important in SCRUM.

When it comes to enterprise architecture issues, the situation is usually somewhat different. Here, the primary concern is conformance and processes that must be followed. Thus, enterprise architects are not useful as permanent members of a SCRUM team, for example.

Architectural Thinking

Architectural thinking describes a collective understanding of architectural quality. The aim is to establish as far-reaching and uniform an understanding of "good" architecture as possible within a company. Of course, this applies all the more to those areas in which architectural decisions are to be made.

A comparison with topics such as waste separation and seat belts in the car suggests itself - in some countries, these take place almost unconsciously, or it is immediately noticeable if they do not take place. You feel uncomfortable when you have to dispose of the yogurt cup to the tea bag on vacation because there is only one trash can; or when the cab driver doesn't wear a seat belt. There is a collective consciousness of right and wrong here.

Similar to how there is a collective idea in the company for a "good product", such as "a good cordless screwdriver", the term Architectural Thinking describes how the understanding of a "good architecture" is established.

According to Prof. Dr. Aier of the University of St Gallen, Architectural Thinking addresses employees outside of enterprise architecture with the goal of understanding enterprise architecture concepts and plans and empowering them to act accordingly.

Formalized and committee-driven architecture management should only take effect when local, autonomous decisions are no longer sufficient. This would be the case, for example, in projects in which work is carried out across several parts of the company and architectural decisions have an impact on areas outside one's own area of competence.

The concept of Architectural Thinking is therefore not a replacement for traditional EAM, but rather a concept for increasing its scope or enlarging its area of influence.

Architecture Domains

Another way of increasing and controlling the scope of the enterprise architecture is offered by the concept of architecture domains. It divides the enterprise architecture into segments/domains, places domain architects there and equips them with decision-making authority. This brings several advantages. Architecture thus takes place closer to the point of action.

The scope of enterprise architecture is now reduced to regulating how the domains deal with each other. While the domain architects each act autonomously, cross-domain actions are governed by rules and standards determined by the enterprise architecture.

The latter benefits in particular from the above-mentioned circumstance that innovations and technologies are domain-specific in each case. While the topics of IOT and analytics dominate in product development, for example, cloud services dominate in the area of back-end systems. The domain architects are thus experts in the topics typical for their respective domains.

Domain architectures and the role of the domain architect can already be found in many companies. However, both are usually still controlled by a central architecture management. What is new about the idea presented here is the autonomy of the domains while at the same time de-cluttering central architecture management and cultivating a collective understanding of "good architecture".

Scaling Agile Methods

It is now well known that agile projects are difficult to scale. Particularly in companies that exceed a certain size, conflicts arise with established processes and committees. For example, a detailed plan of the overall project must first be available to determine costs before the project budget can be approved. This is not feasible for agile projects, which do not know in detail at the beginning of the project what will actually be delivered at the end.

Scaling agile methods to program and portfolio levels is addressed by the Scaled Agile Framework SAFe, among others. SAFe is the most widely used framework and is constantly being improved by a large, active community by incorporating insights from everyday practice.

A discussion of this framework is beyond the scope of this article. However, it is worth taking a look at the role of enterprise architecture in this framework.

 

Summary

Agilization, digitalization and technological innovation pressures are increasingly coming from areas outside IT, increasing the pressure and placing higher demands on the ability to deliver. The central processes and bodies that are supposed to ensure a uniform design of the enterprise architecture are proving too cumbersome and obstructive.

Decentralized decision-making authority in architecture topics would relieve the situation. The EAM function is particularly affected by the lack of architectural knowledge, and it is generally not possible to provide personnel support directly in the projects.

Establishing a collective understanding of architecture (architectural thinking) in combination with the support of domain architects establishes local decision-making authority and enables the central EAM to be streamlined. If the provisioning systems are enabled in parallel in the direction of release on demand, the prerequisites for optimal support of agile projects are created.