„When the rate of change increases to the point that real time required to assimilate change exceeds the time in with change must be manifest, the enterprise is going to find itself in deep yogurt.“ (John Zachman: Enterprise Architecture, The Issue of The Century, 1997, p. 1)

Norbert Gronau, Chair of Business Informatics at the University of Potsdam, describes a corporate architecture as the structured and coordinated collection of plans for the design of a company’s process and IT landscape. The definition does not contain any of the buzzwords that analysts and consultants nowadays like to use. Nevertheless, it is part of every modern IT project, since corporate architectures must always be taken into account when IT changes are made.

Whether service-oriented architecture (SOA), big data, cloud service, virtualization, Internet of Things, Industry 4.0, robotic process automation (RPA) or artificial intelligence, the consideration of the associated architecture was and is always relevant. Only then can a company ensure that – to paraphrase John Zachman – it is not “in the yogurt” and controlling change. Architecture management is part of it, whether you call it that or not.

The term „digitization“ is expressly excluded from the above list. It’s hard to see what’s really new about digitization, after all we’ve been digitizing since the 1960s. The introduction of the first ATM in Germany in 1968 and the start of the nationwide expansion of its network based successor from 1978 onwards changed the business processes and IT architectures of banks more extensively than some trend topics today marketed under the buzzword digitization. The professional and technical changes required to set up and operate the more than 68,000 ATMs in Germany would have been unthinkable without comprehensive architecture management.

Therefore, the theoretical background is not new. As early as the late 1960s, Duane Walker at IBM developed a formalized approach to architecture management using the Business Systems Planning (BSP) method. Frameworks based on this, such as PRISM, Zachman, NIST, EAP, TAFIM and TOGAF, followed in the succeeding years. Actually, architecture management should have established itself over the past decades with advances in theory and tools. Sadly, this is not the case. The following situations still occur too often in daily practice in companies and administrations.

As part of the introduction of company-wide standard software, no up-to-date documentation of the interfaces with third-party systems, including the technical data structure, can be found. When creating a business continuity plan, the relationships between information, IT systems and business processes are not available, although some stuff has already been documented within the GDPR efforts. The Process Mining project encounters an unforeseen „rockfall“, since the information provided by the software unfortunately only shows half of the truth if it is not linked with analog process steps. In the RPA project, everyone „builds“ their own service, which means that a confusing „zoo“ of automated mini-activities obscures the overview between processes and connected IT solutions. Everyone in the IT business knows similar situations. They all have one thing in common: the architecture management failed. This creates the question, why is it not given a stronger position in many companies?

Unfortunately, one has to say that architecture management is not innocent. Too often unnecessary detail has been imposed and practical needs ignored. The time when this form of architecture management could be continued is finally over. Based on seven changes that build on one another, it can be shown which changes architecture management is exposed to and how it can best react to address them:

1. Content: from a global to a project-related view
2. Detailing: from rigid to flexible methodology
3. Topology: from island to grid
4. Description: from graphic to abstract representation
5. Collection: from manual to automatic collection
6. Visualization: from modeling to generation
7. Tools: from suites or best-of-breed to hub-and-spoke

Content: from a global to a project-related view

The idea of using an enterprise architecture to create a comprehensive description of an organization and to plan and control its holistic development was the primary goal in Architecture Management for a long time. Whoever thought holistically, had in mind not only the content related to the IT architecture but also operational and fundamental strategic aspects. This required a global view of the entire organization. The approach, which is laudable from a theoretical point of view, has one major flaw. Due to the demand for global documentation, there are constant conflicts with individual projects that require content from Architecture Management. From the point of view of a project manager, the comprehensive, organization-wide and globally correct recording, documentation and updating of an enterprise architecture is irrelevant in case of doubt. Projects are under time pressure and have to deliver a defined result in a specified time with limited resources. On the other hand, there are the architecture managers, who have made it their task to bring all relevant company content into a global context. Most of the time, this position represents an unbridgeable obstacle for project managers, as they are measured by the timely completion of their project. Architectural management as “science in an ivory tower” is ignored at best, fought against as an unnecessary waste of money in the worst case. This situation is fatal because both sides are right in their own way. The projects, because it is not their job to deal with basic strategic orientations and the Architecture Management, because it pursues the goal of accompanying the long-term further development of the organization in the best possible way. Over the years, the projects have mostly “won” in this area of tension. You have to solve concrete problems of day-to-day business and deliver an operational effect in the short term that shows up quickly. The positive effects of building an integrated architecture will only become visible in the future and are lost in the hectic, number-driven corporate world. And not just since agile methods shifted the focus to results and user acceptance.

