Towards a Method Framework for EnterpriseArchitecture Management – A Literature

Analysis from a Viable System Perspective

Sabine Buckl, Florian Matthes and Christian M. Schweda

Chair for Software Engineering of Business Information Systems (sebis),Technische Universitat Munchen,

Boltzmannstr. 3, 85748 Garching, Germany{buckls,matthes,schweda}@in.tum.de

http://wwwmatthes.in.tum.de

Abstract. The discipline of enterprise architecture (EA) managementis albeit a long history still developing. This is becomes obvious, whenliterature on the EA management function is analyzed. Multiple ap-proaches describe different make-ups for the overall function, while acommon sense does yet not exist. In this paper, we analyze EA manage-ment functions as proposed in literature from a systemic perspective andderive typical management activities such a function should encompass.Based on these activities, a method framework for EA management isderived, which is assessed in a case study from the financial industry.

1 Motivation and overview

Enterprise architecture (EA) management is a discipline, which has recentlygained increased attention from academia and practitioners. Thereby, a few top-ics which are nowadays regarded to be part of EA management, have a longhistory in information systems research. This can be exemplified with the topicof business-IT-alignment, which has been discussed e.g. by Henderson and Venka-traman in the late nineties as strategic alignment [1]. While these discussionsmight have catalyzed the evolution of EA management, the overall discipline isstill subject to ongoing development. This in particular applies as different re-search communities continue to argue on the perspective, from which EA man-agement should be approached. Some researchers emphasize on business aspects,advocating for an understanding of EA management as an economic managementdiscipline (cf. Frank in [2]). In contrast, other groups point to the engineeringaspects (cf. Aier et al. in [3]) or take a systemic perspective on the topic (cf.Buckl et al. in [4] and Wegmann in [5]). The approaches nevertheless agree thatEA management needs to provide a holistic view on an enterprise, accountingfor aspects from all layers, ranging from business to IT aspects.

Regardless of the question of perspective, other indications for the ongoingdevelopment of the EA management discipline exist. A prominent example forthis is the topic of EA modeling. Although most EA management approaches

M. Petit, G. Gal, A. Castiaux, J. Ralyté, and P. Plebani (Eds.):CAiSE 2010 Workshop BUSITAL’10, Hammamet, Tunisia, pp. 46-60, 2010.

emphasize on the importance of modeling the EA, no common metamodel (calledinformation model in accordance with Buckl et al. in [6]) has yet been estab-lished. In the last years, many information models were proposed but none ofthem has yet gained broad acceptance. Some researchers even challenge the hy-pothesis that such a model exists (cf. Buckl et al. in [7] and Kurpjuweit andWinter in [8]). They expect enterprises to have largely different expectationson the benefits of EA management, and therefore assume that an informationmodel is an enterprise-specific artifact. Similar discussions apply to the overallmake-up of the EA management function. Many different activities have beenargued to be inseparable parts of EA management (see Section 3). In contrast,approaches presenting constituents of the EA management function or compre-hensive processes descriptions are rare in academic literature (for one example cf.Hafner and Winter in [9]). Similarly, few practitioners (cf. Niemann in [10] andSchekkerman in [11]) and standardization bodies (cf. The Open Group in [12])discuss processes but stay on a fairly abstract level. These processes are usuallycomplemented with a remark that ”they have to be adapted to the company’sneeds”[12], while the details of this adaptation are left to the reader.

We expect the EA management function, similar to the information model,to be enterprise-specific, although – on a more abstract level – every EA man-agement function might be comprised of similar activities. Thereby, we mustprovide additional clarification in respect to the understanding of the term EAin different research communities. While some researchers refer to the term EAas the management function, aiming at managing the evolution of the EA, othersregard the EA as the inevitable fact, which refers to the make-up of the enterprisesummarized as ”every system has an architecture”[13]. The terminology used inthis paper adopts the later wording and clearly distinguishes between the artifact(EA) and the corresponding management function (EA management).

The article presents a first step towards establishing a consolidated methodframework for EA management, which can be configured according to theenterprise-specific needs of a company. The framed method is grounded in asystemic perspective on EA management, which is exhibited in Section 2. Fromthis perspective, Section 3 revisits prominent approaches to EA managementfrom literature and collects typical work packages that these approaches pro-pose. In addition, the representations of the EA, the so called EA descriptions,are analyzed. With the activities and the descriptions at hand, Section 4 proposesa method framework for EA management, consisting of four main activities ofan EA management function and three different types of EA descriptions. Theframework further describes how the activities relate to each other, and spec-ifies which descriptive information about the EA is exchanged between them.In this respect, it can be regarded as abstract method framework for the EAmanagement function, providing the answers to the article’s research questions:

