the impact of the enterprise soa on the future role of the ...€¦ · enterprise service-oriented...

In Collaboration With

DIPLOMA THESIS

The Impact of the Enterprise Service-Oriented Architecture

on the Future Role of the Enterprise Architect

Author Mister Sven F e u r e r

University University of Applied Sciences, Karlsruhe / Germany

Faculty Business Information Systems

Supervisor Prof. Dr. Uwe Haneke

Employment SAP AG, Walldorf / Germany

Date September 2006 - January 2007

Abstract ii

Abstract Enterprise Service-Oriented Architecture (Enterprise SOA) has evolved as an approved concept that accelerates innovation and energizes growth within a company in consid-eration of facing future demands. An Enterprise SOA is based on Enterprise Services that run on the SAP NetWeaver platform. The platform empowers all SAP solutions and builds an ecosystem for partners and customers. It also enables changes of busi-ness processes in order to realize strategic goals. All these aspects implicate changes in the way people do their job. But it also requires special skills of employees as new jobs arise and traditional architecture roles are evolving. The following thesis gives an overview on Enterprise SOA and delivers an insight into its organizational changes. The new role of IT and especially the one of an Enterprise Architect are discussed in detail as the main part of the thesis.

Contents iii

Contents Preface ...........................................................................................................................v

Acknowledgement .......................................................................................................vi

1 Enterprise Architecture .....................................................................................1 1.1 Executive Summary .............................................................................................1 1.2 Definition ..............................................................................................................2 1.3 Enterprise Architecture: The Foundation for Execution .......................................2 1.4 Enterprise Architecture Frameworks....................................................................3 1.5 Enterprise Architecture Building Blocks ...............................................................5 1.5.1 Business Viewpoint..............................................................................................7 1.5.2 Technology Viewpoint..........................................................................................8 1.5.3 Information Viewpoint ..........................................................................................9 1.5.4 Solution Viewpoint .............................................................................................10

2 Survey and Interviews .....................................................................................13 2.1 Executive Summary ...........................................................................................13 2.2 Research Method...............................................................................................13 2.3 Survey and Interview Contents and Its Combination with the Thesis ................14 2.4 General Information about the Survey Participants ...........................................15 2.5 Diagram Interpretation and Tool Limitations ......................................................17

3 Enterprise Architecture and Enterprise SOA: A Meeting of Disciplines ....19 3.1 Executive Summary ...........................................................................................19 3.2 Definition ............................................................................................................19 3.3 IT Meets Business .............................................................................................20 3.4 The Evolution of the Enterprise Service-Oriented Architecture .........................21 3.5 Exposing Business Functionality via Enterprise Services..................................25 3.6 The Enterprise SOA Approach in the Context of an Enterprise Architecture.....29

4 The Evolving Role of the Enterprise Architect..............................................32 4.1 Executive Summary ...........................................................................................32 4.2 Definition ............................................................................................................32 4.3 The Enterprise Architect’s Field of Responsibility..............................................32 4.3.1 Phase 1: Initiate the Enterprise Architecture Program.......................................36 4.3.2 Phase 2: Establish Governance Structure .........................................................38 4.3.3 Phase 3: Define the Architecture Approach.......................................................40 4.3.4 Phase 4: Develop the Enterprise Architecture ...................................................45 4.3.5 Phase 5: Use the Enterprise Architecture..........................................................53

Contents iv

4.3.6 Phase 6: Maintain the Enterprise Architecture...................................................55 4.4 Transitioning Through Enterprise Architecture Maturity Stages ........................57 4.4.1 Stage 1: Business Silo Architecture...................................................................58 4.4.2 Stage 2: Standardized Technology....................................................................58 4.4.3 Stage 3: Optimized Core....................................................................................59 4.4.4 Stage 4: Business Modularity (Enterprise SOA) ................................................60

5 Organizational Structure .................................................................................63 5.1 Executive Summary ...........................................................................................63 5.2 From Traditional to Lean Information Systems Organizations...........................63 5.3 The Enterprise Architecture Team .....................................................................69

6 Conclusion and Outlook .................................................................................71

Appendix......................................................................................................................73

List of Figures .............................................................................................................89

List of Graphs..............................................................................................................90

List of Tables...............................................................................................................90

Glossary.......................................................................................................................91

List of Abbreviations ..................................................................................................96

Bibliography ................................................................................................................98

Index .........................................................................................................................102

Preface v

Preface This Diploma Thesis evolved over the past four month. It forms the final part of the au-thor’s educational development at the University of Applied Sciences, Karlsruhe. The author has worked out the Thesis in the Solution Marketing Team of SAP.

The main challenge of this study was the immense amount of information in combina-tion with its topicality of discussion. To understand “The Impact of the Enterprise SOA on the Future Role of the Enterprise Architect” the reader will be introduced to various topics, current challenges and today’s market trends. Target groups are consequently enterprise architects, subordinated architects, groups and roles that finally implement and use the enterprise architecture, as well as all other roles striving for additional in-sight, along with guidance for additional information.

The study’s content will only provide a broad picture without drifting into deepness. In order to back up the content of the Diploma Thesis, the author has conducted an inter-national survey concerning the future role of the enterprise architect. The survey activi-ties and its results are introduced in chapter 2 and incorporated in almost all topics of the thesis. Due to the large extent of the survey, not all results can be discussed in this main document and are part of a separate document (Appendix E-F).

Furthermore the author conducted several interviews with enterprise architects and IT directors from global companies. Results of these interviews are also smoothly inte-grated into the content of the thesis. The complete interviews are also attached in a separate document (Appendix G).

Further information in regard to this academic research may be obtained directly from the author. Discussions and feedback are more than welcome. The author may be con-tacted at [email protected].

Acknowledgement vi

Acknowledgement I would like to express my sincere gratitude to my supervisors; Professor Dr. Uwe Haneke at the University of Applied Sciences, Karlsruhe; and Thomas Mattern of the Solution Management team at SAP, whose insightful advice and guidance have been indispensable throughout my work. Thanks are also due to the other members of my thesis committee at SAP - Ulrich Scholl and Ori Inbar. They have offered valuable sug-gestions throughout the composition process.

I would also like to thank Andre Blumberg (CLP), Scott Feldman (SAP), Paul Kurchina (KurMeta), Peter Loop (Intel), Steve Nunn (OpenGroup), and Darin Paton (Trans Alta) for their valuable support in regard to activities concerning the survey. Ultimately, I also want to thank all members of the enterprise architecture group of the Americas’ SAP Users’ Group (ASUG) for their time in filling out the survey.

I would also like to express my appreciation to Juergen Hauck (Pfizer), Dr. Klaus Schoo (Pfizer) and Hermann Schlamann (Credit Suisse). They were intervieweesfor a series of interviews that I conducted and so delivered valuable practical experience for this research.

I deeply appreciate the help of all further involved SAP colleagues for their case provi-sion and practical advice. They are: Ina Arndt, Mary Bazemore, Craig Cmehil, Barrett Conway, Simon Dale, Scott Feldman, Natan Gur, Christian Hastedt-Marckwardt, Chris-topher Hearn, Rudolf Hois, Alexandra Jochim, Franck Lopez, Steven Maginnis, Susan Martin, Harald Nehring, Johannes Neuer, Amit Sinha and Jochen Vatter.

Finally, I wish to thank my girlfriend Kerstin and my family for their warm and continuing support and patience over the past four month.

December 2006

1 Enterprise Architecture 1

1 Enterprise Architecture

1.1 Executive Summary From a business perspective, enterprise architecture has long been considered a con-cept to primarily cut costs and increase the efficiency of the company. This mindset dates back to the 1970’s, although enterprise architecture was not really a prominent concept until the introduction of Zachman’s Framework for Information Systems Archi-tecture in 1987. However, in these days of globalization, with high complexity and high rates of change, enterprise architecture is seen as a central concept that empowers and affects the whole company. So it mainly focuses on quality of products, services and business processes, as well as agility to realize ever-changing business, IT and organizational strategies [LaHa06].

Building a future-state enterprise architecture means finding the right balance between IT efficiency and business value. This process can be very challenging because it sometimes requires a redesign of the existing enterprise architecture and even a change of the organizational structure. It is quite important to underline that enterprise architecture must be considered a central process and should not be performed in a vacuum. In fact, companies should include enterprise architecture in their strategic planning disciplines. This is a powerful foundation to align the company’s technology and IT strategy and to achieve real synergies and leverage the business’ value.

Before we dip into the world of the enterprise architect, you may imagine enterprise architecture as a discipline comparable with city planning (figure 1). A city plan pro-vides guidelines that ensure that all buildings will “work” harmoniously together, as well as with surrounding, pre-existing buildings. Each building must be designed and placed in a specific way to fulfill planning regulations, design principles and architectural com-pliance. A city planner has to consider a new building’s impact on sewers, traffic and the electrical grid. However, unlike a constructing a building, developing a company’s enterprise architecture will never be in a final state.1

Figure 1: Enterprise architecture from a city planner perspective

1 Further information about the city planning approach for rebuilding enterprise information sys-

tems can be found in the study of Yukio Namba [Namb05]. IDS Scheer also provides addi-tional information in a white paper which describes how to map the analogy of city planning to enterprise architecture by using the ARIS design platform [Sche04c].

Sour

ce: [

BrAl

06]


1.2 Definition What exactly is enterprise architecture? There are many definitions for enterprise archi-tecture, all of which can be captured in one short answer: Enterprise architecture is how to build an enterprise. Gartner Incorporation, a global leader in business research and consultancy, describes enterprise architecture as follows [LaHa06]:

The process of describing, and the description of, the desired future state of an organization's business process, technology and information to best support the organization's business strategy. The definition of the steps required, and the standards and guidelines to get from the current state to the desired future state.

Gartner defines enterprise architecture by differentiating three important architectural perspectives: business, technology and information. These perspectives are described in more detailed in chapter 0 and recur in the discussion about the enterprise architec-ture group in section 5.3.

1.3 Enterprise Architecture: The Foundation for Execution The purpose of enterprise architecture has changed since companies are highly af-fected by globalization and overall business processes. An interconnected, globalized world facilitates collaboration between employees, teams and organizations in a way never seen before. It enables companies to set up highly vibrant ecosystems of cus-tomers, partners, suppliers and other interest groups or stakeholders. Customers also benefit from this trend because bargaining power moves to their side. They are able to compare offerings of international companies easily and then pick out the most favor-able products or services. Companies of virtually every industry have recognized this and have become more demand-driven today. They adjust their business processes around customers’ requirements to fulfill one of their major goals - high and sustainable customer satisfaction.

Many companies are currently changing their business focus from cost to quality and also from efficiency to agility. From an IT perspective, you can determine a continuous cycle of three steps: quality, speed and cost. This cycle is closely associated with the economic situation in the IT industry. For instance, you can compare the step ‘speed’ with the phase after Y2K when companies intensively invested in e-business applica-tions in order to accelerate their financial transactions with suppliers, partners and cus-tomers. After this time there was a phase of economic instability wherein companies had strong cost awareness, like the step ‘cost’ demonstrates. Today, spending for IT is increasing, but it is done more prudently in the step ‘quality’. Companies primarily want to achieve higher quality goals with their IT investment programs, while factors like costs and speed are not forgotten. Enterprise architecture often represents one of these quality programs [LaHa06].

There are several definitions of enterprise architecture that prove helpful to getting a general impression of what enterprise architecture is and which business goals are to be achieved. But before you think about enterprise architecture, you first have to criti-cally challenge why enterprise architecture should be the answer for achieving organ-izational goals. In quick reply to this question, enterprise architecture plans and sup-ports the organizational strategic goals. Enterprise architecture provides the foundation for execution by ensuring that all the money spent in information, technology and proc-


ess improvement leads to new opportunities and enables rapid responses to an ever-changing market environment [LaHa06].

1.4 Enterprise Architecture Frameworks Especially in modern and large organizations, a rigorously defined enterprise architec-ture framework is fundamental. An enterprise architecture framework is something that provides structure when specifying how technology needs to be organized to support the business. It helps to grasp a vision of the “to be” architecture, clearly identifies the state of the current architecture and also provides a process to close the gap between both architectural states. This enterprise architecture process can be very complex, and so enterprise architecture frameworks must align many different aspects from mul-tiple viewpoints. Enterprise architecture frameworks can be considered a master plan that forces coordination and alignment between strategic enterprise planning activities, business operations and the technological infrastructure of the company. Such integra-tive efforts need to have strong governance principles.

Today many enterprise architecture frameworks coexist. Enterprise architecture frameworks2 can be categorized into three major groups [Wiki06]:

• Government and authoritative frameworks: Government frameworks are devel-oped and utilized by public agencies primarily in the defense area. Defense de-partments have started development of such frameworks because of an increasing need for standard architectural approaches for multinational military operations. Frameworks such as Zachman or TOGAF are very authoritative and elaborated. Many frameworks today are built as specific refinements and add-ons based on au-thoritative frameworks.

• Vendor-specific frameworks: These are frameworks mainly developed by soft-ware vendors. They provide their experiences and best practices, obtained from past architectural projects, in the form of frameworks.

• Miscellaneous frameworks: This group comprises multiple frameworks focused on special industries or providing further features and functions.

1. Government and Au-thoritative Frameworks

2. Vendor-Specific Frameworks

3. Miscellaneous Frame-works

• DoDAF (Departm. of De-fense Architecture Framework, US) and Mo-DAF (Ministry of Defence Architecture Framework, UK)

• Gartner EAF

• TOGAF (The Open Group Architecture Framework)

• Zachman

• E2AF (Extended Enter-prise Architecture Framework of the Institute For Enterprise Architec-ture Development)

• Capgemini’s Integrated Architecture Framework

• NIH Enterprise Architec-ture Framework

Table 1: Classification of enterprise architecture frameworks

2 This is just a small selection of enterprise architecture frameworks. Please find enclosed the

results of the survey regarding enterprise architecture frameworks.


Table 1 lists enterprise architecture frameworks assigned to major categories. Most of these frameworks are very important for the companies who participated in the survey3. Frameworks listed in the table above represent 96% of all responses in total. However, 22% (31 people) of the participants did not complete the question about relevant enter-prise architecture frameworks. Sometimes they included comments such as ‘I don’t know’ or ‘tell me more’. That is not surprising at all because enterprise architecture frameworks are the most important area of content for education programs4 (34%).

Graph 1: The importance of enterprise architecture framework

Based on the survey, the graph above (graph 1) demonstrates the importance of single enterprise architecture frameworks:

• Both DoDAF and MoDAF reached a relative frequency of 8%. DoDAF was devel-oped by the U.S. Government Department of Defense. It mainly focuses on the ar-chitecture of military systems, but it is also applied in the public, private and volun-tary sectors. MoDAF was created by the U.K. Ministry of Defence in order to realize an integrated and coherent approach to better acquire, manage and operate mili-tary capabilities5.

• Gartner’s Enterprise Architecture Framework was chosen by 29% of the partici-pants and ranked third with a relative frequency of 18%. This framework explicitly drives architecture out of the business strategy and supports governance by both the framework and the process.

• TOGAF is the most popular framework among the participants. It was selected by 54% of the participants and reached a relative frequency of 33%. This vote clearly results from the fulfillment of almost all of the important criteria to evaluate these frameworks. TOGAF provides a robust advice on architecture governance and is aligned to a process for developing enterprise architecture.

3 The survey is an integral part of this study. It will be introduced in chapter 2. 4 See question VI.2 of the survey. 5 Sources: http://www.defenselink.mil/ and http://www.modaf.com/.

0,60,50,40,30,20,10

Mean

11%

22%33%

1%1%

18%

2%2%

4%8%

TOGAFZachman

GartnerCapgemini

DoDAF MoDAFE2AFFEAF

NASCIOPosix

OtherFW

0.54 0.35

0.29 0.13 0.06

0.04 0.03

0.01 0.01

0.17

Question 3.3: What are relevant frameworks for your sector?

108 r

espo

nses

So

urce

: Sur

vey


• The Zachman framework reached a relative frequency of 22%. The framework is one of the “richest” frameworks in terms of detail.

• Only 5 of 139 participants (4%) chose E2AF as an important framework. This framework, created by the Institute for Enterprise Architecture Development, is in-fluenced by several other frameworks (e.g., by the Zachman framework) [Sche04].

• Capgemini’s Integrated Architecture Framework reached a relative frequency of 11%. It is a comprehensive framework developed from the experiences and best practices of architecture professionals in Capgemini6.

• The NIH (National Institutes of Health) Enterprise Architecture Framework was not selected by the participants. This framework mainly supports the mission and goals of NIH’s IT strategy7.

As you can see above, the survey identifies TOGAF, Zachman and Gartner as the most important enterprise architecture frameworks. Together they reached a relative frequency of 73%. Utilizing frameworks are no one-time effort. Companies often need to adapt and reassess their frameworks from time to time to remain in sync with chang-ing architectural requirements. Groups, vendors or governments responsible for their frameworks typically provide updated documentation- of their frameworks that can be downloaded; however, companies may need specific add-ons that are not provided by one single framework. Because there is no ‘one-size-fits-all’ approach, they may evalu-ate several frameworks to combine different approaches. Furthermore, 29% of the sur-vey participant had not utilized enterprise architecture frameworks at all (see survey, question III.1a).

One crucial responsibility for enterprise architects is to evaluate and select an enter-prise architecture framework when defining the architecture approach. So the three most relevant frameworks (TOGAF, Zachman and Gartner’s) are re-addressed and assessed in chapter 4.3.3.

As the Gartner Enterprise Architecture Framework is clearly structured and well-defined, the following subsequent chapters define enterprise architecture building blocks by terms of Gartner’s notion.

1.5 Enterprise Architecture Building Blocks It is not easy to describe a general approach to enterprise architecture since every en-terprise is different. A clear and sophisticated enterprise architecture design is shown in figure 2.

Shown in the figure below, enterprise architecture is business-driven based on the business context. That is the highest level of abstraction, but it is not directly part of enterprise architecture and so belongs to wider business strategy and enterprise plan-ning activities8, which have their own lifecycles within the enterprise [Toga03].

Therefore the business context is primarily for CxO-level executives who need to get a “big picture” in order to make strategic decisions. The business context defines the

6 Source: http://www.capgemini.com/services/soa/ent_architecture/iaf/. 7 Source: http://enterprisearchitecture.nih.gov/. 8 Strategic business planning is the process of defining the mission and long-range objectives

for conducting the business and developing the strategies for achieving them [Spew93].


business strategy and its implications for the enterprise. It also considers environ-mental factors (market, regulatory or technology pressures) and their influence on the enterprise architecture. The business context also includes a set of high-level, princi-ples for ensuring that the business strategy is properly translated into architecture de-sign.

The model describes an enterprise architecture from at least three fundamental viewpoints9. The business viewpoint represents the business architecture, which mainly deals with the enterprise in its business environment. The second viewpoint, the tech-nology viewpoint, specifies technological elements (such as hardware, software, net-work and data) of the underlying infrastructure. The last perspective focuses on infor-mation architecture. This architecture provides an effective use of information (on both a logical and a physical level) to best manage the information structure, assets and flow.

Figure 2: Enterprise architecture viewpoints

Each fundamental viewpoint (the business, the technology and the information view-points) of the framework is divided into three different levels of abstraction: the concep-tual, the logical and the implementation levels. These layers enforce a traceable de-composition from the conceptual design of the architecture to an extensive and detailed implementation plan. On the conceptual layer, strategic decisions have already been made by executives and are now conceptualized by the senior management. Senior managers also have the “big picture” in mind. They ensure that architecture issues, as well as opportunities, are addressed and reflected in the long-term and short-term business plans of the organization. The logical layer is mainly for operational manage-ment, which has a logical view of enterprise architecture. The lowest level is implemen-tation. It is the scope of change agents who go into detail when implementing systems and improving processes. Abstraction is important to effectively communicate layer-specific issues with different stakeholders [JHLG05].

9 Additional viewpoints are possible and may be extracted from the business, information and

technology viewpoints. For instance, a separate viewpoint for compliance provides a chief compliance officer with a specific compliance view of the architecture.

Business Viewpoint

Technology Viewpoint

Information Viewpoint

Strategy, Trend

Enterprise Architecture

Business Context

Solution Viewpoint


It is important to point out that all three different viewpoints can be described by, at the least, architectural requirements, principles and models. These architectural elements (artifacts) are not only developed within each viewpoint, but also for each level of ab-straction (figure 3).

Figure 3: Abstraction layers of the technology viewpoint

Conceptual, architectural elements for each architecture viewpoint are described in more detail subsequently. These elements are described with a concrete case in chap-ter 4.3.

1.5.1 Business Viewpoint The first architecture that can be identified when you view the enterprise from a busi-ness perspective is the business architecture. It represents the process and organiza-tional concerns of business architects. Business architecture (sometimes called ‘enter-prise business architecture’) is the most dominant architectural discipline to improve performance of the enterprise. This architecture shows the business value which re-sults from other architectural efforts, such as information, technical and solution archi-tecture. Business architecture gets initial input from wider enterprise planning activities which themselves define business mission, vision, strategy and goals. The architecture has the task of translating these high-level business goals into business requirements that are relevant for this architecture. Analyzing enterprises architecture from a busi-ness perspective is mostly a complex issue. A comprehensive approach to business architecture defines end-to-end business processes (sometimes called ‘core proc-esses’) and their relationships to internal users and external customers of an organiza-tion. Furthermore, business architecture creates an architectural blueprint for meeting or even exceeding customers’ requirements, competing and sustainably operating in a market, as well as interacting with suppliers, partners and employees [WiMy04].

Core processes are customer-centric and can span multiple functional departments. They are designed to deliver effective and efficient results in functional organizations. Finally, the performance of these processes can be evaluated by linking them to previ-ously defined, measurable results of a long-term business goal [Whit05].

Defining the business architecture raises the question of how much the architecture actually relates to business process management. The business architecture ends with the creation of optimized business process models that are aligned with the business

Business Viewpoint

Technology Viewpoint

Information Viewpoint

Conceptual • Requirements • Principles • Models Logical • Requirements • Principles • Models Implementation • Requirements • Principles • Models

Conceptual

Logical

Implementation

Conceptual

Logical

Implementation

Conceptual

Logical

Implementation

Abstr

actio

n lay

ers


strategy. Presently, business process management uses these business process mod-els, aims to automated them, and creates end-to-end business processes. Medium-term both disciplines are expected to converge [Hand06].

1.5.2 Technology Viewpoint Historically the focus of enterprise architecture has been on the technical architecture (sometimes called ‘enterprise technology architecture’). This architecture represents the technical implementation and operational concerns of technical architects. Techni-cal architecture provides the technical foundation that reflects and supports the other architectural viewpoints. From a technical viewpoint you can identify and plan a consis-tent set of technical components upon which enterprise solutions can be built or even purchased.

The technical architecture addresses several technical components in eight technical domains. Each of the domains10 is an important component of a holistic technical archi-tecture approach [Vita06].

• Application domain: The first domain provides the technical foundation for imple-menting and adapting business processes to be able to respond to changing busi-ness requirements.

• Database domain: It includes technical topics and components for databases and data management systems that best support storage, retrieval and backup of data.

• Information domain: It addresses technical topics like reporting, data manage-ment, business intelligence and knowledge management. This domain defines a logical structure of multiple databases and describes a methodology to integrate data sets.

• Integration domain: It includes tools and services that integrate databases, mes-sages, services and applications, even when they run on multiple platforms of many different vendors.

• Networking and communication domain: This domain identifies technologies and services to provide a comprehensive communication infrastructure.

• Platform domain: It is a very important domain that aims to standardize and sim-plify the platform landscape of the enterprise. A platform describes some sort of framework, both in hardware and software, that enables software to run. This do-main typically includes technology topics like personal computing devices, servers and utility services.

• Security domain: The purpose of this domain primarily is to establish, maintain and improve information security across the enterprise technology architecture. Components of this security domain address secure systems interoperability, data, physical and personnel security, as well as other security engineering topics.

• Enterprise systems management: It primarily concentrates on infrastructure top-ics and components. There are three core processes addressed within this scope: service delivery, which controls management activities to meet customers’ business needs; operation management, which provides operative infrastructure compo-

10 Technology domains are sometimes also called ‘technology areas’.


nents; and service support, which ensures that users have access to services to support business functions.

1.5.3 Information Viewpoint Information is a fundamental driver for the successful operation of a business. The in-formation viewpoint makes up the discipline of information architecture. This architec-ture represents the information (flow) modeling concerns of information architects. The main objective of information architecture (sometimes called ‘enterprise information architecture’) is to leverage all types of information across the enterprise. Accurate and timely information is needed for several purposes. It helps to determine profitability and efficiency. Furthermore, information is needed for monitoring quality, managing people and communicating with suppliers, customers and business partners. Finally, informa-tion is very valuable for decision-making at operational, tactical and strategic levels.

Peter Drucker once defined information as [Druck89]:

Information is data endowed with relevance and purpose.

This ancient definition has not lost any relevance to this day and often appears in litera-ture about information management and information architecture.