Architecture Management must respond by acknowledging that projects are the drivers in day-to-day business practice. In the future, the central task will be to consolidate, link and, where necessary, supplement documented content within the environment of projects. Architecture Management is therefore primarily responsible for providing the „glue“ between the project-specific content. This has consequences for the methodology used to detail content.

In the future, projects will be the primary sources for content in Architecture Management and will essentially control the content orientation.

Detailing: from rigid to flexible methodology

The conventions that are defined are essential for capturing the content of an architecture. The architecture framework TOGAF lists within the „Architectural Artifacts“ which content should be recorded in the domains of business, data, application and technology architecture, but does not provide any assistance on how to do this. Architects are therefore faced with the challenge that there are specifications as to which content is to be documented, but only little information is provided on how this is to be done. From a practical point of view, this is understandable, because in addition to the general goal of designing and controlling the (IT) landscape of an organization with the help of Architecture Management, the individual requirements usually differ significantly. Universally applicable specifications are difficult to formulate. For example, Architecture Management in an industrial company that has grown over many years has completely different demands than a young Internet start-up. As a result, every company has to answer the question Rob Davis asked in his „Generally Accepted Modeling Principles“: „Know when you have done enough“. However, that’s easier said than done. Because with the aim of controlling the overall development of a company, many resort to the classic approach, which requires a uniform and comparable description of the architecture throughout the organization. This is accompanied by mandatory uniform specifications with regard to detailing. These must be adhered across the documentation within the company, regardless of whether they are required in the context of the specific project situation or not. Only then the classic approach works and allows to compare different domains within the Architecture Management. The problem here is that the documentation effort increases exponentially with the level of detail. The basis for failure is laid with the requirement to observe the global specifications for capturing the architecture in every project. Projects are usually only interested in observing the requirements of Architecture Management if they are in line with their individual information needs. For reasons of time and money, a global perspective cannot usually be pursued through a project. Projects have little interest in helping the Architecture Management to collect or update content beyond the actual information needs. Rather, they define their own methods and notations that best support the project goal from a time, quality and cost perspective. If these do not correspond to the specifications of the Architecture Management, this is usually accepted with approval from the responsible stakeholders. The fact that projects with individual methods and notations will dominate the shape and scope of enterprise architectures in the future may not please everyone, but it has to be accepted.

It is irrelevant which of the enterprise architecture domains is considered. For example, it makes no sense to fully describe all of a company’s business objects down to the technical data structure if only individual content is required for an application migration project. But even if you look at Architecture Management from a high level, it becomes clear that the flexible detailing of content contributes to efficient implementation. Nobody will create a detailed description of the communications of each instance of application software on various devices. But the relationships of the associated server communication is probably important. This is particularly evident for process modeling within the business architecture. Who doesn’t know endless process overviews with endless levels that took months and sometimes years to create. They often contain descriptions of work down to individual steps that can no longer meaningfully be broken down. Is this kind of process documentation really widely used in companies? My experience is it is not. There are cases where up to 80% of the recorded content is used little or never at all. At best, an auditor checks it once a year whether everything has been properly written down. But is this approach worth the effort to create and update the model? The argument for this approach is often that infrequent work processes can be carried out more securely or that new employees can be trained more quickly. That’s correct. But if you consider the exponentially increasing effort for documentation and continuous maintenance of this material, in combination with the low frequency of use, this approach can no longer be justified.

As a consequence, there is a requirement to variably adjust the content created in individual projects with different levels of detail. Modern Architecture Management combines the content of each individual project into a whole.