– Which typical activities constitute an EA management function?– Which information objects are created by, exchanged between, and used for

these activities?– How do the activities relate in a method framework for EA management?

Towards a Method Framework for Enterprise Architecture Management 47

Section 5 sketches the results of a case study on the EA management functionof a company in the financial industry. We thereby show to which extent themethod framework can be validated. The article concludes with Section 6, whichsummarizes the findings, shows limitations of the research approach chosen, andgives indications of future areas for research.

2 EA management from a systemic perspective

Enterprises form highly complex systems consisting of various different elementsinterlinked by a large number of interdependencies. These systems are furtherembedded into a changing environment that they continuously have to adapt to.In particular, market changes and new legal requirements force enterprises to ad-just their architectures, e.g. to rework their business processes or to evolve theirIT artifacts. Additionally, newly emerging technologies may enable new businessopportunities that an enterprise should proactively seek to gain competitive ad-vantage (Ross et al. in [14] and Wagter et al. in [15]). Both the reactive andthe proactive change of the enterprise fall into the responsibility of enterprise-level management functions, as application or project portfolio management, butalso of the EA management function. In this respect, the different managementfunctions on the one hand and the EA management function on the other handform an interacting system. Understanding this system of systems is a necessaryprerequisite for developing a method framework for EA management.

The viable system model (VSM) (Beer in [16, 17, 18]) provides a frameworkfor describing complex management systems from a systemic perspective. In thefollowing, we discuss the five subsystems of the VSM – operation, coordination,control, planning, and identity – and identify these subsystems with constituentsfrom the EA management system.

– The enterprise-level management functions form system one (operation) di-rectly changing the EA via projects. Especially the management functions sur-rounding the project lifecycle contribute to system one. Exemplary functionsare: enterprise-wide demand management, where demands are captured andprioritized; strategies and goals management, where demands and projectsare aligned with the enterprise’s goals; synchronization management, whereproject dependencies are monitored (cf. Wittenburg et al. in [19]).

– The communication function of EA management forms system two (coor-dination) by which architecture descriptions are distributed via appropriatecommunication channels. Thereby, the different enterprise-level managementfunctions (cf. Wittenburg et al. in [19]) are provided a shared understand-ing of the as-is (current) and the to-be (planned) state of the EA. Based onhis shared understanding peer-level coordination between the enterprise-levelmanagement functions should be fostered.

– System three (control) forms the reactive function of EA management, that es-tablishes higher level control over the coordination function. In particular, the

48 S. Buckl, F. Matthes and C. Schweda

reactive EA management observes the behavior of the enterprise-level man-agement functions in coordination and assures that no ’oscillatory’ effects be-tween these functions develop. This would for instance be the case, if projectswould adapt to comply with current architectural standards for business ap-plications, while simultaneously the standards were adapted to incorporatethe realities of the new application portfolio.

– Where system three ensures stability in the interactions of the enterprise-levelmanagement processes, EA management also encompasses a proactive func-tion in system four (planning). Latter system is responsible for anticipatingchanges in the environment of the enterprise and for addressing these changesby altering the status-quo that is maintained by the underlying homeostaticcontrol in system three.

– Completing, system five (identity) is responsible for EA management gover-nance, i.e. is concerned with questions of the overall scope and reach of EAmanagement. It further shapes the design of the EA management functionitself. Thereby, it ensures a balance between short-term and long-term efforts,and steers the EA management system as a whole.

3 State-of-the-art in EA management literature

This section provides an overview about selected EA management approachesfrom a viable system perspective as introduced above. Thereby, we focus onactivities described as being part of the EA management function and detail onthe EA descriptions they expect for input or provide as output. In the descriptionof the approaches, the original terms employed by the authors are used.

One of the most prominent frameworks for EA management is proposed byThe Open Group – The Open Group Architecture Framework (TOGAF) ([12]).The core contribution of TOGAF in respect to describing the EA managementfunction is the Architecture Development Method (ADM), which delineates howan EA can be developed and maintained. The ADM describes EA managementas an iterative and stepwise process consisting of different phases. The initializa-tion of one EA management cycle is performed in the preliminary phase, wheredecisions about the scope and reach of the management endeavor are made (sys-tem 5). Thereby, the topic how to link EA management to other enterprise-levelmanagement functions is decided upon. The following four phases architecturevision, business [architecture], information systems [architecture], and technologyarchitecture are concerned with the development of a target state, the investi-gation of the current state, and gap analyses comparing these states. From aviable system perspective these phases present the reactive and proactive EAmanagement. The transition planning from the status quo to the desired targetarchitecture is performed in phase opportunities and solutions and decided uponin phase migration planning. The execution of the transformation is monitoredin the implementation and governance phase. Finally, the overall performanceof the management process is measured and assessed in the phase architecture

