Norbert Gronau, Chair of Business Informatics at the University of Potsdam, describes a corporate architecture as the structured and coordinated collection of plans for designing a company’s processes and IT landscape. This definition does not contain any of the keywords often used by analysts and consultants nowadays. Nevertheless, it is important for every larger IT project as the corporate architecture always has to be taken into account when the IT changes. But the risks need to be considered as well: Companies find themselves in a „deep yoghurt“ if the execution of change requires more time than the phase in which changes manifest themselves, wrote John Zachmann already in 1994.

Regardless of whether it is service-oriented architecture (SOA), Big Data, Cloud Service, Virtualization, Internet of Things, Industry 4.0, Robotic Process Automation (RPA) or Artificial Intelligence (just to name a few of the IT buzzwords of the last 20 years), considering the associated IT architectures was and is always crucial. Only when a company can handle this underlying architecture it is ensured not to get stuck “in the yogurt” and master change. Architecture management is an important part of it, whether you call it like that or not.

I deliberately avoided the term “digitalization” when listing the IT buzzwords above. I find it practically hard to identify what is really new about digitalization. After all, we are digitalizing our professional and private environment on a large scale since the 1960s. The introduction of the first ATM in Germany in 1968 and the nationwide expansion of its networked successors from 1978 onwards changed the business processes and IT architectures of banks more extensively than many current “hot topics” do. The professional and technical adjustments of the implementation and operation of more than 68,000 ATMs in Germany would have been unthinkable without comprehensive architectural management.

The theoretical background is therefore not new. Already at the end of the 1960s, Duane Walker at IBM developed a formalized approach to architecture management using the Business Systems Planning (BSP) method. Frameworks based on this groundwork – such as PRISM, Zachman, NIST, EAP, TAFIM and TOGAF – followed in the years after. Based on that architecture management should actually have become established over the past decades, with the many advances in theory and – in terms of tools – also in practice. Unfortunately, that is not the case.

The following situations still occur way too often in companies and government authorities:

• During the implementation of a company-wide standard software (e.g., switching to SAP S4/ HANA), no current documentation of the interfaces with third-party systems, including the technical data structures, is available.

• When creating a business continuity plan, the relationships between information, IT systems and business processes are not automatically documented and therefore not up to date, although they should already be provided as part of the GDPR initiatives.

• The recent process mining project ran into an unforeseen „rockfall“ because information “mined” by the software only contains half the story if it is not linked with analogous process steps and the overall process picture.

• In an RPA project, everyone “builds” their own “no code” services, which means that a confusing zoo of automated mini-tools emerge without a high-level overview between processes and the backend IT solutions. Controlling these “mini apps” becomes impossible at a certain point.

Everyone in the IT business is familiar with similar situations. They all have one thing in common: the architecture management didn’t work. This raises the following question: why isn’t there an integrated architecture management in place in so many organizations? Unfortunately, it has to be said that the architecture management is not innocent. Too often unnecessary detail was forced and the requirements of the operational business were ignored. But the times in which this kind of architectural management could be practiced are finally over. The following steps, which build up on one another, describe the changes architecture management is exposed to and how it can respond:

1. Content: from a global to a project-related view
2. Detailing: from a rigid to a flexible methodology
3. Topology: from islands to grid
4. Description: from graphic to abstract representation
5. Collection: from manual to automatic
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

For a long time, the primary goal in architecture management was to comprehensively describe the organization within an enterprise architecture model in total and to plan and promote its holistic development. This approach required not only to cover IT architecture but also business-operations and fundamental strategic aspects. In the end this often led to a centralized view of the entire organization.

However, the theoretically correct approach has a significant flaw: the requirement of a global documentation creates conflicts with individual projects that rely on information based on the architectural model. For a project manager, the comprehensive, organization-wide and globally correct identification, documentation and updating of the whole corporate architecture is often irrelevant. Projects experience time pressure and have to deliver a defined result at a certain date with limited resources. This is where architecture managers, having the mission to bring all of the company’s content into an overarching context, often get in the way.