Documentation created according to a fixed specification is becoming less important and is being replaced by variable documentation with an individual level of detail.

Topology: from island to grid

The shift from a global to a project-based approach, in connection with flexible and individual detailing, inevitably increases the heterogeneity of the recorded content within an architecture. The combination of project-specific focal points with different content in the domains themselves leads to a heterogeneous documentation. For example, a project for the technical optimization of order processing primarily provides content of the business and data architecture from the receipt of the order to the delivery of a product or service. Other technical areas of business and data architecture are most likely not included because they are simply out of scope. It becomes clear that a focus on projects leads to a fragmented description in the form of individual „architecture islands“. But hasn’t it always been the task of Architecture Management to combine individual approaches in an integrated architecture? That’s right. However, this was mostly done using an approach based on globally specified methods and notations. In theory, the „old“ way is correct, as it leads to a description that is as homogeneous as possible. Unfortunately, due to the usually high documentation effort, it only works inadequately in practice. To make matters worse, projects are increasingly specifying what should and shouldn’t be documented. This forces Architecture Management to merge different content. Operationally oriented projects only follow general architecture specifications up to a very limited extent, which impede agile and efficient processing. Inevitably, increasingly heterogeneous descriptions are created, which a modern Architecture Management must consolidate, integrate and prepare for evaluation. And that with a simultaneous loss of control over the underlying methods and notations for detailing.

The conclusion is, that the classic approach of capturing the architecture domains of an organization globally and with rigid methods and notations is no longer up to date. Rather, modern Architecture Management is required to consolidate and relate content in a project-related and flexible manner in the form of a network. In order to implement this, the complexity of the documentation, the automation of the collection and a focus on the generation of graphic visualizations needs to be addressed. At the same time, there is the possibility of using free software to a greater extent, which means that a cost reduction can also be achieved. We take a closer look at these options within the following points.

Due to the need to link project-specific content, Architecture Management is evolving from the creator to the integrator of an organization’s architectural knowledge.

Description: from graphic to abstract representation

Various content types must be considered when capturing the business, data, application and technology architecture. The business architecture describes, among other things, processes, organizational structures, roles, geographic structures, business services, performance indicators and goals of an organization. In addition, the data architecture also considers conceptual and logical data structures, data security aspects, migration information and content relating to the life cycle of data. The application architecture describes the application landscape, technical communication relationships, internal functional structures of the applications and externally offered technical services. The technology architecture documents the technological standards used and the associated hardware portfolio as well as network and low-level communication relationships.

The list does not claim to be complete. However, it shows that there is a wide range of content to be described in Architecture Management. Figure 1 shows a possible ontology for defining the associated object types and relationships. For example, the question of which business processes and users are affected by the failure of a specific piece of hardware can be answered by taking a comprehensive look at the technology, application, and business architecture. In the example ontology shown, the cells „Roles/positions“, „Sub-processes/detailed technical processes“, „Special applications/logical interfaces“ and „Infrastructure instances“ and their relationships are to be evaluated. In classic Architecture Management, it is common to model this content graphically in form of diagrams. A large number of different notations are used for this purpose. TOGAF alone defines 18 core and 16 extension diagrams to describe the business, data, application and technology architecture. Together with the ArchiMate notation, both standards from the Open Group, graphic visualizations are often created through these two standards alone. In practice, additional content, from unstructured text to graphic representations, often has to be consolidated into the architecture description as well. The comprehensible heterogeneity means that content has to be consolidated in order to create an integrated overall picture of the architecture. If notation-specific aspects have to be taken into account in addition to content, the complexity of the necessary harmonization and aggregation increases considerably. A better way is to work without the graphic documentation during the consolidation and to abstractly document the content without graphic representation. This only requires a meta-model of the overall architecture, which defines the content of the elements, the associated attributes and the relationships between the elements. Figure 2 shows an example of the transfer of process diagrams, organization charts, data models and application trees into an abstract model.