Towards a Method Framework for Enterprise Architecture Management 49

change management, which therefore deals with aspects of EA management gov-ernance. The aforementioned phases are continually adapted to the needs andconcerns of the stakeholders in an activity, called requirements management.TOGAF complements the description of the activities with elaborations on theinput and output artifacts of each phase – namely visualization artifacts, e.g.a solution concept diagram or a business interaction matrix, as well as textualdocumentations, e.g. reports or catalogs. The aforementioned EA descriptionstogether with the stakeholder management, which a dedicated chapter of TO-GAF emphasizes on, contribute to the communication task of EA management.A characteristic of the TOGAF framework is that each iteration of the ADMcycle is project-driven, which on the one hand guarantees the sponsorship forthe EA management initiative, but on the other hand makes it hard to ensurethe continuity of the outcomes. A consequence of this approach is the absenceof an activity, which keeps the EA documentation up to date.

Similar to the TOGAF ADM, Schekkerman [11] describes EA managementas an iterative and stepwise process. Each iteration starts with the developmentof the EA vision (phase 1), which defines the environment, business drivers, andguiding principles. In addition, the scope and context (phase 2) as well as thegoals, objectives, and requirements (phase 3) of the EA management endeavorare defined. Subsequent phase 4 derives different opportunities and solutionsfrom existing documentations of the current state and future architecture plans.Thereby, special attention is paid to support decision making during manage-ment via adequate visualizations, models, and reports, which are chosen in thisphase. Based on the opportunities identified in the preceding phase, differentevolution scenarios are developed and evaluated regarding their organizationalimpact (phase 5). The costs and benefits of the scenarios are analyzed via busi-ness case calculations (phase 6) to support funding of the EA managementendeavor. The results of the preceding phases are used in phase 7 to set up ascheduled transformation plan, including capability planning for the EA. Finally,a governance structure is implemented (phase 8), which defines the responsi-bilities as well as roles, groups, and committees needed. The EA descriptionsdeveloped in and exchanged between the phases are only briefly alluded to. Fur-ther, viewpoints used in the different phases of the EA management process areonly discussed with regards to content without providing graphical representa-tion. Furthermore, EA management governance is not presented as being partof the EA management function, although the importance of EA managementmaturity is discussed and a model to assess the maturity is presented.

Niemann also emphasizes on the iterative and stepwise nature of EA man-agement incorporated in the corresponding management ”cycle”, that consists offour phases – document, analyze, plan, and act – and a parallel check phase [10].The document phase is concerned with gathering and maintaining informationabout the current state of the EA. The architects have to decide on the adequatelevel of detail of the documentation and define the appropriate EA descriptionsto populate the model as part of the communication system of EA management.For the latter case Niemann further proposes different kinds of visualizations

50 S. Buckl, F. Matthes and C. Schweda

in [10], which can be used to document parts of or provide an overview overthe EA. Although the approach elaborates on questions regarding what shouldbe documented, it does not detail on the question how this information shouldbe gathered and maintained. Based on the documentation an analysis of thecurrent state of the EA is performed in order to identify potentials for improve-ment and optimization (reactive EA management). Niemann presents differentareas for analysis, e.g. dependencies, heterogeneity, complexity, or conformityand provides methods as well as appropriate visualizations to perform the anal-ysis. During the plan phase integrated development plans leveraging identifiedpotentials for improvement and optimization are established. They representplanned states of the EA that are further assessed regarding their impact one.g. business and IT goals, costs, and risks. The assessment should result in theselection of the optimal development plan in respect to the criteria devised be-fore. This plan is realized in the act phase. Therefore, on the one hand referencearchitectures and blueprints are developed and implemented. On the other handthe required governance structures and processes are set up, e.g. the role andresponsibilities of the enterprise architect are refined. In respect to the viablesystems perspective a focal point in the approach lies on the reactive system ofEA management. The EA management governance system is presented in thecheck phase, in which the performance of the previously described phases is mea-sured and controlled. Thereby, key performance indicators (KPIs) are defined toanalyze the overall performance of the EA management endeavor.

Hafner and Winter present a consolidated process model for enterprise ap-plication architecture management in [9]. Although the paper restricts itself toenterprise application management, the approach is discussed here, as the pre-sented process model is designed with the goal of effective and efficient business-IT-alignment, and therefore takes an EA perspective. The process model con-tains the phases architecture planning, architecture development, architecturecommunication, and architecture lobbying. The architecture planning phase isconcerned with the documentation of current states of the EA. Thus, also EAprinciples are identified, derived, and updated, which guide the evolution of theEA. The proactive and reactive aspects of EA management are reflected in thearchitecture development phase, in which strategic and operational requirementsregarding the EA are continuously recorded, consolidated, and prioritized. Sub-sequently, these requirements are incorporated in planned states of the EA. Thephases architecture communication and architecture lobbying explicitly refer tothe communication function of EA management. Nevertheless, aspects on howto relate the EA management endeavor to existing enterprise-level managementprocesses are only briefly alluded to. More precisely, Winter and Hafner in [9]resort their approach to identifying target groups for training, information de-livery, etc. While the task of analyzing the EA is made explicit as part of theconsolidated process model, the assessment and improvement of the EA man-agement approach itself (EA management governance) is not discussed.

