Enterprise Architecture Management Patterns-Exemplifying the Approach

Abstract:

Enterprise Architecture (EA) management has been gaining importance in organizations, and while EA management frameworks provide a holistic and generic view on the subject, organizations introducing EA management are often left alone regarding the details of the approach. The EAM Pattern Catalog, presented in this article, is a collection of best practices for addressing speciﬁc concerns in EA management related to e. g. architectural standardization, application landscape planning, or interface, business object, and service management. It provides methodologies for addressing these concerns, together with information models deﬁning the relevant concepts, and viewpoints for visualizing them. This article describes the structure and extent of the EAM Pattern Catalog, and exempliﬁes its approach by outlining EAM patterns for addressing architectural standardization. Architectural standardization tries to tackle the complexity of the EA created by historically grown structures. These structures lead to disadvantages as low maintainability, low bargaining power at IT suppliers, or the need of largely diverse skills in the IT workforce.

Introduction & Motivation:

Enterprise Architecture (EA) management is one of the major challenges of modern enterprises. It aims at aligning business and IT in order to optimize their interaction. Additionally, regulations like e. g. Sarbanes Oxley Act (SOX [29]) require companies to document and plan their EA.

Whatever preliminary work exists in a company, there commonly is a demand for a more structured way to manage the evolution of the EA. A variety of approaches to introduce EA management has been proposed by academia and practice (see e.g. [4], [13], [24]), but they all have to cope with at least one of the following problems:

EA management is introduced from scratch, not considering related initiatives already present inside or outside the organization.
EA management frameworks, like Zachman [36], TOGAF [34], etc., are usually either too abstract and therefore not implementable, or too extensive to be used in practice, as they have to be utilized as a whole.
Lacking an actual starting point for an EA management initiative, companies tend to collect requirements from potential EA stakeholders in the organization. Consolidating their demands and integrating their information needs, an all-embracing EA management approach is likely to emerge, which would demand a vast amount of data to be gathered, although only a part of it would be needed to address the real pain points of the company.
If an approach has been implemented, it is often not documented, why certain decisions have been taken, e. g. why a certain concept has been introduced in the information model. This leads to information models, which cannot be adapted or extended, due to the fact that no one knows what analyses rely on which parts of the information model.
Approaches proposed e. g. by organizations or standardization groups are usually all or nothing approaches, meaning that they are supposed to be introduced as one single piece instead of incrementally. This results in an EA management approach that is not tailored to the company’s EA maturity.

In order to address the problems stated above, we propose to apply patterns, well known from other disciplines like architecture or software engineering. Alexander et al. [1] deﬁne a pattern in the context of architecture as follows: ”Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” Additionally, [1] details that ”each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution”. In software engineering, design patterns are e. g. deﬁned by Gamma et al. [14] as ”descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.” The common ground of both deﬁnitions is that patterns are a general, reusable solution to a common problem and are dependent on their context.

The above described properties are the basis for the EAM pattern approach, which initially has been introduced in [8]. EAM patterns describe solutions, based on best practices for recurring problems in EA management that can and may have to be adapted to a speciﬁc enterprise context. In addition to addressing the problems stated above, patterns offer further advantages. According to [16], an advantage of the pattern concept is that it enables architects to understand the impact of the architectural decisions at design time, because patterns contain information about consequences and context of the pattern usage. Harrison et al. [15] state that patterns have shown to be a useful and important vehicle for capturing some of the most signiﬁcant architectural decisions. As information on possible consequences of pattern usage is included in pattern descriptions, they qualify for documenting the rationale and expected consequences of a decision. Another advantage is that patterns can also be included in current EA management frameworks to enrich them with concrete instructions on how to address a speciﬁc concern. The following three kinds of EAM patterns have been introduced in [8].

A Methodology Pattern (M-Pattern) deﬁnes steps to be taken in order to address given concerns. Furthermore, as a guidance for applying the method, statements about the intended usage context are provided, which include the concerns to which the M-Pattern can be applied. The procedures deﬁned by the MPattern can be very different, ranging from e. g. visualizations and group discussions to more formal techniques as e. g. metrics calculations [23]. M-Patterns have been introduced, because missing methodologies constitute a common issue in EA management information models. Additionally, frameworks as e. g. TOGAF [34] provide a process model (TOGAF ADM), but leave the details of the methodologies supporting the speciﬁc activities in the EA management process relatively open. M-Patterns explicate the methodologies in order to complement activities carried out in an ad-hoc manner or relying on implicit knowledge with activities carried out more systematically.

A Viewpoint Pattern (V-Pattern) provides a language used by one or more M-Patterns and thus proposes a way to present data stored according to one or more I-Patterns. In our research project Software Cartography (see e. g. [7], [8], [22], [35]), we found that industrial users often specify viewpoints by example. This means that an exemplary view is provided for the viewpoint, possibly together with some textual explanations. While we do not contend that this may be sufﬁcient in certain use cases, e. g. sketching concepts in presentations, we see problems arising, when the goal is providing ofﬁcial information to a wider audience for an extended period. In order to ensure the understandability of a diagram, we regard e. g. a legend to be mandatory.

