State of the Art in Enterprise Architecture Management 2009

Ente

rpris

e Ar

chite

ctur

e M

anag

emen

t Too

l Sur

vey

2008

Mat

thes

| B

uckl

| Le

itel |

Sch

wed

a

Florian Matthes, Sabine Buckl, Jana Leitel, Christian M. Schweda

Enterprise Architecture Management Tool Survey 2008

Enterprise architecture (EA) management is one of the most attrac-tive approaches for IT managers trying to align business and IT. This survey analyzes the emerging market for EA management tools in depth.

If you are searching for tool support in EA management or you are establishing an EA management endeavour you will find a detailed analysis of major players in the EA management market as well as a detailed introduction to EA management.

To accomodate the diversity of EA management approaches, the results of this study are not compiled into a simple ranked list of tools, but are aggregated according to two sets fo evaluation crite-ria. These criteria targeting both specific functionality and support for EA management tasks reflect the cumulative requirements of the sponsors and partners of the survey. The requirements are further operationalized by scenarios exemplifying best practice approaches to EA management.

These partners provided comprehensive input to the evaluation criteria and information about their approach to EA management, which were distilled into a set of scenarios as the basis for this evaluation.

The fine grained evaluation result enables the reader to individually match their specific requirements with the tools investigated. Thus, the survey provides a structured decision support rather than a simple one- or two-dimensional ranking.

Tools Analyzed

Adaptive EAM (Adaptive), planningIT (Alfabet AG), ADOit (BOC), EA/Studio (Embarcadero), ARIS IT Architect (IDS Scheer AG), MEGA Modeling Suite 2007 (MEGA International SA), ProVision (Metastorm), Telelogic System Architect (Telelogic AB), and Troux (Troux Technologies Inc.)

Key Points

• Comprehensive description of 18 scenarios developed in coope-ration with sponsors and partners for analyzing the tools: Targe-ting both specific functionality and support for EA management tasks.

• Detailed analysis of each tool based on simulations of scenarios, including screenshots, reports, etc. generated by each tool.

• Ranking of the tools based on eight criteria for specific tool func-tionality and nine criteria for support of EA management tasks.

• 384 full color A4-pages with over 350 graphics, screenshots, and tables.

SponsorsAllianz Group IT

sd&m - software design & manage-ment

Siemens IT Solutions and Services

Co-Sponsorsact! consulting

Detecon

Münchener Rück

o2 Germany

SYRACOM | The Business and IT Architects

PartnersBMW Group

BSH Bosch und Siemens Hausgeräte

Deutsche Bahn IT-Strategie

Deutsche Bank

Deutsche Telekom

EWE

FIDUCIA IT

Fraport

HSH Nordbank

HVB Information Services

Kuehne + Nagel

LVM Versicherungen

Nokia Siemens Networks

Postbank

Procter & Gamble

Schufa

SEB Bank

TUI

Wacker Chemie

ZF Friedrichshafen

Zollner Elektronik

www.systemcartography.info

ISBN-10: 3-00-024520-0

ISBN-13: 978-3-00-024520-6

State of the Art inEnterprise Architecture Management

Sabine Buckl, Alexander M. Ernst, Josef Lankes,Florian Matthes, Christian M. Schweda

2009

State of the Art in Enterprise Architecture

Management 2009

Sabine Buckl, Alexander M. Ernst, Josef LankesFlorian Matthes, Christian M. Schweda

Software Engineering for Business Information Systems (sebis)Ernst Denert-Stiftungslehrstuhl

Chair for Informatics 19Technische Universitat Munchen

Boltzmannstraße 3, 85748 Garching b. Munchen, Germany

[email protected]

March 2009

About sebis

sebis is the chair ”Software Engineering for Business Information Systems” at the Institute forInformatics of the Technische Universitat Munchen. sebis is partially funded by the Ernst Denert-Stiftung and headed by Professor Dr. Florian Matthes. The main research areas of sebis are:

• Software and System Cartography: Enterprise application landscapes are complex intan-gible structures created, utilized, financed, and managed by people with vastly differentbackgrounds and objectives. Software cartography supports the communication betweenthese stakeholders by intuitive and precise visual maps and thus contributes to an improvedunderstanding and management of enterprise architectures.

• Innovative technologies and software architectures for information and knowledge manage-ment (enterprise solutions, groupware, and social software).

• Security for business applications.

sebis is using software engineering methods (model construction & abstraction, analysis & design,construction & evaluation) and is working in close relationship with industrial partners and withorganizations from the public sector.

Florian Matthes holds the chair Software Engineering for Business Information Systems at theTechnische Universitat Munchen. The current focus of his research is on enterprise architecturemanagement, social software, and model-driven web application engineering. He is co-founder offour high-tech software and service providers (CoreMedia, infoAsset, 20six, 21publish) with morethan 160 employees.

Copyright

Copyright c© 2009 Technische Universitat Munchen, sebis, Germany. All rights reserved.

Disclaimer

The information contained herein has been obtained from sources believed to be reliable at thetime of publication but cannot be guaranteed. Please note that the findings, conclusions, andrecommendations that TU Munchen, sebis delivers will be based on information gathered in goodfaith from both primary and secondary sources, whose accuracy cannot always be guaranteed byTU Munchen, sebis.

TU Munchen, sebis disclaims all warranties as to the accuracy, completeness, or adequacy of suchinformation. TU Munchen, sebis shall have no liability for errors, omissions, or inadequacies inthe information contained herein or for interpretations thereof. In no event shall TU Munchen,sebis be liable for any damage of any kind (e.g. direct, indirect, special, incidental, consequential,or punitive damages) whatsoever, including without limitation lost revenues, or lost profits, whichmay result from the use of these materials. The reader assumes sole responsibility for the selectionof these materials to achieve its intended results.

There will be no warranty that the results of this publication will be economically and technicallyexploitable and unencumbered by third-party proprietary rights.

Contents

1 Introduction 6

2 Overview 7

3 Findings of the survey 10

3.1 Searching for a Definition of EA Management . . . . . . . . . . . . . . . . . . . . . 10

3.2 The E in EA Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Governance and EA Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 EA Frameworks offer only minor Assistance . . . . . . . . . . . . . . . . . . . . . . 14

3.5 The information gathering process . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.6 Visualizations as a Communication Basis . . . . . . . . . . . . . . . . . . . . . . . 18

3.7 On the Importance of Communication . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.8 Tools for EA Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.9 The role of SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.10 Metrics and KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Outlook 30

c© TU Munchen, sebis, 2009. All rights reserved. 5

1Introduction

EA management is a relatively new and henceconstantly evolving discipline, which targets atestablishing methods for aligning business andIT on a company-wide level. As state of the artand trends in this discipline are widely diversein the industry, we compiled this report as acomprehensive insight into the current state ofthe practice and the roles, which it is going totake in the future.