Another prominent approach in the field of EA management is the systemicenterprise architecture methodology (SEAM) [5]. The methodology defines the

Towards a Method Framework for Enterprise Architecture Management 51

role of EA management as to federate the efforts of the specialists [from theenterprise-level processes] to ensure successful projects. This point-of-view inter-prets EA management as the glue between the different processes, i.e. bringingtogether information in this multi-disciplinary environment, thereby especiallyemphasizing on the communication function. The federation of efforts is achievedvia enterprise models, which form means of analysis and communication of EArelevant information. These models account for the multi-disciplinarity of the en-vironment, but go beyond specific models for each discipline, e.g. process chainsor network topology models. They provide an integrated view on the enterprise.In [20], Le and Wegmann 2005 highlight two additional aspects of EA man-agement: firstly, the reactive aspect, which deals with necessary business andtechnology changes ex post; secondly, the proactive aspect, which anticipatesfuture changes of that kind and prepares the enterprise to them by increasingagility and flexibility. In contrast SEAM abstains from discussing questions ofhow to establish and govern the EA management process.

In addition to the aforementioned approaches, which claim to define theirown EA management function, various approaches exist that focus on selectedtopics in the context of EA management. Lankhorst et al., for example, detail onthe topics of EA communication, documentation, and analysis in [21]. Therefore,a specialized modeling language is introduced, which fosters the communicationbetween business and IT stakeholders, and can also be used for documentingcurrent, planned, and target states of the EA. As means for decision-support,different kind of analysis techniques, including analtytical and simulation tech-niques are discussed. Thus, the approach focuses on aspects of reactive andproactive EA management in the sense of a viable system perspective, while theaspect of the communication system is discussed as a side-effect of the proposedmodeling. Similar considerations hold for the approach of multi-perspective en-terprise modelling (MEMO) presented by Frank [2]. The approach focuses onthe activity of EA modeling by providing special purpose languages for differ-ent parts of the EA, e.g. the IT modelling language (ITML) [22] – for modelingIT related aspects – or for different activities performed in the context of EAmanagement, e.g. the ScoreML [23] – contributing to the field of analyzing EAs.Although, the EA management function is not in the focus of the approach ofFrank, he contributes to the field of reactive and proactive EA management inthe terms of our viable system perspective.

4 A method framework for EA management

Based on the above discussions of the EA management function and specialpurpose approaches for dedicated EA management activities, we devise a methodframework for EA management. Central to our framework is the understandingof the three different architectural states – current, planned, and target – thatcan be found throughout the approaches discussed in Section 3. Table 1 revisitsthe state-of-the-art in EA management with a focus on EA descriptions.

52 S. Buckl, F. Matthes and C. Schweda

[2] [5] [9] [21] [10] [11] [12]target state # H# H# # planned state H# current state H#

Table 1. EA description in literature

These architectural states are subject to different activities during EA man-agement. Aggregating them to a high level view, we identified activities for

developing and describing an architecture state, which is concerned with de-scribing the enterprise-level management functions (system one) as well asdeveloping planned and target states of the EA in an proactive manner (sys-tem four),

communicating and enacting an architecture state, which considers communi-cation function aspects (system two),

analyzing and evaluating and architectural state, which analyses architectural(system three), and

configuring and adapting the EA management function itself, which representsEA management governance (system five).

Table 2 revisits the state-of-the-art from Section 3 and summarizes the results.

[2] [5] [9] [21] [10] [11] [12]Develop & describe H# H# H# Communicate & enact # H# # # #Analyze & evaluate # Configure & adapt H# # # H# H# H#

Table 2. EA management activities in literature

The method framework for EA management provides the abstract frameconsisting of the aforementioned activities and EA descriptions, any EA man-agement endeavor encompasses. This framework is not concern1-specific, i.e., it isa generic method that can be used in combination with typical EA managementconcerns as e.g. discussed in [25]. As detailed below, the activity configure andadapt activity is concerned with determining the scope and reach of the EA man-agement function. Thus, the goals of the EA management endeavor are mappedto corresponding concerns, which can be detailed utilizing concern-relationships(cf. [26]). Subsequently, we introduce the activities of the method frameworkbriefly and provide additional details on the architectural descriptions that arecreated and consumed by activities. The activity develop and describe is further