The (semi-)automatic documentation is considerably simplified by skipping the graphic representations, since it is no longer necessary to consolidate the visual representation as well. The focus is exclusively on the artifacts defined in the meta-model and their relationships. This approach allows to create a content-integrated overall model, detached from the specifications of graphic notations. Of course, graphic visualization is also very important for communication. We will come back to this.

The abstract, notation-neutral consolidation of all content in one model efficiently brings architectural knowledge together.

Collection: from manual to automatic collection

One of the biggest mistakes in enterprise Architecture Management is taking the term “enterprise” literally. It’s not about documenting the entire organization. Rather, only content that is required for the structured planning and design of the organization should be recorded. Architecture Management can only achieve this goal with justifiable effort if the underlying meta-model is able to provide the necessary insights. It is extremely difficult to define ex ante what content will be needed in the future. Many architecture projects deal with this situation in the form that meta-models are designed more extensively to be on the safe side and as a result more content has to be recorded. Just in case that additional information may be needed at some point in the future. Even if this approach is not very efficient, everything is fine as long as the existing capacities are able to carry out the required collection work. Most of the time, however, this is not the case and at some point “blank spots” appear in the database. This is a dangerous state for Architecture Management. Because if the meta-model promises more than it can deliver in terms of content, the user’s trust in the Architecture Management suffers. This situation must be avoided at all costs. This is where automation of data collection comes into play. Wherever possible, the content of the architecture model needs to be collected using an automated process. Figure 3 shows examples of sources that provide content for the abstract model. By following an approach without graphical visualization, the effort involved in “translating” the source data into the abstract model within the integration layer is significantly reduced. In some cases, the consolidation is only possible by skipping the graphic information.

This does not only apply to the initial recording. Long-term maintenance and updating also benefit from this approach. The life cycle of the architecture description from the creation, change up to deletion is much easier to automate due to the reduction on abstract elements and relationships. Since no graphic information is contained in the model, it does not have to be taken into account when the content is changed.

As already mentioned, however, the graphic communication of the findings of Architecture Management is indispensable. Even if it doesn’t seem so at first glance, the abstract form of documentation in an integrated model is also advantageous here. Required diagrams are easily generated.

Automatic processes for collecting, processing and storing architectural knowledge help to document and consolidate complex individual information in the long term with justifiable effort.

Visualization: from modeling to generation

Graphically presented information is more convincing than textual descriptions. Especially when the results of Architecture Management are shown at management level. Complex facts are communicated a lot easier via a graphical representation. The recognition of patterns, trends and connections can then be recognized much better. Browsing tables, on the other hand, is impractical because the human brain is much more engaged by good visualization than by text or numbers. Graphic representations make a decisive contribution to ensuring that results are understood and used beyond the boundaries of the Architecture Management itself. Good visualization is there for the best investment in long-term support for Architecture Management across the organization. But creating diagrams is a time-consuming task. As an example, let us consider process descriptions with the Business Process Model and Notation (BPMN) in a high level of detail. The BPMN notation allows workflows to be described exactly. For example, to design a system for automating processes in an IT solution. BPMN diagrams also provide valuable contributions as addition to contract documents when creating requirement or functional specifications as well as in the context of harmonization and optimization of processes. In case of doubt, a BPMN diagram is more consistent than a textual process description. However, some companies spend years recording and documenting processes, even though the results are later only required for a few topics. Then the company-wide documentation of detailed workflows with BPMN in Architecture Management is just a waste of money. The same applies to the other domains of Architecture Management. It is better to limit manual work for graphic documentation to the areas in which the creative intellectual power of a human brain is required for visual depiction. In all other cases, automatic generation of diagrams is preferable. Figure 4 shows an automatically generated Data-Application-Flowchart based on an abstract model, which was created including the layout with freely available software. The abstract storage of content in a database allows to create high-quality visualizations with the help of modern algorithms. This significantly reduces the effort in Architecture Management, in addition to the improvements already achieved through the automated recording.

You don’t even have to purchase expensive software to set up the integrated architecture model and automatically generate visual representations. The central functions can be implemented with free software alone.