This report is based on the results and findingsof a survey, which was conducted from 2006 to2008 to answer the following questions aboutthe state of the art in EA management in Eu-rope:

• What definitions of EA management existand are used in practice?

• To what extent is business considered inEA management?

• What kind of governance is in plan forEA management?

• What EA frameworks are used in practiceand can they satisfy their users?

• What strategies are used to gather infor-mation on the EA?

• What is the role of visualizations in man-aging the EA?

• What are the problems obstructing com-munication between business and IT?

• What EA management tools do practi-tioners use and what is their role?

• How does EA management relate to ser-vice oriented architectures?

• What role do metrics and KPIs play inEA management?

The survey is based on a twofold approach. Atfirst, guided interviews were conducted with 22enterprise architects, which were recorded, tran-scribed, and evaluated. This analysis resultedin quotations and textual information on EAmanagement approaches used in the companiesof the interview partners. Second, an extensiveonline survey, which had a return rate of about50%, was conducted with 31 participants.

The following companies participated in thesurvey: Allianz Group IT, AXA, BMW Group,BSH Bosch Siemens Hausgerate, Credit Su-isse, Deutsche Bahn, Deutsche Borse Systems,Deutsche Post, Deutsche Telekom, FIDU-CIA, HVB Information Services, Krones,Kuhne+Nagel, Munchener Ruck, O2 Ger-many, Siemens CIO, Siemens PG, and ZollnerElektronik.

The remainder of this report is structured as fol-lows. Section 2 gives an overview about the sur-vey participants and their background, followedby Section 3 presenting the findings of the sur-vey structured along ten topics complementingthe questions about the EA management stateof the art.

These findings are supported by quotations ofpractitioners, which we gathered in the inter-views of the survey. The technical report con-cludes with an outlook on how to address typi-cal, recurring problems in EA management uti-lizing the EAM Pattern approach.

6 c© TU Munchen, sebis, 2009. All rights reserved.

2Overview

Results included in this first chapter are solelybased on the online survey, whereas the follow-ing chapter shows results from both the onlinesurvey and the guided interviews.

In order to obtain an overview about the in-dustry sectors, which the participants belongto, they were asked to classify their companyin one of the following eight categories. Thedistribution is shown in Figure 2.1.

• Production: Production of physicalgoods from raw materials.

• Service: Offering of intangible assets(non-financial).

• Commerce: Act as an negotiator be-tween a producer and a consumer, e.g. adepartment store.

• Finance: Banks and other financial or-ganizations.

• Information Industry: Companieswhich primarily draw profit from sellingintellectual property.

• Public Utility: Electricity suppliers,water suppliers, etc.

• Transport and Logistic: Companiesdrawing profit from transporting goods.

• Miscellaneous: The company could notbe classified based on the offered cate-gories.

To get an overview about the level of knowledgeof the survey participants, they were asked threequestions:

Figure 2.1: Which sector does your companybelong to?

• How do you estimate your IT-knowledge?(Question 1)

• How do you estimate your knowledge con-cerning the business, which you supportor execute? (Question 2)

• How do you estimate your level of knowl-edge in EA management? (Question 3)

Figure 2.2: Overview personal knowledge

Figure 2.2 shows the answers to these questions.It has thereby to be noted that the estima-tion of the IT knowledge is mostly ”very good”,


while business knowledge and EA managementknowledge is mostly ”good”.

The participants of the survey were all part ofthe IT departments of the respective companywith about 20 % being employed at the CIOlevel. The remainder of the participants is di-vided in IT and technology development, as wellas IT operations. Figure 2.3 shows this catego-rization more in detail.

Figure 2.3: Responses to the question: Catego-rize your work into the following schema.

Figure 2.4: Responses to the question: Whatwas the focus of your education?

Knowledge and experience in EA managementdepends on the background of the participant.This has been considered in a question concern-ing the education of the participants. Most ofthe participants had an IT related educationlike informatics, followed by business related ed-ucation like business administration. An inter-esting point is that participants with a business

informatics related background follow on thirdplace. Mathematics and engineering related ed-ucation represent the smallest fraction. Moredetailed information is given in Figure 2.4.

The size of the application landscape in a com-pany may influence the importance of EA man-agement in this company. Therefore, the par-ticipants of this survey had to indicate the sizeof their company’s application landscape. Fig-ure 2.5 shows the results of this question.

Figure 2.5: Responses to the question: Howlarge is your application landscape (Number ofdeployed applications)?

The last question targets the maturity of thecompany in respect to its application land-scape. Thereby, the degree of standardizationand modularization has been analyzed. Partic-ipants could choose from the following list ofanswers, which are loosely inspired by [WR04].

• A: IT is characterized by applications fo-cused on support for specific areas, forwhich it is optimized.

• B: A homogeneous, standardized infras-tructure is the execution environment ofthe applications.

• C: IT supports standardized processesin the organization and enables the pro-cesses to use data owned by the differentapplications.

• D: IT is based on process- andapplication-components, which can be


used in a modular way and thus provideflexibility.

About one third of the companies use businessapplications optimized to support specific busi-ness processes. The least participants answeredthat their company uses application compo-nents, which are modularly reusable. Detailedresults are shown in Figure 2.6, where the let-ters A-D refer to the options from above. Figure 2.6: Responses to the question: Which

of the following statements describes your en-terprise best?


3Findings of the survey

3.1 Searching for a Defi-

nition of EA Manage-

ment

Even though EA management is an emergingtopic, which is addressed by nearly every glob-ally acting company, no common establisheddefinition yet exists. Nevertheless, most defini-tions, which can be found in literature and weregathered during the interviews with our surveyparticipants, emphasize the following aspects:

Alignment: The goal of the process of EAmanagement is to improve the alignment ofbusiness and IT. Thus, especially the strategiesand business goals of an enterprise need to beconsidered to manage the evolution of the EA.

Holistic view: EA management is concernedwith various aspects of the enterprise, e.g. orga-nizational units, business applications, projects,which can be organized in different layers –ranging from business to infrastructure layer.Thereby, the interconnections between theselayers are of vital importance for the process ofEA management, not only the elements itself.

One important part [of EA management]is [the set of] interconnections betweenthe different layers (especially between thebusiness and IT layers).

An Enterprise Architect from the ServiceIndustry

Process character: EA management is a con-tinuous, iterative process, which on the onehand needs input from other enterprise-level

management processes, e.g. project portfoliomanagement, strategies and goals management,and on the other hand provides input for thesemanagement processes. Thus, it acts as a glueto align enterprise-level processes.

EA management evolves from an reactiveprocedure to an active enabler and driverof the business

An Enterprise Architect from theProduction Industry