1 The term concern is used here in accordance with its definition in the ISO Std.42010, which defines a concern as ”those [areas of] areas of interest which pertainto the system’s development, its operation or any other aspect that are critical orotherwise important to one or more stakeholders” [24].

Towards a Method Framework for Enterprise Architecture Management 53

subdivided to exemplify the development and description of current, planned,and target states of the EA. Similar subdivisions could be introduced for theother activities but are not detailed here for reasons of brevity.

Develop & describe target state – This activity is concerned with cre-ating a target state of the EA based on the business and IT strategies that theenterprise seeks to implement. Different sub-activities are e.g. the creation of atarget business architecture and the design of a target application portfolio. Inthe target business architecture the future product portfolio of the enterpriseis reflected and complemented by corresponding business processes. The targetapplication portfolio is designed towards the support for the intended businessarchitecture. In addition, a target infrastructure architecture is set up, describ-ing the basic services as well as the execution environment, which the businessapplications can rely on. The target state further goes beyond simple architec-tural descriptions on different EA levels. It establishes architecture principlesthat guide the evolution from the current to the target state. Such principlesreflect specific parts of the business or IT strategy that do not directly shapethe make-up of the future architectures. To exemplify this, one could think ofan outsourcing strategy that would be converted to an architectural principledemanding that support for business processes of low criticality is not providedin-house, if a suitable outsourcing provider is available.

Develop & describe current state – This activity is concerned with cre-ating a description of the current state of the EA, i.e., the as-is architecture.Thereby, all levels of architectures ranging from business and organization level,via the application and information level, to the infrastructure and data levelare considered. Further, information on projects, which affect the EA, as well ason business and IT strategies is documented. The same is true for informationon current architectural principles and standards. The develop & describe cur-rent state activity is thereby greatly influenced by the EA concerns that drivethe EA management function. For implementing the activity, different ways canbe used, ranging from documentation endeavors on regular basis, to continuousendeavors accompanying the EA relevant projects (cf. Moser et al. in [27]). Irre-spective the chosen way, the activity develop & describe current state providesand maintains an appropriate description of the current state of the EA.

Develop & describe planned state – With the target and the currentstate at hand, the activity derives intermediary architectural plans that are re-alized by projects. These projects are thereby, not solely derived from the twoarchitecture descriptions, but also based on the demands, from enterprise-widedemand management. In this respect, a planned state is not expected to strictlydevelop towards the target state, but can also pursue a different road of devel-opment in response to an urgent business need. The intermediary states are inthis way tightly coupled to the planned projects that are necessary for their im-plementation. More precisely, each planned project of EA relevance contributessome changes to an intermediary state of the EA. By selecting sets of architec-turally compatible projects, i.e., projects whose changes do not interfere, differentscenarios for the intermediary states can be derived. The descriptions of these

54 S. Buckl, F. Matthes and C. Schweda

scenario architectures, which also encompass references to the thereby addresseddemands, form the output of the activity develop & describe planned state.

Communicate & enact – EA management is heavily concerned with mak-ing plans as well as defining architectural principles and propagating them tothe enterprise-level management functions. This propagation aims at influenc-ing the decision making in the related functions. Therefore, communicating andenacting architectural principles is always connected to contributing to the de-cision making in the enterprise-level management functions. Enacting takes thearchitecture plan and principles as input and effects the decision making in theother management functions. Again, as with the other activities, different waysto implement the activity communicate & enact exist. These range from thefairly non-interfering way of informing the decision makers to the most powerfulmethod of having the right to stop projects, which are non-conformant to theEA. This activity hence always takes the description of the planned EA and thearchitectural principles as input, but can create multiple output artifacts thatare handed over to the enterprise-level management functions. These artifactsthereby depend on the method of communication and enactment chosen.

Analyze & evaluate – At some points during the management of the EA,different states of the EA, i.e. current, planned, and target state, or architecturalplans, i.e. different scenarios of the planned state, exist. The analyze & evaluateactivity makes these architectures comparable in order to prepare a subsequentdecision on the state to pursue. Different properties of the architecture maythereby be of interest, ranging from the compliance with architectural principlesto economic properties. Functional properties of the architecture, as e.g. theprovided business support, may also be important (cf. Niemann in [10]). Mostcommonly non-functional properties, e.g. the availability of certain business ser-vices (cf. Johnson et al. in [28]) or the flexibility of the overall architecture areused for analyzing different states. In literature, a broad variety of approaches toEA analysis have been proposed, differing widely in respect to the employed levelof formalization, ranging from expert-based assessments (cf. Niemann in [10]) toindicator-based computations (cf. Frank et al. in [23] and Iacob and Jonkersin [29]). The approaches also vary concerning their time reference: some ap-proaches are designed to analyze current architectures (cf. Niemann in [10]),while other approaches (cf. De Boer et al. in [30]) provide prediction capabilitiesthat can be used to analyze architectures not yet realized.

