EAM Patterns: Best Practices for Enterprise Architecture Management

In the dynamic business environment of staggering globalized economy, today’s enterprises are more than ever forced not only to react to changing situations but to proactively seek emerging business opportunities that help them stay “ahead of the crowd.” To enable this enterprise agility, it is important for managers to know what their enterprise is good at, and in which parts there is potential for improvement. But this question is neither a “business-only” question nor a purely IT-related one; it is the interplay of business and IT, which is essential for an enterprise to stay successful, especially when times get rough.

Together, business and IT aspects as well as their dense and complex web of interdependencies form the enterprise architecture (EA). This architecture constantly evolves over time, as various business and IT projects keep changing the structure of the enterprise and hence tune the interplay of business and IT. Managing this evolution holistically is necessary to avoid growing dissonances and to increase the alignment of business and IT. This is one of the root causes of why many enterprises are on the way to introducing an integrated EA management (EAM). During these introductions, the enterprises are likely to ask the question of “How to start?” One would expect this question to be not too hard to answer—but in fact, it is. In this article, we discuss some typical problems an enterprise will come across in starting an EAM endeavor; our approach to EAM, which is both holistic and modular; and how our approach can help enterprises willing to introduce an EAM to select best practices, which address an enterprise’s specific EA-related issues.

Thinking about how to start an EAM initiative is where the problems occur

As we’ve mentioned, EAM is concerned with the holistic and integrated management of both business and IT aspects in an enterprise. Nevertheless, EAM is not the only management endeavor targeting business or IT elements; various initiatives already present in the enterprise are likely to cover the management subject of EAM at least partially. Albeit the existence of such initiatives, EAM is often developed as a “Greenfield approach,” neglecting the already established related management initiatives and programs. This may, on the one hand, lead to collecting similar data and documenting the same parts of the EA repeatedly and, on the other hand, hold certain groups in an enterprise away from participating in “the EAM thing,” which they have already done for a long time.

But even, if the existing initiatives are accounted for or in the case where there are no relevant initiatives, finding the right way to start an EAM is not easy. This might be surprising, as various frameworks exist, which one would expect to provide help for setting up an EAM endeavor. A closer look at two prominent frameworks reveals why they are not that helpful.

The well-known and longtime-established Zachman framework gives a good example in this context. The questions and layers of abstraction introduced therein are useful to structure the area that EAM is covering, and they also communicate how all-embracing and holistic its management body targets the enterprise. Nevertheless, opening the windows in Zachman’s “EAM advent calendar” reveals some more abstract insights on the corresponding question/layer combination, but does not provide concrete information on how an EAM process for answering this question looks like.

The Open Group Architecture Framework (TOGAF), on the contrary, specifically accounts for an EAM process by providing the architecture development method (ADM), a cyclic process that contains steps from business visioning to the realization of a derived EA. Nevertheless, the single process steps are described very generically and hence are not easy to implement without consulting.

Some other EAM frameworks exist, proposed by standardization bodies, practitioners, or freelancers from consulting, but most of them are “all-or-nothing” approaches, i.e., they are supposed to be introduced completely instead of incrementally. This may result in an EAM kick-start that does not account for the EA maturity of the specific enterprise.

Having read the above, one may be tempted to say: “Let’s do it our own way. Bring the people interested in this topic together and find out what they want to do in EAM.” Such approach at the first might sound enterprise specific and is likely to quickly produce a large number of requirements and ideas representing the demands of corresponding stakeholders. Nevertheless, after consolidating the requirements and making explicit the information needed to satisfy them, an all-embracing EAM approach is likely to emerge that would demand a vast amount of data to be gathered and to be kept up-to-date. Additionally, the specific information demands of such a comprehensive EAM approach are in most cases only weakly linked back to the enterprise’s pain points, such that decisions on how to prioritize the different information demands are often made without looking at the EA-related questions, which will stay without answer, if a specific information is not gathered.

The EAM Pattern Catalog: a collection of best practices

The idea of patterns, as proven, practice-based, general, and reusable solutions to recurring problems originating from the area of architecture, was introduced in 1977 by C. Alexander in his famous book A Pattern Language: Towns, Buildings, Construction. The fundamental concept of patterns was quickly adopted by various other disciplines, as e.g., software engineering. Our approach to EAM continues this story of successful applications of patterns onto the field of managing the EA. Therefore, we have collected a catalog of patterns designed for the context of EAM and evaluated the patterns’ applicability in cooperation with 30 industry partners, including Allianzm, BMW Group, Deutsche Telekom, and Siemens AG. The resulting catalog contains 162 EAM patterns, which are available online in the EAM Pattern Catalog Wiki at http://eampc-wiki.systemcartography.info.