In addition to the similarities of EA manage-ment definitions regarding the contained as-pects as alluded to above, a common sense con-cerning typical tasks for EA management exists.Whereas standardization and homogenizationcan be regarded as internal tasks, further re-sponsibilities subsist, which emerge from exter-nal influences, e.g. regulations, laws, and com-petitors. Nevertheless, communication is seenas a central challenge in EA management.

The greatest challenge in the context ofEAM is to convince people to replace anestablished solution, irrespective if it is agood one or only a worse workaround, byanother, in order to support the entirecompany. This is the challenge we haveto address in the next years.


The quotation given above describes the inter-personal problems arising in EA management,which can only be addressed by communicatingthe benefits of the chosen approach.


Furthermore, EA management is an ongoing en-deavor, which needs sufficient time in advance(some years) until return of investments are vis-ible. In addition, these returns can hardly bemeasured quantitatively, as the highly complexmanagement body mostly delivers only qualita-tive results.

[The greatest challenge of EA managementis the] calculation of business cases in re-spect to EA management endeavors

An Enterprise Architect from the FinanceIndustry

Concludingly, it can be said that, although nocommonly accepted definition of EA manage-ment exists, a common understanding of whatEA management is about is widely given. Be-low our definition of EA management is pro-vided, which centers around the commonalitiesfrom above:

EA management is a continuous, iterative(and self maintaining) process seeking toimprove the alignment of business and ITin an (virtual) enterprise. Based on aholistic perspective on the enterprise fur-nished with information from other enter-prise level management processes it pro-vides input to, exerts control over, and de-fines guidelines for other enterprise levelmanagement these processes.The EA management process consists offour interconnected distinct phases: plan,execute, control, and maintain. Duringplanning envisioned EA scenarios are cre-ated, evaluated, and finally decided upon.The execution phase provides EA deliver-ables, which are used to steer, guide, andinfluence other enterprise level manage-ment processes. In the control phase per-formance is measured on enterprise leveland aggregated to key performance

indicators. These measurement results andindicators are used in the maintenancephase to improve the overall EA manage-ment process as well as to adapt and shapethe roles and bodies involved.

sebis

3.2 The E in EA Man-

agement

Literature and presentations mention the prob-lem of EA management being mostly an IT-only endeavor, which thus fails to provide itsfull benefit e.g. in respect to mutually aligningbusiness and IT. The following quotation em-phasizes this issue from a practitioners point ofview.

EA is a hype topic. If we look at it in de-tail, we can see that most companies do notcare about aspects, which go beyond tech-nological aspects. As long as EA is only anIT topic it is doomed to fail, as it is expen-sive to collect the data and the benefit canonly be gained if business is incorporatedin the endeavor in a way that they under-stand what EA management is all about.


The following questions try to shed a light onthe perception of the role of business in EAmanagement in practice as well as on its drivingforces.

As an introduction we asked who was the driverfor EAM in your enterprise? Figure 3.1 showsthe results of this question.

70% of all respondants of the survey said thatIT is the driver of EA management in their com-pany. In contrast only 22% see the combina-tion of business and IT in the lead in EA man-agement. This supports the statement of the


Figure 3.1: Drivers for EA Management?

above quotation, that business is not sufficentyinvolved in current EA management projcets.Therefore, we asked the participans of the inter-views, if business was sufficienty included in theEA management endeavor in their enterprises?

Figure 3.2: Is the business sufficiently involvedinto EA Management?

The results are illustrated in Figure 3.2. Morethan half of all respondents answered that thebusiness was not sufficiently incorporated in thecurrent EA management approach. As a resultit can be summarized, that EA managementmostly is an IT topic in current approaches.

One of the task of EA management should bethe definition of targets and rules for the futuredevelopment of the EA. This rules also have tobe enforced. As we had often been reportedissues with the enforcement of rules, we askedthe following question to analyze the situationin more detail: Where in your organizations are

the goals for the future evolution of the applica-tion landscape set? The possible answers werethe following:

• A: Different persons/groups try to setgoals, but have no formal power for en-forcing them.

• B: A person/group (e.g. IT-architects)tries to set goals, but has no formal powerfor enforcing them.

• C: A person/group with the necessarypower for enforcing them sets goals.

• D: Different persons/groups with the nec-essary formal power set goals.

The results are shown in Figure 3.3.

Figure 3.3: Where are the targets for the futureevolution of the application landscape set up inyour organization?

Nearly 40 % of the participants selected answerC, indicating that usually it is a person or groupwith appropriate formal power, which sets suchgoals. The interesting result of this question isthat an almost equal part of the participantsanswered that a person or group, which did notposses formal power to enforce them (answer Aand B), sets the goals. This situation is mostlikely to lead to goals, which are set but neverread as they are not enforced at all.


3.3 Governance and EA

Management

Governance, no matter weather IT, business, orboth are concerned, is a topic, which attractsrising attention from practitioners as well asresearch groups. Thereby, a variety of defini-tions for corporate governance as well as forIT governance currently exists. According to[MW05] corporate governance is responsible forthe establishment of the legal and factual or-ganizational framework for managing and con-trolling enterprises. Complementary, [In05] de-fines IT governance as follows: IT governance isthe responsibility of executives and the board ofdirectors, and consists of the leadership, orga-nizational structures and processes that ensurethat the enterprise’s IT sustains and extends theorganization’s strategies and objectives. Sub-sumingly, the establishment, enforcement, andimprovement of committees (e.g. architectureboards on different management levels), roles(e.g. enterprise architect, business architect,project manager), and responsibilities (for fi-nancial, temporal, or information aspects) canbe regarded as the central tasks of governance.

Governance has to be distinguished from theassociated management task – managementmakes decisions, governance determines whocontributes to the decisions and who makesthem. The following quotation of [WR04] il-lustrates the relation between management andgovernance.

The difference between management andgovernance is like the difference between asoccer team running harder and practicinglonger and the team stepping back to ana-lyze its composition and game strategy.

Ross and Weill, 2005

The governance structures play an importantrole in the execution of the EA management

process, as they can e.g. act as quality gatesin the transformation process of the enterpriseto ensure the fulfillment of given guidelines orstandards. As an example, in a project manage-ment process it might be obligatory that eachproject has to undergo an architectural review,which checks the conformity of the envisionedfuture architecture to guidelines. Thereby, twodifferent ways of escalation in case of a noncon-forming envisioned architecture are commonlyused – horizontal and vertical escalation.

• In a horizontal escalation, the deci-sion on the project’s future remainson the management level, where thenon-conformance has been detected.Enforcement can be achieved via bud-geting. Thereby, the project manager isallowed to implement the project withthe non-conforming architecture, but hasto reserve funds for the costs of a laterproject, which transforms the architec-ture according to the defined standardsand guidelines, in the total project bud-get.