Configure & adapt – Before starting an EA management endeavor thegoals and objectives of the initiative should be clearly defined. Based on thesegoals, decisions must be taken during the activity configure & adapt regardingthe management subject of the EA management function. Relevant stakehold-ers must be identified and the concerns, which should be addressed, need tobe defined. Further, decisions on the scope and reach on the EA managementfunction must be made, ranging from bottom-up approaches, in which only acertain division of the enterprise is considered regarding a certain aspect likestandardization, to top down approaches, where the whole enterprise is exam-ined regarding multiple aspects like risk management, compliance, etc. After the

Towards a Method Framework for Enterprise Architecture Management 55

initial establishment of an EA management function, the configure and adaptactivity is concerned with measuring the overall performance of the EA man-agement function. Adaptations can be necessary, e.g. if the enterprises matureor the scope and reach of EA management change.

The above described activities form an idealized framework. In reality, thedifferent activities of the EA management function are executed parallel andwith distinct frequency and duration. The method fragment does controverselynot add prescriptions on the frequency and ordering of the activities and stepsto be taken, but provides an abstract and general frame of the main constituentsof an EA management function.

5 A case study from the financial industry

In order to validate the method framework for EA management, we conducteda case study in the financial industry. Subsequently, we give a short character-ization of the enterprise at hand and then discuss to which extent the methodframework can be used to classify the approach taken.

The case study was conducted at an internationally operating bank fromGermany. The topic of EA management has a long history in this enterprisesince a merger in the year 1996. Prior to the merger both companies indepen-dently conducted enterprise-wide data modeling endeavors. After the merger,the enterprise-wide data models were maintained, although a change in the fo-cus as well as the reach took place. In certain parts of the enterprise the focusshifted towards a strongly business process centric approach, while other partscontinued with data modeling. In the year 2002 the term EA management makesits first appearance, when a project was launched to increase the business-IT-alignment based on a holistic approach. In this holistic approach architecturalinformation from different parts of the enterprise was consolidated and used toidentify fields for action. In order to assess the advances made in this field, asimilar project was launched in the year 2005, which refined the utilized EAmanagement process. The take-over by an international banking company atthe end of 2005 changed the overall make-up of the company significantly. Inparticular, the IT departments of the formerly independent enterprises, as wellas the IT assets developed, operated, and managed by them, were to undergoextensive changes leading to an increased centralization of structures.

The EA management function currently operated at the banking companyencompasses the evolution of the technical as well as the business architecture.Thereby, the technical architecture is organized in the following layers: operative,system, integration, and application layer. The business architecture covers thebusiness process and the business model layer. The goals of the efforts are amongothers defined as follows: The EA management function

1. supports planning processes,2. demonstrates benefit of architecture development,3. identifies and aligns needs for action,

56 S. Buckl, F. Matthes and C. Schweda

4. develops future scenarios of the EA as well as migration plans, and5. ensures balance between short-term realization of business functions and

long-term improvement of the EA.

These goals were selected as they can be used to illustrate the systemic ap-proach to EA management, which was taken by the banking company. Thereby,the goals 1 to 5 directly map to the respective systems of the viable systemsapproach as presented in Section 2, while no counterpart of the EA managementgovernance function or the activity configure & adapt is alluded to.

The management function established at the banking company consists ofthe following activities:

(1) Creation and adjustment of IT strategy: Based on the enterprise busi-ness strategy, the IT strategy is developed, which includes information oncore competencies, products, business areas, etc, and is used to design atarget state of the EA. Furthermore, an IT security strategy is formulated.

(2) Development and update of architectural guidelines and standards:Architecture principles are identified and guidelines as well as standards aredeveloped and updated on this basis. To decide on new guidelines or stan-dards, an architecture board was introduced.

(3) Identification of needs for action originating from business and IT:Business and IT demands are collected and analyzed in respect to theirstrategic or operative importance. The identified needs are further assessedand prioritized according to the architectural principles identified as archi-tecture conformity, costs, risks, benefit, etc.

(4) Development and update of architecture artifacts: EA descriptions,like viewpoints, artifacts, guidelines, and standards are developed from threeperspectives: the functional, technical, and security perspective. They areupdated on a yearly basis either prior to or after the creation of the an-nual project plan. Therefore, defined EA descriptions like e.g. the technicalbuilding block maps are used.