These patterns can help to give an enterprise’s EAM initiative a jump-start in two different ways.

Establishing an enterprise-specific EAM process

The different stakeholders of EAM may have different expectations on the benefits an EAM process may deliver to them. This is likely to complicate the specification of requirements and goals for EAM. The pattern catalog simplifies this task by listing typical concerns and problem statements from the context of EAM. From this list, a couple of relevant concerns can be selected by the group of stakeholders. These concerns are not only helpful in the step of setting up an enterprise-specific EAM, but also provide a useful means for communicating with consultants and tool vendors.

From the requirements elicited above, the enterprise-specific EAM process can be derived. The concerns from the catalog relate to the EAM patterns, which contain best practices for addressing the corresponding concern. Thereby, the following three types of EAM patterns are distinguished:

Methodology Patterns (M-Patterns) define steps or processes to be taken in order to address a given concern.

Viewpoint Patterns (V-Patterns) provide a language used by one or more M-Patterns and thus propose ways to present data (graphical, tabular, text based, etc.) stored according to one or more I-Patterns.

Information Model Patterns (I-Patterns) supply an underlying model and a glossary of the used concepts for the data visualized in one or more V-Patterns.

The EAM patterns make explicit which potentially conflicting forces might exist in the enterprise in respect to the addressed concern. They further denote known usages of the pattern in practice as well as implementations of the pattern in EAM tools. Finally, applying a specific solution to a given problem commonly does not come without cost. The pattern accounts for this fact by giving indications on consequences that may arise from the usage of the pattern (e.g., the effort related to data collection).

All the above descriptions and information can be utilized to prioritize the EAM concerns and hence to decide on the EAM patterns, which should actually be put into practice in the company. The EAM patterns also give helpful and concrete advice for using them. To exemplify this hands-on EAM style, we show a view for V-Pattern in figure 1, as it is contained in the EAM pattern catalog.

This view can be employed in an EAM process, to address the concern: Do currently used business applications correspond to architectural standards? Are deviation reasons documented, e.g., strategic decisions? Therefore, the relationships between the business processes, the business applications, and the organizational units of the enterprise should be visualized.

Additionally, the view uses color coding to indicate which business applications conform to architectural standards and which do not. Further, a check mark symbol is used to indicate exceptions from the architectural standards that are allowed, e.g., per management decision.

The M-Patterns provide guidance for the steps, which are to be executed to address the corresponding concern, and point to the V-Pattern, which can be used for supporting these steps. Thereby, the M-Patterns are also designed to complement existing EAM frameworks with more in-depth information on how the best-practice steps for executing a typical EAM task look like.

Inspiring and assessing an already implemented EAM approach

The pattern catalog cannot only be used to design an enterprise-specific EAM approach from scratch, but it can help to assess the current approach of the enterprise and inspire adaptations. This is possible because the enterprise’s approach can be compared with best practices used elsewhere and because the catalog contains a fourth type of EAM patterns, which can also be helpful for understanding typical problems linked to the execution of EAM tasks. This is the so-called EAM anti-patterns document solutions, which have proven to lead to suboptimal results or explicate usage contexts, under which certain EAM patterns do not work as expected. They are intended as guidance to prevent blind alleys.

Success stories of the EAM Pattern Catalog

The pattern-based approach to designing and establishing an enterprise-specific EAM has been successfully applied at different case studies in practice among others at a large German car manufacturer and a global-acting insurance company. From these successful applications and from trainings held on-site at industry partners, a growing community of practitioners has evolved, which not only use the EAM Pattern Catalog but are encouraged and willing to contribute and share their insights and experiences with the approach in the EAM Pattern Catalog wiki. The pattern idea also has gained followers among consulting companies that have recently discovered the knowledge gathered in the catalog and have started to use the freely available information to enhance their services in the area of EAM consulting.

The EAM Pattern Catalog can be found at http://eampc-wiki.systemcartography.info

by SABINE BUCKL, ALEXANDER M. ERNST, and CHRISTIAN M. SCHWEDA, research assistants at the chair for Software Engineering for Business Information Systems (sebis) at the Technische Universität München (TUM–Munich University of Technology). Their research interests cover the field of system cartography, EAM, and related domains.