Information in any business is based on structured and unstructured data - the funda-mental bricks of information architecture. Structured data is typically stored in relational tables, which normally consist of multiple entries (rows) that are characterized by sev-eral criteria (columns). These entries need to be interpreted and contextualized in order to make sense of them. Structured data includes business data and metadata (data about business data). It is often stored in databases, spreadsheets and word process-ing tables. Compared to structured data, unstructured data cannot be interpreted eas-ily. It is mostly in the form of word processing documents, presentations and similar incoherent documents. To understand the meaning of unstructured data, you need more of it than you would need of structured data. Furthermore, metadata is essential for describing the context of data and properly grasping the content [RuRu06].

The major challenge of the information architecture is to find the right balance between structured (concrete) and unstructured (abstract) data and to make it available throughout the organization; therefore, it is critical to differentiate four categories of information [RuRu06]:

• Public information: There are no security constraints for sharing this information publicly inside and outside of the enterprise.

• Internal information: This type is not confidential but provides internal information about the operation of an organization, such as network information, internal user names, etc.

• Confidential information: This information should be private and only divulged by authorized people. It is typically salary data and other private employee information.

• Secret information: This information is critical to the enterprise’s success and should only be shared with trusted and authorized parties.

In order to drive and build the information architecture, you need an inventory that represents what information assets are currently available. Furthermore, the inventory shows where and how information is stored, as well as how timely, mature and accu-rate it is. Information plays a significant role, e.g., in application systems and business processes, and thus relates to other disciplines of enterprise architecture.


In addition, the information architecture gives consideration to external regulations, for instance, the Sarbanes-Oxley Act, the Health Insurance Portability and Accountability Act and the Gramm-Leach-Bliley Act, all of which prescribe and control how organiza-tions have to manage information [RuRu06].

1.5.4 Solution Viewpoint On the one hand, business has special demands (e.g., real-time enterprise, BPM, busi-ness intelligence); on the other hand, technology has appropriate solutions (e.g., enter-prise SOA, model-driven architecture). That is a statement that exactly defines the situation of enterprise solution architecture today.

Solution architecture describes a challenging, and perhaps the most important architec-tural viewpoint. It describes the combination and unification of all enterprise architec-ture viewpoints (enterprise business architecture, enterprise information architecture, and enterprise technology architecture) which are loosely coupled and are often con-tradictory. Solution architecture represents a meta-architecture because it describes an architecture combined of other architectures. This leads to an aggregated architecture for a specific enterprise solution. Solution architecture helps to structure solutions in order to deliver value, leverage appropriate systems and identify risks and complexity. Many other enterprise architecture frameworks unfortunately lack this viewpoint or deal with it in an insufficient way. Definitions of both enterprise solution architecture and enterprise solutions are listed below [JHLG05]:

Enterprise solution architecture is a consistent architectural description of a specific enterprise solution. Enterprise solution architecture combines and reconciles the requirements, principles and models of intersecting stakeholder-specific viewpoints into a complete architectural description of a specific enterprise solution.

Visualized in figure 4, the solution viewpoint combines loosely-coupled architectural descriptions of diverse viewpoints (business, technology and information viewpoint) to provide a unified, holistic and non-conflicting foundation for creating enterprise solu-tions. Typically enterprise solutions are the final outcome of architectural efforts. This makes it important to provide a clear definition of enterprise solutions:

An enterprise solution is a system that addresses a business problem, issue or function (or a set thereof) that spans the enterprise. It is com-posed of sub-solutions (or subsystems) that may span only part of the enterprise (that is, a specific business unit or line of business).

The more agile and mature the enterprise solution architecture, the faster enterprise solutions can be developed in an efficient and qualitative way.


Figure 4: The enterprise solution viewpoint

All three different viewpoints are incorporated in enterprise solution architecture by identifying their architectural requirements, principles, models, etc. This holistic view of solution architecture builds a complete set of architectural descriptions that form an enterprise solutions portfolio [JHLG05].

In this context we should clearly distinguish between both enterprise applications which are an integral part of the enterprise technology architecture and enterprise solutions (also called business solutions) which are the result of the enterprise solution architec-ture. Application architecture both designs and engineers applications and so builds the technical platform for enterprise solutions. Enterprise solutions in turn represent a holis-tic and geared product that reconciles all architectural viewpoints. To better understand this differentiation between these terms, please have a look at this simple example about SAP’s enterprise resource planning (ERP) system, mySAP ERP11.

• mySAP ERP is an application. It describes data processing software that handles business processes and information.

• mySAP ERP Financials represents a solution. An enterprise solution primarily wants to solve business problems. It typically facilitates information flows, auto-mates business processes, and involves people whenever human intervention is required.

Traditionally, boundaries of enterprise applications are closed and highly inflexible. Based on these applications, enterprise solutions are either developed by company-internal groups or they are bought from external software vendors. These enterprise solutions do a fantastic job as long as requirements remain constant and nothing has to be expanded or adapted. Such solutions mostly focus on fixed user groups utilizing pre-defined user interfaces.

As a result of their inflexible enterprise applications, companies were unable to create or change enterprise solutions efficiently. Different teams tackled the hurdle of consoli-dating expensive custom code into cost efficient standard applications. Another obsta-cle is the existence of different technology platforms that make it difficult to compose new, innovative solutions while leveraging existing packaged applications.

So packaged enterprise applications need to be more open and standardized for creat-ing an interoperable solution architecture. This is the advent of the service-enabled,

11 Further information about mySAP ERP: http://www.sap.com/solutions/business-suite/erp/.

Solution Viewpoint

Business Viewpoint Technology Viewpoint Information Viewpoint

Enterprise solution architecture combines different viewpoints


packaged applications specified in chapter 3. These packaged applications expose particular business functionality in the form of reusable, modular components (enter-prise services12) based on open standards. In addition to buying applications versus building or changing your own custom applications, composition represents the “third alternative” for creating flexible and customer-specific solutions13 at an affordable cost. Over time, a core of standardized services will become available and new services will appear on the market. Companies may directly use these services or extend them in a way that differentiates them from competitors. These solutions may not only consume functionality exposed by service-enabled, packaged applications but also consume functionality provided by custom-developed applications [Robe06].

Now we are at the doorway to enterprise SOA and the evolving role of the enterprise architects. However, before embarking on these topics, the survey and the interviews will be introduced in order to understand future references to insights based on these instruments.

12 Enterprise services will be defined in chapter 3.5. 13 Composing enterprise solutions is a central characteristic of an enterprise SOA and will be

addressed in chapter 3.5.

2 Survey and Interviews 13

2 Survey and Interviews

2.1 Executive Summary The objective of the survey was to obtain a comprehensive overview of the current and future role of an enterprise architect within the changing business and IT environment. The evaluation of the survey and the interpretation of the results have been frequently segmented by the companies’ industries and sizes. This detailed examination has led to interesting results which would otherwise not be identifiable. Issues that require fur-ther explanation are addressed in separate interviews. Attendees of the interviews were primarily enterprise architects and IT directors. Due to the extent of both the sur-vey and the interviews, they are included in their entirety in a separate document14. This chapter aims to introduce the overall results of both the survey and the interviews. Further results from this research are incorporated into and discussed in almost all of the topics of the thesis.

2.2 Research Method The survey was performed in collaboration between the ASUG (Americas SAP User’s Group) and SAP and conducted through six main phases. These phases are briefly described below.

Figure 5: Phases of the research method

In the first phase, a comprehensive literature review was performed to get a general overview of “hot” enterprise architecture topics and identify current pain points of enter-prise architects. The result was a document with seven chapters. Each chapter already included appropriate questions that were specified by a detailed description and a spe-cific purpose. Answers were not defined for these early questions.

14 See Appendix E-G in the separate document.

Phase 1 Literature Review

Phase 2 General Feedback Loop

Phase 3 Survey Preparation and Pre-Test

Phase 4 Instrument Distribution

Phase 5 Interviews

Phase 6 Data Analysis


In the second phase, questions were evaluated by multiple SAP employees and part-ners. These people possess strong competencies in their individual domains and thus contributed professional, topic-specific feedback. These responses were basically pro-vided both by an online feedback tool (called SAP End-User Feedback Service) and by e-mail.

The next phase was initially about the selection of an applicable survey tool and the addition of appropriate answers to the reviewed questions. After that, the survey was pre-tested online, and it was paper-based in order to identify weak points, as well as redundant or missing questions and answers.

In phase four, the proper survey publication and distribution started. About three quar-ter of the survey responses came from survey activities done at SAP TechEd15 ‘06 in Las Vegas (USA) and SAP TechEd ‘06 Amsterdam (Netherlands)16. Actually the survey was positioned on the agenda of enterprise architecture pre-day sessions primarily managed by Paul Kurchina and Peter Loop, both chairmen of the enterprise architec-ture SIG (special interest group) of ASUG. These sessions effectively opened the door to get about 75% of the survey responses from enterprise architecture professionals who participated in these sessions. The remaining 25% of the survey’s participants filled out the online questionnaire17 published during October 2006.

In phase five of the research, multiple interviews were conducted to delve into topics that require more extensive explanation. In the last phase, the survey was analyzed using SPSS - a professional, statistical analysis software18.

2.3 Survey and Interview Contents and Its Combination with the Thesis

The combination of the outcomes provides a valuable backbone for the thesis. The survey results are associated with several statements and conclusions within the fol-lowing chapters.

The organization of the questionnaire is aligned with the structure of the thesis. The questionnaire includes the following main topics:

• General information: Questions within this part are used to categorize the partici-pants and their companies. This information is frequently used when reviewing the survey’s result.

• Enterprise architecture: The results help to determine the most crucial issues of enterprise architectures and the hot topics for enterprise architects. Resulting in-sights build the foundation for skills and experiences required by enterprise archi-tects.

15 SAP TechEd is a technical education conference. The conference offers jam-packed days of

educational lecture sessions, instructor-led hands-on workshops, and networking opportuni-ties. Thousands of attendees can come together to learn the tools they needed to innovate with SAP (https://www.sdn.sap.com/irj/sdn/sapteched).

16 First survey activities were done in Las Vegas on 9 September 2006 and in Amsterdam on 17 October 2006.

17 The online survey was developed with QuestionPro (www.questionpro.com). 18 The survey analysis was realized using SPSS 14.0 (Statistical Package for Social Sciences);

www.spss.com).


• Enterprise architecture frameworks: This part identifies relevant enterprise archi-tecture frameworks and their prioritized features and also discusses the attitude to-wards vendor-specific frameworks.

• The evolving role of the enterprise architect: Questions in this part of the survey are used to (re)define the enterprise architect’s role and to update the architect’s position especially in the context of enterprise SOA.

• Organizational structure of the enterprise architecture team: This section pri-marily concentrates on the enterprise architecture team, its common reporting structure and its position within the organization.

• Education and certification: This section basically determines contents and fea-tures of education and certification programs in order to effectively qualify enter-prise architects.

• Communities for enterprise architects: Results of this part of the survey help to assess how necessary communities actually are for the job of enterprise architects.

In addition to the survey, the interview series comprised three different calls with enter-prise architects who gave further insights from a senior management perspective. These interviews can be summarized as follows:

• Interview 1 (Dr. Klaus Schoo and Juergen Hauck, Pfizer): Juergen Hauck is foun-der of a Pfizer-internal European community. The community helps to share infor-mation across decentralized locations to ensure that global enterprise architecture guidelines are all kept. Furthermore, the community aims to facilitate innovation in the countries. Klaus Schoo placed emphasis on leading skills of enterprise archi-tects. He also underlined that enterprise architects must be good communicators I order to get budget for the architecture program from senior management.

• Interview 2 (Herman Schlamann, Credit Suisse): Hermann Schlamann described both the consolidation and the service-enabling process of the systems landscape of Credit Suisse. He underlined that enterprise architects should transform the ar-chitecture through a managed process; he calls it: ‘Managed Evolution’. Only in that way companies can find the right balance between IT efficiency and business value.

• Interview 3 (A certified IT architect from a global software company19): This inter-view mainly discusses communities for enterprise architects. A company-internal IT architects’ community enables its members to share information and even share reusable architectural components of previous customer projects (reference archi-tectures).

Detailed information about the survey and the complete interviews is attached in the separate document about this analytical study.

2.4 General Information about the Survey Participants The following diagram provides a general overview of the different roles of all survey participants. There were 139 survey participants in total.

19 The interview was not approved due to global One Voice policies of that company.


Graph 2: Roles of the survey participants

As graph 2 illustrates, enterprise architects represent the largest group of the survey’s participants because they were the major audience on the enterprise architecture pre-day sessions at SAP TechEds (47 people, 34%). The second largest group consists of 19 technical architects (14%). 13 people are solution architects who belong to the third largest group.

Graph 3: Geographic regions the companies of the participants are located in

The graph above shows that about two thirds of the participants (67%) primarily work for companies located in North America (28%), Europe (21%) and Asia Pacific (18%). However, one-third of the people (33%) work for companies based in Latin America (14%), the Middle East (10%) and Africa (9%). This distribution gives the survey an international character and leads to representative results.

Graph 4: Industries in which the participating companies operate

Question I.5: What industry does your business belong to?

4334%

1915%

2016%

119%

1310%

108%

119%

OthersHigh TechConsumer productsChemicalsRetailProfessional servicesOil and gas

Industries

139 responses Source: Survey

0,8

0,6

0,4

0,2

0

Mea

n

18%

10% 9%

21%

14%

28%

Africa Middle East Latin America Asia Pacific Europe North America

0.76 0.58

0.48 0.40 0.28 0.25

Question I.3: Please select the geographic region of your company.

139

resp

onse

s So

urce

: Sur

vey

2719%

1914%

139% 7

5%

4734%

75%

75%

129%

Question I.2: Please specify your role in the organization.

OthersTechnical architectSolution architectInformation architectEnterprise architectDeveloperConsultantApplication architect

Roles of the participants

139 responses Source: Survey


Indicated in graph 4, most people work in the consumer products industry (16%). Other major groups of the survey participants come from the high tech (15%) and the retail industry (10%).

2.5 Diagram Interpretation and Tool Limitations In order to avoid confusion when looking at a diagram, you must be clear about the type of value being reported. In general, you have to differentiate among absolute fre-quency, relative frequency and mean (see figure 6).

Figure 6: Differences between relative frequencies

• Absolute frequency: This value represents the absolute frequency (sum of votes) of an outstanding attribute in a diagram. Looking at absolute frequency is some-times very helpful in order to define the weighting of an outstanding attribute.

In the example above, the first answer to the question (“Select 1”) was chosen by all of the participants. Consequently, this attribute reaches an absolute frequency of 2.

• Relative frequency: This frequency is the frequency of an outstanding attribute in relation to other attributes in a statistical unit. An item that was selected by all sur-vey participants does not achieve a relative frequency of 100% when there are other items that also count in this statistical unit.

Referring to the example, the first attribute (“Select 1”) was chosen by two partici-pants. Other answers to this question reached an absolute frequency of 3 votes. This means that the first attribute (“Select 1”) reaches a relative frequency of 40%.

• Mean value: This value is the average of samples in a statistical study. It demon-strates the average weighting of a statistical attribute. Referring to the survey, this parameter is particularly important when questions allow for the selection of multi-ple items.

In the example, the first answer to the question was chosen by two participants over two valid questionnaires. Each of these selections was statistically processed with the value “1.00”. Consequently, this attribute reaches a mean of 1.00 (meaning that it was selected by 100% of the participants).

Limitations of the survey tools

• Since the survey was conducted in different ways (paper-based and online), there might be small discrepancies in the form of the questions. The tool used for the online survey was quite complex and provided functionality for various types of

Select 1

Select 2

Select 3

Select 4

Select 1

Select 2

Select 3

Select 4

Question Question + =Select 1: 40.0% 1.00 2

Select 2: 20.0% 0.50 1

Select 3: 20.0% 0.50 1

Select 4: 20.0% 0.50 1

Results

Questionnaire 1 Questionnaire 2

Arithmetic mean Relative frequency

Absolute frequency


questions. But it lacked the ability to provide the “others” branch with questions that were designed to be ranked within a matrix table.

• Question II.1: “What are characteristics of future-proof EA?”

• Question IV.1: “What are responsibilities of enterprise architects?”

• Question IV.2: “What skills are essential for enterprise architects?”

• Question VII.2: “How important are communities for enterprise architects?”

• Question VII.3: “What might be your participation type in a community for enter-prise architects?”

• Regarding question I.3: “Please select the geographic region of your company.” Please consider that participants could even select several answers. For instance someone who works for a global company could choose all regions in which the or-ganization is located.

3 Enterprise Architecture and Enterprise SOA: A Meeting of Disciplines 19

3 Enterprise Architecture and Enterprise SOA: A Meeting of Disciplines

3.1 Executive Summary Historically, enterprise architects have been limited in designing an architecture that supports the business with flexible and adaptable IT solutions. With the advent of en-terprise service-oriented architectures (enterprise SOA), IT now faces a dramatic ex-pansion of the world of the possible. Enterprise SOA represents an architectural con-cept that meets desired characteristics of a future enterprise architecture. A future ar-chitecture is identified by systems that are built to change. Furthermore, these systems must be horizontally integrated to allow process-oriented composition. The answer to why enterprise SOA really meets characteristics of a target architecture lies in its en-terprise services - the fundamental building blocks. This chapter describes the concept of enterprise services in greater detail because services represent an offspring of a synthesis of business and IT. In addition, the chapter compares and delineates a va-nilla service-oriented architecture (SOA) approach with an enterprise SOA. Lastly, there is a mapping of enterprise architecture viewpoints and supporting elements of an appropriate enterprise SOA perspective.

3.2 Definition Enterprise SOA can be defined as the sum of enterprise services and service-oriented architecture. A system that simply exposes its functionality as services can be defined as service-oriented architecture (SOA). However, enterprise SOA is more than just SOA. It is defined in the following way20:

Enterprise SOA is a business-driven architecture that increases adapta-bility, flexibility, openness, and cost efficiency. With an enterprise SOA, companies can compose applications and enable business processes rapidly using enterprise services. With enterprise SOA, organizations can improve their reuse of software and become more agile in responding to change.

Enterprise SOA wants to facilitate cross-functionality and incorporates business proc-esses based, not only on individual Web services, but on enterprise services charged with business semantics and defined in a central enterprise services repository. As the foundation for enterprise SOA, SAP NetWeaver allows companies to decouple their business processes from underlying IT systems. So they are able to manage these processes quite easily without interrupting daily operations [WoMa06].

When we talk about enterprise SOA and other related terms and issues we mainly refer to the architecture of mySAP Business Suite21.

20 Adapted from: http://www.sap.com/platform/esa 21 mySAP Business Suite is a “comprehensive family of adaptive business applications, provid-