(5) Check architecture conformity: The EA conformity in respect to thearchitectural principles is ensured via quality gates for projects. Thereby,the vertical escalation in the organizational structure depends on the scopeof the project.

The EA management function as presented above was subject to variouschanges in the past, where the performance of the function itself was assessed.Such an assessment took place in the year 2005, where impediments, which ham-pered the successful management of the EA, were identified. As a consequence ofthis assessment, decisions on architectural guidelines (cf. Activity (2)) were notlonger taken in a central board, if the activities have only local impact. Thereby,an overloading of the architecture board was prevented and the decision processwas sped up. Although this assessment is not part of the documented process ofEA management in the company, it refers to the EA management governancediscussed in Section 2.

Towards a Method Framework for Enterprise Architecture Management 57

In summary, the EA management function established at the banking com-pany can be mapped to the activities of the method framework presented inSection 4 as shown in Table 3.

(1) (2) (3) (4) (5)Develop & describe Communicate & enact Analyze & evaluate Configure & adapt

Table 3. Mapping the method framework to the banking company

6 Conclusion and outlook

This paper aims at establishing a method framework for EA management. There-fore, existing literature on EA management is analyzed from a viable systemperspective. The objective of this analysis is the identification of typical man-agement activities performed in this context. Furthermore, the architecture de-scriptions exchanged between these activities were of interest to analyze the re-lationships between the activities. As a result of the paper, it can be stated thata method framework for EA management should contain the following activities:develop & describe different states of the EA, communicate & enact architecturalprinciples and plans, analyze & evaluate different states of the EA, and finallyconfigure & adapt the EA management function. The identified activities couldfurther be evaluated via observing a case study at a banking company, in whichthe EA management function of the company was analyzed. Nevertheless, thecase study presented in this article only provides an ex post evaluation. In orderto further investigate the applicability and suitability of the proposed activities,an ex ante setting, where the activities identified are used to establish an andenterprise-specific EA management function, is necessary. In addition, furthercase studies need to be conducted to prove the applicability in different industrysectors and for different company sizes.

The case study discussed in this paper hints to the need for configurabilityof the EA management function. Via configurable method building blocks forthe different activities of the method framework, an effective EA managementfunction can be designed and established. Making the configuration points ex-plicit in the method framework, problems and exceptional situations during EAmanagement can be linked back to these points, where adaptations have to takeplace as part of the activity configure & adapt.

This paper presents a method framework for EA management on a very ab-stract level. In order to foster the applicability of the approach in practice, moredetailed information on the execution of the single activities would be benefi-ciary. Such best practice realizations could be documented as EA management

58 S. Buckl, F. Matthes and C. Schweda

patterns (cf. [25]) for which the method framework would not only provide a clas-sification but also would supply information on how to interrelate and integratesingle patterns.

References

1. Henderson, J.C., Venkatraman, N.: Strategic alignment: leveraging informationtechnology for transforming organizations. IBM Systems Journal 32(1) (1993)472–484

2. Frank, U.: Multi-perspective enterprise modeling (memo) – conceptual frameworkand modeling languages. In: Proceedings of the 35th Annual Hawaii InternationalConference on System Sciences (HICSS 2002), Washington, DC, USA (2002) 1258–1267

3. Aier, S., Kurpjuweit, S., Saat, J., Winter, R.: Enterprise Architecture Design as anEngineering Discipline. AIS Transactions on Enterprise Systems 1 (2009) 36–43

4. Buckl, S., Matthes, F., Schweda, C.M.: A viable system perspective on enterprisearchitecture management. In: 2009 IEEE International Conference on Systems,Man, and Cybernetics. (2009)

5. Wegmann, A.: The Systemic Enterprise Architecture Methodology (SEAM). Tech-nical report, EPFL (2002)

6. Buckl, S., Ernst, A.M., Lankes, J., Matthes, F., Schweda, C., Wittenburg, A.:Generating visualizations of enterprise architectures using model transformation(extended version). Enterprise Modelling and Information Systems Architectures– An International Journal 2(2) (2007) 3–13

7. Buckl, S., Ernst, A.M., Lankes, J., Schneider, K., Schweda, C.M.: A pattern basedapproach for constructing enterprise architecture management information models.In: Wirtschaftsinformatik 2007, Karlsruhe, Germany, Universitatsverlag Karlsruhe(2007) 145–162

8. Kurpjuweit, S., Winter, R.: Viewpoint-based meta model engineering. In Re-ichert, M., Strecker, S., Turowski, K., eds.: Enterprise Modelling and InformationSystems Architectures – Concepts and Applications , Proceedings of the 2nd In-ternational Workshop on Enterprise Modelling and Information Systems Architec-tures (EMISA’07), St. Goar, Germany, October 8-9, 2007. LNI, Bonn, Germany,Gesellschaft fur Informatik (2007) 143–161