• In case of an vertical escalation, the deci-sion about the project’s future is handedover to a committee on a higher manage-ment level. Thereby, the project man-ager of the non-conforming project is de-manded to explain the reasons for his de-viation to the higher management.

Within the process of establishment and im-provement of governance structures, our re-spondents stated the following topics as themost challenging ones:

• First of all, the top management mustback the establishment of governancecommittees as well as support the deci-sions taken by them and the enterprisearchitects in order to ensure the bindingcharacter of their results.


• The right balance between establishingthe necessary governance structures andavoiding abundant bureaucracy must befound to ensure a fast, understandable,and reproducible decision making processand the enforcement of given standards.

• In order to set up a schema of defined re-sponsibilities, the processes must be doc-umented first.

Especially the question of the right balanceseems to be a challenging one. This is also re-flected by the following statement of one of ourindustry partners:

There are committees and boards estab-lished within our company in order to dis-cuss architectural decisions. Some col-leagues even say, there are too many ofthem!

A Project Manager from the FinanceIndustry

Altogether, a tendency in favor of business re-quirements in the context of governance exists.This means that business requirements over-rule requirements from EA management. Thistendency is nevertheless regarded by the busi-ness and architecture people to be an importantone.

3.4 EA Frameworks of-

fer only minor Assis-

tance

Enterprises seeking to establish EA manage-ment often start by searching for acceptedstandards in order to get deeper insights intothe topic and to avoid known pitfalls. Thus,sooner or later, they will come across EA

frameworks, e. g. Zachmann [Za87, JZ92],The Open Group Architecture Framework (TO-GAF) [Th07, Th09], or the Department of De-fense Architecture Framework(DoDAF) [DD04]. In addition, further frame-works exist in the tools available for EA man-agement, e. g. ARIS or planningIT [Ma08].

Figure 3.4: Awareness level of existing frame-works

According to the results of our survey [Ma08],there seems to be nobody who uses a frameworkout of the box (see Figure 3.5). Initially manyorganizations look at Zachman or TOGAF toget a first overview on EA management(see Fig-ure 3.4). TOGAF constitutes the most promi-nent approach, which is used by a majority ofour respondents to provide ideas for the devel-opment of an enterprise-specific approach. Themajor drawback of TOGAF is, according to ourrespondents, the extensive description, whichcovers about 800 pages.

After an intensive phase of familiarizationand an initial workshop, where TOGAFwas presented to the involved stakehold-ers, we decided: Thanks, too complicatedfor us.

An IT Architect from the Service Industry

In addition to TOGAF, our respondents regardthe Zachmann framework to be especially help-


Figure 3.5: Usage of frameworks during the es-tablishment of EA management

ful to present the idea, of EA management to in-volved stakeholders in general and the top man-agement in particular, as the following quota-tion points out.

The topic EA management was presentedthree times to the management, it was re-jected twice. The third time, the Zach-man framework was used to explain the en-deavor and what EA management standsfor as well as what it means to have anholistic view on the enterprise. This time,we received a go from the management.Now, we use the Zachmann framework asa static model, which is pinned on wallsin many rooms without far-reaching conse-quences.


In summary, the majority of our respondentsuse an EA management approach, which is in-dividually developed, sometimes based on in-puts gathered from existing frameworks. Rea-sons for the development of enterprise-specificEA management approaches are according toour respondents the individual way of thinking,which exists in most enterprises. Furthermore,the frameworks appear theoretical and impossi-ble to implement.

I will not say the existing frameworks arefreaky theoretical, but far far away fromthe possibilities we have in our enterpriseto implement them.

A Project Manager in the FinanceIndustry

3.5 The information

gathering process

One important issue in EA management is gath-ering information as well as their maintenance.Thus, initially the question, which informationshould be gathered is more important than howto gather it, as gathering information, whichis not really needed to address the pain pointsof the enterprise, will lead to labor-intensiveand time-consuming tasks, annoying a greatamount of information stewards1. In addi-tion, the information stewards performing theselabor-intensive tasks are not identical with thestakeholders benefiting from the gathered dataand thus cannot see the advantage of the workthey are demanded to perform. These circum-stances may lead to a decreasing acceptance anda lack of support of the EA management en-deavor.

In order to establish a successful EA manage-ment approach including an active EA informa-tion gathering and maintenance process, the fol-lowing pitfalls should be avoided according toour industry partners:

• Consider carefully, which major painpoints of the enterprise should be ad-

1We refer to the term of an information stewardto describe the members of a company who are in-volved with the information gathering and maintain-ing process. The crowd of information stewards mayhave an intersection with the group of stakeholders,which have a certain concern that is addressed bythe EA management process.


dressed by the EA management initiativeand which information is needed. Other-wise, you will start with 20 informationconcepts and end up with 500.

• Think about the process, to gather thenecessary information in advance. If youstart walking around with MS Excel orMS Word, you perhaps will end up withthousands of sheets you don’t know howto consolidate in the end.

• Remember to spend some thoughts aboutwhom to ask for the information. If youdo not clearly define, who the informa-tion stewards are, and if they are not con-vinced of the benefit of their work, yourendeavor will die after the initial phase.

• Keep in mind to think about how to visu-alize the information, how to analyze it inorder to enhance the situation, and howto maintain the information.

The aforementioned pitfalls mainly refer to theinitial EA management tasks of developing anenterprise-specific information model and stor-ing the respective data in a repository. Accord-ing to the experience of our industry partners,the development of an information model re-quires the involvement of several stakeholdersfrom different areas (e.g. business, IT, strate-gies, projects). As this approach leads to severaliterations, it has to be ensured that the informa-tion model does not grow infinitely. The follow-ing statement of one of our interview partnersprovides a solution to that problem.

The enterprise architects initially createdour information model and we then askedin several iterations the department mem-bers to delete concepts from the model,which they think are not of importance.

An IT Strategist from the Transport andLogistics Industry

Once the initial decision, which informationshould be gathered, is made and an informa-tion model conforming to that decision has beenbuilt, the maintenance process has to ensure anadequate data quality. In this context, differentapproaches to ensure the actuality of data exist:

• Projects have to update the information.As projects are the means to changethe architecture of an enterprise, theproject manager is responsible for updat-ing changed artifacts.

• Data is updated in certain intervals (e.g.every year, twice a year, monthly). Thereexist defined points in time, at which theresponsible information stewards have tocheck the accuracy of the data they areresponsible for.

• Data is always kept up to date. The re-sponsible information stewards (businessapplication owners, etc.) ensure that theinformation is up to date.

• Data is automatically updated via a sys-tem. To a certain extent information,especially infrastructure information, canbe kept up to date via specialized tools(e.g. CMDBs).

Figure 3.6 provides an overview, which of theaforementioned methods of information gather-ing and maintenance are used to what extentamong our industry partners. The possible an-swers were:

• A: Automatically, e.g. by source codeanalysis, crawler

• B: In periodic cycles (annually, twice ayear, monthly,...)

• C: Continuously, in the context ofprojects

• D: Continuously through e.g. applicationor process manager


Figure 3.6: How is information of the EA man-agement currently maintained in your enter-prise? (for the meaning of the letters refer tothe option description above)

We tried the three methods [via projects,defined points in time, and the informa-tion stewards], which were planned, doc-umented, and communicated within thedepartments but none of them survivedlonger than two months.

The Team Leader of EnterpriseArchitecture from the Transport and

Logistics Industry

We experienced a high interest among our inter-view partners regarding a process for automatedinformation gathering via CMDBs or systemsmanagement tools. While 33% of our indus-try partners already use CMDBs or systemsfor automated information gathering and main-tenance of infrastructure data, further 33% isplanning to automate the maintenance via suchsystems in the near-time future (cf. Figure 3.7).

As 0% of our industry partners are totally sat-isfied with their data quality (cf. Figure 3.8)some of them developed incentives for the in-formation stewards to support the maintenanceprocess.

• A: No, not sufficient regarding topicality

• B: No, the correctness is not sufficient

• C: No, the completeness is not sufficient

• D: Yes, the data quality is sufficient

• E: n/A

Figure 3.7: Is infrastructure information auto-matically gathered in your enterprise, e.g. froma CMDB?

Figure 3.8: Are you satisfied with data quality?

Among these incentives are e.g. the establish-ment of a benchmarking process for data qual-ity to make it comparable between the differ-ent departments or organizational units or thetagging of last-modification dates of data. Fur-thermore, visibility for other departments canadditionally influence the willingness to updatedata as illustrated by the statement below:


Sometimes, staff members from depart-ments even ask for the questionnaire, asthey want to be present on the visualiza-tions of the landscape due to marketingreasons.

The Team Leader of EnterpriseArchitecture from the Transport and

Logistics Industry

Nevertheless, the process of information main-tenance heavily depends on the culture and will-ingness of the information stewards involved, asstated by our EA practitioners below:

EA management is based on heroism, ifyou have a lot of heroes at hand you willdiscover no problems. Nevertheless, heroesdon’t want to do the same all day.

Head of IT Strategy from the Transportand Logistics Industry

There are departments, which always pro-vide their updated information, but thereare others, which have another culture anddo not think its necessary to update theinformation.


3.6 Visualizations as a

Communication Ba-

sis

A picture says more than thousand words isa widely known proverb. It is also applica-ble to EA management, as visualizations area powerful tool to illustrate complex relationsand unquestioned as a means for communica-tion among practitioners.

We first tried to start a discussion on theavailable information about the EA basedon textual information, but quickly real-ized that we needed a graphical represen-tation. Utilizing the graphical representa-tion, we found out that we then could talkabout things we had not even realized be-fore.


The aforementioned importance of visualiza-tions in EA management was seen by all ofour participating partners, leading to a ”yes”-response of 100% on the question Do you seea general need for visualizations in the con-text of EA management? Further detailing onthe importance, 44% of the people involved inEA management stated, that they received theneeded information from visual sources (cf. Fig-ure 3.9), nowithstanding the fact that no estab-lished best practice notation for those visualiza-tions yet exists.

Figure 3.9: From which source do your employ-ees get the information about EA?

One possibility heavily discussed in the con-text of EA management is the Unified ModelingLanguage (UML) (cf. [Ob04, OM05]). Whereasits practicability and usability in the contextof software engineering is unchallenged, it isconsidered to be too detailed and complex tobe intuitively understandable to the top-level


management and other non-technical stakehold-ers involved in EA management. Herein, mostEA practitioners agree that more simple nota-tions (realized e.g. as MS PowerPoint presenta-tions) are more suitable to provide a high leveloverview.

The UML is used in many different depart-ments and on various abstraction levels torepresent the EA or parts thereof. The ac-ceptance in the projects to maintain infor-mation available in UML is given. Never-theless, you will never find an UML dia-gram in our presentation prepared for thehigher management.

The Head of IT Architecture from thePublic Utility Industry

If an notation other than the UML is used to il-lustrate certain aspects of the EA, the semanticsof the symbols and possible meanings of certainpositionings have to be explicated as stated be-low.

Legends are important for the understand-ability of visualizations.

An IT Architect from the ProductionIndustry

Most visualizations in the context of EA man-agement are used to start discussions aboutcertain aspects and to provide a communica-tion basis for stakeholders with different back-grounds.

Visualizations of the EA are pinned to thewalls of many meeting rooms and are takenalong by colleagues to important meet-ings. It is vital that these visualizations arepresent in the mind of the people, as theyprovide a common basis for discussions.

A Business Architect from theInformation Industry

In order to provide this common informationbasis the visualizations should contain and linkbusiness as well as technological aspects. Ac-cording to our EA practitioners, especiallythe visualization of key performance indicators(KPI) and metrics is of vital importance as theycan condense, quantity, and aggregate informa-tion.

Portfolio diagrams and possibilities to vi-sualize metrics and KPIs are of vital im-portance for us to get the business peopleinvolved.


Nevertheless, EA experts tend to show toomuch information, thus creating complex visu-alizations that are not intuitively understand-able to people not used to that kind of illustra-tion. A mechanism to hide certain informationon visualizations – e.g. the layering principle2

– can thus be useful.

Understandability is the crucial factor ofvisualizations. We, as experts, tend to puttoo much information into our visualiza-tion, which demands to much of the view-ers.

A Project Manager from the InformationIndustry

3.7 On the Importance of

Communication

Besides the various problems linked to EA man-agement processes, as information gathering,maintenance, or establishment of governance

2Refer to [Bu07] for more information on the lay-ering principle.


structures, a further challenge is the setup ofthe EA management process itself. Assure yourprocess is fully documented, explicating to thegreatest detail who has to do what at whattime. Assure also, that all involved partiesare informed. However, if they are not con-vinced about the benefits of the process, theprocess will end up dead without solving anyproblems. In order to ensure acceptance by thestakeholders and information stewards involved,one needs to communicate the necessity and thebenefits of such an approach.

It is very important that not only the enter-prise architects and the department man-agers understand the topic EA, every sin-gle staff member needs to understand andaccept the topic in order to get the EA tobe updated regularly. I think it will takeone to two years until the topic is reallyestablished.


The challenge is to get the people on board.

A Business Architect from theInformation Industry

For the communication of EA related topics48% of our industry partners follow the twofoldapproach of using text-driven documents com-plemented by visual resources (cf. Figure 3.10).

Enterprise architects are simply communi-cating people. They have to translate be-tween the business and IT people. Whatimplications does a business decision havefor the IT behind the scene and vice visa?

