Feature
Architect's Spotlight: Tanaia Parker
Articles
Essential Layers, Artifacts, and Dependencies Of Enterprise Architecture
Robert Winter and Ronny Fischer
Presenting a Theory-Based Model for IT Management Responsibilities
Magnus Gammelgard, Marten Simonsson, and Asa Lindstrom Enterprise Architecture and Change Management Fatima Espinoza
The Future of Information Technology - Part 4 Robert Ellinger
Case Study
The Methodology for Business Transformation v1.S:
A Practical Approach to Segment Architecture Colleen Coggins and Jerad Speigel
May 2007 I Volume 3, Number 2
4
7
19
27 36
45
A quarterly publication of the Association of Enterprise Architects An International Forum for Enterprise Architecture
al EA
The Journal of Enterprise Architecture
May 2007
Volume 3, Number 2
Features
Editor's Corner
alEA Points of Contact Architect's Spotlight
Articles
Essential Layers, Artifacts, and Dependencies
Of
Enterprise ArchitectureRobert Winter and Ronny Fischer
Presenting
a
Theory-Based Model for IT Management ResponsibilitiesMagnus Gammelgard, Marten Simonsson, and Asa Lindstrom Enterprise Architecture and Change Management Fatima Espinoza
The Future
of
Information Technology - Part 4 Robert EllingerCase Study
The Methodology for Business Transformation v1.5:
A Practical Approach to Segment Architecture Colleen Coggins and Jerad Speigel
2 3 4
7
19
27
36
45
a/EA
JOURNAL
Scott Bernard, Editor
This quarter's issue of the Journal of Enterprise Architecture (JEA) is once again packed with good information on various topics that are pertinent to enterprise architecture (EA). Being the Chief Editor of JEA is a great vantage point for seeing what is going on in EA practice areas as well as emerging areas of related theory. The view that I see (while admitting some bias) is that that EA continues to mature and grow on a global basis by becoming "grounded" in established theory from the social and physical sciences, as well as adopting proven best practices from the public and private sectors.
Evidence of this is seen not only the increasing number of EA workshops, seminars, and conferences around the world; but also in an increase in the number of courses, books, and articles on EA that are appearing in both trade and academic publications. Further evidence of the growth of EA is seen in laws and policy that continue to emerge from the public and private sector that require or acknowledge EA processes as a part of overall governance.
Examples include the provision of e- Government services in the U.S., Korea, Canada, and Denmark using EA best practices; as well as the development and implementation of internal financial controls in businesses in the U.S. to meet Sarbanes- Oxley mandates or the security and privacy requirements of HIPAA. It is interesting that the Japanese government has adopted an equivalent to Sarbanes-Oxley and companies in Japan are also looking at EA as one way to meet the mandates that take effect next year (see the related article on that in the February 2007 issue of JEA).
Many articles in JEA thus far have been from practitioners as opposed to researchers, which is typical of a new area of inquiry. It should be no surprise that academia lags behind, in part because one of the main drivers of research is available funding, and primary sources of funding are government and industry. For funding to become available for research and conferences there has to be a critical mass of interest from those who will provide needed
resources. That is happening now, which will serve to accelerate the development of EA best practices that are grounded in theory.
Areas of theoretical grounding from the social sciences include organizational theory, management theory, and systems theory.
Relevant areas of applied theory from the physical sciences come mainly from computer science and engineering. These theories relate to the strategic, business, and technology aspects of enterprise architecture methodologies and frameworks, and it is very important in the maturing of EA as a professional discipline to firmly root its best practices in the validated research of how organizations function and how they use technology; and not to ignore that research, as has unfortunately happened during much of the first 20 years of EA concept development.
The May issue marks the first time that JEA has 'teamed up" with an academic conference, which was the 2006 Trends in Enterprise Architecture Research (TEAR) Workshop that was held in Hong Kong in conjunction with the EDOC Enterprise Computing Conference.
This year's TEAR Workshop will be held June 6-9 at St. Gallen's University in Switzerland in conjunction with the European Conference on Information Systems www.ecis2007.ch/ws tear.php.
The May issue of JEA begins with two articles from the TEAR 2006 Workshop, one from Robert Winter and Ronny Fischer on the
"Essential Layers, Artifacts, and Dependencies of an EA" and an article from Magnus Gammelgard, Marten Simonsson, and Asa Lindstrom on a "Theory-Based Model for IT Management Responsibilities." We then have an article from Fatima Espinosa on "EA and Change Management" as well as the final of a four-part series by Robert Ellinger on "The Future of IT." The May issue finishes with an interesting case study by Colleen Coggins and Jerad Speigel on how the U.S. Department of Interior is using their Methodology for Business Transformation (MBT) to promote change in the organization and the use of segment architecture approaches as part of their EA.
alEA
URNAL
International Executive Committee
President: John Gotze [email protected] Vice President: Gary Doucet [email protected]
Secretary: Kristian Hjort-Madsen [email protected] Treasurer: Scott Bernard scott.bernard@aeajoumal,org
National Chapters Australia Chapter
Levine Naidoo
Canada Chapter
Mike Giovinazzo [email protected]
Chile Chapter
Alfredo Piquer:
Colombia Chapter
Francisco Ballesteros
Denmark Chapter
John Gotze
India Chapter
Sunil Dutt Jha
Ireland Chapter
Liesel Muth
Korea Chapter
John Kang
New Zealand Chapter
Mike Lowe
South Africa Chapter
Graham McLeod [email protected]
United Kingdom Chapter
John Good
United States - Local Chapters Atlanta Chapter
Andrew LeBlanc
andrew. leblanc @sap.com
Dallas
I
Fort Worth ChapterWilliam Krauter
Delaware Valley Chapter
Michael Robison
California Chapter
Kenneth Griesi
Midwest Chapter
Chuck Ohms
New York Chapter
Brian Clark [email protected]
San Antonio Chapter
Orvis Meador
San Diego Chapter
Karl Garrison
Seattle Chapter
Marci Hadnot
Tampa Chapter
Liesel Muth
Tennessee Valley Chapter
Shawn Wilson
Washington DC Metro Chapter
JohnWu
a/EA
JOURNAL
Tanaia Parker
Tanaia Parker is one of the most talented enterprise architects that I have seen come along in recent years. She is the Founder and President of T. White Parker, a strategy and management consulting firm specializing in
"enterprise problem solving" and "strategic management". For over thirteen years, she has worked as a strategy consultant, enterprise architect, business advisor and IT professional to various levels of management within multi- billion dollar companies, public sector organizations as well as emerging start-ups.
Her breadth of experience has helped to create a unique perspective and approach to strategic planning, strategy development, management and execution. Tanaia has a bachelor's degree in Business Administration from The American University and an M.B.A. from The George Washington University. Tanaia is a member of the Association of Enterprise Architects and currently serves as President of the National Capital Area Chapter of the Association for Strategic Planning.
JEA: How did you become involved with enterprise architecture?
Parker: My initial involvement in EA was in 1998 during the telecommunications industry boom. I was working for a new telephone company that had already developed a portfolio of systems that was not optimal for the company. The VP of IT chartered an EA initiative to help our company get a hold on how we were going to leverage and/or re-engineer all of our silo'd systems to become more competitive in the marketplace and more effective operationally. I was assigned to lead the team .. yes, an IT Project Manager who had no clue what an EA was! I had to come up to speed on EA pretty fast and at the time there were not a lot of EA resources. I was grateful (instead of being embarrassed) when one of my EA consultants took me under his wing and assigned me some reading homework.. the "Cook book" of EA at the time .. Melissa Cook's "Building Enterprise Information Architecture: Reengineering Information Systems" and John Zachman's EA
framework. After my assignments, I started to dig deeper on my own. After putting the pieces together, I decided that EA could truly be used to catapult an organization .. not only from a systems perspective (which is what we were looking to do) but also from a business perspective. I was hooked at that point and have been an EA disciple ever since.
JEA: One of your specialty areas is strategic planning, how does this relate to enterprise architecture?
Parker: First, let me say that I believe EA is truly about strategic planning and strategic management for an organization .. period. The key words here are "planning" and
"management". Although IT is a huge consideration in the development of an EA program and EA artifacts, IT should only be viewed as the enabler of the business while the business itself should be operating from some sort of strategy (even if it's what we call a "loose"
strategy).
The relationship between strategic planning and EA is natural when you separate an EA into its traditional piece parts .. Current State, Target State and Transition Plan. In this view, an organization can choose to present its strategic plan in the form of an expanded EA Target Architecture & Transition Plan. The goals of a Target Architecture and Transition Plan are to describe the future state of an organization from various perspectives of an organization and provide a road map for getting there. This is absolutely the objective of a strategic plan!
In another view of the strategic plan and enterprise architecture relationship, the strategic plan presents the vision, mission, set of goals and objectives for an organization while the EA Transition Plan serves as the action plan for getting there. One of the most common pitfalls in strategic planning is execution. Most organizations dump loads of dollars into developing a well-informed, good looking strategic plan with no thought into how it will be executed. I continue to propose that a well-
orchestrated EA program is the answer to the strategy execution dilemma.
JEA: What was your most enjoyable EA project and why?
Parker: My most enjoyable EA project was my first at the telecommunications company. EA was relatively new and there was much to learn, much to debate and everything to lose on this project. We had no EA tools .. only MS Office suite and a few modeling tools. Coming from an IT background, of course I thought everything had to be about IT. It was in having to make the EA program deliver business-related results that got me off of my IT high-horse and on the mission to ensure that the business drove IT decisions and not the other way around. This was a turning point in my career.
JEA: What was your least enjoyable EA project and what made it that way?
Parker: My lease enjoyable project was for a client several years ago that chartered an EA effort for only compliance reasons with no intention to use the EA at all ... I was literally told to "do what you have to do to ensure we pass". After a couple of failed attempts to try to persuade the client that EA was a good thing and that we should really try to make a concerted effort to "do the right thing", I had to back off. At the time, the organization just had to be able to say that they had an EA .. not that they were using it or that the EA was even a good one. Of course, this organization passed with flying colors which reinforced their reluctance to get on board with a true EA program.
JEA: In your opinion, what is the greatest challenge to the practice and profession of EA today?
Parker: I believe the greatest challenge to the practice and profession of EA today is not having a well-defined value proposition. EA is still not tangible for many. The definition of EA and the value it delivers is truly "in the eye of the beholder". What do we as a profession know for sure as the EA value proposition? Every architect can give you an answer but it will
probably be different and maybe not even connected. This makes EA a hard sell. I think we'll get there.
JEA: Do you see EA as a viable career path of business and technology professionals?
Parker: Absolutely! As the discipline continues to mature, I believe we will see EA becoming more tangible. We will also begin seeing areas of expertise within the EA discipline like what we've seen in the world of strategic management. For business professionals, it will become more and more about how to leverage EA to improve business results while technology professionals will enjoy working to design more solutions to support EA efforts as the initiatives themselves become more sophisticated.
JEA: What would you recommend to someone who is considering a career in EA?
Parker: Learn everything you possibly can about what is out there in EA .. the different viewpoints, challenges, the different tools, frameworks, etc.. Given what you have learned, develop your own view of EA and how it will deliver value to an organization. Look at how your view works (or doesn't) with the other views. Develop a niche and work the niche to deliver tremendous results to your customers.
Call for Papers
The Journal of Enterprise Architecture
is accepting article submissions for its 2007-2008 issues Research and Best Practice articles
are sought on EA-related topics, including:
Case Studies, Configuration Management, Culture, Documentation, Evaluation, Frameworks, Governance, Implementation, Maintenance,
Methodologies, Taxonomies, Theory, Training, Tools, Use, Value Issue
February May August November
Due Date November 1 February 1 May 1 August 1
Send articles to the JEA Editor at
Author submission guidelines can be found on the aJEA website at
www.aeajournal.orq
a\EA
JOURNAL
Essential Layers, Artifacts, and Dependencies of Enterprise Architecture
By Robert Winter and Ronny Fischer Abstract
After a period where implementation speed was more impottant than integration,
consistency and reduction of complexity, architectural considerations have become a key issue of information management in recent years again. Enterprise architecture is widely accepted as an essential mechanism for ensuring agility and consistency, compliance and efficiency. Although standards like TOGAF and FEAF have developed, however, there is no common agreement on which architecture layers, which attifact types and which dependencies constitute the essence of enterprise architecture. This paper contributes to the identification of essential elements of enterprise architecture by (1) specifying enterprise architecture as a hierarchical, multilevel system comprising aggregation hierarchies, architecture layers and views, (2) discussing enterprise architecture frameworks with regard to essential elements, (3) proposing interfacing requirements of enterprise architecture with other architecture models and (4) matching these findings with current enterprise architecture practice in several large companies.
Keywords
enterprise architecture, architectural components, architectural layers, architectural views, interfaces
ENTERPRISE ARCHITECTURE: DEFINITION According to ANSI/IEEE Std 1471-2000, architecture is defined as the '1undamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution" (IEEE 2000).
Enterprise architecture (EA) therefore is understood as (1) the fundamental organization of a government agency or a corporation, either as a whole, or together with partners, suppliers and / or customers ("extended enterprise"), or in part (e.g. a division, a department, etc.) as well as (2) the principles governing its design and evolution (Opengroup 2003) .
While an EA model is a representation of as-is or to-be architecture of an actual corporation or government agency, an EA framework provides (Opengroup 2003)
• One or more meta-model(s) for EA description,
• One or more method(s) for EA design and evolution,
• A common vocabulary for EA, and maybe even
• Reference models that can be used as templates or blueprints for EA design and evolution.
The components of an EA framework should be applicable for a broad range of corporations and government agencies.
Traditionally, architecture in the information systems context is focusing on IT related artifacts like IT platforms, software components and services, applications, IT processes, and maybe IT strategy in order to support more efficient IT operations, better return on IT investment, and faster, simpler and cheaper IT procurement (Opengroup 2003). In contrast to this approach which better should be designated information systems architecture (ISA), EA should also include business related artifacts like organizational goals, products and services,
markets, business processes, performance indicators, etc. (BraunlWinter 2005). Only when 'purely' business related artifacts are covered by EA, important management activities like business continuity planning, change impact analysis, risk analysis and compliance can be supported.
ENTERPRISE ARCHITECTURE:
REPRESENTATION
The aforementioned definition of enterprise architecture restricts included components to be 'fundamental'. Due to the broad range of relevant component types, EA may nevertheless comprise a huge number of such artifacts. As a consequence, most EA frameworks distinguish several architecture layers and architecture views in order to reduce the number of artifacts per model (Schekkerman 2004, Tang et al.
2004). When several architecture layers and architecture views are differentiated, design and evolution principles have to address consistency and integration issues. The theory of hierarchical, multilevel systems (Mesarovic et al.
1970) provides a conceptual foundation for such methods.
For EA, a hierarchical approach usually applies the 'IT follows business' principle, starting with strategic positioning from the business management point of view, then deriving appropriate organizational processes and structures on this basis, and finally specifying the information system, i.e. the interaction between human and technical information system components that appropriately support business requirements (BraunlWinter 2005).
Most frameworks differentiate the following EA layers:
• Business architecture: The business architecture represents the fundamental organization of the corporation (or government agency) from a business strategy viewpoint. Typical artifacts represented on this layer are value networks, relationships to customer and supplier processes, targeted market segments, offered services, organizational goals, and strategic projects (WeiliNitale 2001, Hedman/Kalling 2003). Design and evolution principles for business architecture can be derived e.g. according to the market based approach (Porter 1998) or the
resource based approach (HamellPrahalad 1990) to strategic management.
• Process architecture: The process architecture represents the fundamental organization of service development, service creation, and service distribution in the relevant enterprise context. Typical artifacts represented on this layer are business processes, organizational units, responsibilities, performance indicators, and informational flows (Davenport 1993).
Design and evolution principles for this layer focus on effectiveness (creating specified outputs) and efficiency (meeting specified performance goals) (bsterle 1995).
• Integration architecture: The integration architecture represents the fundamental organization of information system components in the relevant enterprise context. Typical artifacts represented on this layer are enterprise services, application clusters, integration systems and data flows.
Design and evolution principles for this layer focus on agility (e.g. by service orientation (Douglas 2003)), cost efficiency (e.g. by reduction of interfaces (Linthicum 2000)), integration (e.g. by analysis of data coupling (IBM 1984)), and I or speed (e.g. by straight- through processing (KuhlinlThielmann 2005)).
• Software architecture: The software architecture represents the fundamental organization of software artifacts, e.g.
software services and data structures. A broad range of design and evolution principles from computer science is available for this layer.
• Technology (or infrastructure) architecture: The technology architecture represents the fundamental organization of computing I telecommunications hardware and networks. A broad range of design and evolution principles from computer science is available for this layer too.
According to the hierarchical, mUlti-level systems theory approach, results on each architecture layer reduce the degrees of freedom of the subsequent layers (Mesarovic et al. 1970).
Most of the artifacts classes represented in EA can be represented as aggregation hierarchies,
i.e. can be modeled on various level of aggregation. For example, the organizational goals of a corporation (or government agency) that are defined on a very aggregate level in a balanced scorecard, are subsequently decomposed into more and more specific performance indicators, resulting in a multi-layer goal/indicator aggregation hierarchy. Such aggregation hierarchies are commonly used not only for goals/indicators, but also for products/services, business processes, organizational units, information objects, or software artifacts.
Figure 1 provides a schematic illustration of an EA comprising the above mentioned five hierarchical layers. On each layer, aggregation hierarchies are used to represent artifacts on different levels of aggregation.
Alongside the formation of architecture layers and aggregation hierarchies, views are often used in order to master complexity (SowalZachman 1992). In a multi-layer architecture, views can be layer-specific or cross-layer. Examples for layer-specific views in EA are the structural view (organizational units, responsibilities) and the process view (business
Business Architecture
Process Architecture
Integration Architecture
Software Architecture
Technology Architecture
processes, performance indicators) on the organization/process layer. Examples for cross- layer views are security architecture and information architecture.
Based on the concepts of multi-layer representation, aggregation hierarchy and cross- layer view, EA can be defined as the view that represents all aggregate artifacts and their relationships across all layers (Fig. 1). This is due to the fact that only the most aggregate artifact representations can be 'fundamental', and that all more decomposed artifact representations have to be covered by specialized architectures.
The remainder of this paper is organized as follows: In Section 2 we analyze several EA approaches with regard to the core artifacts they propose. Interfaces to other corporate architectures and models are discussed in Section 3. In Section 4, we compare our recommendations against several EA case studies in large companies from different countries and industry sectors. In Section 5, conclusions regarding the level of detail of EA core artifacts and their interfaces to other architectures are drawn, and an outlook to future research in this area is given.
Enterprise Architecture
Figure. 1. Enterprise Architecture as a Cross-layer View of Aggregate Artifacts
CORE ARTIFACTS OF EA
In this section, we discuss which core artifacts should be covered on the five regarded EA layers. As a basis for consolidating artifact types that are considered as being important for EA, we analyze widely used EA frameworks such as
organizational units business locations
business goals and objectives (for each organizational unit) perfonnance metries
business functions (as an aggregation hierarchy) internal and external business services
business processes (including measures and deliverables) business roles (including skills requirements) programs
TOGAF 8.1 Business Architecture Business Architecture Business Architecture Business Architecture Business Architecture Business Architecture Busincss Architecture
TOGAF 8.1 (Opengroup 2003), FEAF version 1.1 (CIO-Council 1999, CIO-Council 2001) and ARIS (Scheer 1999) with extensions from (IDS Scheer 2005). The results are exhibited in Table 1 below.
FEAF 1.1 Technology Architecture"'
Application Architecture"' Application Architecture
AAIS Organizational Architecture
Business Perfonnance Architecture
Business Process Architecture Organizational Architecture data (various views)
applications (various views) conceptual I semantic dam model logical data model
Infonnation Systems Architecture Infonnation Systems Architecture
Data Architecture Data Architecture"' Data Architecture
Data View Data View data management process models
data entitylbusincss function malrix various data related views 'process' systems models
'place' systems models (location, org unit) 'time' systems models (events, messages) 'people' systems models
outputs, products (business logistics model) various application related views softwIU'C components hardware models communications modcls proccssing models other technology models
Data Architecture Data Architecture Data Architecture Data Architecture Applications Architecture Applications Architecture Applications Architccture Applications Architccture Applications Architecture Technology Architecture Technology Architecture Tcchnology ArchitectW"e Tcchnology Architecture
Data Architecture Application Architecture"' Technology Architecture
Technology Architecture'"
Application Architecture Application Architecture Technology Architecture Technology Architecture
Function View Organization View Control View Organization View Output View Function View Organization View Control View
'" also componcnts of Business Architecture
Table 1. Enterprise Architecture as a Cross-layer View of Aggregate Artifacts TOGAF's business architecture is populated
with many artifact types. The five-layer approach presented in the preceding section therefore differentiates between strategy related artifacts (specifying the "whaf') and organization/process related artifacts (specifying the "how"). TOGAF's IS architecture layer can be compared to the proposed integration/application layer. Data and applications architecture are assigned to different layers in TOGAF, whereas they are treated as views on the software layer in the proposed framework.
FEAF's data architecture, application architecture and technology architecture can be interpreted as cross-layer views, while business architecture comes close to a simplified business & process architecture.
In general, FEAF comprises not many artifact types, and has - like the Zachman framework from which it was adapted - not put much effort into specifying EA-relevant artifact relationships.
Goal/performance related artifacts and product specifications are not covered by FEAF at all.
The five views of the original ARIS framework (Scheer 1999) comprise artifacts that are located mainly on the software component layer of the proposed EA framework. This mainly 'technical' subset of artifacts has recently been extended (IDS Scheer 2005). But even with 'business architecture' extensions, strategy related artifacts are not covered in depth. There is also a lack of artifacts that represent high- level constructs on the integration/application layer (e.g. application clusters, enterprise services). On the other hand, many artifacts are covered that are considered not to constitute an important component of EA (e.g. computer hardware details, machine resources).
When comparing these framework approaches to EA, the following set of artifact types results as a hypothesis for EA core artifacts:
• Strategy specification ("what" questions):
hierarchy of organizational goals and success factors, product/service model (including partners in value networks), targeted market segments, core competencies, strategic projects, maybe business principles, dependencies between these artifacts.
• Organization/process specification ("how"
questions):
o Specification of structure: organizational unit hierarchy, business location
hierarchy, business role hierarchy (including skills requirements), dependencies between these artifacts o Specification of behavior: business
function hierarchy, business process hierarchy including inputs/outputs (internal and external business services including service levels), metrics (performance indicators), service flows o Specification of information logistics:
business information objects, aggregate information flows
o Dependencies between these artifacts, e.g. responsibilities, information requirements
• Application specification (business IT alignment questions):
o Specification of applications and application components
o Specification of enterprise services and service components
• Software specification:
o Specification of software components:
functionality hierarchy, event/message hierarchy
o Specification of data resources:
conceptual, logical and physical data models
o Dependencies between these artifacts, e.g. data usage by software
components (CRU D)
• Technical infrastructure specification:
o Specification of IT components:
hardware units, network nodes, etc.
o Dependencies between these artifacts
• Specification of dependencies between layers, e.g.:
o Organizational goals/success factors vs.
process metrics
o Products/services vs. process deliverables
o Organizational units vs. applications (ownership)
o Activities vs. applications o Activitiesfbusiness
processes/information requirements vs.
enterprise services (orchestration) o Applications/enterprise services vs.
conceptual data entity types o Applications/enterprise services vs.
software components (composition) In the following Section, we will first discuss which artifact types on which aggregation levels should be part of EA, and which should be part of other, specialized architectures and models.
In Section 4, we will compare our
recommendation with several EA case studies that exhibit current EA practice in large companies.
INTERFACING EA WITH OTHER
CORPORATE ARCHITECTURES & MODELS It is obvious that the complexity of a medium or large corporation (or government agency) cannot be covered by one single EA. In real life, several EAs for different parts of the enterprise might be maintained, and/or EA will co-exist with other, more specialized architectures that cover a subset of artifacts. Hence a useful interfacing between EA and specialized architectures must be specified.
An analysis of the goals of EA seems useful in order to specify this interface. EA should
• Support IT business alignment by providing support for consistent design and evolution of artifacts on different layers and/or in different views,
• Support transformation (business development, process reengineering, IS reengineering) by providing impact analyses, and
• Support maintenance, compliance, risk management etc. by documenting not only structures and direct dependencies, but also allowing the analysis of mUlti-step dependencies (e.g. server - software
service - enterprise service - process deliverable - product - revenue}.
As a consequence, EA should be 'broad' rather than 'deep': For multi-step dependency analyses and holistic coverage of IT business alignment, it is much more useful to cover a large number of artifact types and their dependencies on an aggregate level, than to cover a small number of artifact types and their dependencies in more detail. This understanding of EA is illustrated in Figure 1. We therefore need to identify appropriate interfaces to partial, specialized architectures like:
• Product/service architecture (managed e.g.
using a product management tool),
• Metrics architecture (managed e.g. using a performance management tool),
• Process architecture (managed e.g. using a process modeling tool and workflow
management systems),
• Information/data architecture (managed e.g.
using a data modeling tool and database management systems),
• Software architecture (managed e.g. using a software design tool and a configuration management tool), and
• Technology architecture (managed e.g.
using a computer system management tool).
In order to provide an indication regarding the specification of interfacing between EA and specialized partial architectures, four EA case studies are presented in the next section.
CASE STUDIES
By presenting four case studies of EA initiatives conducted by large companies from different industries and countries, we want to validate our recommendations for essential EA artifact types in Section 3.
The data was collected by desk research, informal interviews with EA project managers and/or personal involvement of the authors in EA projects of these companies. Table 2 below gives an overview of the four analyzed companies.
Company A CompanyB CompanyC CompanyD
Country Industry
Switzerland Financial
services
South Africa Mining
Germany Banking
Switzerland Insurance
Table 2. Overview of Case Studies The description of the cases is structured as
follows. We start with outlining the core business of the company. Then we describe the motivation for adopting an EA program within the respective company. After this, the EA model layers of the respective project are specified and mapped to the architecture layers proposed in Section 1. Finally we identify core artifacts within each layer and important intra- layer as well as cross-layer dependencies between artifacts.
Company A
Company A is a major Swiss financial service provider. The EA program of company A was started in 2005 and is ongoing. The program
was initiated because an aggregate, enterprise- wide view of important entities and dependencies did not exist.
Unlike many other organizations, IT business alignment is not the major driver for EA efforts in company A. Instead, EA is aimed at supporting strategy implementation, in particular at supporting the project selection/project portiolio planning process. In addition, EA is regarded as foundation of business continuity planning, service management and security management.
The enterprise architecture model of company A comprises four architectural layers as is shown in Figure 2 on the next page.
EA layers of Company A Proposed EA layers
I
Strategy Architecture• • I
Busin~ss:Archit~cture:I I
w'Sus'ines's
Archtte6t'u~e• • I
: ,Pro'cess ArchitectureI
AppJicatibn' Ardh~fect,~re
• • I
integrai~6:~"Ar'Chite~'~re"I
• • I
S~fiWare' Arb~it~ct~'reI
• •
InfrastrilCtJre:Archit~~dure' , ,'" , >Figure. 2. Mapping between EA layers of Company A and proposed EA layers The strategy architecture represents
organizational goals as well as projects aiming at implementing these goals, and project results linked to these goals. Company A intends to extend the strategy architecture by adding success factors related to organizational goals and performance indicators for these success factors.
The business architecture corresponds to the process architecture mentioned in Section 1 (Figure 2) and represents core business functions, organizational units, business locations and service level agreements which are all linked to high level business processes.
The services offered by company A are also represented on this layer. This is a major difference to our proposal in Section 1 where we assigned business services to the strategy layer.
Organizational units are depicted by a hierarchical model which defines organizational units broadly at first and then with increasing detail. Furthermore, core business functions are linked to strategy implementation projects (as part of the strategy architecture).
Application services, applications, application clusters and information objects are artifact types assigned to the application architecture.
Here the most important dependencies regarding artifacts from the same layer as well as from superordinate layers are:
• Dependencies between application services and business processes as well as between application services and core business functions,
• Dependencies between information objects and applications, and
• Dependencies between information objects and business processes.
The IT architecture comprises deployed applications which are linked to application services on the superordinate layer and IT components called "configuration items"
(servers, databases, etc.). IT components are represented by a hierarchical model.
With respect to the development of enterprise architecture content, Company A strongly relies on information from models which already exist within the enterprise. A single EA repository is used to integrate meta data on all EA artifact types. Artifact meta data from various sources is cleaned, and redundancies are eliminated during the repository update process. There is no need for specific EA modeling activities except for representing aspects that are not covered by existing models.
CompanyB
Company B is one of the world's leading producers of precious metals with exploration and mining activities in South Africa, Canada, Russia, Brazil, and Zimbabwe.
The adoption of an EA program at company B was motivated by the need for accurate, timely and consistent information regarding the corporate structure. Main reasons for dealing with EA at company B have been poor IT business alignment, absence of an effective IT governance, and unification of modeling methods, tools and standards across the enterprise.
Company B's EA model is subdivided into five layers, as is shown in Figure 3 on the next page.
The business architecture represents strategic objectives, business principles, offered products, business roles, organizational units and business locations as well as risk items. All of these artifact types are linked to high level business processes. The business processes model itself is a hierarchical model consisting of
EA layers of Company B
r:' i'~fo.m~tici~,',A'r6hitectu~e
AP~lfc"tionAr~BitectJ~e
enterprise processes (level 0) which are decomposed into value chains (level 1). These value chains are then decomposed into processes (level 2). Summarizing these findings, company B's business architecture can be understood as a combination of the proposed business architecture and selected parts of the process architecture from Section 1, as shown in Figure 3 below.
Proposed EA layers
~
• 1<··lrjl~cira~oi1J\rchit~ctur~
•~
(x) • 1Soft..ar~Archlt~~ture
~
• 1Infrastructur~ Archit~cture
(x) Mapping refers to data-related artifacts only
Figure. 3. Mapping between EA layers of Company B and proposed EA layers The information architecture is comprised of an
information object hierarchy and a metrics hierarchy as well as dependencies between information objects and metrics on the one hand and processes, applications and data models on the other hand.
Applications, application clusters, application modules and application interfaces are artifacts represented by the application architecture. In order to enable IT business alignment, applications are connected 'upward' to business processes and organizational units (on the business layer).
The data architecture depicts (logical) data models embracing data subject areas, entities, tables and their relationships to business processes and organizational units/business roles.
The technology architecture comprises infrastructure applications and network nodes.
Both are linked to applications, databases, organizational units and business locations.
CompanyC
Company C is a large German full-service bank with more than four million private customers and almost half a million corporate clients.
Company C developed EA to enhance the transparency of process architecture and integration architecture. By that means, potentials for optimization across business segments should be revealed, and information required for sourcing decisions should be provided.
Company C's EA approach distinguishes between business architecture and technical/IT architecture, with both architectures being subdivided into several layers. The mapping between company C's EA layers and the EA layers proposed in Section 1 is illustrated in Figure 4.
For each business segment, the business model layer represents value networks, targeted market segments and offered services. The service model is a hierarchical model comprising
three levels: level 1 (product categories) is decomposed into level 2 (product groups) which
then is decomposed into level 3 (products).
EA layers of Company C Proposed EA layers Businesi:Mociel
Architecture
<441---+"I': BJsin'es~ ArchltJciui"e ' BusineSs~pr6G6~S Ai-C'h\t~cture
<441---+" IPro~~~'Architecture I
.. Application Architect"r"I
4I
Integration Architecture'I
4. Integration Architec!UrE.
I
System Architectur~I
+--.~ 4 SoftWare Architecture Opera!idDall\rchitec!ure +--.~ 4 Infras!ructureArchitectureFigure. 4. Mapping between EA Layers of Company C and Proposed EA layers
The breakdown of enterprise processes/value chains into sub-processes and their relationships are represented on the business process layer. By means of a org unit hierarchy, the organizational structure of the company is represented on the business process layer too.
In addition, the following dependencies are specified on the business process layer regarding artifacts from the same layer as well as from other layers:
• Dependencies between business processes and organizational units
• Dependencies between business processes and application clusters as well as single applications
• Dependencies between offered services and corresponding business processes
• The application layer is comprised of logical application clusters, while the integration layer describes principles and technologies for application integration. Technical components related to applications are represented on the system layer. The operational layer represents mandatory principles for application operation.
Company 0
Being a major player in the Swiss insurance market with more than one million customers and focusing on non-life insurance, Company D
has launched its EA initiative more than four years ago.
Investment in EA has been justified by a lack of transparency regarding dependencies between IT and service offerings / business processes.
As a consequence, an EA model was created as a means for enterprise planning, to eliminate redundancies, and to standardize business processes as well as information systems.
Company D's EA model is comprised of three architectural layers. Alongside these three layers, two architecture views exist. Fig. 5 depicts the mapping of this approach to the EA layers proposed in Section 1.
EA layers of Company D Proposed EA layers 4
• I
~B'~~Io'e~'~ A;~6it~ct,u'r~I
4
• I
Pip~s~'Ar~hiteCtur~I
4
•
< :':;::)ht~d;~tion Ai6~'iteCtute,4
• I:
:)S~~~t~"Arbi;it~tiu~e:', I
4
•
hlfra'struclure ArchitectureFigure. 5. Mapping Between EA Layers of Company D and Proposed EA Layers The business architecture is aimed at
representing corporate strategy, services, business principles, business scenarios, business processes and corresponding activities as well as business components and business objects. Business processes are depicted by means of an aggregation hierarchy. Elementary processes are decomposed into activities.
Business scenarios are mapped to services.
Dependencies between business activities and applications, application components, application services and application interfaces are represented by the application architecture.
The technical/IT architecture is comprised of two sub-layers designated as "implementation technology" and "runtime environment".
Software systems and their decomposition into software components, software modules as well as software interfaces are represented by the
"implementation technology" sub-layer. Software interfaces are linked to application interfaces.
Platforms, databases, integration systems and network nodes required to run the systems are represented by the "runtime environment" sub- layer. In addition, dependencies between platforms and integration technologies on the one hand, and software components on the other hand are specified on the runtime environment sub-layer.
The data architecture encompasses data objects, entity types and tables. Data objects are linked to business objects represented within the business architecture.
Business risks, non-functional requirements and technical precautions are represented by the security architecture. Dependencies between
business risks and business activities are also represented as part of the security architecture.
CONCLUSIONS AND OUTLOOK
Based on the discussion of current EA frameworks, we proposed a set of EA layers, artifacts and dependencies in Section 2 that we consider as essential for a business-oriented approach to EA. In Section 3, we presented arguments for differentiating between EA and other, specialized architectures and models in enterprise modeling. Since the basic layer design "from business to IT", most of the artifacts and many dependencies can be identified in various actual EA cases summarized in Section 4, it is justified to propose our recommendation of EA essentials as a hypothesis. Of course, broad empirical studies need to validate this proposition.
We believe that an important success factor for EA initiatives is to clearly distinguish between the broad, but aggregate EA on the one hand, and a set of specialized, detailed partial architectures on the other. Enterprise modeling can achieve its goals only if interfaces between EA and specialized architectures have been conceptually specified and efficiently implemented.
With reference to the essential EA artifacts proposed in Section 2 and our findings from the case studies in Section 4, we suggest that interfaces between EA and specialized architectures should be specified as follows:
• Business Architecture: While product/service categories, product/service groups and products/services should be comprised in EA, more detailed product/service representations like variants, versionslreleases and components should be represented by a product sub- architecture, and managed by a product management tool. Furthermore, projects aiming at realizing strategic goals should not be decomposed in EA. Project portiolio tools and / or project management tools are more appropriate for this purpose.
• Process Architecture: Business processes should not be decomposed further than to the sub-process level. Detailed process descriptions including specifications of activities and work steps are out of EA scope and should be maintained by using specialized business process modeling tools and / or workflow design tools. As a consequence, process performance management tools are much better suited to represent performance indicators related to activities, while the aggregate performance information represented in balanced scorecard tools might be a valuable part of EA.
• Integration Architecture: While aggregate dependencies / data flows between applications or application components are belonging to EA and should be managed by appropriate EA tools, detailed interface descriptions for data exchange, remote procedure calls etc. should be maintained by using tools like integration repositories of enterprise application integration (EAI) tools.
• Software Architecture: Detailed descriptions of data objects (e.g. attribute lists) are not essential for EA purposes and should be managed e.g. by using a data modeling tool. In addition, structural and behavioral aspects of single software components are not covered by EA and should be managed by using software design tools.
• Infrastructure Architecture: Detail specifications of IT components (hardware units etc.) are not essential for EA; Asset management tools should be used for managing such meta data, and appropriate
interfaces have to maintain consistency between the different repositories.
In addition to a broader empirical validation of the proposed essential layers, artifacts and dependencies of EA, further research will be needed to identify and validate a reference meta architecture that specifies architecture components (EA, performance management, product management, project management, workflow design, data management, EAI configuration, software design, IT asset management, etc.) and interfaces between those components.
Another interesting aspect that has not been covered in depth is the differentiation of EA scenarios, e.g. by clustering EA approaches based on EA goals, enterprise size, enterprise structure, etc. Based on an appropriate scenario model, the recommendation of reference structures and reference processes for EA could then be refined by scenario-specific configuration.
AUTHOR BIOGRAPHIES
Dr. Robert Winter is full professor of information systems at the University of St. Gallen (HSG), director of HSG's Institute of Information Management and academic director of HSG's Executive Master of Business Engineering program. He received master's degrees in business administration and business education as well as a doctorate in social sciences from Goethe University, Frankfurt, Germany. After eleven years as a researcher and deputy chair in information systems, he was appointed chair of information management at HSG in 1996. His research interests include business engineering methods and models, information systems architectures / architecture management, and integration technologies / integration management.
Ronny Fischer is a research assistant and doctoral student at the University of St. Gallen (HSG). He holds a master's degree in business administration and information systems (concentration in financial analysis, application systems, and operations research) from the University of Leipzig, Germany. His research interests include enterprise architecture modeling, enterprise architecture management, and IT/business alignment. He has been a
project manager of bilateral projects with industry partners conducting applied research in the areas of process modeling, enterprise architecture modeling and enterprise architecture management. Mr. Fischer is currently writing his doctoral thesis on enterprise architecture management.
REMARK
This paper is an extended version of a paper previously presented at the First Workshop on Trends in Enterprise Architecture Research (TEAR 2006) within the Tenth IEEE International EDOC Enterprise Computing Conference (EDOC 2006), Hong Kong, China, 16 October 2006.
REFERENCES
Braun, C. and Winter, R. (2005). A Comprehensive Enterprise Architecture Metamodel and Its Implementation Using a Metamodeling Platform, G I-Edition Lecture Notes in Informatics (LNI), Enterprise Modelling and Information Systems Architectures, Proc. of the Workshop in Klagenfurt, Klagenfurt,
24.10.2005, P-75, pp. 64-79.
CIO-Council (1999). Federal Enterprise Architecture Framework, Version 1.1.
CIO-Council (2001). A Practical Guide to Federal Enterprise Architecture.
Davenport, T. H. (1993). Process Innovation- Reegineering Work through Information Technology, Harvard Business School Press, Boston.
Douglas, K. B. (2003). Web Services and Service-Oriented Architecture: Your Road Map to Emerging IT, Morgan Kaufmann Publishers, Hamel, G. and Prahalad, C. K. (1990). The Core Competence of the Corporation, in:
Harvard Business Review, 68, No.3, pp. 79-91.
Hedman, J. and Kalling, T. (2003). The business model concept: theoretical underpinnings and empirical illustrations, in: European Journal of Information Systems, 12, No.1, pp. 49-59.
IBM (1984). Business Systems Planning - Information Systems Planning Guide, 4th ed.
Ed., Atlanta.
IDS Scheer (2005). Enterprise Architectures and ARIS Process Platform, Saarbrucken.
IEEE (2000). IEEE Recommended Practice for Architectural Description of Software Intensive Systems (IEEE Std 1471-2000), IEEE Computer Society, New York, NY.
Kuhlin, B. and Thielmann, H., eds. (2005). The Practical Real-Time Enterprise: Facts and Perspectives, Springer Verlag,
Linthicum, D. S. (2000). Enterprise Application Integration, AWL Direct Sales, Reading, Massachusetts.
Mesarovic, M. D., Macko, D. and Takahara, Y.
(1970). Theory of Hierarchical, Multilevel Systems, Academic Press, New York, London.
Opengroup (2003). TOGAF "Enterprise Edition"
Version 8.1,
http://www.opengroup.org/architecture/togaf8- doc/arch/, last accessed on 27.11.2004.
Osterle, H. (1995). Business in the Information Age - Heading for New Processes, Springer, New York.
Porter, M. E. (1998). Competitive Advantage:
creating and sustaining superior performance, 2nd ed. Ed., Free Press, New York.
Scheer, A.-W. (1999). ARIS - Business Process Frameworks, 3rd Ed., Springer, Berlin et al.
Schekkerman, J. (2004). How to Survive in the Jungle of Enterprise Architecture Frameworks:
Creating or Choosing an Enterprise Architecture Framework, 2nd Ed., Trafford Publishing, Victoria, British Columbia.
Sowa, J. F. and Zachman, J. A. (1992).
Extending and Formalizing the Framework for Information Systems Architecture, in: IBM Systems Journal, 31, No.3, pp. 590-616.
Tang, A., Han, J. and Chen, P. (2004). A Comparative Analysis of Architecture
Frameworks, SUTIT-TR2004.01, Swinbourne University of Technology, Swinbourne.
Weill, P. and Vitale, M. R. (2001). Place to Space: Migrating to eBusiness Models, Harvard Business School Press, Boston, MA.
alEA
JOURNAL
Presenting a Theory-Based Model for IT Management Responsibilities
By
Magnus Gammelgard, Marten Simonsson, and Asa LindstromABSTRACT
Enterprise architecture is al/ about the IT systems, the IT organization, and how they provide value to the business. Nonetheless, the complex relations within this trinity have previously been overlooked in literature. The herein proposed reference model for IT management responsibilities therefore aims at explaining how IT organizations and IT systems serve as value enablers to the business, thus clarifying the boundaries of IT management's responsibilities. The model is based on extensive literature studies and has been tested in a series of empirical studies.
KEYWORDS
IT management responsibilities, IT systems, IT organization, business value, IT governance, enterprise architecture
INTRODUCTION
The business organization is taking a greater and greater interest in decisions on issues that affect or is affected by the information technology (IT) systems and the IT organization.
The background is of course an increased understanding for IT as a value enabler for the business. In the same way, changes made to IT and how such are managed will also affect the business. There is a broad range of issues that need to be managed to ensure IT's value delivery.
A number of models for the responsibilities of IT management have been published, e.g. Nolan's Stage Theory, described e.g. by (Renken 2004).
Feeny and Willcocks (Feeny and Willcocks 1998) focus on the capabilities of the IT organization with their nine core IS capabilities.
The recent Val IT framework provides high level supporting practices to assist executive management in understanding and carrying out their roles related to IT investments (IT Governance Institute 2006). These models have a strong IT organization focus, but they lack support for the overarching relation between IT systems, the IT organization, and the value delivered to the business. The Balanced Scorecard® approach, originally proposed by
(Kaplan and Norton 1996), has successfully been used for performance management in organizations, and Van Grembergen among others has illustrated applications to IT (Van Grembergen et al 2004). However, how the business value is related to the specific characteristics of the systems is not taken into account.
Addressing this lack of business value traceability from IT, this paper presents a model for IT management responsibilities. These comprise i) the IT systems, Le. the soft- and hardware including communicational infrastructure, and ii) the parts of the organization set to manage and develop the systems, Le. the IT organization (see Figure 1).
The IT organization and the IT systems cannot be studied in isolation; and the value delivered to the business organization has accordingly been included in the model. Even though this paper focuses on the theoretical parts of the model, its use has also been successfully verified in empirical studies. (See e.g., Lindstrom 2006; Gammelgard 2007).
Figure 1 on the next page shows the division of IT management responsibilities and how value is provided to the business organization as proposed in this paper.