An Information Model Pattern (I-Pattern) supplies an underlying model for the data visualized in one or more V-Patterns. An I-Pattern contains an information model fragment including the deﬁnitions and descriptions of the used information objects. As described in [8], different languages are possible for describing an I-Pattern, varying in their degree of formality, including among others textual descriptions in natural language, the Meta Object Facility (MOF [26]), Uniﬁed Modeling Language (UML [25]) class diagrams, ontology languages, and mathematical formalizations, or combinations of these approaches. Choosing a speciﬁc approach basically has to consider the needs of the use cases to be supported. While an object-oriented description might be sufﬁcient for creating a visualization or a tabular report, e.g. process simulation may only be reasonably possible on a more formal basis. Therefore, we propose using a language adequate to the problem to be addressed, thereby strongly considering UML as the default language, as it is widely understood and has been found by us to be problem-adequate in many practical settings in the context of EA management information models [7]. In case a language different from UML is chosen, complementing its speciﬁcation with an UML-based description can yield advantages, especially as integrating information model patterns is simpliﬁed by them being available in a common language.

The conceptual UML class diagram in Figure 1 shows the dependencies between the EAM pattern types. The class Concern in the conceptual diagram reﬂects the fact, that the EAM pattern approach is concern driven. Concerns are usually the entry point for management activities. In order to improve readability and comparability, the structure of the EAM patterns is similar to the structure proposed by [14]: pattern name, problem, solution, and consequences. Additionally, all EAM patterns include versioning information in order to be able to differentiate between different development stages.

The remainder of the article is structured as follows. Section II describes the EAM Pattern Catalog, how it has been compiled, and its relationship to EAM patterns. Section III introduces exemplary EAM patterns for addressing architectural standardization, followed by a resume and outlook in Section IV.

Resume & Outlook:

The article outlined an approach for consolidating, publishing, and advancing detailed practices for addressing EA management concerns. Thereby, the idea of design pattern, as originally introduced by [1], and made prominent in software engineering by [14], constitutes the foundation of the approach. A research direction we pursue in this respect concerns the integration of EAM patterns. We are currently applying the EAM Pattern Catalog and parts thereof in EA management projects in practice, in order to validate our integration ideas presented in Section II-B, and ﬁnd other challenges connected to integrating and implementing the patterns in a practical setting [2], [11].

The article also presented the EAM Pattern Catalog, a collection of best practices for EAM building on the pattern based approach. As another research direction for pattern integration, we are presenting the patterns in the catalog as extensions to EA management frameworks. As mentioned in Section I, frameworks like TOGAF or Zachman leave details about procedures to be taken, visualizations to be used, and data to be collected relatively open. Therefore, we view integrating the patterns from the catalog into an EA management framework as an effort complementing the highlevel guidance provided by the frameworks with the detailed practices of the catalog.

As the catalog’s utility depends on fostering, advancing, and establishing the speciﬁc patterns as accepted solutions to EA management problems, we are planning to evolve them via a community process. Thereby, we would like to apply approaches used in pattern communities in software engineering. We are planning to put a web platform at the center of our activities to create an EA management pattern community, allowing users to exchange related information:

Accessing the patterns, navigating along the pattern graph, and downloading related content, as e. g. the information models in XMI format, or related tools, e. g. for creating the visualizations
Creating new versions of pattern, including the respective versioning workﬂows and statuses (in work, in review, etc.)
Commenting on patterns, discussing about them, voting on patterns, or conducting surveys about them
Reports of usage in practice

In creating an EA management pattern community, we are not planning to rely on a web platform alone. By initiating activities, from driving publications about worthy enhancements to patterns, to organizing workshops targeted at improving patterns in a cooperation of practitioners with researches, we plan to bring and keep alive a pattern community enhancing and establishing the pattern catalog. To exemplify a possible enhancement, a potential approach for advancing patterns addressing architectural standardization could be introducing quantitative techniques, as e. g.:

Metrics measuring degrees of architectural standardization, in order to be able to distinguish ﬁner degrees of conformance, or
Quantitative models for estimating the effect of architectural standardization or its absence on key quality attributes of an application landscape, as e. g. ﬂexibility to change or incorporate new functionality, or scalability in cases of increased load. Such quantitative models might e. g. rely on simulations of processes running in and affecting an application landscape.

Techniques as mentioned above can be used in M-Patterns to make more founded decisions regarding which architectural standards to prescribe, and when to allow which deviations from them. By being able to measure the deviations, and predict their negative effects, checking whether they are worth a beneﬁt expected from a nonstandard architecture becomes basically a business case decision. As far as those approaches might seem from current practices, as e. g. put forward by EA management tools, or EA management frameworks, they point in a direction where EA management is less an art practiced by IT staff, but a science providing documented, predictable approaches to experts supporting business with the IT it needs. Building the EA management pattern catalog constitutes a key advancement in this direction to us.