9. Hafner, M., Winter, R.: Vorgehensmodell fur das management der un-ternehmensweiten applikationsarchitektur. In Ferstl, O.K., Sinz, E.J., Eckert, S.,Isselhorst, T., eds.: Wirtschaftsinformatik, Heidelberg, Germany, Physica-Verlag(2005) 627–646

10. Niemann, K.D.: From Enterprise Architecture to IT Governance – Elements ofEffective IT Management. Vieweg+Teubner, Wiesbaden, Germany (2006)

11. Schekkerman, J.: Enterprise Architecture Good Practices Guide – How to Managethe Enterprise Architecture Practice. Trafford Publishing, Victoria, BC, Canada(2008)

12. The Open Group: TOGAF ”Enterprise Edition” Version 9. http://www.togaf.org(cited 2010-02-25) (2009)

13. Rechtin, E.: Systems Architecting of Organizations – Why Eagles can’t swim. CRCPress LLC, New York, NY, USA (1999)

14. Ross, Jeanne, W., Weill, P., Robertson, David, C.: Enterprise Architecture asStrategy. Harvard Business School Press, Boston, MA, USA (2006)

Towards a Method Framework for Enterprise Architecture Management 59

15. Wagter, R., van den Berg, M., Luijpers, J., van Steenbergen, M.: Dynamic Enter-prise Architecture: How to Make IT Work. John Wiley (2005)

16. Beer, S.: The Heart of Enterprise. John Wiley, New York, NY, USA (1979)17. Beer, S.: Brain of the Firm. 2nd edn. John Wiley, New York, NY, USA (1981)18. Beer, S.: Diagnosing The System for Organisations. John Wiley, New York, NY,

USA (1985)19. Wittenburg, A., Matthes, F., Fischer, F., Hallermeier, T.: Building an integrated IT

governance platform at the BMW Group. International Journal Business ProcessIntegration and Management 2(4) (2007)

20. Le, L.S., Wegmann, A.: Definition of an object-oriented modeling language forenterprise architecture. System Sciences, 2005. HICSS ’05. Proceedings of the 38th

Annual Hawaii International Conference on (2005) 179c21. Lankhorst, M.: Enterprise Architecture at Work: Modelling, Communication and

Analysis. Springer, Berlin, Heidelberg, Germany (2005)22. Kirchner, L.: Eine Methode zur Unterstutzung des IT-Managements im Rahmen

der Unternehmensmodellierung. PhD thesis, Universitat Duisburg-Essen, Berlin,Germany (2008)

23. Frank, U., Heise, D., Kattenstroth, H., Schauer, H.: Designing and utilising busi-ness indicator systems within enterprise models – outline of a method. In: Model-lierung betrieblicher Informationssysteme (MobIS 2008) – Modellierung zwischenSOA und Compliance Management 27.-28. November 2008, Saarbrucken, Germany(2008)

24. International Organization for Standardization: Iso/iec 42010:2007 systems andsoftware engineering – recommended practice for architectural description ofsoftware-intensive systems (2007)

25. Chair for Informatics 19 (sebis), Technische Universitat Munchen: Eam patterncatalog wiki. http://eampc-wiki.systemcartography.info (cited 2010-02-25) (2010)

26. Buckl, S., Matthes, F., Schweda, C.M.: Interrelating concerns in ea documentation– towards a conceptual framework of relationships. In: 2nd European Workshopon Patterns for Enterprise Architecture Management (PEAM2010), Paderborn,Germany (2010)

27. Moser, C., Junginger, S., Bruckmann, M., Schone, K.M.: Some process patternsfor enterprise architecture management. In: Software Engineering 2009 – Work-shopband, Bonn, Germany, Lecture Notes in Informatics (LNI) (2009) 19–30

28. Johnson, P., Nordstrom, L., Lagerstrom, R.: Formalizing analysis of enterprisearchitecture. In: Interoperability for Enterprise Software and Applications Confer-ence, Bordeaux, France, Springer (2006) 10

29. Iacob, M.E., Jonkers, H.: Quantitative analysis of enterprise architectures. InKonstantas, D., Bourrieres, J.P., Leonard, M., Boudjlida, N., eds.: Interoperabilityof Enterprise Software and Applications, Geneva, Switzerland, Springer (2006)239–252

30. de Boer, F.S., Bonsangue, M.M., Jacob, J., Stam, A., van der Torre, L.: Enterprisearchitecture analysis with xml. In: Proceedings of the 38th Annual Hawaii Inter-national Conference on System Sciences (HICSS 2005). Volume 8., Los Alamitos,CA, USA, IEEE Computer Society Press (2005) 222b

60 S. Buckl, F. Matthes and C. Schweda