The Head of IT Architecture from theService Industry

Figure 3.10: How do your employees generallycommunicate/document the information aboutthe EA?

Furthermore, it is important to have the stake-holder involved in the EA management decisionprocess or at least make the resulting decisionsunderstandable to them.

If the decisions are made in an ivory towerand are only handed over to the peoplethere will be no acceptance.


In addition, it is not only important that the de-cisions are communicated but also documented,which is only achieved at 42% of our respon-dents’ enterprises (cf. Figure 3.11).

Moreover, further impacts which EA decisionsmight have, should be considered, as trans-parency of the decisions may not only have posi-tive influences to the involved stakeholders. So-cial impacts as the one stated below, should alsobe thought of.


Figure 3.11: How would you estimate the defi-nition of the goals for the evolution of the ap-plication landscape?

It is important and difficult to communi-cate the results of architectural planning.There might be business application own-ers who loose the business application theyare responsible for.


3.8 Tools for EA Man-

agement

Most of our industry partners regard tool sup-port to be necessary in order to perform EAmanagement. Although the amount of dataneeded could be stored in a simple database sys-tem or even MS Excel files, dedicated tools sup-port is beneficiary to gather, maintain, and vi-sualize this information. This is especially true,if more sophisticated functionalities, e.g. role-based access or collaboration support, are re-garded. Especially, the functionalities providedby the tools to create visualizations suitablefor different stakeholders from business, IT, ormanagement are considered an important fea-ture of an EA management tool.

I have not found a tool capable of gener-ating different visualizations especially re-garding the attribute-based coloring of ob-jects.

The Head of IT Strategy from theTransport and Logistics Industry

The market of EA management tools is still anemerging one, offering a variety of new and es-tablished tools. Table 3.1 provides an overviewof vendors positioning their tools in the field ofEA management. The table ranks these tools(see ”Total”) according to the interest of theindustry partners participating in an extensivesurvey about EA management tools [Ma08].

The origins of the different tools range frommeta modeling tools via business process mod-eling tools to visualization tools. Accordingly,the different tools emphasize different aspects ofEA management. Whereas some tools focus onthe methodology or process used to perform EAmanagement, others provide flexible visualiza-tion and meta modeling functionalities to sup-port self-developed, enterprise-specific EA man-agement approaches. In addition, some toolsprovide means for automatic information gath-ering from different sources (see Section 3.5).

It would be good to have a standardizedcore information model, that could be usedto exchange information between differenttools [...].

An Enterprise IT Architect from theProduction Industry


No Name of Vendor Name of Tool(s) Total1 alfabet AG planningIT 692 IDS Scheer ARIS IT Architect 683 Telelogic Telelogic System Architect 604 Troux Technologies Troux 555 IDS Scheer ARIS ArchiMate Modeler 536 Hewlett Packard Mercury Project and Portfolio Manage-

ment Center49

7 Casewise Corporate Modeler Suite, IT ArchitectureAccelerator

48

8 IBM Rational Software Architect 469 MEGA International MEGA Modeling Suite 4510 BOC ADOit/ADOxx 4411 Adaptive Adaptive EAM 4212 Metastorm ProVision 3813 BEA AquaLogic Enterprise Repository 3714 CA Clarity 3515 Comma Soft infonea 3516 Agilense EA WebModeler 3417 QualiWare EAM Suite 3418 Embarcadero EA/Studio 3319 Primavera ProSight 3320 process4.biz process4.biz 3321 Avolution ABACUS 3222 Sparx Systems Enterprise Architect 3223 ASG ASG Enterprise Management/Rochade 3024 pulinco TopEase Suite 3025 Visible Systems Corporation Visible Enterprise Products 3026 BiZZdesign BiZZdesign Architect, BiZZdesigner 2827 GoAgile GoAgile MAP 2828 Orbus Software iServer for EA iServer 2729 BTM Corporation BTM 360 Product Suite 2630 INOVA Engineering MERGE-Tool 2631 Intelligile Map Suite 2632 LogicLibrary LogiScan Logidex 2633 Sybase PowerDesigner 2634 Enterprise Elements Elements Repository 2535 Future Tech Systems ENVISION VIP 2536 NetViz NetViz 2537 AB+ Conseil SOLU-QIQ 2438 Acceptsoftware Accep360 2439 Framework Software Structure 2440 Knotion Consulting SYNAP-C Solution 2441 Select Business Solutions Select Component Architect 24

Table 3.1: Vendors and tools in the area of EA management


Based on a hypothetical widely-accepted infor-mation model, specialized tools for dedicatedareas (project portfolio management, IT infras-tructure management, etc.) could exchangeand integrate information as shown in Fig-ure 3.12. Simplifying the information collectionand maintenance process though automated in-formation gathering is a goal worth pursuing inthe near-time future for some of our industrypartners.

In 3-4 years there will be tools, which arebased on an implementation of ITIL andpartially update the content automatically.


EA management tools will be integratedwith ITIL tools to support different ana-lyzes e.g. how does the failure of a systemaffect my business processes.


3.9 The role of SOA

Service Oriented Architecture (SOA) has beenone of the major topics in IT management in thelast three years. Many articles have been pub-lished and many presentations have been given.They present SOA from a different perspectives,emphasize on different aspects, and aim at dif-ferent results.

EA management is a precondition for SOA.You need the information in order to beable to encapsulate functions the right way.

An Enterprise Architect from theFinancial Industry

The quotation above shows the importance ofthe relationship between SOA and EAM. There-fore, we included the topic in our interviews andin our online survey. In order to emphasizethe importance of SOA, we asked the follow-ing question in our online survey: Do service-oriented architectures play a role in your en-terprise? The participants could choose one ofthese answers:

• A: Yes, currently it is considered to intro-duce a service-oriented architecture.

• B: Yes, a service-oriented architecture isintroduced in a certain part right now.

• C: Yes, a service-oriented architecture iscurrently introduced enterprise wide.

• D: Yes, the enterprise already uses aservice-oriented architecture.

• No

The results of this question are shown in Fig-ure 3.13.

Figure 3.13: Do service oriented architecturesplay a role in your enterprise?

Only 11 % of the participants answered SOAdoes not play a role in their enterprise. Everysixth answer stated that the enterprise alreadyuses a SOA. The rest of the answers give evi-dence that the companies consider introducingan SOA, or that the introduction has alreadystarted.


Figure 3.12: Information integration

According to our interviews SOA is about in-troducing a new layer of abstraction betweenthe IT and the business to support and im-prove communication and understanding be-tween them. Typically SOA is thereby under-stood by the participants of our survey as fol-lows.