Graphic visualizations are generated on the basis of an abstract model and are no longer manually designed.

Tools: from suites or best-of-breed to hub-and-spoke

As in other areas of computer science, there are often two opposing camps when selecting software for Architecture Management. On the one hand there are the representatives of the suite approach, which try to map the entire IT support of the Architecture Management with a single software solution. Gartner Peer Insight alone lists 29 different software applications that support enterprise architects and other IT stakeholders in the strategic planning, analysis, design and implementation of Architecture Management. But even if the manufacturers of enterprise architecture software claim otherwise, no provider has yet succeeded in bringing a software suite onto the market that is so comprehensive that it combines all the requirements of Architecture Management in one solution and meet the needs of all possible fields. On the other hand, there are the representatives of the best-of-breed, who use the most suitable software for different problems. For example, each has its own tools for the process modeling of workflows in the business architecture, data modeling tools in the data architecture and data center infrastructure management software for capturing the infrastructure architecture.

In practice, a mix of various tools occurs almost automatically. The operational areas of an organization will always use the tools for their work that allows them to fulfill their tasks in the best way. These are mostly specialized tools. As already mentioned, this situation is exacerbated by the fact that operational projects are increasingly the main suppliers of content in Architecture Management. The change from a global to a flexible, project-driven approach has had a massive impact on the tools used in Architecture Management. A hub-and-spoke approach is therefore required to integrate the various sources, which relates relevant content from various domains as simply as possible in a central repository, updates it automatically, reacts flexibly to structural changes and extensions, and enables the most comprehensive analysis possible. This is where native graph databases come into play, managing content directly in a network structure. Due to the schema-less design they are ideal as a central architecture repository. This simplifies the setup and long-term maintenance of a central architecture repository. In addition, the content linked by graphs offers comprehensive analysis and evaluation options. Another plus is that the mathematical analysis methods of graph theory and artificial intelligence are mostly build in. They can be applied directly to the architectural content and automatic visualizations are usually available out of the box. Figure 5 shows the content of a process management tool (in the example content from BIC Process Design) in combination with an integrated architecture model based on the graph database Neo4j. This enables analyzes that are not available with the original process management tool alone. These range from the identification of methodical optimization points right within the model up to the generation of End-2-End diagrams for the identification of critical process flows, application usage scenarios, interfaces or business objects from the point of view of the entire organization. By using artificial intelligence, these insights can often be derived without additional supplementation of the original data.

In addition, the standardized data structure allows content to be flexibly transferred to third-party tools, for example for reporting to JasperReports or Microsoft Power BI. Graph databases and statistical data analysis tools are often available as free or community version, avoiding additional licensing costs.

Schema-free graph databases and analysis tools enable individual architecture content to be flexibly connected, evaluated more specifically and communicated more easily.

The Neo-Enterprise Architecture – from building to refactoring

At first glance, it appears that the changes presented can only be fully implemented if Architecture Management does not yet exist in an organization. But this is not the case. Rather, the integration of the central architecture content in a hub-and-spoke approach brings advantages both with a „green field“, with partially existing architectures as well as with an already comprehensive architecture documentation. If Architecture Management has not yet been established in an organization, it allows a cost-effective entry on the basis of a lightweight foundation that can be implemented quickly. No expensive enterprise architecture tools have to be bought and the first results can be tested directly for their usability. If it becomes apparent that a specialized software solution for Architecture Management is required, essential work for its implementation has already been completed. If parts of the architecture content have already been collected but not yet comprehensively merged, the approach enables integration without a large block of costs. It usually turns out that the solution is so stable that it already allows comprehensive evaluations and can therefore be used for long-term operation. Additional investments in further enterprise architecture software can then be omitted. And even if a comprehensive architecture in an enterprise architecture tool already exists, the possibilities for evaluation are expanded considerably by integrating the content in a graph database.

It doesn’t matter whether an organization already practices Architecture Management or not. Anyone who actively tackles the changes in Architecture Management will definitely avoid – to paraphrase Zachman again – standing with both feet in the yoghurt.