In the best case, those responsible for the project ignore architectural management because they are driven by the timely finalization of their project. In the worst case, they sabotage their “colleagues in the ivory tower” and fight their approach as an unnecessary waste of money. This situation is fatal because both sides are right in their own way. The first drive the projects forward, the others are trying to ensure the long-term development of the organization.

In recent years project managers mostly “won” in this arena of tension. They had to solve concrete problems within the day-to-day business and deliver a short-term operational effect, which usually becomes apparent quickly. In contrast, the positive effects of building an integrated architecture will only be recognized in the future. Therefore, this is easily lost in the hectic, numbers-driven corporate world. And this is not only true since agile methods have shifted the focus to quick results, adaptive design and user acceptance.

IT architecture management must respond by recognizing that projects are the driver in the daily business practice. In future, its central task will be to consolidate, link and – where necessary – supplement project content. Architecture management will therefore primarily be responsible for providing the glue between project-specific content. This has consequences for the methodology used.

Conclusion 1: In the future, projects will be the primary sources of architecture management content and will essentially control the internals of the individual content building blocks.

Detailing: from a rigid to flexible methodology

The methodology defined as basis of the architecture design is essential for capturing content. As example, the TOGAF framework suggests multiple „Architectural Artifact“ classes and types to describe business, data, application and technology domains. But it does not provide any assistance regarding the best notations for practical execution. In consequence IT architects face a challenge that, although there are specifications what content should be documented, there is little information available how this should be practically done in a specific EAM scenario.

From a practical point of view this is understandable, because companies often only focus on the goal of designing and controlling the (IT) landscape with the help of an Enterprise Architecture Management. Even just from this reduced perspective, the goals often differ significantly. An industrial company that has grown over many years has completely different EAM requirements compared with an Internet startup.

This underlines that every company has to find its own definition of the postulate “Know when you have done enough”, set out by Rob Davis in his “Generally Accepted Modeling Principles”. However, that is easier said than done. With the goal of the overall development of an organization’s architecture in mind, many resort to the classic approach, which requires a uniform and harmonized architectural description throughout the entire organization.

And this is almost automatically accompanied by a uniform specification regarding the architectural detailing. This specification must then be adhered to across the whole organization when documenting architectural structures, regardless of whether they are required in the context of specific project situations or not. Only then the classic approach is feasible and a joint perspective on different domains within the architecture management can be derived.

The problem with this approach is, that the effort required for documentation increases exponentially with the level of detail. If a global specification is forced to be observed in every project, the basis for failure has already been laid. The reason for this is:

• project participants usually only pay attention to the requirements of architecture management if they are in line with their individual information needs. Due to time and cost reasons, a project generally cannot pursue a higher-level or a global perspective.

• project participants often have little flexibility to adjust their information needs with the “bigger picture”. Rather, they define their own methods and notations that support the project goals best from a time, quality and cost perspective. If these methods and notations are not in line with the global specifications of the architecture management, this is usually accepted (at least rather than jeopardizing the project goals).

Not everyone may like the fact that projects and the individual methods and notations used by them will determine the shape and scope of the overall corporate architectures in the future, but it must be accepted. And this affects all enterprise architecture domains. For example, it makes no sense to describe a company’s business objects in total down to the technical level, when only a specific application needs to be migrated. But even when looking at architecture management itself, it becomes clear that flexible detailing of content contributes to an efficient EAM implementation. Nobody has the resources to create a detailed picture of the communication relations of every application instance for various devices. But covering the relationships of associated server communications is likely possible.

This becomes particularly obvious when we take a look at process modeling in business architecture. Who doesn’t know the procedural “high-rise process houses” with their seemingly endless number of levels, which took months and sometimes years to create? They often contain descriptions of work instructions up to a final process step that can no longer be broken down in a meaningful way. In my experience, this process documentation is hardly used in companies. In other words, often a waste of time and money.