From an IT perspective, functionalities to sup-port business processes have so far been pro-vided by business application. This task is nowaccomplished by services. Services may existon different levels of granularity, ranging fromsimple database calls up to aggregated serviceslike a service for billing an order, which in-cludes calling other services. The focus on ser-vices should foster reuse of services and reducecosts, as functionalities only have to be imple-mented once and can then be reused by otherservices. Additionally, the participants of oursurvey mentioned that the concept of buildingblocks should enhance flexibility in respect tochanges, e.g. in the supported business pro-cesses.

Concerning the business perspective, the partic-ipants regarded SOA as a way to reorganize theEA with a focus on business support. In thiscontext business processes and business capa-bilities, which have to be supported by servicesand are organized in domains are in the spot-light.

The question, ”what is SOA all about” receivedwidely spread answers in our interviews, rang-ing from SOA is pushed by vendors and will onlyhave minor impact to SOA means modulariza-tion of the application landscape. Sometimes,SOA is further mixed up with Software-as-a-Service, meaning to rent a service, instead tobuy, or build a software.

Overall, the following statements were made inthe interviews

• SOA is nothing new, we have been doingthis for a long time.

• We are migrating to SOA.


• We are waiting for experiences of othercompanies or results of pilot projects.

• Telecommunication companies have em-braced SOA early.

Two things are crucial for SOA, standardizedbusiness processes and a shared data repository.Business processes need to be standardized anddocumented for services being able to supportthem and offer potential for reuse. Thus, theparticipants had to answer the following ques-tion: The processes in the different units (sec-tions, divisions, regional companies, etc.) of theenterprise are

• A: standardized and defined.

• B: autonomously, not standardized andnot defined.

The results in Figure 3.14, show that 59 % ofthe participants regarded the business processesin their company to be standardized and given.

Figure 3.14: Standardization of business pro-cesses (the letters A,B are introduced above)

In many companies a high-level aggregation ofthe business architecture above the businessprocess-level, e.g. via business domains is con-sidered an important prerequisite to the imple-mentation of an SOA.

Creating a domain structure is needed foran SOA.

The Head of IT Strategy from theTransport and Logistics Industry

SOA needs a good business architectureand a stable process for further develop-ment.


This high level business architecture can beused as a framework to structure the servicelandscape by assigning each service to a do-main. This helps to avoid services with over-lapping functionality and organizes the wholelandscape into manageable pieces.

A business model behind SOA is needed,offered functionality has to be paid.

An Enterprise Architect from theTransport and Logistics Industry

Simply introducing an SOA is not enough, anSOA has to be based on a business model. Run-ning services creates costs, which have to bepaid by someone within the company. Aggra-vating is that a basic principle in an SOA is there-use of services. Typically, the organizationalunit providing a service is not the same whichuses the service. Consequently, accounting forrunning and using services is needed, which alsorequires to measure e.g. the number of usages,etc. as a basis for billing.

High costs arise for managing dependenciesbetween services and their usage.

An Business Architect from theInformation Industry


Charging may be based on processes andtheir support by services. A lot of datahas to be collected to do the billing.

An Enterprise Architect from theTransport and Logistics Industry

After discussing different aspects of SOA, wefurther analyzed, what the participants of thesurvey thought about SOA in general. Theseopinions are discussed alongside the followingquotations.

SOA is pushed by vendors.

The Head of Information Technology fromthe Production Industry

A similar impression has been pointed out bythree of the participants and shows that an SOAis not only introduced because there is a need tointroduce it, e.g. to increase the agility in sup-porting new business demands, but that SOA isalso introduced because the software productsfrom third parties, which are in use are basedon service oriented concepts. This may resultin a need to introduce a serviceoriented infras-tructure.

Also, the participants at the survey associatesome positive effects with SOA:

Gaining new flexibility, driven by processmanagement, is one goal of SOA.

An IT Architect from the InformationIndustry

Using SOA, a more holistic understandingwill emerge from business to applications.

An Enterprise Architect from theInformation Industry

Both quotations point to an increased cooper-ation between business and IT resulting in amore holistic approach to manage the EA.

3.10 Metrics and KPIs

You can’t manage what youdon’t measure.

It is an old management adage that is still accu-rate today, but in EA management more oftenthen not metrics are only considered to be im-portant but they are not really used in practice.For this reason we analyzed metrics used in thecontext of application landscape managementas a part of EA management.

The initial prerequisite for using metrics in EAmanagement is the inclination of practitionersto use this kind of instrument. This was sur-veyed via the following question: Has your or-ganization used metrics in managing the appli-cation landscape up to now, or if not, do youregard metric usage possible in your organiza-tion?

Figure 3.15: Current metric usage in the sur-veyed organizations

The evaluation results (see Figure 3.15) showthat a large share of practitioners indicated thatthey actually use metrics, while an even largershare saw usage as a future possibility. Only aminority viewed metrics as not sensible. In thequestionnaire, the practitioners were also askedto indicate their experience in IT and in EAmanagement, and which kind of education theyhad received. Further analysis of this data con-ducted in [La08] suggests that stakeholders with


a business background are more inclined to usemetrics.

In order to obtain more detailed insight intothe aspects which practitioners would like toaddress EA concerns by using metrics, the on-line questionnaire provided a set of quality at-tributes for an application landscape, whichcould be assigned an importance rating. Thefollowing attributes had previously been gath-ered and refined by us together with practition-ers from a financial service company in a projectrelated to application landscape management in2005 (see [La08]):

• Maintainability indicates the effort con-nected to technical development andmaintenance.

• Flexibility relates to the question, ifchanges in business functionalities areswift and inexpensive.

• Testability is concerned with the effort oftesting the landscape.

• Performance considers the fulfillment ofservice level agreements by the systems ofthe application landscape.

• Scalability relates to the question, howthe landscape supports distributing loadto additional hardware.

• Operational Risk indicates the businessrisks posed by the application landscape.

• Operational Cost advantages in opera-tion are concerned with the expenses con-nected to operating the application land-scape.

• Installability refers to the effort of deploy-ing new systems in the application land-scape.

• Functionality indicates the business sup-port offered by the application landscape.

A question was used to survey information onthe attributes’ importance. The participantswere given the possibility to assign an impor-tance rating to each attribute on a five pointscale (1 not interested in – 5 very interestedin): Which attributes of an application land-scape would you like to examine using metrics?

The results of the question are presented in Fig-ure 3.16 as average importance rating assignedto the respective attribute. Business relatedattributes, as functionality or operational riskwere rated high, the more technical quality at-tributes as maintainability and installability re-ceived the lowest ratings. Since stakeholderswith a business background tend to favor met-rics usage, these ratings are easily explained bythe fact that these technical attributes lack di-rect business relevance.

Figure 3.16: Importance values for the surveyedquality attributes

To better understand the expectations concern-ing the use of metrics in the enterprise, weasked the following question with the optionspresented below again rated on a five point scale(1 not important – 5 very important): Whatproperties of metrics are important to you?