ing best-of-breed functionality built for complete integration, industry-specific functionality, unlimited scalability, and easy collaboration over the Internet” (source: http://www.sap.com).


3.3 IT Meets Business It is not a new phenomenon that IT and business departments often fail to communi-cate and collaborate effectively. This situation is often due to divergent architectural viewpoints, incoherent concepts and different terminologies of IT and business groups. Historically, business and IT have had their own visions. Both groups primarily wanted to realize their individual goals. Many business people preferred to create dedicated business models and diagrams that were mostly loosely defined and without a uniform shape. These guys expect that a holistic architecture would be too technical and too formal for them [WiMy04].

Another inefficient approach has happened in the IT department over the past years. Many IT specifications were created with purely functional analytical methods (func-tional analysis). When designing applications, IT technicians basically aimed to derive specifications for software components from specific business functions. This inevitably led to applications that were very inflexible. Unfortunately, changing business require-ments always affected all dependencies between those programs. Emerging object-oriented programming then enabled programmers to encapsulate functionality, re-use software components and utilize new development methods. Long-time object-oriented analysis based on UML (Unified Modeling Language) appears to be the adequate an-swer to closing the gap between business and IT. However, UML did not become a general language to describe the business [LoAn05].

Today, the concept of services primarily intends to interlink the world of IT and busi-ness. Hereby, services illustrate common building blocks that span the bridge between the functional approach of business departments and the object-oriented approach of IT divisions. Services (e.g., enterprise services or Web services in the broader sense) have the potential to actually facilitate the consolidation of business and IT. Services exchange data in the form of standardized messages. This feature makes services that powerful and independent unlike any other implementation technologies in the past. Figure 7 shows the bridge between business and IT and its paving realized by ser-vices.

Figure 7: Services bridge the gap between business and IT

In general, the figure above shows services as fundamental building blocks that close the gap between business activities and IT; however, you can look at the figure to demonstrate the concerns of building each enterprise solution as well. Business wants to rapidly translate its demands into flexible IT solutions that can be shared across business departments or sourced from partners in a business process. Consequently they look for services that perform their required business functionalities. On the other hand, IT professionals consider services to be reusable building blocks that facilitate the composition of enterprise solutions.

Business

Adapted from: [Lapk06c] and [LoAn05]

Services

Functional business approach

Object-oriented IT approach

IT


After all, there is a strong demand to link IT and business to create synergies between both activities. But what is the right way? Where do both disciplines meet each other and what technology facilitates this effort?22

3.4 The Evolution of the Enterprise Service-Oriented Architecture

Before we go further into the question above, we first turn toward the evolution of en-terprise SOA and how services fit into the holistic concept of enterprise architecture.

The beginning of enterprise applications occurred during the mainframe era. Early mainframe applications were directly developed on the mainframe’s operating system. There was no division of concerns, which assumed different layers such as the user interface (UI), the application or the database layer. The final outcome of this architec-ture was an enterprise application characterized by a huge monolithic collection of functionalities and tasks that had to be performed entirely by the application itself [Wood04].

In the late 80’s and early 90’s, applications could run on personal computers and were connected to other applications in the network. For the first time, the implementation of enterprise application was done with consideration to three major layers (UI, monolithic application and database). In addition, personal computers were much cheaper and more powerful than traditional mainframe systems. Today, the enterprise architecture of most companies typically consists of a collection of those monolithic enterprise ap-plications23 (figure 8).

Figure 8: Monolithic, silo-based enterprise architecture

Such architectures have the following main drawbacks [Wood04]:

22 We will have a look at the organizational structure of IT divisions; therefore chapter 5.2 pro-

vides a general insight into the evolution from traditional IT departments to lean IT organiza-tions.

23 This kind of architecture is sometimes called “silo architecture” because each application represents a separated IT silo. That makes it difficult to support cross-functional processes.

Adapted from: [Wood04] CRM

User Interface

Monolithic Application

ERP

User Interface


SCM

User Interface


Tight Integration

Tight Integration

Database Database Database


• Build to last: This inflexible, architectural concept mainly hinders innovation (both business and process innovation) and creativity, which are basic characteristics of successful enterprises within a changing business environment.

• Tight integration: Systems are tightly integrated. That makes it difficult (and some-times even impossible) to adapt and update them. Changing a software component of an application can lead to undesirable side effects in other systems and may have dramatic impact on their operation.

• Code-oriented development: As discussed and already indicated in chapter 1.4 traditional enterprise applications naturally provide an inflexible basis for the solu-tion architecture. Enterprise solutions are built by development teams who consoli-date expensive custom code into cost-efficient standard applications. Software components need to be implemented within multiple systems and cannot be re-used.

• Technical complexity of the IT: The architecture is often characterized by proprie-tary technologies that make it difficult to create an interoperable platform. This is the reason why there is a fundamental gap between business and IT.

Consequently, silo-oriented architectures do not provide an agile foundation that is re-quired for successful business execution. Thus the enterprise architecture needs to be enhanced to achieve a next enterprise architecture maturity stage. Modularized ap-proaches such as enterprise SOA fulfill the requirements of future-proof enterprise ar-chitectures [WoMa06].

Today’s Architecture Target Architecture: Enterprise SOA

Build to last Build to change

Tight integration Loose horizontal integration

Code-oriented development Process-oriented composition

Technical complexity of the IT infrastructure Interoperable architecture for business and IT

Table 2: Architectural characteristics - today and in future

The table 2 lists and compares the characteristics of both a today’s, silo-based archi-tecture and an enterprise SOA. A target architecture should be characterized as fol-lows:

• Build to change: Once an application is created it mostly needs to get optimized and adapted to current requirements. Companies need to implement or change systems within weeks and months to have a real impact. In general, flexibility can only be meaningful by little costs at the same time. In order to prove this first char-acteristic the survey delivers a similar result. Future-proof enterprise architectures must deliver a roadmap for change, not for last - that is one of the most important features of question II.1 rated with 91 out of 100 points.

• Loose horizontal integration: Today you cannot assume that a company only runs systems from one single software vendor. Heterogeneous system landscapes are inevitable and may result from homemade applications, special software prod-ucts from external vendors or mergers and acquisitions. This requires loose inte-gration of systems and enabling of cross-functional, end-to-end processes. At the same time the architecture needs to manage the consistency of data properly to get


valid, accurate, usable and consistent databases across the entire system land-scape.

• Process-oriented composition: Service (re)composition means the plug-and-play assembly of process components in order to orchestrate and tweak business proc-esses. Composing basically enhances flexibility and shortens development time when building custom specific solutions.

• Interoperable architecture for business and IT: Since IT is seen more as an en-abler of growth, the enterprise architecture is shared with empowered employees who are on the front lines of business. An interoperable environment, though, needs to have easy-to-use, comprehensive model-driven and pattern-based devel-opment tools to support the attempts of process innovation. These tools are the fu-ture offspring of a synthesis of business and IT.

The key idea differentiating enterprise SOA (and the SOA approach in general) from earlier approaches of distributed computing lies in the notion of enterprise services as the least common denominator. Enterprise services meet all architectural requirements outlined above. This architecture enables innovation and standardization in an envi-ronment that allows the IT management to deliver at the speed and efficiency required by the business [WoMa06].

Figure 9 illustrates the concepts of vanilla SOA and enterprise SOA. The left graphic shows the service-oriented architecture. SOA describes the general approach of loosely coupled services to support business processes.

Figure 9: Service-oriented architecture versus enterprise SOA

SOA is not implicitly restricted to a specific technology24, though it is mostly realized via Web services. However, vendors who offer applications based on SOA often lack the

24 A service-oriented architecture can be implemented by using technologies like CORBA,

DCOM, REST, RPC and Web services.

Enterprise Services

SAP NetWeaver Business Process Platform

Adapted from: [Woods04] and [WoMa06]

ESR

CRM

ERP

…

Composite Application

SCM

Enterprise SOA Vanilla SOA

CRM

ERP

…

SCM

Composite Application

Servi

ce

Prov

ider

Web Services Se

rvice

s En

viron

ment

Servi

ce

Cons

umer


answer to how companies can utilize and oversee Web services of their systems land-scape to adapt their processes or build their own composite applications25 [WoMa06].

By contrast, the right graphic above demonstrates the enterprise SOA blueprint. Com-parable to the design of a service-oriented architecture, functionality of existing sys-tems (service providers such as CRM, an ERP or SCM systems26) is exposed as a collection of services. On top of these systems, the SAP NetWeaver27 composition plat-form provides extensive integration capabilities of people, information, processes and applications, and it enables standards-based interoperability with other platforms. At the same time, SAP NetWeaver provides the services of the underlying systems in a central, unified enterprise services repository - and that is one key difference between enterprise SOA and other SOA approaches. The enterprise services repository is the actual container in SAP NetWeaver that includes descriptions and metadata about en-terprise services, business objects and business processes available across a com-pany’s service landscape. This repository actually holds a wide variety of services from SAP, customers and partners. Companies can draw upon the contents of the reposi-tory to not only run SAP solutions but also to design, compose and run their own solu-tions. Enterprise services change the way of developing applications - especially the one type of applications called composites, or composite applications. The key charac-teristic of composite applications is that they “run across applications and systems”. To build them, you need to look at all the participants in a business scenario from an end-to-end perspective and compose them by using enterprise services. Finally, there are various technologies that enable users to access composite applications and to partici-pate in the process. Around enterprise SOA, SAP furthermore delivers tools for model-ing user interfaces and orchestrating processes based on enterprise services [WoMa06].

To get to the bottom of this discussion, the survey is consulted to deliver an extra in-sight in regard to enterprise SOA and its real importance in current processes of enter-prise architecture planning (graph 5).

25 Composite applications consist of functionality drawn from several systems and sources

within an enterprise SOA environment. See glossary. 26 In general, a systems landscape of a company incorporates systems to manage customer

relationships (CRM), supplier relationships (SCM), and all the data and processes of the company itself (ERP).

27 The SAP NetWeaver platform helps companies align IT with business requirements. Because SAP NetWeaver unifies integration technologies in a single platform, it reduces the need for custom integration and ensures that mission-critical business processes are reliable, secure and scalable (see glossary).


Graph 5: Enterprise SOA in the context of enterprise architectures

• On the one side, more than two third of the participants (67%) assume that enter-prise SOA is the right concept toward a flexible and innovative enterprise architec-ture. There is a basic consent (48%) that loosely-coupled, standardized compo-nents are the right way to build mature enterprise architectures. Linking customers, partners and suppliers close to companies’ business processes represents a rela-tively large benefit of 40%.

• On the other side, 32% of the participants are more skeptical and suggest enter-prise SOA as one possible architectural blueprint among others. 28% find fault with the technical maturity of the current concept, and less than one-tenth of the partici-pants (9%) basically do not put enterprise SOA on the agenda.

• Beside 30% of the criteria that show that enterprise SOA is not very relevant for companies, 70% of the criteria clearly demonstrate the importance of enterprise SOA.

The key to why enterprise SOA successfully meets requirements of target architectures is the enterprise services themselves.

3.5 Exposing Business Functionality via Enterprise Services In contrast to traditional software components that exchange data by passing parame-ters based on proprietary protocols, services communicate by transmitting messages based on open standards [LoAn05].

Since enterprise services have became fundamental building blocks for the enterprise SOA, we ultimately map them to all previous characteristics of traditional and target architectures. The answer for meeting future, architectural requirement is in the charac-teristics of enterprise services (see table 3).

Question II.4: How does enterprise SOA fit in your EA planning?

0,60,40,20Median

21%

14%

13%

4%

18%

30%Enterprise SOA is the right concept toward a flexible and innovative EA

The future of EA will be standardized loosely coupled components

Enterprise SOA links customers partners, and suppliers close to

business processes

Enterprise SOA is just one of possible business architectures today

Enterprise SOA is not technically matured today

Enterprise SOA is not part of our strategic planning

0.67

0.48

0.40

0.32

0.28

0.09 139 r

espo

nses

So

urce

: Sur

vey


Today’s Architecture Target Architecture: Enterprise SOA

Enterprise Services: Characteristics

Build to last Build to change • Service-enabled systems to increase flexibility

Tight integration Loose horizontal integra-tion

• Open standards to ease integration

Code-oriented devel-opment

Process-oriented com-position

• Reusability to leverage productivity

Technical complexity of the IT infrastructure

Interoperable architec-ture for business and IT

• Business semantics to empower enter-prise SOA

Table 3: Architectural characteristics and the role of enterprise SOA

This leads to the following properties of enterprise SOA and enterprise services:

• Service-enabled systems to increase flexibility. Each enterprise service pro-vides a stable interface, which ensures the same way of invocation both today and in future releases. This makes it easy to adapt functionality in service-enabled composite applications because you only need to recompose enterprise services and do not have to change the implementation of underlying enterprise services.

• Open standards to ease integration. Enterprise services are based on non-proprietary industry standards (e.g. Odette, RosettaNet, etc.) and technology stan-dards (e.g., XML, SOAP, UDDI, WSDL, BPEL4WS, etc)28. This makes it possible to integrate applications (A2A; application to application), enterprises (B2B; business to business), and different user interfaces.

• Reusability to leverage productivity. Defining enterprise services requires de-termining a special level of granularity. This is very critical because, dependent on this specification, enterprise services can be (re)used more or less effectively. Ulti-mately, an advanced pool of documented and well-defined enterprise services en-able the efficient composition of enterprise solutions.

• Business semantics to empower enterprise SOA. Enterprise services are struc-tured according to a harmonized enterprise model based on process components, business objects and global data types. Enterprise services are mostly defined by utilizing an “outside-in” approach. It is an approach that comes, not from the data, but from the top down, from the business side, and it is driven by business re-quirements and by the benefits it provides to the customer. You first model the en-terprise service interface for a special business purpose and then lead the imple-mentation of the service29. This approach enables even non-IT professionals to contribute to shaping IT around real-world scenarios and business processes. That makes enterprise services understandable even for employees outside the IT do-main. But enterprise services can be designed “inside-out” as well. This approach

28 Interoperability standards are not yet common in the IT industry; they are just evolving and

the services concept is one driver. There are standardization organizations like WS-I (Web Service Interoperability Group) which is responsible for defining web service standards. Simi-lar groups are the World Wide Web Consortium (W3C) and OASIS.

29 Enterprise services are aligned with the unified enterprise model. In short, an enterprise model consists of special elements (e.g., people, processes, resources, information) that de-scribe the structure of the enterprise, as well as its goals and business constraints.


exposes existing function modules of the backend systems and so directly pre-defines the interface of the enterprise service.

Enterprise services in mySAP Business Suite provide business functionality and enable service consumers to develop composite applications on top of the application mySAP ERP. From the technical point of view, enterprise services can be compared with Web services30. But from the business perspective enterprise services are charged with business semantics, thus they stand out from common Web services [ABBG06]:

Enterprise services are Web services that have been co-defined by SAP and/or partners. Enterprise Services provide business processes or busi-ness process steps that can be used to compose business scenarios while ensuring business integrity and ease of reuse.

Sometimes, enterprise services are categorized by the role they play in composite ap-plications or by the business value they deliver. This classification associates enter-prise services with categories such as master data management, business intelligence consumer services, analytics, knowledge management, collaboration and mobile ser-vices. Ultimately all services attempt to expand the value and functionality of composite applications to meet users’ needs [WoMa06].

The subsequent graphic (figure 10) shows a typical business scenario. The figure illus-trates an order management process in the form of a composite application.

Figure 10: Example scenario about a canceling an order process

This composite may be able to create, modify or delete an order31. During its run-time, the composite application must access business functionalities implemented in the ex-

30 A Web service is a software system designed to support interoperable machine-to-machine

interaction over a network. It has an interface described in a machine-processable format. Other systems interact with the Web service in a manner prescribed by its description using

31 Functions like “Order_Delete” or “Flag_Material” are Web services that expose special func-tionalities, for instance by wrapping a BAPI (business application programming interface) from a particular system.

Adapted from: [WoMa06] and SAP INFO Magazine 141, p. 35

Existing Systems

Order_Delete Flag_Material Notify_Custo.

Notify_Inv _Departm.

Rem_Order From_Plan

SAP NetWeaver

…

Composite Application (Business Process): Order to Cash

ESR

Cancel Order


isting systems. One action, which is described in more detail, is the cancellation of an order. You would probably expect that the order be deleted in only one particular sys-tem (e.g., the ERP system) when choosing “Delete Order” in the menu of your user interface; however, there are more activities required to completely cancel an order. The record might also exist in the customer relationship management (CRM) system, which deals with the sales aspects of the order. And there is the supplier side and a Supply Chain Management or SRM system, which could also contain order objects. So the process of canceling an order has many different steps. For instance, when the order is deleted, you would also send a confirmation to the customer, remove the order from the production plan and reorganize your production, flag the corresponding mate-rials, and finally, notify the billing department to revise the calculation.

How can companies discover enterprise services? Enterprise services can be browsed and tested in the Enterprise Services Workplace (ES Workplace). The ES Workplace provides frictionless and complete information about enterprise services productized within SAP systems32. Starting from the business point of view you can choose the appropriate business processes from a solution map and then drill down to its functional details until you discover assigned enterprise ser-vices. Another approach for searching enterprise services can be taken via the enter-prise services index. The ES Workplace will be discussed as one crucial tool for enter-prise architects within the enterprise SOA environment (see chapter 4.4.4).

How can companies get new enterprise services? Packages of enterprise services will be released by SAP as part of enhancement packages. In general, these enhancement packages help to relieve chief information officers (CIOs) of the most common dilemma they face today.

Once my system is up and running, you can touch my core once every 5 years ... and I need it to be a Saturday … and my CEO wants me to in-novate every quarter.

Source: CIO, Fortune 1000 Manufacturing Company

On the one side CIOs basically want to keep the core of their systems untouched and only change them once every five years. On the other side the chief executive officer (CEO) demands business and process innovation quarterly. This means that the enter-prise architecture must be able to respond to those business needs. That is exactly where enhancement packages come into play. These packages are optional and en-able companies to take advantage of continuous innovation without interrupting the operations of a business with major system upgrades. Enhancement packages are structured modularly and so enable companies to use and activate only the features and functionalities they require. They include enterprise services and provide new func-tional and industry-specific features in order to improve shared services, end-to-end business processes (e.g. order-to-cash, “hire-to-retire”), as well as supplier collabora-

32 The ES Workplace covers following SAP applications: mySAP ERP, mySAP Supply Chain

Management, mySAP Supplier Relationship Management and mySAP Customer Relation-ship Management. (Source: ES Workplace, http://www.sdn.sap.com, December 2006).


tions. The first enhancement package was released with mySAP ERP 2005 in Decem-ber 2006. 33

3.6 The Enterprise SOA Approach in the Context of an Enterprise Architecture

While enterprise SOA introduces a new architectural concept, it does not require changing the basic approach to enterprise architecture. Companies that address enter-prise SOA need to expand their views of the architectures and adapt their architectural strategy. When managing the adoption of enterprise SOA it is essential to clearly de-scribe the business, technology and information architecture of the enterprise. So the enterprise architecture group is able to effectively lead this architecture initiative and develop a well-balanced service portfolio to construct a solid foundation for business execution [CuAl06].

The following table lists the architectural viewpoints and demonstrates the perspective of enterprise SOA and its supporting elements.

Enterprise Architecture: Viewpoint

Enterprise SOA: Perspective

Enterprise SOA: Supporting Elements

• Define business func-tions to be service-enabled

• Model-driven development tools for designing high-level business processes and backend business proc-esses

Business viewpoint

• Use the enterprise SOA ecosystem to gain more value from enterprise SOA

• Communities around enter-prise SOA

Technical viewpoint • Define the strategic platform for the op-eration of the archi-tecture

• SAP NetWeaver infrastruc-ture

Information architecture • Standardize commu-nication and harmo-nize business objects

• Global data types and busi-ness objects

• Ensure broad appli-cability of enterprise services

• Integrated and standardized development tools

• Promote consumabil-ity of enterprise ser-vices

• Enterprise services reposi-tory

Table 4: How enterprise SOA fits into a company’s enterprise architecture

33 Further information about SAP’s first enhancement package and its concrete contents are

available on the SAP Developer Network.


Business viewpoint To migrate the existing business architecture toward enterprise SOA companies often utilize an outside-in approach by determining business functions of their systems to be service-enabled. Since modeling is the organizing principle of enterprise SOA, SAP therefore provides a variety of specific modeling tools. For instance, tools are available for adapting high-level business processes (ARIS for SAP NetWeaver) and backend business processes (SAP NetWeaver Exchange Infrastructure’s Cross Component Business Process Management). When processes are designed in an interoperable services-based environment, steps within business processes can be linked together to create process automation. By automating the tasks between systems and humans (particularly realized by analytical tools34) you generally increase the overall efficiency of the process. Enterprise SOA makes it possible to realize innovation by flexibly com-bining processes that can go beyond traditional boundaries of an organization [WoMa06].

In order to improve the value from an enterprise SOA, the architecture comes with an extensive ecosystem including system integrators, independent software vendors, con-sultants and hardware suppliers. Companies that adopt enterprise SOA can join this vibrant ecosystem and participate in diverse communities such as the Enterprise Ser-vices Community (ES Community)35 or the Business Process Expert Community (BPX Community)36. These communities provide a wide range of contributions for everyone’s benefit [WoMa06].

Today communities are important for keeping a competitive position at the front of IT and business progress. An ecosystem around a concept such as enterprise SOA is a totally new approach of leveraging the quality of the architecture.

Technical viewpoint Enhancing the enterprise architecture to better drive business change basically means providing a flexible, technical foundation. The SAP NetWeaver platform represents the technical foundation for the enterprise SOA. SAP NetWeaver unifies integration tech-nologies in a single platform based on open standards. It reduces the need for custom integration and ensures that mission-critical business processes are reliable, secure, and scalable. SAP NetWeaver provides a whole modeling and operating environment for enterprise services. This includes as a set of technology and tools that primarily want to ensure secure, reliable, and optimized communications between service pro-viders and service customers. This allows the implementation of enterprise SOA ac-cordingly to architectural guidelines, accounting for Web service standards, design pat-terns, security and transaction mechanisms [WoMa06].

Information viewpoint Because enterprise SOA focuses on integrating and composing many end-to-end busi-ness processes - especially those that span heterogeneous systems, multiple organi-zations and relationships with business partners - it is important to have a keen under-standing of business data. For instance, the order canceling process explained above

34 Analytical tools enable the automation of processes. These tools provide the opportunity to

react instantly to a specific event by analyzing the process. 35 ES Community: http://www.sap.com/platform/ecosystem/escommunity/index.epx


has several key data artifacts (business objects), such as the order, the customer, the production information, the material, the invoice and the confirmation receipt. Describ-ing these artifacts in a standard way is important for an enterprise SOA approach to ensure that each service that participates in the process can understand the data equally. In the enterprise SOA environment this is realized through global data types37.

Enterprise architects need to expand their architectural viewpoint by fostering a broad applicability of enterprise services. This basically means that services need to be de-signed as simply as possible. Architects and developers utilizing integrate development tools must define the appropriate level of granularity of these reusable assets. In prac-tice the level of granularity is mostly dependent on the functionality of a specific enter-prise service.

The next important aspect that changes the viewpoint of information architecture is consumability of enterprise services. It is not sufficient to create a pool of enterprise services that eventually can be used in diverse business situations. In order to use and consume enterprise services, they provide metadata about their specific usage scenar-ios and are stored in a central enterprise services repository [BlJa03a].

The enterprise services repository is a searchable archive for reusable enterprise ser-vices. The enterprise services repository stores metadata about how enterprise ser-vices are linked to business processes and the way that they may be accessed at run-time [WoMa06].

Solution viewpoint Well-defined business, technology and information architectures are the foundation for adopting enterprise SOA in a managed way. Finally, the migration of those architec-tural viewpoints affects the solution architecture and changes the way that applications are designed and built. Applications move away from being hard-coded and rigid enti-ties toward dynamic compositions of services. In order to prevent that application teams from developing these enterprise services for whatever they want, the solution viewpoint must be expanded with a service portfolio view. This portfolio categorizes enterprise services and shows their basic relation to business units and business proc-esses. It basically shows available capabilities of the enterprise for building and com-posing a specific application. The enterprise services portfolio provides an overview of “as is” services and helps the enterprise architecture group to decide what services are needed for future initiatives (“to be”) [CuAl06].

Managing these services of the service portfolio is a continuous process driven by changing business and IT requirements. Ultimately, this is a crucial point that shows the differences between a service portfolio management and a traditional software de-velopment lifecycle38.

36 BPX Community: https://www.sdn.sap.com/irj/sdn/bpx 37 Global data types place a constraint upon the interpretation of data to ensure that data in

transferred between enterprise services in a standardized format. Business objects are col-lections of functionality that represents a business entity. See glossary.

38 Further reading regarding to modeling of service-oriented solutions: http://www-128.ibm.com/developerworks/rational/library/jul05/johnston/

4 The Evolving Role of the Enterprise Architect 32

4 The Evolving Role of the Enterprise Architect

4.1 Executive Summary Would you build or remodel your house without an architect? It is doubtful. Nor should you set up or transform your core business processes without an enterprise architect. While the concept of enterprise architecture is old, the position of the enterprise archi-tect is undergoing a renaissance. In the past, enterprise architects mainly focused on developing technical architecture as well as standardizing and consolidating their sys-tems landscape in order to reduce cost. In today’s state, enterprise architects expand their sphere of influence. They aim to provide a flexible, service-based platform to lev-erage activities such as business process management and information management. It is the enterprise architect who is responsible for ensuring that all money spent in in-formation, technology and process improvement is well-aligned to the business strat-egy and the holistic enterprise architecture. Thus the enterprise architect needs to pos-sess a certain level of authority to fulfill this new, challenging task. It is quite obvious that the evolution of enterprise architecture implicates changes within the organization structures as well.

4.2 Definition Enterprise architects look at the company from an architecture perspective. Some companies call and identify an enterprise architect as a “chief architect” or “chief enter-prise architect”; however, we will solely use the term “enterprise architect” and define it at follows [HaWe06]:

The enterprise architect is responsible for leading the enterprise architec-ture process to develop, maintain and evolve the enterprise architecture across the enterprise.

This definition is short; however, it implies a broad range of skills and authority of an enterprise architect. The enterprise architecture process describes the steps necessary to move the current architecture toward the target architecture.

4.3 The Enterprise Architect’s Field of Responsibility Commonly enterprise architects are called “change architects” because they are re-sponsible for designing and reengineering the company’s enterprise architecture. This means enterprise architects have to transform while performing at the speed of change, need to possess myriad skills, require a good grasp in different disciplines, and are able to utilize diverse tools.

As shown in figure 11 basically there is a gap between current and future state enter-prise architecture that is filled by the enterprise architecture process. This process en-sures an architectural migration toward the desired future state in a managed way.


Figure 11: Move the current architecture toward a target architecture

Current state (“as-is”) and future state (“to-be”) architecture The current architecture is a representation of the “as-is” or baseline of the existing architecture. It is important to understand and document the current state because if you do not know where you are (current state), you do not know if you are on the way to where you are going (target state). The current-state architecture typically lacks the ability to adapt the change accompanying a realigned business strategy. Then it is im-portant to define the target state and initiate the enterprise architecture process to achieve it. Simply stated, implementing the target state architecture (sometimes called “to-be”, future or desired state architecture) is ultimately a final outcome from the en-terprise architecture process. The target state represents a snapshot of the enterprise architecture at some future point, which will be achieved once it meets the predefined architectural goals reflecting the business vision [Lapk05].

The Enterprise Architecture Process The enterprise architecture process is a pragmatic and logical approach that includes several phases for any organization wishing to transform its enterprise architecture to the target state. To transform the enterprise architecture to the target state, the enter-prise architecture process should not happen in isolation. It must be linked to both stra-tegic IT planning as well as to the company’s systems development lifecycle39.

As declared in the definition above, leading this process to target architecture is the central task for the enterprise architect. The survey exactly confirms this definition as it evaluates the architect’s responsibility “promoting of the enterprise architecture proc-ess” with 93 out of 100 points (graph 6).

So we want to turn to the enterprise architecture development process and outline re-sponsibilities and skills of an enterprise architect within this process. The enterprise architecture process consists of six main phases illustrated in figure 12.

39 Linkages of the architecture process with strategic IT planning and systems development

lifecycle processes, however, are not explicitly addressed in this thesis.

Current

State

“As-Is”

Enterprise

Architecture

Target

State

“To-Be”

Enterprise

Architecture

Enterprise Architecture Process


Figure 12: The enterprise architecture process

Initiating the enterprise architecture process requires a strong business case that dem-onstrates the need for the new architecture. In the first phase of the process, the CIO and the enterprise architecture group need to obtain support from both senior execu-tives and business units and define a basic communication strategy for the initiative. In the second phase, it is important to establish (or adapt) a governance structure that helps the organization to control and monitor the enterprise architecture activities and progress. The next phase in the process is defining the basic enterprise architecture approach that facilitates managing the upcoming change. Phase four focuses on build-ing the target state and documenting the current state of the architecture and ultimately developing a migration sequence between both states. Afterwards it is critical to ensure that the architecture is used across the organization and that the architecture remains current and reflects the up-to-date requirements of the business.

Before going through the process in greater detail, we will briefly turn to the key activi-ties for enterprise architects. They are: lead, communicate as well as oversee and con-trol. These activities are listed in the center of the enterprise architecture process (figure 12) and accompany the enterprise architect throughout the process.

The survey results shown below (graph 6) identify appropriate skills enterprise archi-tects must possess to perform these key activities. Loosing sight of key activities dimin-ishes the probability of program success.

Maintain the EA

Lead

Communicate

Oversee and Control

3

1

5

2

Use the EA

Establish Governance

Architecture Approach

Initiate the EA Program

Develop the EA Adapted from: [Fcio01]

4

6


Graph 6: Key responsibility and main skills regarding to the EA process

The goal of the enterprise architecture process is to translate business strategy into concrete prescriptive guidance to be used by the organization in projects that imple-ment change. Indicated in graph 6, enterprise architects must be able to translate busi-ness strategy into architecture requirements (skill1). That is the most important skill (rated with 95 out of 100 points) of enterprise architects and directly relates to the goal of the architecture process.

Below, key activities essential for the enterprise architecture processes are linked to other highly-ranked skills reported in the survey (illustrated in graph 6):

• Lead (mapped to skill 2, rated with 87 points): Enterprise architects must be experienced “change architects” to minimize resistance occurring throughout the process: “We need architects who are involved in projects. They have to prove their standards, which were defined by them earlier on and evangelize architecture within these projects. They bring the idea of architecture into projects”40. Enterprise architects ensure that the value of the target architecture is higher than its over-head.

• Communicate (mapped to skill 3, rated with 91 points): Enterprise architecture cannot be over-communicated! In order to minimize “change pain” and increase support for the architecture, the enterprise architect possesses excellent skills to communicate it to stakeholders and users of the enterprise architecture.

• Oversee and control (mapped to skill 4, rated with 91 points): Enterprise archi-tects must have a “big picture” in mind in order to transform the enterprise in its whole. The strategic “big picture” enables them to control and govern the architec-ture and measure the progress of the architecture process.

40 See interview with Hermann Schlamann (Credit Suisse).

93 Points

95 Points

Totally Unimportant (0 Points)

Enterprise architects…

Question IV.1 and IV.2: What are responsibilities and skills of enterprise architects?

Sour

ce: S

urve

y

Promote the enterprise architecture process

Are able to translate business strategy into architecture requirements (skill 1)

Fairly Unimportant (25 Points)

Indifferent (50 Points)

Fairly Important (75 Points)

Totally Important (100 Points)

Question IV.1 (responsibilities): 137 responses

Question IV.2 (skills): 138 responses

Possess strong leadership skills (skill 2)

Are excellent communicators and negotiators (skill 3)

87 points

Can hold the balance between "big picture" and short-term activities (skill 4)

91 points

91 points


Before initiating the enterprise architecture process, you need a strong business case based on enterprise principles that demonstrates the need of the future architecture. The business case is a structured proposal that includes information about how the architecture wants to achieve operations cost reduction, more efficient business proc-esses, as well as potential new revenue streams and identifies expected risks of the initiative.

4.3.1 Phase 1: Initiate the Enterprise Architecture Program The first phase of the enterprise architecture process is a critical area of responsibility of enterprise architects because they call for sustainable executive commitment to the entire architecture program.

Figure 13: The enterprise architecture process - Initiate the EA program

Obtain support from senior executives and business units Before starting on the path, you need to obtain broad management commitment and approval for the IT investment. On the one hand this task demands strong awareness and commitment of senior executives and on the other hand, it needs the support from business unit leaders.

While the CIO is responsible for obtaining executive buy-in and sponsorship for the architecture, the enterprise architect primarily creates a plan to obtain support for the architecture from business units. It is recommended that business unit leaders (domain owners) and subject matter experts set up a leadership group. Thus the leadership group can contribute to the enterprise architecture process by ensuring that their ap-propriate business unit is considered properly within the business viewpoint of the en-terprise architecture [Fcio01].

The survey results deliver further insights in challenges for a CIO and the enterprise architect on the way to target architecture. Graph 7 demonstrates four organizational challenges.

1

Initiate the EA

Tasks in this area: • Obtain executive support • Obtain support from business units


Graph 7: Organizational challenges on the way to a target architecture

• Lack of executive awareness: With reference to the enterprise architecture, this is a major challenge for CIO’s. It accounts for 33% of all challenges facing companies from 1,000 to 40,000+ employees41. It is notable that this challenge is quite equally distributed over all three classes of company sizes.

• Missing support from business leaders: This is the second largest challenge that is of particular concern for enterprise architects. In total it accounts for 29% of all challenges but in particular, it presents a large challenge for companies with 10,000 to 40,000 employees - even for 75% of companies having this company size.

• Missing support from IT leader: Since the CIO is involved in architectural issues (see question II.2a of the survey), IT leaders typically provide their active support for the enterprise architecture. However, 48% of the larger companies (10,000 - 40,000 employees) say that they have difficulty getting support from IT leaders. At first, this result appears confusing because the transformation of the enterprise ar-chitecture is initiated and realized by the CIO of the organization. However, the re-sult may be due to frustrated business people who have experienced diverse archi-

41 33% is the sum of this challenge and was calculated as follows: 11% (companies with 1,000

to 10,000 employees) + 12% (comp. with 10,000 to 40,000 employee) + 10% (comp. with more than 40,000 employees).

2,5

2

1,5

1

0,5

0

Mea

n

10%

12%

11%

6%8%

6%

8%13%

8%

8%

5%5%

More than 40,00010,000 - 40,0001,000 - 10,000Company size

Question II.3: What are challenges and issues to overcome on the way to the best-fitting EA?

135

resp

onse

s S

ourc

e: S

urve

y

Lacking executive awareness of EA Missing active support from IT leaders

0.64

0.39

0.48

0.29

0.71

0.48

0.75

0.27

0.61

0.39

0.48

0.50

Missing support from business leaders Organizational restructuring efforts


tectural initiatives in the past that did not really support their specific business needs.

• Organizational restructuring efforts: Ultimately this is a relatively small challenge for organizations with impending architectural change. Only 25 to 29% of compa-nies that employ up to 40,000 people state organizational restructuring efforts as a challenge when transforming the enterprise architecture. However, 50% of large companies (more than 40,000 employees) see organizational restructuring as a major challenge on the way toward their target state (“to-be”) enterprise architec-ture. Architecture initiatives in such companies need more executive buy-in and strong governance.

Indications of the evolving role Don’t “sell” enterprise architecture in a traditional way: Enterprise architects have real-ized that driving the enterprise architecture process is a difficult undertaking. Because enterprise architecture is a complex concept that does not provide quick return on in-vestments it is poorly comparable to a traditional IT investment. Therefore, enterprise architects need to points out that the key for realizing value of the architecture man-agement. Architects are in the unique position to identify the greatest reuse opportuni-ties. They should guide the organization to reuse architectural assets (architectural components, patterns, services, designs, metadata, data, business processes, sub-processes, documentation, etc.) to add value at an incremental level. Putting the archi-tecture into practice by utilizing the re-use concept does not involve asking for a budget of several millions of dollars. Instead the architecture team just needs to ask for enough money to solve the problem of the first people - but in an enterprise architecture con-text. This means that this initial effort generates architecture deliverables (architecture products) that can be reused in later architecture initiatives.

4.3.2 Phase 2: Establish Governance Structure Next it is crucial to establish a management structure and control mechanism to suc-cessfully develop the target state architecture. Effective governance is a key factor for transforming the architecture to the next architecture stage by facilitating and improving the performance of roles and responsibilities.

Figure 14: The enterprise architecture process - Establish governance structure

Why is governance so especially important for the IT organization and for the enter-prise architecture? IT governance provides leadership, processes and management

Establish

Governance

Tasks in this area: • Define principles for EA governance • Embed the EA in IT governance and establish

appropriate governance bodies

2


structures that ensure that the enterprise’s IT is aligned with the corporate strategies and objectives. In turn the enterprise architecture represents the foundation for busi-ness people and IT experts to define and establish internal control mechanisms. Man-aged and well-documented enterprise architecture is an enterprise asset that provides senior management with a high-level perspective of the enterprise (including business processes, data structures, enterprise systems, etc.) needed to effectively manage the controls. In the past, the lack of these controls has been rather awkward and embar-rassing; however, since the Sarbanes-Oxley Act charges many companies with over-seeing, regulating, inspecting and maintaining disciplined accounting procedures, in-ternal control reporting has reached a new dimension of importance [FiCl04].

Even investors have realized the importance of governance. A survey from McKinsey shows that they pay up to 20% more on shares of companies having well-defined gov-ernance structures implemented42.

Define principles for enterprise architecture governance Management and organization principles delineate the high-level rules and guidelines that are used by the organization to govern the enterprise architecture process. They influence implementation, usage and maintenance of the enterprise architecture. Lead-ing the creating of principles though is no key responsibility of enterprise architects43.

Embody governance in the enterprise architecture The main formal bodies that are required to establish a governance structure for the enterprise architecture are listed below; however, the enterprise architecture roles should be evaluated dependent on the size and complexity of the business and the architecture. While in small and medium organizations a single person may be respon-sible for several roles, in large companies an individual is more likely to be assigned to one specific role44 [HaWe06]:

• Enterprise Architecture Execute Steering Committee (EAESC): This committee primarily guides and oversees the enterprise architecture program. In addition it approves high-level architecture artifacts and the entire enterprise architecture. This committee should be composed of senior managers and executives who have the power to make decisions within the organization and who can ensure that these decisions are carried out as well.

• Enterprise Architecture Program Management Office (PMO): This governance body is responsible for managing, monitoring and controlling the enterprise archi-tecture program. The PMO governs the enterprise architecture development proc-ess and creates an enterprise architecture roadmap to achieve the goals set by the EAESC. It wants to ensure the overall success of the enterprise architecture pro-gram.

• Enterprise Architecture Review Board (EARB): This governance body is re-sponsible for validation, reviewing, and approving enterprise architecture content and outcomes at a lower architectural level (e.g. any type of architecture models on

42 McKinsey’s Investors Opinion Survey, June 2000 43 See question V.1 of the survey. 44 Further information about their responsibilities and interaction types will be addressed in

chapter 5.


a logical and implementation level). Members of the EARB include senior IT and business leaders. As the EARB also governs the use of enterprise architecture out-comes, members of this board utilize their authority to promote the enterprise archi-tecture in their teams.

• Enterprise Architecture Team: An integral role for building an architectural man-agement structure is the enterprise architecture core team. This team typically con-sists of business, technology, information and solutions architects and support staff. The head of the team is the enterprise architect. The enterprise architecture team is basically charged with all activities regarding the development, implementation and maintenance of the enterprise architecture. Once the scope of the enterprise archi-tecture is defined in the next phase (see 4.3.3), the architecture effort can be con-verted into required full-time equivalents with more accuracy.

Indications of the evolving role Enterprise architecture process becomes more formal: In order to support governance and management of the architecture, today more and more companies implement a formal enterprise architecture process. They want to ensure that the enterprise archi-tecture is transformed and expanded in a managed way. Therefore, enterprise archi-tects ensure the right management structures composed of the right roles and people. Furthermore they track progress of architectural initiatives and the compliance with architecture principles.

4.3.3 Phase 3: Define the Architecture Approach Phase three defines the basic enterprise architecture approach that intends to close the gap between the desired future state and the current state of the architecture.

Figure 15: The enterprise architecture process - Define the architecture approach

Understand and use the operating model of the enterprise This model shows how the organization basically aims to do business, how it delivers goods and services to customers and how it plans to grow and act in its business envi-ronment. The idea of this approach is to assign each enterprise to one of four general groups: diversification, coordination, replication and unification.

Even though a detailed discussion about operating models would go beyond the scope of describing responsibilities of enterprise architects the strategic positioning of the

Tasks in this area: • Understand and use the operating model

of the enterprise • Encapsulate the EA in a core diagram • Contribute to defining use and scope of the

architecture • Create a communications plan • Evaluate and select an EA framework • Develop an education plan for the EA group

Architecture Approach

3


enterprise illustrated in an operating model is seen as a valuable input for the first phase of designing and building the enterprise architecture45.

Encapsulate the enterprise architecture in a core diagram The enterprise architecture process should start with encapsulating the enterprise ar-chitecture in a core diagram. This diagram is a simple one-page picture derived from the company’s operating model. The core diagram demonstrates the desired architec-ture state consisting of processes, information and technical elements. The main ad-vantage of such a diagram lies in its high-level view of all building blocks of the archi-tecture. This allows both business and IT managers to discuss the target architecture and afterwards to communicate the vision throughout the organization. Companies may address different architectural components in their core diagram. Nonetheless, four key components can be identified [RoWR06]:

• Core business processes: This first component includes only a few business processes that are most important to perform the company’s operations and to re-spond to changing market needs.

• Shared data: This component considers shared data, particularly that which is used within business processes that are crossing multiple business units of the or-ganization.

• Integration technologies: The technical aspect of core diagrams is mainly ad-dressed by “middleware” technologies applied to integrate distributed applications and used to provide standardized user interfaces to these systems (e.g., enterprise portals).

• Key customers: The last part of core diagrams is presented by major customer groups.

The enterprise architect uses core diagrams due to their capability to translate busi-ness strategy into architecture requirements46. To design an enterprise architecture core diagram, one utilizes an appropriate template for the specific operating model. Templates suppose a specific modeling sequence of the architecture components and design them in a specific manner. How to create core diagrams by using the operating model of a company is introduced in Appendix A.

Contribute to defining the use and scope of the enterprise architecture Architecting a future state should typically be linked to the strategic plan of the organi-zation. Before designing and constructing the architecture, the enterprise architect ini-tially should help to define how the target state architecture will be used and formulate how it is intended to meet these business requirements. The enterprise architect needs to update the use and purpose of the enterprise architecture, as it is likely to evolve over time. Furthermore, the enterprise architect contributes to defining the scope of the architecture. In order to avoid a target architecture characterized by disparate systems and “stovepipe” operations, the views of the enterprise architecture must span the en-tire organization. This is typically realized by using a broad high-level business per-spective. In addition, it is important that the scope of the architecture is considered in a

45 The concept of operating models is introduced in Appendix A.


vertical dimension as well. It requires a top-down approach of each basic architectural viewpoint. This approach ensures that the architecture is driven by the business strat-egy and that it is structured in a consistent and hierarchical way [Cio01].

Create a communications plan Since enterprise architecture is a complex concept that is not intuitively grasped out-side the IT organization, the CIO and the enterprise architect should prepare a com-munication plan that demonstrates the benefits and the value of the architecture. This plan includes information about general communication purposes, audiences and mes-saging, communication channels and types, action plans and a feedback process [Fcio01].

The goal of this endeavor is to involve stakeholders in the enterprise architecture proc-ess in order to gain support for the initiative and ensure that the architecture is really understood and used after the transition of the architecture. Therefore, a comprehen-sive stakeholder analysis should be conducted.

A very important group that the communication program should focus on is that of ap-plication developers. Only 45 of 138 participants said that application developers of their companies care about enterprise architecture (33%)47. This result is quite repre-sentative and describes the situation of application developers in traditional IT organi-zations. However, especially after the transition to matured enterprise architecture, for instance enterprise SOA, the role of application developers is changing. Technically skilled people in the IT organization like application developers will not create applica-tions from scratch like they did it in the past. Instead, they will create enterprise ser-vices while the business side composes applications based on existing services. The interaction between application developers and business analysts will increasingly fo-cus on defining what services to create, and in which order [WoMa06].

Communication should be taken seriously following timetables, milestones and meas-ures. If a lack of audience interest is registered, the enterprise architecture staff should pursue interviews and try to get direct feedback from the audience.

Evaluate and select an enterprise architecture framework As mentioned in chapter 1.4, there are many well-established frameworks for the pri-vate and public sector. These frameworks provide agreed-upon sets of constructs to communicate and express building blocks of the enterprise architecture. In addition, enterprise architecture frameworks typically provide a design process including best practices to reduce the time for creating a target state architecture. Alternatively, an organization may come to the decision to develop its own framework. On all accounts, an organization should always balance costs, benefits and risks of creating its own framework against those of adapting and tailoring an existing framework. The three most relevant frameworks identified by the survey48 are:

• The Open Group Architecture Framework (TOGAF) (chosen by 54%)

• The Zachman Framework for Enterprise Architecture (chosen by 35%)

46 Referring to Graph 6, translating business strategy into architecture requirements represents

the top responsibility for enterprise architects (95 of 100 points). 47 See question II.2a of the survey. 48 See question III.3 of the survey.


• The Gartner Enterprise Architecture Framework (chosen by 29%)

Although 71% of companies utilize enterprise architecture frameworks, it seems that they have difficulty with effectively understanding and applying their frameworks. At least that is the result from the survey, as frameworks are the most important content of education programs for enterprise architects49.

Before selecting an enterprise architecture framework, an enterprise architect should have a general understanding of distinct criteria to evaluate frameworks50. The most important criterion ascertained by the survey is a top-down approach (24%). This crite-rion encourages driving the architecture out of the business strategy. The next feature for evaluating frameworks is a process (23%) that supports guidance in the creation of target state enterprise architecture. A framework should also provide advice on archi-tecture governance (17%). Architecture governance is a key process for managing organizational changes while meeting goals and strategies of the target architecture. Frameworks can apply governance in a relatively pragmatic way (such as an agree-ment and IT principles) or in various strongly enforced policies. The next criterion is coherence and uniformity (13%) because a consistent architecture concept may facili-tate the communication of the architectural goals. The fourth feature is adaptability and expandability (12%). because an architecture framework will rarely be in a final state. Markets evolve and business requirements change continuously. Companies within vibrant business environments may add particular weight to this aspect. Another less important criterion is abstraction (6%), which means that the framework is able to pro-vide the right level of abstraction for specific stakeholders. The last criterion for evaluat-ing enterprise architecture frameworks is maturity (5%). Most good frameworks do not start out perfect; they have to face architectural challenges over time and must be en-hanced when necessary.

The most important frameworks as determined by the survey Most rele-vant criteria identified by the survey

The Open Group Architecture Framework (TOGAF)

The Zachman Framework for EA

The Gartner EA Framework

Top-down approach

• Well supported by the ADM and the continuum

• Very neutral, no predefined se-quence for filling and populating the cells.

• The architecture is explicitly driven out of the busi-ness strategy (business con-text)

Process • Mature and well-defined process

• Neutral deliver-ables

• Well defined process model

Governance • Strong governance • Governance is supported

• Governance is supported by the process and the framework

• Legend: + = good - = caution

Table 5: Comparison of enterprise architecture frameworks

49 See both question III.1a and question VI.3a of the survey. 50 See question III.1b of the survey.


The Open Group Architecture Framework (TOGAF) is available free of charge and represents an industry standard in designing, evaluating and developing enterprise architecture. TOGAF supports a top-down approach for developing its four basic archi-tecture domains (business, data, application and technology architecture). However, the reality of time and resource constraints often hinders practicing an all-inclusive top-down description of all architecture domains, even when the scope of the architecture clearly limits the full extent of the organization. The process of TOGAF, the Architecture Development Method (ADM) is quite mature. The ADM is applied to develop an enter-prise architecture that will fulfill the company’s business and IT needs. The process is cyclic and iterative. Architectural requirements are disposed, addressed and prioritized within each relevant phase of the process. In addition, the expanded ADM provides a separate process having extra steps for developing the technology architecture. Phase G of the ADM is dedicated to implementing governance and ensures that the transition of the architectures are realized through change projects. However, the implementation of governance is only one aspect of architecture governance. Thus TOGAF provides an Architecture Governance Framework that is an integral part of the Enterprise Con-tinuum51.

The Zachman Framework for Enterprise Architecture provides enterprise architects with a way in which to think about an enterprise systematically and in a structured way; however, it is characterized by its latitude in populating the cells of the matrix. This may lose the general notion to drive the architecture out of the business strategy. In addi-tion, the framework says nothing about the processes for defining and developing ar-chitectural viewpoints. Zachman’s methodology of designing the architecture is rela-tively neutral because it does not dictate any specific outcome of each cell (e.g., a dis-tinct deliverable in the form of a model). The framework includes principles reflected in the set of rules (addressed in the motivation column) that govern the transformation of the enterprise architecture52.

The Gartner Enterprise Architecture Framework is characterized by a clearly de-fined top-down approach. The architecture is explicitly driven out of the business strat-egy (business context including environmental trends). This approach divides the over-all strategy into three basic architecture viewpoints: the business, technology and in-formation viewpoint. Each viewpoint is described by using three different levels of ab-straction: the conceptual, the logical and the implementation levels. These layers en-force architecture decomposition from the conceptual design to an extensive and de-tailed implementation plan. Gartner’s process for developing an enterprise architecture is well defined and aligned to its enterprise architecture framework. It is a multiphase, gradual and nonlinear process model with an emphasis on architecture development, evolution and migration. The process addresses governance within the step “develop principles”. This step establishes a consistent set of architectural principles that will help the organization to make conscious IT investment decisions53.

51 TOGAF is outlined in Appendix B1. 52 The Zachman framework is briefly introduced in Appendix B2. 53 Since the introduction in enterprise architecture (see chapter 0) often refers to Gartner’s no-

tion of enterprise architecture, the Gartner Framework was not described in greater detail in an extra chapter.


Develop an education program for the enterprise architecture group Enterprise architects should initiate an education program for the enterprise architec-ture group. Developing target state architecture typically brings in new technologies, innovative business processes and new ways that information is managed across the organization. Consequently, enhanced skills are necessary to lead the enterprise archi-tecture process and to understand the viewpoints of the target architecture.

Resulting from the survey, there is a basic agreement that education programs are important for an enterprise architect and the members of the architecture group. Edu-cation should be organized as a combination of long-term programs (selected by 62%) and of short, well-directed workshops (selected by 53%). Additionally, these programs should be categorized by “mentor-mentee” relationships.

Today an education program should address topics such as enterprise architecture frameworks (selected by 85%) and enterprise SOA (selected by 82%). It also should provide a deeper insight into business architecture (selected by 79%).

Indications of the evolving role Increase stakeholder involvement: The involvement and support of key business and IT stakeholders are critical to the success throughout the enterprise architecture process. Since enterprise architecture requires creative collaboration across a wide range of professionals, sustainable involvement must ensure that appropriate resources are brought to bear. Consequently, the communication plan should include customized stories for each group of stakeholders. After all, enterprise architects should be on the same page with architecture stakeholders.

Architecture scope extends the reach of architects: Today many companies are char-acterized by integrated business processes that go beyond their organizational boundaries and include customers, suppliers and partners. This also affects the devel-opment of the enterprise architecture as it describes the current and future state of an organization’s business processes, technology and information. Therefore, an enter-prise architect often interacts and works with individuals and systems outside of his or her own company.

4.3.4 Phase 4: Develop the Enterprise Architecture In phase four the target enterprise architecture is developed by implementing the roadmap. The basic viewpoints of the enterprise architecture - business, technology and information architecture - are transformed and expanded in a managed way.

Figure 16: The enterprise architecture process - Develop the EA

Tasks in this area: • Collect information • Define future state EA • Document current state • Review architecture products • Develop gap analysis • Derive migration plans • Approve and publish the overall EA

Develop the EA

4


Collect information The first step within the developing phase is about identifying documentation of the existing architecture, as well as collecting architectural blueprints for the desired future architecture. This activity is quite crucial for sequencing steps. All information compiled and collected should be placed in an information system that is able to store and pro-vide access to these architectural assets - typically called the enterprise architecture repository. Furthermore, this enterprise architecture repository should be able to detect relationships and dependencies among information elements and work products; there-fore, electronic links among different architectural elements can facilitate the under-standability of the information. Furthermore, the repository should provide versioning functionality for tracing architectural assets [Fcio01].

In addition, this step should include a reviewing of documentation of the current archi-tecture. If the amount of information about the architecture is insufficient, it may be nec-essary to interview subject matter experts (SME) and domain owners; however, partici-pation is these interviews should be guaranteed due to the communication and buy-in process described in area one (chapter 4.3.1).

After conducting this step, the architecture core team can begin with developing enter-prise architecture products and elements, identify the differences between products of the baseline and target architecture (gap-analysis) and lead the migration to the target architecture.

Define the future state of the enterprise architecture The process of moving the organization from where it is today to where it wants to be in the future requires formal thought. This thought process is documented in the strategic plan of the enterprise. It summarizes long-range business goals and objectives in mis-sion and / or vision statements and offers overall direction and strategic management to a company. The strategic plan typically relates to the company’s operating model because the business strategy alone provides a poor direction for developing an IT infrastructure and business process capabilities. But in conjunction with the operating model, you can drive a top-down sequence of enterprise architecture development [RoWR06].

As described in chapter 4.3.1 and shown in Appendix A the enterprise architecture core diagram encapsulates the operating model of an organization. The core diagram pro-vides a high-level view of the company’s customers, business processes, technology, and data and even illustrates their interdependencies. This “big picture” diagram repre-sents an optimal starting point to derive conceptual models and tools for each view-point of the enterprise architecture.

Developing the target architecture should be done before analyzing the current state architecture. Target state architecture describes each basic viewpoint of the architec-ture and so produces the following architectural elements [Lapk05]:

• Requirements: Frame the demands of the enterprise

• Principles: Provide guidance by articulating decisions of the architecture

• Models: Visualize how components of the target state architecture interoperate to generate value


The following example scenario outlines how the business, technology and information architectures are developed, utilizing Gartner’s notion of enterprise architecture [Lapk06b]:

Scenario A consumer goods company is structured in four completely independent lines of business that are operating autonomously. The company indirectly sells its products to approximately fifty wholesalers.

Business strategy

The distribution model of the company results in high cost that is passed along several intermediaries to the customer. The management decides to reduce the number of wholesalers and strives to increase market share by implementing a direct sales strategy.

Impacts of the strategy on the business

The organization must be able to share customer data across the organiza-tion and thus integrate processes among the largely autonomous LOBs.

Architecture principle

The architecture supports sharing of customer information across lines of business.

Table 6: Sample scenario for demonstration architecture development

The new strategic direction of the company outlined in the scenario above (table 6) affects the enterprise architecture in respect of customer data. Business units should be integrated and use shared data for corporate business processes such as direct selling to the customer. In conjunction with the architecture principle(s) the business strategy can derived in descriptions of architecture viewpoints.

In order to avoid complexity, the basic viewpoints are consecutively defined only for the conceptual layer. This layer describes the architecture out of a senior management perspective. The logical layer which addresses concerns of operational management and the implementation layer which represents detailed concerns of change agents should keep clearly in mind but are disregarded in this exemplary scenario.

Requirement Principle Model

Conceptual Order entry, fulfill-ment and collection process must inte-grate seamlessly

Customer-facing busi-ness processes will be consistent across all LOBs

Conceptual cross-functional process models

Logical … … …

Implementation … … …

Table 7: Exemplary conceptual layer of a target business architecture

The business viewpoint of the target architecture (table 7) is characterized by a seamless integrated business process. The process should span multiple silos and includes process steps such as order entry, order fulfillment and order collection. To ensure a consistent model that is aligned to the business strategy the enterprise archi-tect assigns principles for each architectural effort. The principle for meeting the re-quirement of a seamless integrated process defines that there must be a consistent interface to the process on the customer side. Ultimately the conceptual business re-quirement of the target architecture can be modeled in a cross-functional process model.



Conceptual Customer-facing component must be available anytime, anywhere to any cus-tomers (service level requirement)

Shared infrastructure services ensure high availability and en-able identity and ac-cess management (asset criticality)

Simple models that show key dependen-cies across domains

Logical … … …


Table 8: Exemplary conceptual layer of a target technology architecture

In the technology viewpoint (table 8), we find service-level requirements at the con-ceptual layer defining the availability and accessibility of customer-facing components. Ensuring identity and access management are important principles that guide devel-opment of the specific target architecture. A target architecture that expresses these high-level, technical requirements can be created by applied models for technical archi-tecture. The models should visualize dependencies among architecture domains (such as the database, the network, the security domain, etc.). For instance the customer facing component can only be running when the network is available, when there is no bottleneck for accessing data from the database, when firewalls and security tech-niques work properly and so forth.

At the logical level these infrastructure design requirements might be decomposed and provide conditions for defining infrastructure that meet specific service levels. At the implementation layer specific product standards might be used for implementing the infrastructure [JHLG05].


Conceptual Leverage customer information across the enterprise

Customer information must be shared across the enterprise

Information flow models

Logical … … …


Table 9: Exemplary conceptual layer of a target information architecture

The information viewpoint (table 9) of the target architecture needs to be changed as well. Realizing a direct sales strategy means that information relevant for the new busi-ness process must be leveraged across the enterprise. A good principle for the con-ceptual level is that all the information concerning customer operations must be shared across business units. Only in that way can customer information be leveraged without having disparate, “stovepipe” system and database silos. To grasp and realize this no-tion, the information flow should be modeled in reference to processes and systems.


The target architecture54 identified through conceptual models may include alternatives, options and unknowns. But this is acceptable because unknowns are filled within the iterative enterprise architecture sequence. As we have seen above, enterprise archi-tects must be able to decompose complex multifaceted business issues into architec-ture viewpoints. These viewpoints are easier to understand and provide clear stake-holder-specific direction.

However, enterprise architects must perform another complementary role. They must be aware that all parts of the architectures are intimately related to each other. So they combine and reconcile loosely coupled architectural descriptions of diverse viewpoints into a consistent architectural description of an enterprise solution. Only an enterprise solution ultimately applied to address a specific business problem can deliver value and leverage appropriate systems and processes [JHLG05].

This role of an enterprise architect can be reflected in a philosophical way as illustrated by the following quotation55 [Sche04a]:

An enterprise architect knows he or she has achieved the perfect solu-tion, not when there is nothing more to add, but when there is nothing left to take away.

The second, complementary role assumes that enterprise architects have knowledge of all enterprise architecture viewpoints. The survey results underline the importance of this skill by rating it with 91 out of 100 points56.

Document the current state of the enterprise architecture In developing the target architecture, an important logical step is describing and docu-menting the current state of the architecture. Describing the “as-is” architecture has the following purposes [Lapk05]:

• Create a baseline to compare it against the target state architecture: Baseline ar-chitecture is crucial to measure the progress of the future architecture.

• Discover drawbacks of the current architecture: Understanding the current state helps to discovers dysfunctions, inefficiency and complexity of the current architec-ture.

• Serve as reference materials: Documentation, e.g., of a specific architecture view-point, serve as reference material for other viewpoints and can be reused as archi-tectural assets for future initiatives.

The survey clearly shows that overseeing documentation is an important responsibility for enterprise architects (this criterion reached 85 out of 100 points)57. However, it is naïve to assume that documentation needs to be perfect because architectural artifacts will be out of date the day after you pass and publish them. Documentation just needs to be good enough so that enterprise architects can understand and communicate the current architecture and future vision for the enterprise. Even when this guidance is

54 In practice future state architecture sometimes is the result of compromises and tradeoffs

versus the ideal state. 55 Original quotation is named “Perfection” and comes from Antoine de Saint-Exupery. 56 See question IV.2 of the survey. 57 See survey, question V.1.


incomplete and fragmentary, it is often much better than the uneducated work of a pro-ject team until it gets official documentation.

For larger organizations that have strong commitments to spent money on baseline analysis, there are methods, models and techniques that yield a complex description of their current architecture. Medium and small enterprises often have a comprehensive inventory that describes the current architecture [Fcio01].

Review architecture products In the first instance, the enterprise architecture core team is responsible for reviewing its architecture artifacts that describe the target state (and maybe the current state) of the enterprise; however, their competency may be insufficient for detailed architecture models to be assessed. Before passing the architecture products to subject matter ex-perts (SME), senior members of the enterprise architecture core team should review them. This review procedure may be repeated until changes of the last review are in-cluded and the architecture products are updated. When the products have a specific level of maturity, the SME review can be conducted. In this review step, completeness and accuracy of the specific enterprise architecture element are defined. Participants are typically subject matter experts (such as business process experts, industry ex-perts, etc.), the enterprise architect, members of the architecture core team, domain owners, as well as quality and risk managers. In this phase, the risk manager can ef-fectively make a contribution to assess business and technical risks and may point out early cost and schedule risks for implementing the architecture. For validation and final approval of the products, they should be passed to the Technical Review Committee (TRC) and then to the Enterprise Architecture Executive Steering Committee (EAESC). Upon approval from these governance bodies, the documentation of the products should be updated and published [Fcio01].

Analyze gaps between the current and future-state architecture The gap analysis is typically accomplished after reviewing the enterprise architecture products. Enterprise architecture deliverables from the review step are now compared in respect to their current and future state specifications. The gap identified by compar-ing appropriate states of architecture deliverables represents the extent of the change initiatives. If all of the current architecture can satisfy the requirements of the target architecture then, in theory, there is no need to charter any projects. To identify and analyze the gaps the following key inputs are required (although not exclusively) [BiKr05]:

• Description of the target state architecture: Models and artifacts that describes the envisioned architectures.

• Documentation of the current state architecture: Specifications and documenta-tion of current architectural assets.

• Requirement of enterprise solutions: Enterprise architects who perform the gap analysis must not only identify but also analyze gaps between both architecture states. This is very important because achieving the envisioned future stages of the enterprise by “simply” closing the gaps will not necessarily lead to a harmonious foundation for building enterprise solutions. To avoid conflicting architecture view-points, the gaps must be analyzed and evaluated for compliance with enterprise so-lution requirements (derived from the common requirements vision).


• Principles of the conceptual architecture: These high-level principles embody the spirit and thinking of the enterprise architecture, reflect consensus across the enterprise and help the organization to guide deployment and implementation of the target architecture.

Analyzing the gaps highlights architecture products that have been inadvertently left out, deliberately eliminated, or are yet to be developed. Gap analysis specifies the fol-lowing activities to use the inputs [BiKr05]:

• Identify and classify: Basically there are different types of gaps that can be identi-fied. The most critical type is the gap in stakeholder concerns, as it was not consid-ered in prior architecture work58. Other potential sources of gaps can be people, process, tools, information, technical, or financial gaps. Afterwards, these gaps should be classified, e.g., into cultural, structural and functional gaps [Toga03].

• Utilize appropriate tools and techniques: Gap analysis typically utilizes different tools that show and highlight the differences between the current and target state of the architecture. One tool proposed by TOGAF is the gap analysis matrix59.

• Develop and prioritize recommendations: After analyzing and understanding the gaps, recommendations are made that describe how to close the gaps - what pro-jects to be made. Generally, the migration from current to target architecture should be managed and pursued incrementally to minimize the impact of unforeseen events on the efficient operation of a company. Migration may be realized by sev-eral alternatives that should be formulated and prioritized in a sequencing plan.

Before planning the migration described in the next step we will exemplarily have a look at one major section of the sequencing plan: the migration analysis. This analysis describes the process of closing the gap especially for technical architecture compo-nents. Therefore three types of systems should be differentiated [Fcio01]:

• Legacy systems that run current operations but are usually phased out during de-ployment of the target architecture.

• Migration systems that temporarily sustain operations during the migration phase (including systems, databases, interfaces and other components).

• New systems that are planned to be an operational part of the target architecture.

58 Concerns of the stakeholders should be specified and on hand by accomplishing a stake-

holder analysis. This prior activity is an integral part of a communication program (see chap-ter 4.3.1).

59 This matrix draws up architectural building block of the baseline architecture on the vertical axis and all architectural building block of the appropriate target architecture on the horizon-tal axis [Toga03]


Figure 17: Systems migration types

The key to changing the systems in this example (figure 17) is to define the right se-quence for phasing out functionality of current systems and deploying new functionality within an enterprise. To ensure an uninterrupted transition of the systems the enter-prise architecture core team commonly operates migration systems until the operation of the new systems can be properly launched. Basically there are six ways a system may evolve [Fcio01]:

• The legacy system does not need to be changed an continues its operation (Sys-tem D)

• Functionality of a current system is superfluous and covered by a target system (System A System B)

• Legacy system evolves into a migration system and afterwards forms a new system (System B System X)

• The current system evolves to a new system without having a migration system (System C System Y)

• The system does not exist at the beginning of the systems migration process. It is deployed during transition and becomes the new system of the target architecture (System E).

• A legacy system transitions to a migration system and finally merges with another legacy system to the new system.

Next to technical and functional dependencies, decisions and recommendations about the sequencing should be driven by costs, benefits and risks.

Plan the migration path for closing the gaps Based on a sequencing plan that defines the step-by-step process for moving from the current architecture to the envisioned architecture, the migration is now planned with consideration to resources such as budget, people and time. For instance changing a business process is typically formulated within an entire program which includes multi-ple projects. Each project represents a logical division of work and is led by an individ-ual project manager. A project focuses on the implementation of one specific change initiative (or a set of initiatives) [Fcio01].

Adapted from: [Fcio01]

System A

System B

System C

System D

System X

System Y

System E

System D

System B

System E

System N System K

Today Transition Period Target


Approve and publish the overall architecture The last step in this phase is about “getting a green light” for the overall enterprise ar-chitecture. This requires the approval by the Enterprise Architecture Executive Steering Committee, the CIO, the enterprise architect, executives and the CEO. However the approval process may differ from organization to organization. Before promoting the usage of the enhanced enterprise architecture, information about the architecture basi-cally needs to be shared. This is typically realized in electronic read-only formats; how-ever, enterprise architecture documentations should not be distributed in its entire ex-tent to all employees and stakeholders because such information may imply a security risk for the organization. Therefore, groups should get detailed information only con-cerning a specific subset of the enterprise architecture [Fcio01].

Indications of the evolving role Move up the architecture stack: Historically the focus of enterprise architecture has been on the technical architecture, which was reflected in the technical skill set of en-terprise architects. Today enterprise architecture is explicitly driven by the business strategy, and therefore, technology expertise is not as paramount as it has been. New and expanded architecture viewpoints (such as business or information architecture) require advanced skills of the architecture team. Enterprise architects must understand the operating model of the company to translate it into architectural requirements.

4.3.5 Phase 5: Use the Enterprise Architecture In phase five, the enterprise architecture is used to implement and enhance the com-pany’s foundation for business execution. This phase establishes a connection be-tween the architecture and implementation organization. The primary goal of this phase is to govern the overall implementation and deployment process.

Figure 18: The enterprise architecture process - Use the EA

Promote usage of the enterprise architecture Enterprise architects need to proactively encourage organizational groups to use the architecture and, therefore, promote its outcomes and results across the organization. As the new architecture encapsulates strategic plans of the organization it should be-come a central tool supporting daily business operations. In order words the new archi-tecture represents a strategic information asset base which supports decision-making

5Use the EA

Tasks in this area: • Promote usage of the EA

• Implement projects by ensuring compliance with the defined architecture


and communication of these decisions across the organization. Promoting and applying this new asset is often a technical and cultural challenge [Fcio01].

• Technical challenges: Using the enterprise architecture to support business op-erations, for instance in the form of rapidly-built business solutions for a specific business problem, frequently implicates technical challenges. Enterprise architects must ensure that the company uses appropriate development tools and techniques for building solutions in compliance with the architecture.

• Cultural challenges: While technical aspects are relatively easy to fulfill, it is often underestimated how much the final success of enterprise architecture efforts de-pends on political and cultural factors. Typically, it is hard to get agreement among members of the organization on what technologies to use and how to use and manage them. In addition, roles can change when the architecture emerges. This may cause resistance of veteran developers due to their unwillingness to accept the new rules for creating enterprise solutions and to conduct projects. That is one of the reasons why the overall issue of IT governance is so important.

Implement projects by ensuring compliance with the defined architecture An integral step in the fifth phase of the enterprise architecture process is the imple-mentation60 of the defined architecture. In times of crisis and disruptive change, when companies need to transform rapidly to survive, it can make sense to implement mas-sive projects; however, this undertaking if often too risky and expensive for companies to realize an all-at-once approach. Alternatively companies can implement one project at a time by ensuring that each project implements one specific piece of the defined architecture. This approach avoids the notion that enterprise architecture is seen as an ivory tower because it guides and relates to each single project. In addition, smaller and manageable projects mitigate risks and shift costs of the implementation across the organization [RoWR06].

The enterprise architect and the architecture core team advise project/program leaders on developing business solutions. They want to ensure that projects that are formu-lated and prioritized in the sequencing plan are really funded and implemented, but they usually do not get involved deeply in the details of a single implementation project. Before the final investment decision61 is made, the architecture team assesses the alignment of project proposals to the enterprise architecture by means of following cri-teria [Fcio01]:

• Business alignment: It is important that the proposed investment is aligned to the business goals and strategy. Since each project is responsible for implementing a small piece of the enterprise architecture, the business outcome of the project must meet its specific conceptual requirements.

• Business case solution: The architecture team evaluates the high-level business case of the project. The solution should only be implemented when the project sup-ports basic architecture viewpoints (business, technology, information architecture).

60 Note that there is an organizational-specific development process (software development

lifecycle) where the actual development occurring in parallel. 61 Investment decisions are made within IT planning processes of the organization. These proc-

esses, which parallel the enterprise architecture process, are not explicitly addressed in this thesis.


• Sequencing plan: The proposed project must fit into the sequence of the overall migration plan to implement the target architecture.

• Technical compliance: The proposed solution must fulfill obligations of technical compliance such as enterprise standards and methodologies.

If project proposals are not aligned to the enterprise architecture, the architecture team additionally will support implementation teams to bring these projects into compliance. However, the survey results indicate that enterprise architects have relatively little re-sponsibility for these consulting activities. 137 participants rated this consulting activity as the least important responsibility of enterprise architects (80 out of 100 points)62.

Indications of the evolving role Linking enterprise architecture contributions with IT benefits: Enterprise architecture efforts need to be linked to the IT results of implemented projects. For instance, enter-prise architects can show the positive impact of the architecture on the reduced time necessary for building composite applications (on top the architecture). Therefore, the architecture team should create a metrics program which demonstrates how the archi-tecture supports achieving IT and business goals.

4.3.6 Phase 6: Maintain the Enterprise Architecture Finally the enterprise architecture should keep up with ongoing changes in business functions and technology of the enterprise. Consequently, each component of the en-terprise architecture needs to be maintained and updated.

Figure 19: The enterprise architecture process - Maintain the EA

Reassess the enterprise architecture periodically and ensure that enterprise architecture products remain current Enterprise architecture is a dynamic process that aims to reflect the current vision of the enterprise. To avoid the architecture becoming “shelf ware”, it needs periodical re-assessment and maintenance to ensure that:

• The current state visualized in architectural artifacts reflects the real IT infrastruc-ture, and the target state properly reflects the business vision of the organization.

6Maintain the EA

Tasks in this area: • Reassess the EA periodically and ensure

that EA products remain current


• The sequencing plan is up-to-date and considers priorities and available resources of the current business environment. The sequencing plan represents the strategy for managing change in the form of short and long-term change initiatives.

Drivers for changing the enterprise architecture can basically be of a technical and business nature:

• Technology drivers such as new technology reports, technology withdrawals or initiatives of technical standards.

• Business drivers such as business exceptions (e.g., an unexpected event in a business process), business innovations and strategic change.

The consideration of high-level technology and business drivers that potentially trans-form the organization characterizes a proactive approach for maintaining the architec-ture. The evolution of business functions and technologies should be planned and ex-pected by the architecture team. Another approach that should be practiced is the reac-tive one. An example is a business process that has changed within business units. Business unit managers and subject matter experts (SME’s) should inform the enter-prise architecture team about changes and initiatives accomplished in their organiza-tion.

We have seen that maintaining and reassessing the enterprise architecture is important to reflect the ongoing change of the enterprise. Once the enterprise architecture no longer reflects business strategy, it needs to be changed. Depending on the extent of the upcoming change initiative, you can distinguish the following types of change [Toga03]:

• Simplification change: This is the simplest form of change. It can be accom-plished by using a change management technique such as configuration manage-ment.

• Incremental change: An incremental change may be accomplished through con-tinuous improvement processes; however, this change may also require an iteration of a part of the enterprise architecture development process.

• Re-architecting change: This type of change is quite radical. It requires the initiat-ing of a completely new enterprise architecture process. This is typically necessary to transform the architecture through major maturity stages in order to adopt mas-sive changes. The enterprise architecture journey and its transition through several maturity stages is describes in the next chapter.

Before launching the next “wave of innovation” (in the form of upcoming change initia-tives), the organization should cash in on lessons learned. This is important because it offers opportunities for improvement. The company’s culture should allow an atmos-phere of trust that makes continuous improvement everyone’s concern. Lessons learned can be compiled from business owners, project development teams, from in-vestment planning and management teams, as well as from the architecture team. Fi-nally the enterprise architecture team should communicate lessons learned to stake-holders of the architecture. In addition, the lessons may be shared with external or-ganizations and consultants.

62 See question V.1 of the survey.


4.4 Transitioning Through Enterprise Architecture Maturity Stages

Since enterprise architecture is a continuous journey, you can basically classify four different maturity levels illustrated in figure 20: the business silo architecture, the stan-dardized technology stage, the optimized core stage, and the business modularity ar-chitecture (e.g., enterprise SOA). In order to achieve the next maturity stage, manage-ment cannot easily shut down the enterprise and start from scratch. They need to re-design and then smoothly implement the architecture without interrupting daily opera-tions.

Figure 20: Enterprise architecture maturity stages

Companies that move through these maturity stages require lots of persistence. How-ever, when they advance their enterprise architecture from the business silo architec-ture to later stages, they can achieve a number of benefits (such as reduced IT costs, increased IT responsiveness, improved risk management, increased management sat-isfaction and enhanced strategic business outcomes).

In order to move the architecture to a next maturity level, a re-architecting change is required. As delineated in the figure above (by the dashed loop), this is managed by accomplishing an entire enterprise architecture process. Many companies migrate through all architectural stages. Some companies may choose not to migrate to a spe-cific architecture stage, and others may wait and see if other companies have success-fully adopted the next architecture stage. As described above, transitioning through the architecture stages affects the organization and changes the way a company does business. Enterprise architects must be aware of the organizational change at each stage and keep on learning from each stage. This is an important pre-requisite for cre-ating value from the current stage and to be ready for the next stage. Companies take different amounts of time- for these transitions. Large companies typically require sev-eral years for each architecture stage [RoWR06].

The following table (table 10) characterizes enterprise architecture maturity levels by defining their impacts on the company, its IT organization and business units. These impacts are specified in the subsequent chapters.

Business Silo Architecture

Standardized Technology

Optimized Core

Business Modularity (Enterprise SOA)

…


Impacts of architectural maturity levels on… Maturity Stages Company IT organization Business units

1. Business Silo Architec-ture

Deliver solutions for local problems and op-portunities.

Implement specific, local business processes. The architecture does not im-pose any constraints on business units’ activities.

Design individual business processes and specify required IT functionality.

2. Standard-ized Tech-nology

Shift from local applica-tion to shared infrastruc-ture.

Provide cost-effective and reliable systems based on standard technologies. For the first time IT shapes business solutions.

Accept standardiza-tion and systems consolidation.

3. Optimized Core

From local view of data and applications to an enterprise view.

Reuse data in several proc-esses and create business process platforms.

Optimize core enter-prise processes and articulate the com-pany’s operating model.

4. Business Modularity

Extends optimized core architecture through reusable modules.

Enable a seamless linkage between (plug-and-play) business process modules. Provide a platform for inno-vation.

Use modules for de-signing and adapting front-end processes.

Table 10: Impacts of enterprise architecture maturity stages

4.4.1 Stage 1: Business Silo Architecture The business silos architecture represents the first stage of enterprise architecture. Companies primarily make IT investments to meet local business needs. In this stage, the architecture does not make any constraints (e.g., standardized business processes, shared services, etc.) on business units’ activities. Thus IT ideally provides the func-tionality for delivering 100 percent solutions to the business. This often results in one-off solutions mainly demanded by local business managers in order to support their individual business requirements. These solutions make companies highly responsive to local market changes. However, one-off solutions are developed from scratch and are often not designed to communicate with each other. Subsequent efforts to integrate these disparate systems are time consuming, risky and expensive. It is often not the frustration about silos that demand the enterprise architect to move to the next maturity stage. It is the cost.

4.4.2 Stage 2: Standardized Technology In the second stage of architecture, maturity standardized technologies are the motor to move from local applications to a shared infrastructure. Companies mainly decrease the number of platforms by establishing a small set of technology standards. IT there-fore utilizes these standards and negotiates solutions (e.g., best-of-breed solutions) if they are not aligned to their technology platforms. Standardized technologies facilitate global flexibility and reduce complexity of the consolidated systems landscape.

Adapted from: [RoWR06]


Before passing this stage, the systems landscape of Credit Suisse was characterized by common business silos. As in most other companies, in the past Credit Suisse bought best-of-breed solutions that did not fully fit in a harmonized and standardized application portfolio. While moving to the second stage, “Credit Swiss defined standard platforms which support this architectural concept. Today there is a basic, architectural decision-making process for purchasing or developing enterprise solutions systemati-cally. This means new applications must be compatible with the existing systems land-scape and need to be aligned with the IT strategy”63.

Systems landscape consolidation by reducing the numbers of platforms is a significant responsibility of enterprise architects in this phase. They have broad knowledge of business operations performed by systems, data structures embedded in applications and technology components that run these platforms. The survey clearly shows (graph 8) that enterprise architects, in junction with the CIO, make and enforce platform deci-sions.

Graph 8: Participation in platform decisions in consideration of company sizes

In general, the enterprise architect similarly participates in these decisions regardless of the company size. 61% to 68% say that enterprise architects participate in almost all platform decisions while 31% to 39% say that enterprise architects just support but cannot control platform decisions. But it seems that in 5% of the large companies with more than 40,000 employees, enterprise architects lose their power to actively partici-pate and contribute in platform decisions. To bring architects into the decision-making process of large companies, they need to gain more authority.

4.4.3 Stage 3: Optimized Core In the optimized core stage, companies view data and applications from an enterprise perspective and so mainly focus on shared data and enterprise systems. IT extracts crucial data from enterprise systems and makes it reusable for business processes and other IT applications. Business process platforms enable companies to effectively cre-

63 Interview with Herman Schlamann (Credit Suisse).

2%5%

31%

62%

39%

61%

32%

68%

100,0%

80,0%

60,0%

40,0%

20,0%

0,0%

Perc

ent

Othershave nothing to do with decision-

making

just support and consult CIO but cannot control

decisions

participate in almost all decisions

Participation in platform decicions

More than 40,00010,000 - 40,0001,000 - 10,000

Company size

Question IV.5b: Do enterprise architects participate in platform decisions?

138 r

espo

nses

So

urce

: Sur

vey


ate solutions on top of the optimized core architecture. However, standardizing shared data and optimizing core business processes necessitates taking control over business processes that were previously “owned” by local business unit leaders. Thus it is diffi-cult for enterprise architects to sell this architecture stage to business managers. Busi-ness managers should articulate the company’s operating model and work hand in hand with senior architects in order to define the enterprise architecture and implement the operating model. Global data and standardized process designs mostly influence or even dictate local decision-making. Even though local business needs are met subop-timally, standardized process designs do best support global business needs.

4.4.4 Stage 4: Business Modularity (Enterprise SOA) Business processes optimized in the third stage are refined and modularized in the forth stage. The outcomes from these activities are reusable modules (mostly based on Web service technology) connected to core data and backend processes. IT ensures that these modules can be seamlessly integrated and (re)composed into business process. These modules even allow business unit managers to individually create and optimize their front-end processes without accounting for backend implementation is-sues. This stage basically fosters a culture of innovation. In general, employees feel more empowered than ever before because they believe that their suggestions can make a difference in the development of new products or in the optimization of proc-esses. In this stage of architecture maturity, IT and business units can more quickly implement these suggestions and reward productivity. In other words, business modu-larity architectures decentralize decision-making by handing the tools to the line man-agers and thus creating a proactive, innovative climate.

Impacts on the role of an enterprise architect Today many companies are at the threshold of migrating their existing architecture to the business modularity stage. One well-known concept characterized by business modularity is Enterprise SOA.

Graph 9: The biggest challenge for enterprise architects

As shown in the graph above, 83% of the survey participants specified that a migration to enterprise SOA is the major challenge for enterprise architects in the future. This is now the right starting point to turn to the challenging impact of enterprise SOA on the role of the enterprise architect.

The advent of enterprise services increases the importance of enterprise architects within companies. Enterprise architects are responsible for managing the development of enterprise services. As mentioned above, enterprise services make up the enterprise SOA and are, by nature, loosely coupled business modules with standardized inter-

0.83

…

Question IV.6: What are challenges for enterprise architects in future?

137 r

espo

nses

So

urce

: Sur

vey

Migration from the existing architecture to Enterprise SOA

1 0,8 0,6 0,4 0,2 0 Mean


faces. Such a loosely coupled architecture does not work by magic. On the one side, enterprise architects have to define the scope of enterprise services with the IT per-sonnel and must make services available throughout the organization. On the other side, enterprise architects must understand the requirements from business units, as well as how they will access and consume those services. However, looking at both sides of the curtain (the one side of service providers, as well as the second side of service consumers) and thereby not losing the oversight to proactively enhance the architecture is a difficult undertaking. Without the enterprise architect, who is responsi-ble for the big picture of the architecture, service specifications hardly reconcile with service requirements and vice versa. If such a mismatch happens, the architecture will not solve any business problems that were expected being solved before adopting the enterprise SOA [BlJa03b].

To meet these challenges of managing modularized enterprise services, enterprise architects must possess a wide range of capabilities, most of them non-technical.

• Manage expectations: Enterprise architects need a certain amount of pragmatism when adopting enterprise SOA. For instance, while enterprise SOA is primarily business process oriented, a deployment of enterprise services must consider the underlying architecture over which the solutions should be deployed. Furthermore, architects may need to reengineer enterprise services before deployment in order to effectively drive service reuse. These are all aspects that demonstrate the need to manage expectations. The adoption of enterprise SOA may be impeded if busi-ness people and IT staff see enterprise SOA as working like a “magic bullet”.

• Ensure stakeholder involvement: Designing enterprise services is best served by inputs from experts of cross-functional teams. Therefore it can be necessary to ex-pand the enterprise architecture team and include virtual members. This team can identify where benefits cross business units and make an impact on business re-sults. Once an enterprise service is integrated into the enterprise architecture (more precisely, into the enterprise services repository of the enterprise SOA environ-ment), users of these services are often non-technical and can be in virtually any part of the organization. The purpose of enterprise services, and so the concept of enterprise SOA, is to remove the day-to-day burden from IT and shift it to business users. Thus enterprise architects must ensure continuous stakeholder involvement to realize value from this architecture maturity stage.

• Decrease the need for SOA governance when using existing services: It is important for enterprise architects to provide the right guidance and control to effec-tively govern the enterprise SOA. On the one side, companies can dramatically re-duce the need for IT governance when adopting enterprise SOA. The answer is quite simple. The company can reduce the incidence of decision-making as they use existing enterprise services provided by SAP. These services are predefined, standardized and freely available. Enterprise architects can easily browse the En-terprise Services Workplace (ES Workplace)64 and afterwards integrate and deploy services in their environment [WoMa06].

• Adapt and reengineer IT governance: However, companies might not only use existing services from SAP and other software vendors. Then enterprise architects need to adapt the existing IT governance in order to ensure management of enter-

64 The Enterprise Services Workplace is described in greater detail in Fehler! Verweisquelle

konnte nicht gefunden werden..


prise services across the entire lifecycle (from inception through analysis, design, construction, testing, deployment and production execution). The IT governance process traditionally starts with defining goals for IT initiatives. Next, the process delegates these goals to departments within the IT organization, such as applica-tion, hardware, security, networking and so forth. The SOA governance, however, tries to keep a constant dialog between business and IT through the concept of domain ownership. A new governance body may be established - let’s call it the SOA governance council - which is responsible for defining these domains. Do-mains are characterized by a set of managed enterprise services sharing a com-mon business context. Consequently, members of each domain have to maintain applications that consume their services and ensure that services interfaces are accessible for other domains. The notion of service domains radically changes re-sponsibilities of development teams. While developers were mainly focused on im-plementing functionality within applications they are now responsible for developing enterprise services within their specific service domain. The enterprise architect should understand that pursuing a cultural shift is necessary in order to make vari-ous developers and IT professionals aware of the new practices and their benefits [BlJa04]65.

• Leverage the architecture by joining an enterprise SOA ecosystem: As enter-prise SOA is adopted, enterprise services will begin to proliferate within companies. It will become increasingly important for enterprise architects to provide services that meet specific requirements of their customers (both internal and external). Therefore SAP has established the Enterprise Services Community (ES Commu-nity)66 as a way for all members to directly influence the design and specification of new enterprise services. Companies who participate in the ES Community are able to make proposals of desired enterprise services that SAP should deliver to lower their integration efforts. Ultimately, enterprise architects should understand how to benefit from the ES Community in order to leverage their enterprise services foun-dation to drive innovation around business processes and composite applications [WoMa06].

65 Please find further information regarding SOA governance: [MiTi05], [MaFr05]. 66 Enterprise Services Community: https://www.sdn.sap.com/irj/sdn/developerareas/esa/esc.

5 Organizational Structure 63

5 Organizational Structure

5.1 Executive Summary Organizations have realized that general business goals cannot be fulfilled by solely adapting their systems landscape and implementing smooth business processes. Fur-thermore, they consider the organizational structure to be a central aspect in becoming a successful, agile market player who is fulfilling these business goals. This requires the definition of roles and procedures for management and the governance of enter-prise architecture early on. Subsequent chapters provide basic insight into the evolving role of the information systems organization as well as a common and future structure of enterprise architecture teams. However, companies should realize that a specific organizational structure is no “magic bullet” that can implicitly ensure the success of the enterprise architecture. Organizational structure rather should be aligned with the strat-egy and processes of an organization.

Structure follows process follows strategy.

Alfred D. Chandler, 1969

5.2 From Traditional to Lean Information Systems Organizations

Information systems organizations come in various shapes and sizes. Each of these organizations is built around major macro processes that it performs or supports. These processes generally fulfill specific, IT-related needs for internal customers. Al-though each information systems organization has a unique structure and individual processes, they may have many elements in common. As the enterprise architecture team is positioned within the information systems organization of a company, we will first address the major structural trends that face the entire information systems organi-zation today [Pear06].

The information systems organization is typically led by a chief information officer (CIO)67. As the CIO is responsible for setting the strategic direction of the information systems organization, he or she has to choose an appropriate organization structure. Figure 21 represents a centralized approach to the information systems organization. A centralized approach was primarily dictated by mainframes in the 1960’s. Mainframes resided in one physical location and required centralized decision-making and local staff that operate and maintain these systems. During the 1980’s, personal computers allowed computing power to be spread beyond the raised-floor, air-conditioned rooms of mainframes. This was the very beginning of a decentralization approach to the in-formation systems organization. Today the strategies, processes and structures of in-formation systems organizations exist along a continuum from centralization to decen-tralization. Organizations should weight benefits and drawbacks against these two ap-

67 Head of the information systems organization can also be a vice president or a director.


proaches. Some companies may combine the two approaches and choose a federal approach68, found in the middle of the continuum [Pear06].

As shown in figure 21, the information systems organization basically constitutes a cen-tral entity along a value chain of service providers and service customers. On the sup-ply side, you can identify external service providers such as systems integrators, tech-nology providers and professional services providers. On the demand side are custom-ers of the information systems organization, mostly represented by company-internal business units.

Figure 21: Traditional IS organization

Further indicated in the figure above are three major macro-processes within the infor-mation systems organization. These macro processes include all activities that the or-ganization executes on operational, tactical and strategic levels [Gart03].

• The first macro process is about driving innovation within the company; therefore, it addresses processes such as strategic IT planning, management and oversight. In addition, this high-level macro process includes defining of business require-ments in order to drive enterprise architecture as a key enabler for innovation.

• The second macro process of this organization takes up the innovations of the up-per macro process and addresses all activities to effectively deliver and facilitate change. This includes supportive processes (such as educational processes, cul-tural change processes, etc.), as well as development processes to build applica-tions and solutions.

• The last macro process is responsible for providing the infrastructure to support existing and emerging systems. This process includes basic IT disciplines such as data operations and maintenance, network management and desktop support.

Today many of these organizations are under tremendous pressure being in a market-place that continuously demands “producing” more while spending less. IT divisions of publicly-traded companies are often challenged by increasing regulatory standards (e.g., the Sarbanes-Oxley Act) and compliance efforts (e.g., technology to enable sus-tainable compliance with these regulations). While information systems organizations have to manage an increased complexity in their IT environments, they additionally

68 Further reading about Federal IT: “Eight Imperatives for the New IT Organization”, John F.

Rockart, Michael J. Earl, Jeanne W. Ross. Sloan Management Review. Fall 1996.

Business Units

External Services Provider

Supply-side Demand-side

1

2

Driving innovation (strategic)

Delivering change (tactical)

Supporting infrastructure (operational)

2

3

1

3

Adapted from: [Gart03] IS Organization


have to offer cost-efficient and convenient business solutions. These demands on IT have prompted information systems organizations to find an innovative answer in order to quickly and effectively meet these challenges. The answer consists of two main is-sues: outsourcing of selective IT services and shifting IT activities to business units. The result is a transformation of the structure of this organization toward a lean infor-mation systems organization.

The impacts of IT outsourcing on the structure of the IS organization To ease IT pressure, many information systems organizations delegate specific parts of their daily operations, and even of their tactical business (illustrated in figure 22), to an external entity that is specialized in these activities69. While an example of IT ser-vices on the tactical layer may be application services, IT services on the operational layer comprise management of networks, data center operations, call center and Web hosting services. Thereby, organizations outsource (relocate) IT services that are not core and thus are not directly responsible for business success. As the left arrow in figure 22 illustrates, IT outsourcing establishes new types of relationships between the IT organization and external services providers. Common vendor relationships shifts to outsourcing relationships, such as strategic partnerships (vendor is responsible for an integral set of operations of the outsourcing IS organization), co-sourcing alliances (both outsourcer and IS organization are responsible for the success of the outsourcing project), and transactional relationships (the vendor processes well-defined, repeatable operations for the outsourcing organization)70.

Figure 22: Evolving IS organization which reflects the trend of outsourcing

Effective outsourcing of IT operations to external service providers moves information systems organizations to a more decentralized structure. Outsourcing enables informa-tion systems organizations to achieve multiple benefits [RoWR06]:

• Lower costs: Outsourcing reduces costs of the IS organization because outsourc-ing partners are mostly more professional in specific outsourced activities and thus

69 As suggested by Geoffrey Moore in his book “Living on the Fault Line”, companies should

outsource anything and everything that isn’t core to their business based on the premise that they primarily invest and reallocate freed resources in core capabilities.

70 Please fine further information regarding these three types of outsourcing relationships and their benefit-risk profiles in [RoWR06].

Supply-side

Business Units (BU)

1

2

3 Demand-side Outsourced

External Services Provider (ESP)

Driving innovation (strategic)

Delivering change (tactical)

Supporting infrastructure (operational)

2

3

1



can perform them more efficiently. Furthermore, offshoring71 provides many IS or-ganizations with the opportunity to harvest the benefits of lower labor costs so they can achieve the value with less cost than through in-house provisioning of the same function.

• Variable capacity: There are diverse ways to price an outsourcing activity. For instance, when outsourcing desktop support, an information systems organization may choose a unit pricing model that offers to pay a fixed amount for each solved user’s support request. This means a conversion of fixed to variable costs. As a re-sult, the organization can efficiently deal with peaks and valleys of demand by using variable capacities of their partners. Outsourced activities are defined and specified in a contract between the IT services provider and a customer in the form of service level agreements 72.

• Mitigate risks: Outsourcing has risks; however, these risks can mostly be identified and measured by their nature, size and criticality. Outsourcing means that a certain amount of the risk is even transferred to the outsourcing party who is running the activities on behalf of the IT organization. So outsourcing partners typically provide advanced processes, offer 24/773 technical support and are quite alert to the out-sourced operations of their customers. IS organizations that, for instance, out-source the operation of their servers and network components, can reduce technol-ogy risks that would otherwise severely impact the business of the company74.

• Focus on core capabilities: Rarely focusing on outsourcing to reduce costs is a short-term objective that ignores the long-time viability of the organization. With a reliable and secure infrastructure as a base, information systems organizations are able to spend more time in business process design and improvements. Organiza-tions are able to concentrate on value-adding core activities to deliver the changes that facilitate and support business innovations.

Outsourcing decisions must be made with adequate care and deliberation. Often these companies overlook the impacts of outsourcing on their employees (changing people’s behavior) and mostly lack an action plan to smoothly and incrementally address those issues. Examples of disadvantages should be considered and include a loss of mana-gerial control over service quality and a thread to security and confidentiality. Further-more, outsourcing can entail a loss of flexibility when organizations need to react to changing business conditions, as well as an increased complexity in managing and controlling outsourcing contracts [ChPe03].

A discussion about outsourcing activities within the information systems organization raises the question whether an outsourced enterprise architecture is the right decision or not. As a quick reply to this question, today the technical challenges of the enterprise architecture can be delegated, at least in part, to an external vendor. However, these transferred challenges cannot reduce upcoming relationship management challenges and organizational change challenges. Ultimately, this means that companies should

71 Offshoring is one type of IT outsourcing. Please see glossary to get further information. 72 CXO Media Inc.: ”The ABC of Outsourcing”. URL:

http://www.cio.com/research/outsourcing/edit/outsourcing_abc.html. 73 This means the service is available 24 hours a day, 7 days a week. 74 DM Review and Source Media, Inc.: “Mitigating Operational Risk in Outsourcing, URL:

http://www.dmreview.com/article_sub.cfm?articleId=1028024.


not outsource their enterprise architecture because it is a crucial tool that links its mis-sion and vision to its IT strategy [RoWR06].

The impacts of an enterprise SOA on the structure of the IS organization Several times in this study, it was underlined that an adoption of enterprise SOA can result in a shifting of particular IT activities to business units. This change is expected to result in a more decentralized structure of the IS organizations. In a decentralized model, the information systems organization is responsible for core IT activities, leaving business units to establish their IT staff and allow them to make specific IT initiatives on their own (see figure 23).

Figure 23: Evolving IS organization which reflects major trends

With the concept of enterprise SOA, four new breeds of technology professionals emerge that can be assigned to appropriate levels of the information systems organiza-tion [WoMa06]:

• Disruptive innovators: This group is challenged to drive the business process innovation in the form of groundbreaking new services, applications and business processes. Disruptive innovators can be assigned to the strategic level of the in-formation systems organization.

• Composers: The second group is primarily responsible for designing current busi-ness processes. Composers use model-driven development tools to efficiently combine process modules in the form of multiple enterprise services. They can be assigned to the tactical level of the information systems organization.

• Consolidators: This group mainly thinks about reusing prior IT investment and replacing legacy systems when they are not differentiating the company anymore and thus become commodity products. Consolidators can be assigned to a tactical organization level.

• Repository keepers: This last group primarily manages services in the enterprise services repository. They create services and maintain the repository to support composers and innovators. As composers and consolidators, repository keepers can be assigned to the tactical level as well.

Supply-side

Business Units

1

2

3

Embedded in business units

Demand-side Outsourced

External Services Provider

Driving innovation (strategic) • Disruptive innovators Delivering change (tactical) • Composers • Consolidators • Repository keepers Supporting infrastructure (operational)

2

3


1


While the enterprise architecture team is charged with all activities around the adoption of enterprise SOA, these groups are responsible for tapping the full potential and ex-ploiting the value of the enterprise SOA. Below, each group is addressed in its appro-priate level of the IS organization.

• Driving business process innovation: Today IT becomes a fundamental ena-bling force to achieve profitable growth through business process innovation. As enterprise SOA provides a platform that allows the composition of business proc-esses and their migration across and outside the enterprise, the company may pro-pel a new era of business process innovation. The importance of a decentralized approach was stated by Dr. Klaus Schoo (Pfizer) as follows: ”An individual strategy depends on the organization structure and culture. Our division, Pfizer Global Pharmaceuticals, is more decentralized than other organization units. Decentraliza-tion builds the foundation for the community. The main idea is that innovation oc-curs in countries and cannot be done centralized.”75 This is the point where disrup-tive innovators come into play. They can be assigned to the strategic level of the IS organization and aim to make a valuable contribution on the competitive edges of a business. “The disruptive innovator has to be a hunter and must be constantly on the move, looking for the next big thing.”76 Having a broad view of the organization and its processes enables them to discover areas of opportunities for disruptive in-novation [WoMa06].

• Application development embedded in the business: On the tactical level, the level of today’s projects and IT initiatives, enterprise SOA has a very important role. The heart of enterprise SOA’s promise is, in fact, to provide empowered employees in business units with tools that help them to do their job better. These employees can be assigned to groups of composers, consolidators or repository keepers [WoMa06]:

• Composers mainly design and change business processes to enhance process efficiency and effectiveness. They are able to translate pure business logic into technical logic to utilize model-driven development tools and to delegate de-ployment of the appropriate solution.

• However, consolidators are charged with phasing out and replacing systems that have outlived their return on investment and do not cope to reduce their TCO. Furthermore, this second group has to consolidate existing services and applications, identify and eliminate redundancies among them and provision ul-timate reuse of these services.

• In order to support process innovation, service composition and service devel-opment, repository keepers ensure a properly running architecture by managing the enterprise services repository. Members of this group define standards and govern the definition process for new enterprise services and business process components.

Driving success of the architecture in a decentralized, lean information systems organi-zation often requires an intensifying of the collaboration between the enterprise archi-tecture team and the company’s program management office. The program manage-ment office manages the project portfolio and ensures that all initiatives (e.g., projects

75 See interview with Dr. Klaus Schoo (Pfizer) and Juergen Hauck (Pfizer) in Appendix G1. 76 Ori Inbar, Senior Vice President of Solution Marketing for SAP NetWeaver (SAP). URL:

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/4807.


of composers, consolidators and repository keepers) are well aligned to the company’s business strategy expressed by the enterprise architecture. Ultimately, the program management office represents an important governance body which approves or de-clines the initiatives arising from IT activities from within both the information systems organization and the business units.

5.3 The Enterprise Architecture Team An essential factor for the enterprise architecture success is the organization structure. First of all, enterprise architecture is a discipline that is handled quite differently across diverse organizations. Some companies may have achieved a certain architecture ma-turity stage that sufficiently helps them to operate their (current) business and thus these companies care little about architects within a formal enterprise architecture team. These companies typically have architects distributed across various IT domains, providing architectural advice in applications and infrastructure.

However, other companies that emphasize the strategic importance of their holistic enterprise architecture and assign key priorities for new architecture initiatives typically centralize all these architects into an enterprise architecture core team. Compared to decentralized architects within various IT domains, architects of the enterprise architec-ture team have a much broader view of the enterprise because they are directly in-volved in enterprise planning activities (strategic business planning in accordance with the business context) [BaJa06].

In order to develop an enterprise architecture fully aligned to the business strategy, the enterprise architecture team must be embedded in the information systems organiza-tion, and its activities must be linked to IT strategic planning processes [WeRB05].

Figure 24: Typical enterprise architecture reporting structure

The organization model above (figure 26) illustrates a quite common enterprise archi-tecture reporting structure. As mentioned above, the information systems organization is typically led by the chief information officer (CIO) who directly reports to the execu-tive management. The CIO is the strategic decision-making head of the entire enter-prise architecture program and thus the key driver of enterprise architecture benefits. The enterprise architect often has the role of a senior manager and reports directly to the CIO. The enterprise architect leads the enterprise architecture team, composed of business, information, technical and solution architects. As the role of an enterprise architect was described above, we will turn particularly to the subordinated roles of an enterprise architect within the enterprise architecture core team [HaWe06]:

Adapted from: [HaWe06]

CIO

Enterprise Architect

Business Architect(s)

Technical Architect(s)

Information Architect(s)

Solution Architect(s)


• Business architects: Business architects are business-savvy people and under-stand the business strategy of the company. They work with further business spe-cialists, such as business analysts and business process experts, in order to de-velop coherent architecture models of the business.

• Information architect: Information architects have a clear understanding of infor-mation requirements, information flows and information usage within various busi-ness operations. They deal with basic topics concerning information accuracy and timing, as well as authentication and security. From a high-level perspective, infor-mation architects ensure that the company can efficiently run all business proc-esses with the right, decision-supportive information at hand.

• Technical architect: Technical architects provide the basic infrastructure to per-form business processes, to manage information and to run enterprise systems. They are often specialized in one or more technical domains.

• Solution architect: Solution architects design required enterprise solutions by combining architectural artifacts of the business, technology and information view-points. Systematic reconciling of these often-conflicting viewpoints allows solution architects to create architectural descriptions that resolve specific business prob-lems in a best-practice manner. So they facilitate a rapid development and delivery of solutions to the business.

Architects of the enterprise architecture team must always hold the balance between architecting and governing the resulting architecture projects. They should not drift too far into issues around implementing the architecture or even implement projects on their own. This is indeed the governing task of a program management office as it en-sures that standards, models, principles and guidelines defined by the architecture team are incorporated into the project life-cycle and afterwards get implemented within the development life-cycle.

As the adoption of the enterprise SOA moves the information systems organization to a more decentralized structure and embeds diverse IT activities in business units (de-scribed in chapter 5.2), it will influence the work of the enterprise architecture team as well. As a result, architects of the enterprise architecture core team more frequently work with multiple resources that are outside of the information systems organization. This new type of collaboration can be reflected in a virtual team structure. Such team structures help to draw talent from multiple organizational sources because virtual team members usually provide the enterprise architecture team with subject-matter expertise and professional competence in their specific (business) domains. Driving the team’s attention beyond the traditional border of IT helps the core enterprise architecture team to retain oversight of the enterprise and enhance the quality of the architecture. How-ever, designing an organization structure is as much art as science [HaWe06].

Finally, there will not be a “one structure fits all” approach to the enterprise architecture team. While we establish organization structure that spells out the positions to be filled with employees of the company, at the end of the day, it is mostly culture that defines the roles that go with these positions and the kinds of people who fill them.

6 Conclusion and Outlook 71

6 Conclusion and Outlook Many companies use enterprise architecture to encapsulate a detailed blueprint of sys-tems, data and technologies. Enterprise architecture begins at the top of an enterprise, taking in account its vision on which the company aims to achieve a competitive advan-tage within its market environment. Enterprise architects then have the crucial task to translate the vision into high-level requirements for the architecture and ultimately de-rive an agile foundation of IT capabilities and business processes that are fully aligned with overall business goals. Realizing value from this transformation process is not only the responsibility of enterprise architects but also of business and IT executives. An enterprise architecture that allows a company to quickly adapt strategic opportunities and efficiently put them into practice will become increasingly important.

Creating an architecture that fulfills continuous-changing business needs is a growing field of responsibility of enterprise architects. With the emergence of enterprise SOA, a major new era was heralded. This architecture stage enables strategic agility through flexible and reusable enterprise services and results in a consummate association be-tween business and IT. In order to leverage the value from an enterprise SOA, many companies join an enterprise SOA ecosystem. This ecosystem consists of several communities that allow IT professionals, business experts and enterprise architects to collaborate for innovation and efficiency. The ecosystem includes various companies from different industries all over the world. An important community for enterprise archi-tects is the Enterprise Services Community77. This community enables companies to share ideas for defining and creating enterprise services. As enterprise services are the fundamental building blocks for an enterprise SOA, it is expected that enterprise archi-tects will intensify their participation in this community in order to influence the creation of services by bringing in their company-specific priorities. Finally, approved service proposals are getting implemented and productized by SAP. An ecosystem like this is very essential for realizing the value of a future-state architecture characterized by in-teroperability and openness.

The enterprise SOA ecosystem will prove whether enterprise architecture modules can really be developed within a collaborative environment of trusted vendors. This is a very significant step along the enterprise architecture journey. Above, enterprise archi-tecture maturity stages were outlined; however, the question of the fifth maturity stage of enterprise architecture was left open. It is anticipated that the future enterprise archi-tecture will extend the concept of reusable enterprise services. The fifth stage of enter-prise architecture is called “Dynamic Venturing”78. This breed of a new architecture not only enables companies to flexibly plug and play process modules but even allows them to flexibly change and reconfigure their portfolio of businesses. Organizations in the fifth stage will be able to shape opportunities for collaboration among many other companies. The business strategy of an organization in the fifth stage is expected to focus on dynamic coupling with companies in order to differentiate from competitors in the market. These organizations provide business partners selective access on their systems and business operations. Dynamic coupling with many other companies is

77 ES Community: https://www.sdn.sap.com/irj/sdn/developerareas/esa/esc. 78 See: Jeanne W. Ross, Peter Weill, David C. Roberton: “Enterprise Architecture as a Strat-

egy”. Harvard Business School Press. August 1, 2006.

6 Conclusion and Outlook 72

mostly a visionary idea; however, it is a logical consequence of the business modularity accompanying enterprise SOA. Economic and business conditions today demand inte-grative and innovative connections and relationships between enterprises of different sizes and industries along the value chain. To realize an integrative business environ-ment, enterprise architects will reinforce the usage of technology and industry stan-dards in their architecture. These standards ensure that companies can run cross-industrial business processes efficiently via seamlessly interconnected platforms. In addition, enterprise architects will become increasingly involved in external relation-ships with companies and peers such as key technology providers, customers and trading partners, as well as standards organizations. In the future, these relationships of an enterprise architect can widely affect the realization of strategic goals.

Compared to the restrictive monolithic systems of the past, the world of enterprise ar-chitecture will be a completely different terrain for enterprise architects in the years to coming. The evolution demands enterprise architects to be resilient in leading the en-terprise architecture process and transforming the enterprise in its whole. If they suc-ceed to expand their scope of traditional IT infrastructure and move toward a business-driven viewpoint that continuously exposes innovative capabilities of an organization, they will have a crucial role within future enterprises.

As well-thought-out enterprise architecture represents a compass that shows the stra-tegic direction of a company, it is in the hands of enterprise architects to actively par-ticipate in shaping the future of an enterprise.

Appendix 73

Appendix Appendix A Operating Models and Core Diagrams..............................................74

Appendix B Enterprise Architecture Frameworks ................................................78 Appendix B1 TOGAF .................................................................................................78 Appendix B2 Zachman...............................................................................................82

Appendix C Enterprise Architecture Roles ...........................................................85

Appendix D Enterprise Services Workplace .........................................................87

Appendix A: Operating Models and Core Diagrams 74

Appendix A Operating Models and Core Diagrams The enterprise architecture process should be based on an approved operating model of the enterprise. This model shows how the organization basically aims to do busi-ness, how it delivers goods and services to customers and how it plans to grow and act in its business environment. The idea of this approach is to assign each enterprise to one specific quadrant of a two dimensional matrix. The key dimensions of the operating model are [RoWR06]:

• Business process standardization: This dimension categorizes companies de-pendent on their level of standardization of business processes and information systems. The more standardized processes are the less manual interventions are necessary and the higher productivity of the process can be. However excellence in standardized processes (so-called “contextual activities”) may not differentiate your business and may not provide competitive advantages79.

• Business process integration: This dimension describes the ability to create end--to-end processes that span across multiple systems and organizational units. Inte-grated business processes can enhance customer services and can facilitate and accelerate the information flow in a company.

The combination of these two dimensions in a matrix identifies four special types of operating models (see figure 25): diversification, coordination, replication and unifica-tion [RoWR06]:

• Diversification (low standardization, low integration): This pattern applies to companies having individual, related but not integrated business units. Each unit commonly has few customers, suppliers and business operations. Business units are managed quite autonomous. They typically synergize with each other, though they can do business on their own. The organization commonly achieves an econ-omy of scale in providing shared services (IT services, procurement services, fi-nancial services, etc.) to their business units.

• Coordination (low standardization, high integration): The business units of the coordination model are highly integrated and use shared data for selling (custom-ers), procurement (suppliers) and production processes (products/services). Com-panies with a coordination model satisfy needs of their customers by providing process expertise and enhanced customer services.

• Replication (high standardization, low integration): In a replication model, the company promotes efficient, standardized business processes to be reused and repeated within each business unit. These units manage their data and transac-tions on their own even though they are limited in designing and running their indi-vidual operations.

• Unification (high standardization, high integration): Unification companies run highly standardized end-to-end business processes that span across several func-tional areas of the organization. These companies often run packaged enterprise

79 Further information regarding the business process lifecycle and the approach of core (focus

on differentiation) and context (focus on productivity) processes can be found in Geoffrey Moore’s textbook “Living on the Fault Line”.


applications (e.g., an ERP system) that are open and standardized. These systems help those companies to integrate their supply chains and manage shared transac-tion data between business units.

Figure 25: The four operation models

To grasp the concept of core diagrams, we will have a look at a practical example of Delta Air Lines, Inc. Business operations of Delta Air Lines can be assigned to a unifi-cation model. This type of operation model is characterized by highly standardized business processes, as well as tightly integrated supply chains and data [RoWR06].

Below is a template for designing a core diagram for the unification model such as that of Delta Air Lines. The template is basically divided in two sections. The top area of the picture shows the modeling sequence (modeling steps) of the diagram; the lower area illustrates the design of the architecture components (core diagram design).

Figure 26: Template for a unification core diagram

high

low

Business process standardization low high

Sour

ce: [

RoW

R06]

Bus

ines

s pr

oces

s in

tegr

atio

n

Coordination

Diversification Replication

Unification

Source: [RoWR06]

Key Customers

Linked and Standard (Core) Proc-esses

Shared Data

Linking and Automating Technologies

Required

Optional Business process

Data

Technology

Customer types

Linking technologies

Automating technologies

Proc

ess

steps

Core

diag

ram

desig

n


The reason why Delta Air Lines strived to transform its enterprise architecture was the many different IT platforms within the organization. These platforms were not compati-ble with each other and are the outcome from unsuccessful IT outsourcing.

As specified by the first process step of the template, Delta Air Lines initially identified important groups of customers and stakeholders of the architecture. Doing so exposes a lack of information flow between ticket agents, reservation agents, gate agents and baggage handlers, which often resulted in unsatisfied customers and employees.

In a next step, Delta Air Lines decided on four core processes and drew them in their core diagram (figure 27): the operational pipeline focused on activities such as prepar-ing, loading, unloading, cleaning and inspecting aircrafts; the customer experience process concentrated on all types of interactions with customers; business reflexes encompassed processes primarily responsible for generating revenue (financial proc-esses, scheduling, pricing, etc.); and the employee relationship management identified key activities for managing Delta Air Lines personnel.

In the third step, Delta Air Lines identified the data structure necessary for gaining effi-cient and effective core processes. This data structure basically consisted of nine core databases. These databases are included in the central Delta nervous system. This nervous system represents the linking technology80 for providing shared data with sur-rounding core processes, as well as with customers and employees of the organiza-tion.

Figure 27: Core diagram of the Delta Air Lines unification model

80 The final step “linking and automating technologies” is identified with a dashed line in the

template diagram (Figure 26). This indicates that this step is only necessary if there are only key technologies that either automate or link processes.

Source: [RoWR06]


Of course the concept of core diagrams is also applicable to other operating models. Templates for the other three operating models as well as a detailed description for delineating core diagrams are specified in [RoWR06].

Appendix B: Enterprise Architecture Frameworks 78

Appendix B Enterprise Architecture Frameworks

Appendix B1 TOGAF

TOGAF is the architecture framework from The Open Group. The Open Group is a vendor- and technology-neutral consortium that developed TOGAF in 1995. Today TOGAF 8.1.1 is a superset of the well-established framework represented by earlier versions. This comprehensive framework enables designing, evaluating and building the right architecture for an enterprise. TOGAF consists of three major parts. The first part is the TOGAF Architecture Development Method (ADM), which represents the process to derive a best-fitting architecture from business strategy. The second part represents the Enterprise Architecture Continuum, which leverages architectural assets throughout the ADM, and finally, the last part is the TOGAF Resource Base that pro-vides supportive information to implement and use the ADM. Basically TOGAF sup-ports four architecture domains [Toga03]:

• The business architecture (sometimes called business process architecture), which mainly describes the business strategy, the organization, core business processes of the organization, as well as governance.

• The application architecture that defines individual systems and their interaction types with other applications and core business processes.

• The data architecture, which designs logical and physical data elements to support the operations of an organization.

• The technology architecture that describes the operational software environment to support applications.

The TOGAF Architecture Development Method (ADM) The TOGAF ADM is the core of the framework. It is a generic method for gradually developing a target architecture that meets business and IT requirements of an enter-prise. The basic, non-expanded structure of the ADM is illustrated below.


Figure 28: TOGAF Architecture Development Method (ADM)

As the figure shows there are nine phases that make up the ADM (the prelim phase as well as the phases A to H):

• Preliminary framework and principles: The preliminary phase generally de-scribes the architecture approach by defining the architecture framework (TOGAF ADM and other framework(s) if required) and informing about principles.

• Architecture vision: Phase A is responsible for obtaining support from corporate management of the enterprise, defining the scope of the architecture and determin-ing key stakeholders and their concerns. This phase also identifies key business requirements and derives an architectural vision that demonstrates how these re-quirements and constraints are addressed by the target architecture.

• Business architecture: Developing the business architecture is an important pre-requisite for the next phases of the ADM. It undertakes the definition of the baseline architecture (“as-is” architecture) and models the business for the target architec-ture (“to-be” architecture). Target state architecture is described by the organiza-tional structure, business goals for each organizational unit, and high-level to low-level business processes. Furthermore this phase analyzes the gaps (of people, processes, tools, information, measurement, financials and facilities) between the current and target architecture.

• Information system architectures: The objective in this phase is to define the kinds of information systems that are able to run the predefined business proc-esses. In addition this phase defines an appropriate data structure necessary to support the business.

Prelim: Framework and Princi-

ples

Require-ments Man-

agement

A Architecture

Vision B Business

Architecture

C Information

System Archi-tectures

D Technology Architecture E

Opportuni-ties and

Solutions

F Migration Planning

G Implementation

Governance

H Architecture

Change Management

Source: TOGAF


• Technology Architecture: This phase develops a technology architecture that will form the basis for the work of the technical implementation. The ADM provides a separate “mini-framework” consisting of eight extra steps for developing technology architecture.

• Opportunities and solutions: In this phase different options for implementing the various target architecture are evaluated and ultimately selected (e.g. buy versus build versus reuse/recompose). In addition top-level work packages (projects) are determined to migrate from the current architecture to the target.

• Migration planning: This phase highlights the implications and hurdles in the im-plementation process. It plans and prioritizes implementation projects and deter-mines dependencies, costs and benefits among them.

• Implementation governance: The main objective is to guide implementation pro-jects to ensure conformance and compliance with the defined architecture.

• Architecture change management: Since enterprise architecture is a continuous process, this phase ensures that the architecture has the flexibility to respond to change in the technical and business environment. Conducting this phase typically means to establish a change management process for the new baseline architec-ture, and therefore, often initiates a new architecture evolution cycle.

Indicated in the center of the ADM cycle is the requirements management. Managing changing requirements affects each phase of the ADM process. As requirements are disposed, addressed and prioritized within the specific phase of the ADM, this is not done in the requirements management process. The requirements management proc-ess is rather responsible for managing requirements for all phases of the ADM.

The Enterprise Continuum A simple description of the Enterprise Continuum can be given as a “virtual repository” of all architectural assets (e.g., models, patterns, architecture description and other artifacts) available within an organization and also in the IT industry at large.

The Enterprise Continuum has several benefits in forming a “virtual repository” of archi-tectural assets [Toga03]:

• The Enterprise Continuum prevents misunderstandings when people talk about architecture. Understanding the Enterprise Continuum helps individuals to point out what part of the architecture the discussion is about.

• The Enterprise Continuum provides a consistent language to effectively communi-cate the architecture. This is an important point because architectures are typically specific to individual industries, products, customers, services and subsystems.

• The Enterprise Continuum also effectively organizes and classifies re-usable archi-tecture and solution assets.


Figure 29: TOGAF Enterprise Continuum

The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solution Continuum. Both concepts are described briefly below. Detailed information about the continuums can be referenced as noted [Toga03].

• The Architecture Continuum: This concept provides a consistent way to define and understand the rules and relationships of architectural components in an infor-mation system. The Architecture Continuum is shown in the top half of figure 29. It illustrates how architectures are becoming more enterprise-specific, ranging from general foundation architectures on the far left side up to organization architectures on the far right side. The arrows represent a bi-directional relationship between the different architecture types (foundation architectures, common systems architec-tures, industry architectures, organization architectures) in the continuum. Arrows that point to the left focus on meeting organizational requirements while arrows that point to the right aim to enhance and leverage architectural components. Moving through the continuum to the right side means that business requirements are cov-ered in increasing detail. Architects commonly try to reuse architectural elements from the less detailed architectures on the left side. Otherwise when elements are not defined, the architect passes the new requirements for these elements to the left of the continuum for inclusion and implementation.

• The Solution Continuum: This concept offers a consistent way to manage and understand the implementation of the Architecture Continuum. Illustrated in the bot-tom half of figure 29, each level of the Solution Continuum refers to a correspond-ing architecture type of the Architecture Continuum. The solution types (products & services, systems solution, industry solutions, organization solution) are character-ized by the building blocks of the appropriate architecture types. Solution types on the far right of the continuum provide greater value than solution types on the left side (indicated by the direction of the arrows). Arrows that point to the left , as they do in the Architecture Continuum, focus on meeting organizational needs.

The enterprise continuum should not be seen as strictly related chains. An enterprise architecture could include architectural components from a common systems architec-ture, while its enterprise solutions could even include a product or a service.

Source: TOGAF


The TOGAF Resource Base This TOGAF Resource Base is a collection of documents designed to facilitate devel-oping and implementing enterprise architectures. The collection of materials includes guidelines for establishing an architecture board, sample tools and techniques for ar-chitecture development, and the relationships of other architecture frameworks to the TOGAF framework [Toga03].

Appendix B2 Zachman

Today the Zachman Framework has become one of the most widely used frameworks by many successful organizations in the world. The purpose of the Zachman frame-work is to provide an architecture blueprint for developing, managing, as well as chang-ing and maintaining, an organization’s information systems. The blueprint is based on a proven methodology that includes an incremental development plan and a work break-down structure of the architecture. Besides the survey that rated the Zachman Frame-work as the second most important framework, evidence of the framework’s accep-tance is apparent at the seminars conducted by the Zachman Institute for Framework Advancement (ZIFA)81.

As shown below in figure 30, the Zachman Framework proposes an architecture schema in the form of a matrix. The matrix is depicted with two dimensions.

Figure 30: The Zachman Framework for Enterprise Architecture

The columns are populated by interrogatives: what, how, where, who, when, why. Us-ing these simple questions enables enterprise architects to break down an architecture into manageable pieces to explain and manage its complexity. These interrogatives help them to quickly deduce missing answers when defining a target architecture. Fur-thermore, this approach is not only an intellectual evaluation activity for defining the

81 These seminars are commonly three-day courses taking place six times per annum. ZIFA

Web site: http://www.zifa.com

Source: Zachman Institute for Framework Enhancement (ZIFA)


right answers for each interrogative; even more, it is an intellectual enterprise invest-ment for creating enterprise assets! The columns are listed as follows [Sche04a]:

• What: Defines data entities for each perspective such as business objects, logical system data, relational tables and basic data definitions.

• How: Presents functions for each perspective such as business processes, logical software and physical hardware functions.

• Where: Shows interconnections and locations for each perspective such as major business locations, several sections in the business logistics, as well as well as memory addresses within the networked systems.

• Who: Defines the relationship of all company-internal stakeholders. This addresses the assignment of responsibilities to organizational units (horizontal) as well as the reporting and delegation structure (vertical). Examples include organizational units important to the business, workflow descriptions, designs for user interfaces, as well as identifying management.

• When: This interrogative covers the aspect of time for each architectural perspec-tive. Answers in this column describe performance criteria and quantify enterprise resources. Examples include lists of events important to business, master schedule plans and system processing sequences

• Why: Represents the motivations of the enterprise. This includes enterprise goals and strategies, a business plan, as well as business rules and models, to design and create a knowledge architecture. Furthermore, it addresses IT principles and governance.

The rows, the second dimension, describe the enterprise architecture from six different perspectives: planner, owner, designer, builder, subcontractor and the functional enter-prise system. The perspectives should be consistent with one another and are sepa-rated as follows [Sche04a]:

• Scope (planner): This first perspective can be considered an executive summary for a planner. The scope describes the context of an enterprise in order to estimate the complexity, costs and functionality of the enterprise architecture.

• Business model (owner): This perspective shows the operations of a company, including business processes, business entities and their interaction types.

• System model (designer): Out of this perspective, a system analyst designs data entities and software functions to fulfill the requirements of the business model.

• Technology model (builder): The perspective places emphasis on the physical, technical aspects to meet the requirements of the systems. This involves the con-sideration of technical constraints.

• Detailed components (subcontractor): These components are the outcome of higher planning efforts. Each component (sometimes called enterprise architecture product or architecture element) can be allocated to contractors for implementation.

• Functioning enterprise: This is not a separate perspective. It represents the basic operational system.

As the framework contains six rows and six columns, designing the enterprise architec-ture yields 36 unique cells or aspects. Each cell in the matrix must be aligned with the


cells directly above and below it. All cells within a row must also harmonize with each other.

Appendix C: Enterprise Architecture Roles 85

Appendix C Enterprise Architecture Roles

Role Members (If composite) Responsibilities

Chief Executive Officer (CEO)

- • Defines enterprise architecture as a company-wide priority.

• Establishes the enterprise architecture executive steering committee (EAESC).

Chief Informa-tion Officer (CIO)

- • Promoting IT within the enterprise as a strategic tool

• Setting strategic direction for develop-ing the enterprise architecture

• Overseeing initiatives around applica-tion development

• Appoints the enterprise architect

• Obtaining executive buy-in and spon-sorship for the enterprise architecture

• Participate in approving the overall architecture

Domain Owners Business unit leaders • Provide sponsorship for the enterprise architecture

• Help the architecture team to design the business viewpoint

• Contribute in reviewing enterprise ar-chitecture products

• Assigns subject matter experts (SME)

Enterprise Ar-chitect

- • Leads the enterprise architecture proc-ess to develop, maintain and evolve the enterprise architecture across the enterprise.

Enterprise Ar-chitecture Core Team

• Enterprise Architect

• Business Architect(s)

• Technical Architect(s)

• Information Architect(s)

• Solution Architect(s)

• Develop and maintain the enterprise architecture

• Creates architecture artifacts

• Provide support to development and project teams

Enterprise Ar-chitecture Ex-ecutive Steering Committee (EAESC)

Should be composed of sen-ior executives from all organ-izational divisions.

• Guides and oversees the enterprise architecture program

• Approves high-level architecture arti-facts and the entire enterprise architec-ture

Appendix C: Enterprise Architecture Roles 86

Enterprise Ar-chitecture Pro-gram Manage-ment Office (PMO)

• Enterprise Architect

• Enterprise Architecture Core Team

• Manages, monitors, controls and main-tains the enterprise architecture pro-gram

• Governs the enterprise architecture development process

• Creates an enterprise architecture roadmap to achieve the goals set by the EAESC

Enterprise Ar-chitecture Re-view Board (EARB)

• CIO

• Enterprise architect

• Domain owners

• IT / business representa-tives

• Validate, review, and approving enter-prise architecture content and out-comes

• Governs the use of enterprise architec-ture outcomes

Quality Man-ager

- • Contribute in reviewing architecture artifacts and

• Ensures quality of architecture out-comes

Risk Manager - • Identifies and manages risks during the enterprise architecture program

Subject Matter Experts (SME)

Experts in a specific area/domain within the en-terprise; external consultant are possible as well

Supports the architecture team with their in-depth knowledge in a special-ized area

Contributes in reviewing architecture artifacts

Table 11: Enterprise architecture roles and responsibilities

Appendix D: Enterprise Services Workplace 87

Appendix D Enterprise Services Workplace The Enterprise Services Workplace (ES Workplace) was launched by SAP as a web-site82 on SDN (SAP Developer Network). The ES workplace is free of charge and al-lows community members to browse enterprise services.

This site is especially useful for enterprise architects who want to service-enable their existing enterprise architecture or provide new enterprise services to adapt business processes. There are two general ways to browse the ES Workplace.

First there is a top-down approach. You initially choose a SAP application (e.g., mySAP ERP) or a special industry (e.g., Chemicals) and then drill down step-by-step until you finally get to the assigned enterprise services. Each navigation level holds broad infor-mation about its technical or business artifacts. On the lowest level of the ES Work-place, you even find the WSDL files (Web Service Definition Language) for a specific enterprise service operation. Alternatively, you can also work with the enterprise ser-vices index. The index lists process components by categorizing them in different ap-plication categories (like ERP, CRM, etc.).

The following figure shows the different navigation levels of these two approaches.

Figure 31: Multiple levels for browsing enterprise services in the ES Workplace

82 The ES Workplace site: http://www.sdn.sap.com/irj/sdn/developerareas/esa/esapreview

Approach 1: Browse by general business structure: Enterprise Application Business Solution

Process Category Business Process Variant

Business Process Enterprise Service Interface

Enterprise Service Operation WSDL

Adapted from: [SaEW06] and Solution Composer

Approach 3: Browse by index structure: Solution Category

Process Component Enterprise Service Interface


Example: mySAP ERP

mySAP ERP Financials Management Accounting

Profit Center Accounting General Ledger

“ManageProfi CenterLineItem…” Cancel Rule, Read Rule, …

Example: ERP

Accounting “ManageProfi CenterLineItem…”

Cancel Rule, Read Rule, …

Approach 2: Browse by industry business structure: Industry Value Chain

Process Category Business Process Variant

Business Process Enterprise Service Interface


Example: Chemicals

Enterprise Management and Support Management Accounting

Profit Center Accounting General Ledger, Transfer Pricing

“ManageProfi CenterLineItem…” Cancel Rule, Read Rule, …

Appendix D: Enterprise Services Workplace 88

The first approach, illustrated by the general business and industry structure, supports people who are familiar with business solutions, processes and process steps. This logical structure helps them to navigate through the ES Workplace. The second ap-proach, described by the index structure, may be preferred by people who have techni-cal background knowledge. But browsing the ES Workplace does not mean either/or. Both approaches are cleverly combined and interlinked.

The content of the ES Workplace is updated continuously by comprising further SAP tools, like the Solution Composer83 and Solution Manager84, as well as ARIS for SAP NetWeaver, SAP NetWeaver Exchange Infrastructure and the SAP Knowledge Ware-house.

In addition, the ES Workplace will be associated with the ES Community in the near future. The main task of this community is to provide input and feedback on the defini-tion of enterprise services in the SAP platform. So the ES Workplace will also show enterprise services that are not available yet but coming soon after the implementation by the ES Community. Enterprise services that were or are currently developed by the enterprise SOA ecosystem are flagged accordingly. Inversely, there is an official Wiki embedded in the ES Workplace website. It enables users to provide feedback to enter-prise services, and so even influences the ES Community.

This makes the ES Workplace a very important place for enterprise architects who want to explore new building blocks (enterprise services) for their enterprise SOA. If enterprise architects also want to test and run these enterprise services, they can ac-cess the ES Workplace backend systems. The systems landscape is based on SAP’s latest mySAP Business Suite 2005. Accessing these playground systems is free of charge. If they need more control and insights in these systems, they even can pur-chase a SAP Discovery System. This hands-on system offers a head start on the road to a full SOA implementation. It is a predefined system for enterprise SOA that includes software and hardware. The system runs mySAP ERP, SAP NetWeaver Visual Com-poser85 and SAP NetWeaver platform components for developing service-based enter-prise solutions.

Finally the ES Workplace is a starting point to discover new productized enterprise ser-vices. These services are delivered as an add-on and are free of charge. You can util-ize the power of these add-ons if you have mySAP Business Suite 2005 or parts of it running.

83 Solution Composer: http://www.sap.com/solutions/businessmaps/composer/ 84 Solution Manager: http://www.sap.com/platform/netweaver/components/solutionmanager/ 85 SAP NetWeaver Visual Composer: https://www.sdn.sap.com/irj/sdn/visualcomposer

List of Figures 89

List of Figures Figure 1: Enterprise architecture from a city planner perspective...................................1 Figure 2: Enterprise architecture viewpoints ...................................................................6 Figure 3: Abstraction layers of the technology viewpoint ................................................7 Figure 4: The enterprise solution viewpoint ..................................................................11 Figure 5: Phases of the research method.....................................................................13 Figure 6: Differences between relative frequencies ......................................................17 Figure 7: Services bridge the gap between business and IT ........................................20 Figure 8: Monolithic, silo-based enterprise architecture................................................21 Figure 9: Service-oriented architecture versus enterprise SOA....................................23 Figure 10: Example scenario about a canceling an order process ...............................27 Figure 11: Move the current architecture toward a target architecture .........................33 Figure 12: The enterprise architecture process ............................................................34 Figure 13: The enterprise architecture process - Initiate the EA program ....................36 Figure 14: The enterprise architecture process - Establish governance structure........38 Figure 15: The enterprise architecture process - Define the architecture approach .....40 Figure 16: The enterprise architecture process - Develop the EA ................................45 Figure 17: Systems migration types..............................................................................52 Figure 18: The enterprise architecture process - Use the EA.......................................53 Figure 19: The enterprise architecture process - Maintain the EA................................55 Figure 20: Enterprise architecture maturity stages .......................................................57 Figure 21: Traditional IS organization ...........................................................................64 Figure 22: Evolving IS organization which reflects the trend of outsourcing.................65 Figure 23: Evolving IS organization which reflects major trends...................................67 Figure 24: Typical enterprise architecture reporting structure.......................................69 Figure 25: The four operation models ...........................................................................75 Figure 26: Template for a unification core diagram.......................................................75 Figure 27: Core diagram of the Delta Air Lines unification model.................................76 Figure 28: TOGAF Architecture Development Method (ADM)......................................79 Figure 29: TOGAF Enterprise Continuum.....................................................................81 Figure 30: The Zachman Framework for Enterprise Architecture .................................82 Figure 31: Multiple levels for browsing enterprise services in the ES Workplace .........87

List of Graphs 90

List of Graphs Graph 1: The importance of enterprise architecture framework......................................4 Graph 2: Roles of the survey participants .....................................................................16 Graph 3: Geographic regions the companies of the participants are located in ...........16 Graph 4: Industries in which the participating companies operate................................16 Graph 5: Enterprise SOA in the context of enterprise architectures .............................25 Graph 6: Key responsibility and main skills regarding to the EA process .....................35 Graph 7: Organizational challenges on the way to a target architecture ......................37 Graph 8: Participation in platform decisions in consideration of company sizes...........59 Graph 9: The biggest challenge for enterprise architects .............................................60

List of Tables Table 1: Classification of enterprise architecture frameworks.........................................3 Table 2: Architectural characteristics - today and in future ...........................................22 Table 3: Architectural characteristics and the role of enterprise SOA...........................26 Table 4: How enterprise SOA fits into a company’s enterprise architecture .................29 Table 5: Comparison of enterprise architecture frameworks ........................................43 Table 6: Sample scenario for demonstration architecture development .......................47 Table 7: Exemplary conceptual layer of a target business architecture........................47 Table 8: Exemplary conceptual layer of a target technology architecture.....................48 Table 9: Exemplary conceptual layer of a target information architecture ....................48 Table 10: Impacts of enterprise architecture maturity stages .......................................58 Table 11: Enterprise architecture roles and responsibilities..........................................86

Glossary 91

Glossary Americas’ SAP Users’ Group (ASUG)

The ASUG is the world’s largest, customer-driven community of SAP. It includes 1,700 member companies and has more than 45,000 individuals. The ASUG allows members to access education contents, aims to facilitate networking among members and SAP representatives, and enables members to influence future SAP product releases.

Architecture

An architecture is a static model that does not consider flows and sequences. Architec-tures describe the style and method of design and construction that comprises the elements of an enterprise and defines the purpose and interrelationships of those ele-ments.

Architecture Artifact

Architecture artifacts refer to any work product that is created in the enterprise architec-ture process.

ARIS for SAP NetWeaver

ARIS for SAP NetWeaver provides centralized administration of process information in a multilingual system tool. You can use this knowledge for project documentation, global system implementations, end-user training and optimization projects. The soft-ware provides modeling functionality that addresses the process architecture models of companies’ business scenarios, business processes and process steps. A value-chain diagram describes the end-to-end process map of a company. In a business-scoping phase, you continuously improve the business blueprint by selecting all relevant busi-ness scenarios and application components involved. Source: SAP.

Business Process Management (BPM)

Business process management describes all activities that are performed by compa-nies to manage and improve their business processes. As BPM is a integral part of enterprise SOA, SAP NetWeaver provides different tools that facilitate business proc-ess management. SAP NetWeaver includes tools for modeling and analysis of busi-ness scenarios; orchestration, automation and deployment of business processes; and active monitoring of the performance of these business processes.

Business Process Platform

A business process platform combines infrastructure and composition technologies, business applications and enterprise services to support rapid business process change. Based on an enterprise service-oriented architecture (enterprise SOA), a busi-ness process platform enables organizations to respond quickly to changing business requirements by utilizing enterprise services to reuse, update or compose applications to improve business processes. The business process platform offering delivered by SAP consists of the mySAP ERP application, the SAP NetWeaver platform and enter-prise services that can be used to rapidly compose new business processes. Source: SAP.

Glossary 92

Business Objects

You can find business objects inside a service provider (e.g. inside an enterprise appli-cation). They are unique, identifiable business entities and characterized by a collection of data and specific functionality. Business objects are designed to represent business ideas. Enterprise services are typically linked and constructed on top of business ob-jects. These services use the functionalities of business objects and expose them to business processes.

Change Agent

A change agent is a person who accelerates and facilitates social, cultural or behav-ioral change. In an ever changing business environment where companies have to adapt strategies and direction, change agents are required to effectively transform the company in its whole.

Composite Application (also called Composite)

An application making use of data and functions provided as services by underlying applications and combining these into a coherent business scenario, supported by its own business logic and specific user interfaces. Source: SAP.

Enhancement Package

New enterprise services are released to companies as part of enhancement packages for mySAP ERP. These packages include documentations that help to deploy and use the new services in order to reconfigure and extend existing business processes.

Enterprise Architecture

The process of describing, and the description of, the desired future state of an organi-zation's business process, technology and information to best support the organiza-tion's business strategy. The definition of the steps required, and the standards and guidelines to get from the current state to the desired future state.

Enterprise Architecture Principles

Architecture principles are influenced by the overall business context (strategy, trends) and want to ensure the alignment of the vision with business and IT strategies. Princi-ples should consider organizational beliefs and reflect the organizations value system. A few, strong and well-thought principles effectively help the organization to make con-scious decisions about IT. However principles relate to each other and need to be used as a set. A good set of principles should be understandable, robust, complete, consis-tent, and stable. Enterprise architecture principles are typically defined by the enter-prise architect, in conjunction with the CIO, the architecture board as well as other key business stakeholders. Principles are important to govern the enterprise architecture process though leading the creating of principles is no key responsibility of enterprise architects86 [Toga03].

Enterprise Service (ES)

Enterprise services are Web services that have been co-defined by SAP and/or part-ners. Enterprise Services provide business processes or business process steps that can be used to compose business scenarios while ensuring business integrity and ease of reuse. Source: SAP.

86 See question V.1 of the survey.

Glossary 93

Enterprise Service-Oriented-Architecture (Enterprise SOA)

Enterprise SOA is a business-driven architecture that increases adaptability, flexibility, openness, and cost efficiency. With an enterprise SOA, companies can compose ap-plications and enable business processes rapidly using enterprise services. With en-terprise SOA, organizations can improve their reuse of software and become more agile in responding to change. Source: SAP.

Enterprise Services Repository (ESR)

The enterprise services repository is the central repository in which service interfaces, enterprise services, business objects and business processes are modeled and their metadata is stored. The Enterprise Services Repository is an integral part of SAP Net-Weaver.

Enterprise SOA Ecosystem

The enterprise SOA ecosystem consists of several communities which allow IT profes-sionals, business experts and enterprise architects to collaborate for innovation and efficiency. The ecosystem was initiated by SAP and includes various companies of different industries all over the world.

Enterprise Solution

An enterprise solution is a software system designed to address a specific business problem. It mostly spans across multiple systems (silos) of an organization and can be composed of sub-solutions (or sub-systems).

Enterprise Solution Architecture

An enterprise solution architecture is a meta-architecture that describes a specific en-terprise solution. Enterprise solution architecture combines and reconciles elements (requirements, principles, models) of intersecting architecture viewpoints into a consis-tent description of an enterprise solution.

Global Data Type (GDT)

Global data types are essential for the concept of enterprise SOA. They place a con-straint upon the interpretation of data to ensure that data is transferred in a standard-ized format. Thus service providers and services consumers can interact efficiently without translating and brokering their messages. This is quite fundamental in an en-terprise SOA environment where enterprise systems are horizontally integrated with silo-spanning processes.

IT Governance

IT governance is the responsibility of the board of directors and executive manage-ment. It is an integral part of the corporate governance and consists of the leadership and organizational structures and processes that ensure that the organization’s IT sus-tains and extends the organization’s strategies and objectives. Source: ITGI.

IT Offshoring (IT Offshore Outsourcing)

Offshore outsourcing is the transfer of information technology (IT) services, from a cli-ent company to a supplier organization. The country of the supplier’s company is an-other than the country of the client’s company.

IT Outsourcing

IT outsourcing is the practice of hiring external organizations to perform information technology (IT) services. Examples of common, outsourced IT services can include but

Glossary 94

are not limited to network operations, desktop support, application development, and Web hosting.

Meta-Model

A model that defines the structure, semantics, constraints and other characteristics for a family of models.

Model-Driven Development

Model-driven development is a software paradigm that enables a quick implement of software modules based on models and metadata. Model-driven development tools are important for an enterprise SOA because they even allow non-IT professionals to de-sign composite applications.

mySAP Business Suite

mySAP Business Suite include several comprehensive business applications such as mySAP ERP, mySAP CRM, mySAP SRM, mySAP SCM, etc. These packaged applica-tions provide business and industry-specific functionality and can be completely inte-grated in the systems landscapes of (large) companies. mySAP Business Suite com-pletely supports the collaboration with customers, partners and suppliers over the Inter-net. Source: SAP.

Process Component

A process component includes groups of processes that are modeled in terms of en-terprise services.

Shelf Ware

Shelf ware is a term that characterizes products that remain unsold on a dealer's shelf or unused by the customer. In the context of enterprise architecture this means that the architecture no longer reflects the business strategy anymore. It needs to be reas-sessed and realigned to the strategic direction of an enterprise.

SAP NetWeaver

SAP NetWeaver helps companies align IT with business requirements. As the founda-tion for enterprise service-oriented architecture (enterprise SOA), SAP NetWeaver helps organizations evolve their current IT landscapes into strategic environments that drive business change. SAP NetWeaver allows companies to compose new business solutions rapidly while obtaining more business value from existing IT investments. Because SAP NetWeaver unifies integration technologies in a single platform, it re-duces the need for custom integration and ensures that mission-critical business proc-esses are reliable, secure and scalable. As an open technology platform, it is based on industry standards and can be extended with commonly used development tools (e.g. J2EE, Microsoft .NET and IBM WebSphere). Source: SAP.

Service-Oriented Architecture (SOA)

A service-oriented architecture is a distributed software model within which all function-ality is defined, published and invoked as independent Web services. Within a service-oriented architecture, these Web services can be used in defined sequences according to the business logic to form applications that enable the business processes. Source: SAP.

Glossary 95

Subject Matter Expert (SME)

A subject matter expert is a person who has in depth-knowledge in a specialized area within the organization. Subject matter experts can be professionals of both the IT and business community of an organization.

Web Service

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format. Other systems interact with the Web service in a manner pre-scribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. Source: W3C.

List of Abbreviations 96

List of Abbreviations A2A Application to Application

ADM TOGAF Application Development Method

ARIS Architecture of Integrated Information Systems

ASUG Americas’ SAP Users’ Group

B2B Business to Business

BAPI Business Application Programming Interface

BPEL4WS Business Process Execution Language for Web Services

BPM Business Process Management

CORBA Common Object Request Broker Architecture

CEO Chief Executive Officer

CIO Chief Information Officer

CRM Customer Relationship Management

CTO Chief Technology Officer

CxO This stands for executive abbreviations such as CEO, CIO, CTO, etc.

DCOM Distributed Component Object Model

EAESC Enterprise Architecture Executive Steering Committee

EA Enterprise Architecture

EAF Enterprise Architecture Framework

EARB Enterprise Architecture Review Board

ERP Enterprise Resource Planning

ES Enterprise Service

ESR Enterprise Services Repository

ES Enterprise Service

GDT Global Data Type

Y2K Year 2000

DoDAF U.S. Department of Defense Architecture Framework

E2AF Extended Enterprise Architecture Framework

FEAF Federal Enterprise Architecture Framework

IS Information System

IT Information Technology

LOB Lines of Business

MoDAF U.K. Ministry of Defence Architecture Framework

NIH National Institute of Health

List of Abbreviations 97

PMO Program Management Office

REST Representational State Transfer

ROI Return on Investment

RPC Remote Procedure Call

SCM Supplier Relationship Management

SDL Systems Development Lifecycle

SDN SAP Developer Network

SLA Service Level Agreement

SLR Service Level Requirement

SOA Service-Oriented Architecture

SOAP Simple Object Access Protocol

TCO Total Cost of Ownership

TEAF Treasury Enterprise Architecture Framework

TOGAF The Open Group Architecture Framework

UDDI Universal Description, Discovery, and Integration

UI User Interface

UML Unified Modeling Language

W3C World Wide Web Consortium

WSDL Web Service Definition Language

XAF Extensible Architecture Framework

XML Extensible Markup Language

ZIFA Zachman Institute for Framework Advancement

Bibliography 98

Bibliography [ABBG06] Aschenbrenner, Peter; Böder, Jochen; Buck-Emden, Rüdiger; Gröne, Bern-hard; Lünzmann, Martin; Saalfrank, Christian: SAP Architecture Bluebook - mySAP Business Suite Service Provisioning. October 17, 2006.

[Aust05] Eric Austvold: Enterprise Architect: A Strategic Role for the Demand-Driven Enterprise. AMR Research Incorporation. June 22, 2005.

[BaJa06] Baker, David C.; Janiszewski, Michael: Seven Essential Elements of EA. Diamond Management & Technology Consultants Incorporation. 2006. http://www.diamondconsultants.com. URL accessed on October 6, 2006.

[BeFo05] Bernus, Peter; Fox, Mark: Knowledge Sharing in the Integrated Enterprise Architecture - Interoperability Strategies for the Enterprise Architects. Springer Sci-ence+Business Media. First Edition (September 2005).

[BlJa03a] Bloomberg, Jason: SOA + Information Architecture = Code Reuse (Finally!). ZapThink LLC. Document ID: ZAPFLASH-10222003. October 22, 2003. http://www.zapthink.com/report.html?id=ZAPFLASH-10222003. URL accessed on De-cember 23, 2006.

[BlJa03b] Bloomberg, Jason: Calling the Elusive Enterprise Architect: You’re More Important Than Ever. ZapThink, LLT. Document ID: ZAPFLASH-09182003. September 18, 2003. http://www.zapthink.com/report.html?id=ZAPFLASH-09182003. URL ac-cessed on December 23, 2006.

[BlJa04] Bloomberg, Jason: SOA governance: Reengineering IT governance. Zap-Think, LLT. Document ID: ZAPFLASH-10272004. October 27, 2004. http://www.zapthink.com/report.html?id=ZAPFLASH-10272004. URL accessed on De-cember 23, 2006.

[BiKr05] Bittler, R. Scott, Kreizman, Gregg: Gartner Enterprise Architecture Process: Evolution 2005. Gartner Incorporation. ID Number: G00130849. October 21, 2005.

[BrAl06] Brown, Allen: The Changing Role of the Enterprise Architect. The Open Group. October 23, 2006.

[Chan69] Chandler, Alfred D.: Strategy and Structure: Chapters in the History of the American Industrial Enterprise. MIT Press, August 1969.

[ChPe03] Chen, Yu-Che; Perry, James L.: IT Outsourcing: A Primer for Healthcare Managers. IBM Inc. December 2003. http://www-304.ibm.com/jct03004c/tools/ cpeportal/fileserve/download0/372/itsourcingrpt_healthcaremgmt.pdf?contentid=372. URL accessed on December 25, 2006.

[Fcio01] Federal Chief Information Officers Council: A Practical Guide to CIO Council - Federal Enterprise Architecture. February 2001, Version 1.0. http://www.gao.gov/ special.pubs/eaguide.pdf. URL accessed on December 17, 2006.

[FiCl04] Finkelstein, Clive: The Enterprise: Using Enterprise Architecture for IT and Business Governance Requirements, Part 1. DMReview.com. October 1, 2004. http://www.dmreview.com/article_sub.cfm?articleId=1011132. URL accessed on De-cember 21, 2006.

Bibliography 99

[Conn06] Conner, Daryl R.: Managing at the Speed of Change: How Resilient Manag-ers Succeed and Prosper Where Others Fail. Villard Books. First Edition 2006.

[CuAl06] Cullen, Alex: The Enterprise Architecture of SOA - Essential Action Items for the EA Group’s Plan. Forrester Research Inc. February 21, 2006.

[Druck89] Drucker, Peter E.: The New Realities. Butterworth-Heinemann Ltd. July 1989.

[EvEv03] Everden Evaine; Everden Rodger: Information First - Integrating Knowledge and Information Architecture for Business Advantage. Butterworth-Heinemann Ltd. September 4, 2003.

[Gart03] Gartner Executive Program: The Reality of IS Lite. Gartner Incorporation. ID Number: G-11-8504. September 2003. http://gartner.com/resources/ 118500/118504/executive_summary_the_realit_118504.pdf. URL accessed on Sep-tember 9, 2006.

[Gull05] Gullen, Alex: Trends 2006: Enterprise Architecture - Still Defining Its Place in the Enterprise. Forrester Research Incorporation. December 7, 2005.

[Hand06] Handler, Robert: BPM and EA - Too Much Synergies to Ignore. Gartner In-corporation. Enterprise Architecture Summit 2006.

[HaTu05] Hazra, Tushar K.: Getting Your EA Metrics Right. Lockheed Martin Corpora-tion. April 6, 2005. Source: Shared Insights community / Enterprise Architectures Net-work. http://www.sharedinsights.com. Document accessed on November 24, 2006.

[HaWe06] Handler, Robert A.; Weiss, Deborah: Role Definition and Organization Structure: Chief Enterprise Architect. Gartner Incorporation. ID Number G00138141. March 31, 2006.

[JHLG05] James, Greta A.; Handler, Robert A.; Lapkin, Anne; Gall, Nicholas: Gartner Enterprise Architecture Framework: Evolution 2005. Gartner Incorporation. ID Number G00130855. October 25, 2005.

[JoSi05] Johnston, Simon: Modeling service-oriented solutions. STSM, IBM Rational. July 25, 2005. http://www-128.ibm.com/developerworks/rational/library/jul05/johnston/. URL accessed on December 14, 2006.

[LaHa06] Lapkin, Anne; Handler, Robert A.: Enterprise Architecture Research Agenda, 2006. Gartner Incorporation. ID Number: G00138626. March 28, 2006.

[Lapk05] Lapkin, Anne: Gartner's Enterprise Architecture Process and Framework Help Meet 21st Century Challenges. Gartner Incorporation. ID Number: G00133132. November 8, 2005.

[Lapk06a] Lapkin, Anne: Activity Cycle Overview: Enterprise Architect. Gartner Incor-poration. ID Number: G00138081. March 22, 2006.

[Lapk06b] Lapkin, Anne: Business Driven EA: Building the Business Context. Gartner Incorporation. Enterprise Architecture Summit 2006.

[Lapk06c] Lapkin, Anne: Planning for EA - What, Who, How, When and Why. Gartner Incorporation. Enterprise Architecture Summit 2006.

[Lega03] Gene Leganza: Defining Enterprise Architecture. Forrester Research Incor-poration. December 18, 2003.

[LoAn05] Lonjon, Antoine: Challenges and Methods for the Implementation of Service-Oriented Architectures. MEGA Incorporation. http://bptrends.com/deliver_file.cfm?file

Bibliography 100

Type=publication&fileName=04%2D05%20ART%20Updated%20EA%20%2D%20 Lonjon%2Epdf. URL accessed on October 23, 2006.

[MaFr05] Martinez, Frank: Govern Services With Standards. Enterprise Architect Magazine. Edition: String 2005. http://www.enterprise-architect.net. URL accessed on: December 23, 2006.

[MiTi05] Mitra, Tilak: A Case for SOA Governance. IBM Corporation. August 16, 2005. http://www-128.ibm.com/developerworks/webservices/library/ws-soa-govern/. URL accessed on December 23, 2006.

[Namb05] Namba, Yukio: City Planning Approach for Rebuilding Enterprise Informa-tion Systems. Tokyo Institute of Technology. January 2005. http://www.is.me.titech.ac.jp/paper/2004/d3/namba.pdf. URL accessed on November 8, 2006.

[Pear06] Pearlson, Keri E.: Managing and Using Information Systems - A Strategic Approach. Wiley & Sons. March 2006.

[Plum06] Plummer, Daryl: Where’s the Architecture in SOA. Gartner Incorporation. Enterprise Architecture Summit 2006.

[Robe06] Robertson, Bruce: Defining the Enterprise Technology Architecture - Infra-structure Patterns and Services. Gartner Incorporation. Enterprise Architecture Summit 2006.

[RoBi06] Rosser, Bill: Building your EA Communication Program. Gartner Incorpora-tion. Enterprise Architecture Summit 2006.

[RoWR06] Ross, Jeanne W.; Weill, Peter; Robertson, David C.: Enterprise Architecture as a Strategy. Havard Business School Press. August 1, 2006.

[RuRu06] Ruest Danielle; Ruest, Nelson: Exploring IT architecture disciplines, Part 3: Move on to the information architecture”. IBM Corporation. August 15, 2006. http://www-128.ibm.com/developerworks/library/ar-iaoverview/. URL accessed on No-vember 15, 2006.

[Sche04a] Schekkerman, Jaap: How to survive in the jungle of Enterprise Architecture Frameworks - Creating or choosing an Enterprise Architecture Framework. Trafford Publishing. Edition 2004.

[Sche04b] Schekkerman, Jaap: Another View of Extended Enterprise Architecture Viewpoints. Institute for Enterprise Architecture Development. September 1, 2004. http://www.enterprise-architecture.info. URL accessed on November 1, 2006.

[Sche04c] IDS Scheer AG: ARIS Design Platform: Enterprise Architecture - IT City Planning. IDS Scheer AG. April 2004. http://www.leonardo.com.au/newsletters/jun04/ IT_City_Planning_WP_en_2004-04.pdf. URL accessed on November 8, 2006.

[Spew93] Spewak, Steven: Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. Wiley Publishing. September 1993.

[Toga03] The Open Group: The Open Group Architecture Framework 8.1.1. December 19, 2003. http://www.opengroup.org/architecture/togaf/. URL accessed on September 29, 2006.

[VeRa05] Venkateswar , N. Raja: Mitigating Operational Risk in Outsourcing. DM Re-view and SourceMedia, Inc. May 24, 2005. http://www.dmreview.com/article_sub.cfm? articleId=1028024. URL accessed on December 25, 2006.

Bibliography 101

[Vita06] Commonwealth of Virginia: Prepared by the Virginia Information Technologies Agency (VITA). Enterprise Technical Architecture - Domain Reports. http://www.vita.virginia.gov/cots/ea/index.cfm. URL accessed on October 19, 2006. [WeRB05] Weiss, Deborah; Rosser, Bill; Blanton, Cathleen E.: Enterprise Architecture Improve IT Planning Synergies. Gartner Inc. ID Number: G00130847. October 31, 2005.

[WeRo04] Weill, Peter; Ross, Jeanne: IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Harvard Business School Press. Edition 2004.

[Whit05] Whittle, Ralph: Understanding the Enterprise Business Architecture. BPMIn-stitute.org. September 15, 2005. http://www.bpminstitute.org/articles/article/article/ understanding-the-enterprise-business-architecture.html. URL accessed on October 9, 2006.

[WiMy04] Wittle, Ralph; Myrick, Conrad B.: Enterprise Business Architecture. CRC Press Inc. August 20, 2004.

[Wood03] Woods, Dan: Enterprise Services Architecture - An O’REILLY Field Guide to Enterprise Software. O'Reilly Media. September 2003.

[Wood04] Woods, Dan: Enterprise Services Architecture. SAP Press. 2004.

[WoMa06] Woods, Dan; Mattern, Thomas: Enterprise SOA – Designing IT for Business Innovation. O’Reilly Media. May 16, 2006.

[Zerf05] Zerfass, Ansgar: Information Readiness - A Framework for Enhancing Corpo-rations and Regions by Innovation Communication. Innovation Journalism. May 23, 2005. http://www.innovationjournalism.org/archive/INJO-2-8.pdf. URL accessed on September 9, 2006.

Index 102

Index Business architect 7, 72

Business architecture 6, 7, 8, 10, 30, 81, 82

Business modularity See Enterprise architecture maturity

Business process management 8, 94

Business process platform 24, 94

Business silo architecture See Enterprise architecture maturity

Capgemini’s IAF 3

Composers 69, 70

Composite application 27, 28, 95

Consolidators 69, 70, 71

Disruptive innovators 69

DoDAF 3

Dynamic Venturing See Enterprise architecture maturity

E2AF 3

Enhancement package 29

Enhancement Package 95

Enterprise architect 33, 34, 36, 37, 42, 44, 46, 55, 59, 61, 63, 71, 72

Enterprise architecture 2, 29, 33

Enterprise architecture framework 3, 15

Enterprise architecture maturity 58, 60, 61

Enterprise architecture process 34, 37, 39, 41, 46, 54, 56

Enterprise service 19, 20, 23, 24, 26, 27, 31, 43, 62, 69, 95

Enterprise services repository 19, 24, 31, 62, 69, 96

Enterprise Services Workplace 28, 63, 90

Enterprise SOA 10, 19, 21, 26, 29, 43, 58, 61, 69, 72

Gartner Enterprise Architecture Framework 5, 45, 48

Information architect 9, 72

Information architecture 6, 9, 10, 31, 103

Interview 13, 15

Interview reference 36, 60, 70

MoDAF 3

mySAP Business Suite 27, 97

mySAP ERP 11, 27, 90, 91

NIH EAF 3

Optimized core See Enterprise architecture maturity

Repository keepers 70

SAP NetWeaver 97

Solution architect 16, 72

Solution architecture 10, 32

Standardized Technology Stage See Enterprise architecture maturity

Survey 13, 23, 25, 34, 35, 36

Survey reference 4, 5, 37, 38, 43, 46, 50, 56, 60, 62, 85

Technical architect 8, 16, 72

Technical architecture 8, 31

Technical component 8

Technical domain 8

TOGAF 3, 5, 44, 45, 52, 81

Web service 27, 61, 98

Zachman Framework 1, 3, 5, 44, 45

Declaration of Academic Honesty 103

Declaration of Academic Honesty I hereby declare to have written this Diploma Thesis on my own, having used only the listed resources and tools. I have indicated the thoughts adopted directly or indirectly from other sources at the appropriate places within the document.

Walldorf, 31 December, 2006

Sven Feurer

the impact of the enterprise soa on the future role of the ...€¦ · enterprise service-oriented...

Documents