There are many cases out there in which up to 80 percent of the recorded content is little or never used. At best, an auditor checks it once a year to make sure everything has been written down properly. But is this approach really worth the effort to create and update the overall model? The argument for this approach is often, that rare process steps can be carried out more safely or that new employees can be trained quickly. That’s correct. But if you consider the exponentially increasing effort for documentation and continuous maintenance and compare it with the infrequent use, then this approach cannot be justified. As consequence, we need to merge the content created in individual projects with different levels of detail in an overall model. Modern Enterprise Architecture Management integrates the content of each individual project into a whole.

Conclusion 2: Enterprise architecture content documented according to fixed specifications becomes less important and is 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 conjunction with flexible and individual detailing inevitably increases the heterogeneity of the recorded enterprise architecture content. As a result, the project-specific focus of capturing individual content in various domains leads to a heterogeneous documentation.

For example, a project focusing on the business optimization of order processing primarily provides content for the business and data architecture from an “Order to delivery” perspective. Other architecture domains will most likely not be taken into account – in most cases due to time and resource reasons. This shows clearly, why a strong project focus will lead to a fragmented description in the form of individual “architectural islands”. But combining such individual approaches via an integrated architecture has always been the task of architecture management? That’s right. But this was mostly achieved by forcing people to comply with overarching enterprise architecture rules. Regardless of whether these meant additional effort for the individual projects.

According to theory, this „old“ way is correct, as it leads to a description as homogeneous as possible. Unfortunately, it does not work adequately in practice nowadays due to the usually high documentation effort. And it becomes even more problematic when projects increasingly define what should be documented and what not. This forces Enterprise Architecture Management to join different levels of content. “Real life” projects follow general architectural specifications only up to a limited extent, as these rules often hinder agile and efficient processing. Inevitably, more and more heterogeneous descriptions arise that modern architecture management must consolidate, integrate and prepare for further use cases. And even worse, this happens with a simultaneous loss of control over the underlying methods and notations.

The classic approach of recording the architectural domains of an organization on a global scale and with rigid methods and notations is no longer feasible. Rather, modern architecture management requires to consolidate and map different content in a project-related and flexible manner in the form of a network. In order to implement this, the documentation must be as simple as possible, the capturing must be automated where possible and generated graphical visualizations must be used. At the same time, open source and license free software should be applied where possible to reduce costs. We will take a closer look at these requirements in the following steps.

Conclusion 3: By orchestrating project-specific content in a flexible way, architecture management advances from a content creator to an integrator of the organization’s architectural knowledge.

Description: from graphic to abstract representation

There are various content types to consider when capturing business, data, application and technology architectures (this list only provides an overview without claiming to be complete):

The business architecture describes

• processes
• organizational structures
• roles
• geographical structures
• professional services
• performance indicators and
• goals

The data architecture covers

• business objects
• conceptual and logical data structures
• data security aspects
• migration information and
• data lifecycle content

The application architecture takes care of

• application landscape
• technical communication relationships
• internal functional structures of the applications and
• technical services offered

The technology architecture documents

• technological standards used
• associated hardware portfolio (incl. virtual structures)
• network and low-level communication relationships
• interfaces

A wide spectrum of content needs to be described in Enterprise Architecture Management. Figure 1 shows a possible ontology for defining the associated object types and relationships. For example, the question which business processes and users are affected by the failure of a particular piece of hardware can be answered by performing an integrated analysis on the technology, application and business architecture columns. In this case, the following cells and their relationships must be evaluated:

• roles/positions
• sub-processes / technical processes
• applications / logical interfaces and
• Infrastructure instances

In classical architecture management, it is often common to describe this content graphically in diagrams. Often a variety of 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, as linked Open Group standard, many of these visualizations can be created. But in practice, often additional content from unstructured text up to various other graphical representations needs to be taken into consideration as well. This heterogeneity means, that content has to be carefully put into context in order to create an integrated overall picture of the architecture.