The results shown in Figure 3.17 indicate, thatmetrics are mainly means of communicationand thus should be well understood and havea communicable meaning, while the calculationprocedure does not need to be as simple. Thiswarns against the often used ”simple counts”,as e.g. number of interfaces, of which the


Figure 3.17: Important properties for landscapemetrics

implications on business are only vaguely sus-pected. Metrics, which are sound and simpleand have a meaning relevant to business, areneeded to bridge the communication gap be-tween the business and IT in managing the EA.

Another important question is the goal practi-tioners have in mind when using metrics. Fourcategories of utilization were distinguished:communicating facts, understanding facts, de-cision support, and fast overview. Those cat-egories could again be rated on a five pointscale (1 not important – 5 very important).Figure 3.18 gives the results highlighting againmetrics as an instrument to facilitate commu-nication.

Figure 3.18: What are the goals in using met-rics?

Besides the goals of using metrics, we examinedthe scenarios, in which metrics are used. Par-

ticipants of the survey could rate four differ-ent usage scenarios on a five point scale (1 notimportant – 5 very important). The scenarioswere: understanding problems, predict effectsof actions, setting goals and check their achiev-ment, and show status quo and possibilities forimprovement.

Figure 3.19: What are the usage scenarios ofmetrics utilization?

The results in Figure 3.19 show that the twousage scenarios setting goals and showing statusquo and potential are of most importance withunderstanding problems being the least impor-tant scenario.

Besides the usage scenarios analyzed in theaforementioned question, two different applica-tion areas have to be considered: Business andIT aspects.

The business value has to be measured, notonly IT efficiency or costs. This demandsthe business to be part of EA management.


Only if a combination of business and IT relatedmetrics is used in an EA management approach,an integration and collaboration of both stake-holder groups can be achieved.

As a conclusion, metrics can be regarded an im-portant aspect in EA management. In contrast


to this, the interviews showed that only a mi-nor part of the surveyed companies are reallyusing metrics on EA level on a regular basis.Nevertheless, the field of metrics for EA man-agement is a young and promising one, worthfuture research.

A reason for this difference may be that partic-ipants of the online survey were not identical tothe participants of the interviews.

The following quotation gives a good indicationof how most of the participants in the interviewsperceive application landscape metrics.

Basically an interesting subject, but thefield is still immature.

The Head of IT Architecture from thePublic Utility Industry


4Outlook

I have seen many different documentationsin various styles, ranging from ”take the filefolder in the shelf behind Anja” to formaldescriptions.

A Project Manager from the FinancialIndustry

The anecdote exemplifies that there are manydifferent approaches to do EA management,which range from very informal ones over typi-cal EA management frameworks to those basedon more formal techniques.

In order to find a compromise between these dif-ferent approaches, we have developed the con-cept of EAM Patterns. These patterns com-plement existing EA management frameworks,providing a holistic and generic view on theproblem of EA management, and provide addi-tional detail and guidance needed to systemat-ically establish EA management in a step-wisefashion within an enterprise.

The EAM Patterns are part of the EAM Pat-tern Catalog, which identifies the dependenciesbetween

• individual management concerns (Whichgoal is to be achieved for which stakehold-ers?),

• management methodologies (Which ac-tivities are required to address a givenconcern?),

• supporting viewpoints (Which diagrams,figures, tables, listings, etc. help stake-holders to collaboratively perform theseactivities?), and

• information models (Which informationis required to create a particular view-point?).

Methodologies, viewpoints, and informationmodel fragments are thereby called EAM pat-terns. An EAM Pattern is a proven practice-based, general, and reusable solution to a com-mon problem in EA management, for a givencontext, identifying driving forces, denotingknown usages, and consequences. They canand may have to be adapted to a specific en-terprise context. Four different kinds of EAMpatterns are included in the EAM Pattern Cata-log: methodology patterns (M-Patterns), view-point patterns (V-Patterns), information modelpatterns (I-Patterns), and Anti-Patterns.

The EAM Pattern Catalog, as a collection ofobserved proven-practices in EA managementsupports different usage scenarios for companiesin the context of EA management:

• Establishing an organization-specific EAmanagement through EAM Pattern inte-gration

• Inspiring and assessing an already imple-mented EA management approach

• Specifying requirements and goals for EAmanagement

To support the future development and refine-ment of EAM patterns and the documenta-tion of additional ones, these patterns are docu-mented in the EAM Pattern Catalog Wiki. Thiswiki also provides case studies, articles, and lat-est news on EAM Patterns. It is available onlineat

http://eampc-wiki.systemcartography.info.


http://eampc-wiki.systemcartography.info

Bibliography

[Bu07] Buckl, S. et al.:. Generating Visualizations of Enterprise Architectures using ModelTransformation (extended version). Enterprise Modelling and Information Systems Ar-chitectures – An International Journal. 2(2). 2007.

[DD04] Department of Defense:. DoD Architecture Framework (DODAF) Version 1.0: VolumeI: Definitions and Guidelines. 2004.

[In05] IT Governance Institute: Cobit 4.0. Rolling Meadows, IL, USA, 2005.

[JZ92] J.F., S.; Zachman, J.:. Extending and Formalizing the Framework for Information Sys-tems Architecture. IBM Systems Journal. 31(3). 1992.

[La08] Lankes, J.:. Metrics for Application Landscapes – Status Quo, Development, and a CaseStudy. PhD thesis. Technische Universitat Munchen, Fakultat fur Informatik. Munich,Germany. 2008.

[Ma08] Matthes, F. et al.:. Enterprise Architecture Management Tool Survey 2008. TUMunchen, Chair for Informatics 19 (sebis). Germany. 2008.

[MW05] Macharzina, K.; Wolf, J.:. Unternehmensfuhrung. GablerVerlag. Wiesbaden. 5 edition.2005.

[Ob04] Object Management Group (OMG):. UML 2.0 Superstructure Specification (formal/05-07-04). 2005.

[OM05] Object Management Group (OMG):. UML 2.0 Infrastructure Specification (formal/05-07-05). 2005.

[Th07] The Open Group:. The Open Group Architecture Framework (TOGAF) ”EnterpriseEdition” Version 8.1.1. 2007.

[Th09] The Open Group:. The Open Group Architecture Framework (TOGAF) ”EnterpriseEdition” Version 9. 2009.

[WR04] Weill, P.; Ross, J.:. IT Governance – How Top Performers Manage IT Decision Rightsfor Superior Result. Harvard Business School Press. Boston, Massachusetts. 2004.

[Za87] Zachman, J.:. A Framework for Information Systems Architecture. IBM Systems Jour-nal. 26(3):277–293. 1987.


State of the Art in Enterprise Architecture Management 2009

Technology

Transcript of State of the Art in Enterprise Architecture Management 2009