And if notation-specific aspects have to be taken into account as well, the complexity of the required harmonization and aggregation increases significantly. A better way is to initially skip graphic documentation during consolidation. Only document content abstractly and without graphic representation. This only requires a meta-model of the overall architecture, which defines the elementary content, the relationships between it and the associated attributes. The following figure shows the general approach to transfer process diagrams, organizational charts, data models and application listings in an abstract graph network.

By initially skipping graphical representations, the (partially) automatic documentation is significantly simplified, as it is no longer necessary to consolidate the visual representations. This approach primarily focuses the artifacts defined in the meta-model and their relationships. In consequences, an overall model is created that integrates on a content basis independent of the requirements of graphical notations. Of course, graphic visualization is still important for communication. We’ll come back to this point in a minute.

Conclusion 4: The abstract, notation-neutral consolidation of all content artifacts in a model efficiently integrate architectural knowledge.

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 needed for the structured planning and design of an organization’s (IT-) landscape should be recorded. Architecture management can only achieve this goal with reasonable 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 architectural projects address this situation by “over-defining” meta-models just to be on the safe side. But in consequences usually much more content is captured than needed. This approach is only justifiable if you have enough resources to cover the additional work. However, this is usually not the case and at some point “white spots” appear in the database. This is a dangerous situation for architecture management. Because if the meta model promises more than it can deliver in terms of content, the trust of the users in the enterprise architecture model suffers. This situation must be avoided at all costs.

This is where automated data collection comes into play. Wherever possible, the content of the architectural model should be collected through automated processes. The following figure shows possible sources that can provide content for the abstract model. By skipping the graphical visualization (see above), the effort required to „translate“ this data into the abstract model during its flow through the integration layer is significantly reduced. And in some cases, consolidation is only possible by eliminating graphical information.

This doesn’t just apply to the initial creation of the integrated enterprise architecture model. Long-term maintenance and updating also benefits from this approach. The life cycle management of the architectural description (Create-Read-Update-Delete) is much easier to automate when reduced to an abstract definition. Since no graphic information is contained in the model, this does not have to be taken into account when changing the content in CRUD operations.

But as already mentioned, graphic communication of architectural data is essential. Even if it is not immediately obvious at first glance, the abstract documentation of an architectural model helps in this respect as well. Required diagram visualizations can easily be generated.

Conclusion 5: Automatic procedures for collecting, processing and storing architectural knowledge help to document and maintain complex individual information in the long term with reasonable effort.

Visualization: from modeling to generation

In many cases, graphically presented information is easier to understand than textual descriptions. This is especially true when the results of architectural management are shown to managers. When presented as “picture”, complex issues can be communicated easily. Patterns, trends and connections are often better recognized. Searching through tables, on the other hand, is not practical because the human brain is more attracted to visualization than text or numbers. In consequences visualizations are the best investment to assure a long-term support of architecture management across the organization.

However, creating diagrams is a time-consuming process. As an example, let’s have a look at process descriptions using the Business Process Model and Notation (BPMN) in a high level of detail. The BPMN notation allows to describe processes very precisely, for example to design a system for automating processes in an IT solution. BPMN also provides valuable contributions as an addition to contract documents when describing requirements or functional specifications as well as for harmonizing and optimizing processes. If in doubt, a good BPMN diagram is always more accurate than a purely textual description. However, if a company invests a lot of time in capturing and documenting processes, even though the results are later only used for a few applications, then a company-wide documentation of detailed workflows with BPMN in architecture management is a waste of money.

The same applies to the other domains of architecture management. It is better to limit manual work on graphic documentation to those areas in which a person’s creative intellectual capabilities are required. In all other cases, automatic generation of diagrams should be preferred. The following figure shows a data application flow diagram that was automatically created based on an abstract model and visualized (including layout) using freely available software. Storing abstract content in a database enables the creation of high-quality visualizations with the help of various algorithms. This significantly reduces the effort in architecture management, in addition to the improvements already achieved through automated recording. The algorithms can create visualizations for different target groups from the same source data. This means that you can pursue different analytical and visualization goals with one data set.

You don’t even need to purchase expensive software to build the integrated architectural model and automatically generate visual representations. Essential visualization functionalities can be implemented with free software.

Conclusion 6: Graphical visualizations are generated based on an abstract model and are no longer designed manually.

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

When selecting software for architecture modeling, we often find two opposing philosophies. On one hand, there is the suite approach, which attempts to represent the entire architecture management using a single software solution. Gartner Peer Insight alone lists 29 software applications that support enterprise architects and other IT stakeholders within their strategic planning, analysis, design and implementation of architecture management. But even if the manufacturers of enterprise architecture software claim otherwise, no one has yet succeeded in providing a software suite so comprehensive, that it covers all the requirements of architecture management in one solution.

On the other side we find the representatives of the best-of-breed approach, who use the most suitable software to address different problems. Examples of this are:

• Tools for modeling business and technical workflows addressing the business architecture
• Data modeling tools in data architecture and
• Software for documenting infrastructure architectures (Data Center Infrastructure Management = DCIM)

In practice, a mix of various tools is almost always the reality. The departments will likely use specialized tools which best fulfill their tasks within their scope of responsibilities. This is even more true, when – as explained – projects become the essential content suppliers in architecture management. The change from a global to a flexible project-driven approach has a massive impact on the tools used in architecture management.

In order to integrate various sources, a hub-and-spoke approach has proven useful. This will connect content originating from different domains as simply as possible in a central repository, updates it automatically, react flexible when structural changes and extensions arise and allows comprehensive analysis. For the technical implementation native graph databases come into play. They manage content in a native graph (network) structure. Due to their capabilities to add individual content extensions without major modifications, they are a perfect match as integrated architecture repository.

In addition, content that is captured as linked property graph offers comprehensive analysis and evaluation options. This allows to apply mathematical graph theory analysis methods and graph artificial intelligence. Automatic visualizations are in many cases available out of the box. Figure 5 shows how content of a process management tool (in the example, content from GBTEC BIC Process Design) can be combined with an integrated architectural model based on the Neo4j graph database. This enables analyzes that cannot be performed with a process management tool alone. They cover the identification of methodical optimization points in the model, the generation of end-to-end diagrams and the identification of central process flows, applications, interfaces or business objects from various perspectives of the organization. By using AI, these insights can often be derived without the need to add additional data.

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

Conclusion 7: Schema-less graph databases and analysis tools enable architectural content to be flexibly connected, evaluated and communicated easily at lowest costs.

The Neo-Enterprise Architecture – from building to refactoring

It may seem that the above-mentioned changes can only be fully implemented if architectural management in an organization has yet to be established. But this is not the case. Rather, the integration of architectural content in a hub-and-spoke approach creates advantages both on the „greenfield“ and where “classical” architectures are already in place.

If architecture management is not yet established in an organization, this approach allows a cost-effective entry based on a lightweight foundation that can be implemented quickly. There is no need to purchase expensive enterprise architecture tools, and initial results can be tested directly for their usability. If it becomes apparent that a specialized software solution for architecture management is needed, essential preparatory work for its implementation has already been completed.

On the other hand, if architectural content has already been collected in parts but not yet comprehensively merged, then the approach enables integration at lowest costs. It usually turns out that this solution is stable enough to allow comprehensive architectural analysis on the long run. When it is used for long-term operation, additional investments in enterprise architecture software can be omitted. And even if a comprehensive architecture is available within an enterprise architecture tool, integrating the content in a graph database significantly expands the evaluation options and possibilities.

It doesn’t matter whether an organization already practices Enterprise Architecture Management or not. Anyone who actively addresses the changes in architecture management presented above should definitely avoid – to paraphrase Zachman – having both feet in the yogurt.

Want to see how other implement these changes in their organization – see what LEONI (international automotive supplier) did.