Journal of Enterprise Architecturelibrary.nic.in/e-journalNew/JEAMagazines/JEA_2011-2.pdfFEATURES...

FEATURES

Editor’s Corner: John Gøtze

Architect’s Spotlight: Adrian Apthorp

ARTICLES

Governance of Enterprise Transformation and the Different Faces of Enterprise Architecture Management by Daniel Simon

Delivering Business Value Through Enterprise Architecture by Toomas Tamm, Peter B. Seddon, Graeme Shanks, and Peter Reynolds

Context-Awareness in Collaboration Architecture: A Conceptual Model for an Enterprise by Abhijit Sur

Evaluating the Effectiveness of Reference Models in Federating Enterprise Architectures by Jeffery A. Wilson, Thomas Mazzuchi, and Shahram Sarkani

EA Heavy and EA Light: Two Examples of Successful Enterprise Architecture by Inji Wijegunaratne, Peter Evans-Greenwood, and George Fernandez

SHORTER ARTICLES

―The business‖ does not exist! Why Enterprise Architecture is often a mission impossible by Piet Jan Baarda

Streamlining IT Application Selection and Integration with a Standard Modeling Language by Iver Band

BOOK REVIEWS

121 Things I Learned in Architecture School (Matthew Frederick) 121 Things I Learned in Business School (Michael W. Preis with Matthew Frederick) Reviews by Len Fehskens

IT Architecture: Essential Practice for IT Business Solutions (Beijer, Peter & Theo de Klerk) Review by Len Fehskens

May 2011, Volume 7, Number 2

Journal of

Enterprise Architecture

www.aeajournal.org

2 © Journal of Enterprise Architecture – May 2011

Journal of Enterprise Architecture

Chief Editor: John Gøtze, PhD, IT University of Copenhagen

Associate Editors

Andy Blumenthal CTO, Bureau of Alcohol, Tobacco, Firearms and Explosives

William W. Krauter, PhD Senior Architect, Lockheed Martin Corporation

Tyson Brooks, PMP School of Information Studies, Syracuse University

Haiping Luo, PhD International Trade Administration, US Dept. of Commerce

Dick Burk Enterprise Architect

Stephen Marley, PhD Harris Corporation

Brian Cameron Professor & Executive Director, Center for EA, PA State University

Thomas J. Mowbray, PhD TASC, Inc.

Larry DeBoever assureEV

George Paras Managing Director, EADirections

Gary Doucet Treasury Board Secretariat, Government of Canada

Pallab Saha, PhD Professor of Information Systems, National University of Singapore

Robert Ellinger, PhD Northrop Grumman Corporation

Cathy Sowell President, Custom Enterprise Solutions, LLC

Len Fehskens VP, Skills and Capabilities, The Open Group

Torben Tambo Associate Professor, Aarhus University Institute of Business & Technology

John Grasso, PhD School of Computer Science, Carnegie Mellon University

Michael Tiemann Enterprise Architecture Consultant

Kristian Hjort-Madsen, PhD Manager, Accenture

Pat Turner Director, Centre for EA & Research Management, Griffith University

Michelle Kaarst-Brown, PhD Associate Professor, Information Studies, Syracuse University

Tim Westbrock Managing Director, EADirections

Leon Kappelman, PhD College of Business, University of North Texas

John Zachman ZIFA International

About the Journal: The Journal of Enterprise Architecture (JEA) is a peer-reviewed international quarterly publication for the

enterprise architecture community. Issues are published in February, April, August, and November each year. JEA supports global academic and practitioner communities of interest through the publication of articles that promote the profession of enterprise architecture, and deals with issues regarding practices and methods, case studies, and standards at the national and international levels. Note that the views expressed in JEA articles are those of the respective authors, and not necessarily those of the publisher, the editorial board, or the Association of Open Group Enterprise Architects (AOGEA).

Sponsors: JEA is sponsored by AOGEA (publisher), the Institute for Software Research International at Carnegie Mellon University,

and the School of Information Studies at Syracuse University.

Copyright: All rights reserved. The reproduction, storage, or transmission of JEA articles or other content is prohibited without prior

permission in writing from the JEA Chief Editor, who can be contacted via email at [email protected].

Article Submissions: Authors may submit properly formatted manuscripts to the JEA Chief Editor at [email protected] for peer-

review and publication consideration. Author submission guidelines are available on the Journal website at www.aeajournal.org. Approximate timeframes from submission to publication for successful manuscripts are 6 to 12 months, depending on the backlog of previously accepted manuscripts. Copyright of all accepted articles and other published content is transferred by the author to JEA upon notification of acceptance by the JEA Chief Editor.

Associate Membership: The cost of AOGEA associate membership is $70.00/£40.00/€60.00. To join, please refer to https://www.aogea.org/membership/JoinMember.

Back Issues: All back issues are available in electronic form, and can be accessed online by subscribers. Libraries can apply for

access by contacting AOGEA.

AOGEA Membership: Membership in AOGEA is automatically obtained and maintained through subscription to JEA. Each subscriber

is assigned to the AOGEA Chapter that is nearest to that member, or to the global ―At-Large Chapter‖. Selection of AOGEA Chapter affiliation is made by the subscriber/member as part of the initial subscription and annual renewal process, done online at www.aeajournal.org.

mailto:[email protected]


http://www.aeajournal.org/

https://www.aogea.org/membership/JoinMember


© Journal of Enterprise Architecture – May 2011 3

Contents Editor’s Corner ....................................................................................................................................................................... 4

Architect in the Spotlight ........................................................................................................................................................ 5

Governance of Enterprise Transformation and the Different Faces of Enterprise Architecture Management ...................... 8

Delivering Business Value Through Enterprise Architecture ............................................................................................... 17

Context-Awareness in Collaboration Architecture: A Conceptual Model for an Enterprise ................................................. 32

Evaluating the Effectiveness of Reference Models in Federating Enterprise Architectures ................................................ 40

EA Heavy and EA Light: Two Examples of Successful Enterprise Architecture ................................................................. 50

―The business‖ does not exist! Why Enterprise Architecture is often a mission impossible ................................................ 65

Streamlining IT Application Selection and Integration with a Standard Modeling Language .............................................. 70

121 Things I Learned in Business Architecture School? ..................................................................................................... 72

IT Architecture: Essential Practice for IT Business Solutions .............................................................................................. 73


Editor’s Corner

By John Gøtze Welcome to the May 2011 issue of the Journal of Enterprise Architecture.

This number’s Architect in the Spotlight is Adrian Apthorp, who is one of the most inspiring enterprise architects I have the pleasure of knowing. Adrian is Head of EA for DHL Express Europe.

The articles in this number cover a wide range of contemporary and emerging issues in our discipline.

Daniel Simon distinguishes between four general modes of architectural transformation governance and presents the different faces of enterprise architecture management prevalent in these modes.

Toomas Tamm, Peter B. Seddon, Graeme Shanks, and Peter Reynolds aim to take a step towards improving the understanding of the value of enterprise architecture by focusing on how it leads to organizational benefits, and present an EA Benefits Model.

Jeffery A. Wilson, Thomas Mazzuchi, and Shahram Sarkani investigate reference models to federate enterprise architectures across multiple agencies and argue that agencies must align their component architectures to the common taxonomy provided by the reference models.

Abhijit Sur discusses the role of context-awareness within a collaboration framework, and presents a technical framework and four architecture principles that would enable a collaboration platform to be context-aware.

Inji Wijegunaratne, Peter Evans-Greenwood, and George Fernandez present two very different, successful enterprise architecture projects, described as EA Heavy and EA Light, that managed to deliver and demonstrate tangible benefits to the respective organizations.

Shorter Articles is our new section with, well, shorter articles, opinions. In his half-short article, Piet Jan Baard argues that ―the business‖ does not exist, and in his short article, Iver Band suggests application vendors and developers adapt ArchiMate

®.

Last, but not least, Len Fehskens presents two book reviews, of three books. As always, Len's reviews are sharp and informative.

Regular readers will notice we do not have a regular case story in this issue. That is because we didn’t get any case submissions. I blame all the non-disclosure agreements we all have to live with. Yet, I know there are so many stories and experiences out there. The irony is that sharing the stories and experiences often become good branding in a world where transparency and openness is increasingly valued by decision-makers.

So I dare you all to share your enterprise architecture stories and experiences! You can reach me on [email protected].

ABOUT THE EDITOR

Dr. John Gøtze is program manager at the IT University of Copenhagen and lecturer at Copenhagen Business School. He is also a partner in EA Fellows, and runs Carnegie Mellon University’s EA Certification program in Europe.



Architect in the Spotlight

Adrian Apthorp I am currently the European Head of Enterprise Architecture at DHL Express having served in a number of regional and global architecture roles with DHL over the last 22 years. Before moving into architecture I worked in IT development and support. Progressively over the years I have moved further away from the physical circuits and electrons I studied at university (I studied electrical and electronic engineering). As a sponsored student with Marconi Radar I was debugging multi-layer circuit boards. However, as an MIET and Chartered Engineer I have retained some of these roots and try to bring general engineering principles to enterprise architecture.

Originally from the UK I am now somewhat of a world citizen having lived and worked in Singapore (I married a Singaporean), Brussels, Prague, and now Germany. When I get the opportunity I enjoy sailing; there must be a connection in navigating the waters, the globe, and the enterprise.

HOW DID YOU BECOME INVOLVED WITH ENTERPRISE ARCHITECTURE?

This was really through a number of chance circumstances starting with my first DHL interview. The interview was with Nigel Green (co-author of Lost in Translation and VPEC-T) who even though he didn’t have a role for me thought I was worth having around and persuaded one of his colleagues to hire me.

Then my first significant project after joining DHL was to integrate and manage the initial deployments of our internal message broker (before third-party products were available) in Singapore and Japan. This is deployed globally and still today is the IT backbone of the Express business. Apart from the exposure to working with different cultures this also gave me insights into the significance of aligning business process and semantics to ensure information systems integration in highly distributed systems.

An internal white paper that I wrote based on what I'd learnt (describing how to use formal methods to configure the routing of messages) got noticed and I was co-opted for a global IT strategy initiative.

This series of events really set me on the road through a variety of architecture roles to eventually become the first global Enterprise Architect for DHL.

WHAT IS THE GREATEST CHALLENGE FACING ENTERPRISE ARCHITECTURE TODAY?

I think the challenge is really the same one that has been facing enterprise architecture for a long time. Enterprise architecture has somewhat of an identity crisis. Much of this comes from the label and others’ perception of enterprise architecture and the space in which many enterprise architectures find themselves. Architecture seems to equate to technical in many people's minds and although ―enterprise‖ should imply a whole enterprise perspective many enterprise architectures operate only in the world of IT.

Also as a relatively young discipline I have come to wonder if enterprise architecture is really a separate discipline or a set of tools for the management toolkit. I certainly hold to the view that if enterprise architecture is about the architecture of the enterprise then it needs to be embedded in it and applied by more than a specialist team of architects.

In conclusion I wouldn't be surprised if enterprise architecture morphs and splits off in different directions in the future. We're already seeing this with the focus on Business Architecture in the last couple of years.

WHAT IS THE NEXT BIG THING IN ENTERPRISE ARCHITECTURE?

The fusion of enterprise architecture with other management practices is an exciting prospect. I see steps in this direction with, for example, the extensions of TOGAF to embrace program and project management. Indeed, traditionally enterprise architecture is discussed and gets applied for change management. However, for enterprise architecture to become truly embedded in the enterprise it has to become relevant in the other aspects of enterprise management; direction setting and operation of the enterprise. For example, how do our enterprise architecture models link to operational constructs, such as the chart of accounts, or to training materials?

Therefore, steps to develop synergies between the practices of these areas of management and enterprise architecture hold the key to really establishing the role of enterprise architecture.

One other area that I think holds some potential, and relates to this, is the development of enterprise architecture patterns and anti-patterns. For example, what patterns are employed to enable agility in an enterprise?


WHAT IS IT LIKE BEING A HEAD OF ENTERPRISE ARCHITECTURE?

It's a balancing act.

First, as senior professionals we have a management responsibility to discharge and indeed need to operate within the governance structure of an organization in order to establish the enterprise architecture. On the other hand, as architects we have both a need and tendency to get embroiled in the content. It's very easy to get stuck into the content and forget the management devices required to establish and maintain the architecture.

Secondly, there is a need from both an experience and credibility point of view to engage in solution architecture. However, of course this needs to be balanced by ensuring the enterprise architecture is in place and being kept up-to-date.

WHAT WAS YOUR FAVORITE ENTERPRISE ARCHITECTURE EXPERIENCE?

Actually two:

1. Standing up in front of your CEO describing how an enterprise architecture approach (with linkages from product definition to business capabilities, processes, and how they are realized with business design and IT infrastructure, etc.) is being used to shape and plan a major change program, and being told that is absolutely the right way to go about it.

2. Seeing key enterprise architecture tools being adopted by others in the organization to communicate and plan. In particular, I'm thinking of our Business Domain Model (capability map).

WHAT WAS A LEAST FAVORITE ENTERPRISE ARCHITECTURE EXPERIENCE?

Have you ever seen that cartoon of battle being fought with knights and swords? Behind a tent is an inventor with a machine gun. The king is saying: ―tell him to come back later, I have battle to win‖. How many of us have felt like that inventor from time to time?

Because of the unique vantage point of an enterprise architect we often think that we have the answers, if only we could get them across. Often times though you have to accept that the only way to do that is for the organization to learn and your role is best played in providing signposts, not the answer.

WHAT WOULD YOU SAY TO SOMEONE CONSIDERING MAKING ENTERPRISE ARCHITECTURE THEIR CAREER AREA? (AND TO SOMEONE HAVING AN ENTERPRISE ARCHITECTURE CAREER?)

Communicate, communicate, communicate. Enterprise architecture has its own unique vernacular, but we need to communicate with our stakeholders in the language they understand, not the language of ―artifacts‖.

Indeed, one of the roles of an enterprise architect is as a translator:

Between the language of business, information, and technology

Between high-level management decisions and concrete design decisions

Between a vision and the concrete actions to realize it

This section aims to bring recognition to a variety of contributors to the enterprise architecture field – from early pioneers, to current practitioners beginning their careers, to experts from other fields that influence enterprise architecture – and is intended to show the rich diversity of backgrounds and views that the enterprise architecture community enjoys.


Visit the JEA website at www.aeajournal.org

Call for Papers The Journal of Enterprise Architecture is accepting article submissions for its future issues.

Research and best practice articles are sought on enterprise architecture-related topics, including:

Case Studies, Configuration Management, Culture, Documentation

Evaluation, Frameworks, Governance, Implementation, Maintenance

Methodologies, Taxonomies, Theory, Training, Tools, Use, Value

The annual cycle includes four numbers. Deadlines for final submissions are three months prior to publication:

Issue Due Date

February November 1

May February 1

August May 1

November August 1

Please send articles to the JEA Editor at [email protected].

Author submission guidelines can be found on the JEA website at www.aeajournal.org.





Article

Governance of Enterprise Transformation and the Different Faces of Enterprise Architecture Management

By Daniel Simon

Abstract

Today, enterprises more than ever find themselves confronted with a constant need to transform themselves to better cope with current pressures and to prepare for future opportunities and challenges. Enterprise architecture management plays a crucial role in that context. It may not only aid in shaping the future enterprise, but it may also facilitate subsequent transformation governance. Based on the perception of enterprise architecture management as both a strategic and an operational exercise, this article distinguishes between four general modes of architectural transformation governance and presents the different faces of enterprise architecture management prevalent in these modes. In particular, this involves solution architecture, roadmapping, and business architecture activities.

Keywords

Enterprise Architecture, Enterprise Architecture Management, Enterprise Transformation, Business Transformation, Architecture Governance, Business Architecture, Roadmapping, Solution Architecture, Standards Management

INTRODUCTION

According to Friedman (2005):

‖… every morning in Africa, a gazelle wakes up. It knows it must run faster than the fastest lion or it will be killed. Every morning a lion wakes up. It knows it must outrun the slowest gazelle or it will starve to death. It doesn’t matter whether you are a lion or a gazelle. When the sun comes up, you’d better be running.‖

Translated to the business world, it is this environment that many enterprises have found themselves being part of and that speaks to the ever-present necessity to transform. Such a transformation, however, needs to be thoroughly planned and governed (Buckl et al 2009; Schmidt 2009).

During the past years, enterprise architecture has become widely acknowledged as a significant facilitator of systematic decision-making (Kappelman et al 2008). In short, an enterprise architecture is a structured and aligned collection of plans for the integrated representation of the business and IT landscape of the enterprise, in past, current, and future states (Niemann 2008). As such, enterprise architecture can be used as the guiding framework for enterprise transformation (Schekkerman 2004; Simon 2009b). As for the final transformation execution, however, there are different governance approaches that can be taken, each of which has a certain level of strategic and operational quality.

Having said this, this article suggests four general modes of architectural transformation governance and sheds light on the different faces of enterprise

architecture management prevalent in these contexts: solution architecting, roadmapping, and business architecting. This will be based on an integrated view of enterprise transformation and enterprise architecture management, which is constructed according to the design science paradigm (Hevner 2004). In particular, this approach assimilates experiences from various project assignments and previous research alike and extends the latter in that it puts key architectural activities into the context of enterprise transformation. A central aspect of this is the division of enterprise architecture management into strategic and operational architecture management, as to be introduced in the following section.

CONCEPTUAL FOUNDATION: TRANSFORMATION IN THE LIGHT OF ENTERPRISE ARCHITECTURE MANAGEMENT

In simple words, the process of enterprise transformation can be structured based on a picture approach; i.e., capturing the current enterprise in the form of an as-is picture, then designing a to-be picture based on that, and finally implementing this to-be picture and thereby making this picture the new reality. This is in line with three major goals of enterprise architecture initiatives (Fischer et al 2007):

Documentation and communication of the as-is architecture

Support for the design of the to-be architecture

Support for projects that transform as-is into to-be architectures


To that end, enterprise architecture management captures all those processes, methods, tools, and responsibilities that are necessary to build a holistic and integrated view of the enterprise and to allow for a continually aligned steering of business and IT (Niemann 2008; Matthes et al 2008). As such, enterprise architecture management deals with different architectural layers. In particular, these include business architecture, information architecture, application architecture, and technology architecture (The Open Group 2009). Across these layers, enterprise architecture management is of both strategic and operational nature (Niemann 2008). Strategic architecture management concentrates on the documentation, analysis, and planning of whole architectural landscapes and is therefore typically associated with processes such as application portfolio management. In contrast, operational architecture management implements decisions made in the strategic process. It is thus done at the project level, where specific architectural solutions are designed. Against this background, both strategic and operational architecture management may act as facilitators of enterprise transformation.

Within the process of enterprise transformation, governance aspects become particularly relevant when it comes to the translation of the designed to-be picture into reality (see Figure 1). In general, transformation governance relates to formal and informal arrangements, mechanisms, and processes used to coordinate and monitor the transformation process at different levels of granularity (Albers 2010). In particular, the actual transformation needs to be carried out in accordance with the designed to-be picture and to be spread throughout the enterprise in spite of any potential resistance. This is where enterprise architecture management may play a crucial role. There are different approaches to architectural governance though, which can be taken. Essentially, this is based on the degree of strategic and operational architecture management involved. The application of operational architecture management, on the one hand, may be the appropriate means to assure that specific architectural solutions are designed and implemented according to the specified transformation requirements. Strategic architecture management, on the other hand, addresses the ―big picture‖ and may support the governance of the transformation initiative as a whole.

ENTERPRISE ARCHITECTURE GOVERNANCE MODES OF ENTERPRISE TRANSFORMATION

With the conceptual foundation for enterprise architecture-based transformation governance being set, four general governance modes can be distinguished (see Figure 2). These modes reflect the relevance of strategic and operational architecture management

within transformation governance. In other words, they indicate a quality of architectural support in transformation governance, on both a strategic and an operational level. Given these two dimensions, the resulting modes include contracting, on the one hand, and the ―active‖ approaches of operational guidance, strategic direction, and enterprise alignment (as the one combining strategic and operational attributes), on the other hand.

Figure 1: Governance within Enterprise Transformation (adopted from Simon 2009b)

Figure 2: Enterprise Architecture Governance Modes

The “Contract” Mode

A low quality of both strategic and operational architecture management within the process of enterprise transformation is where governance may primarily make use of contracts to capture relevant architectural requirements, principles, and standards that individual solution projects need to consider. Using

As-Is EnterpriseAs-Is Enterprise

Transformation Governance

To-Be EnterpriseTo-Be Enterprise

As-Is

Picture

To-Be

Picture

Align

Qu

ali

tyo

f S

tra

teg

icA

rch

itec

ture

Ma

na

gem

en

t in

Tra

ns

form

ati

on

Go

ve

rna

nce H

igh

Lo

w

HighLow

Quality of Operational Architecture

Management in Transformation Governance

Direct

GuideContract


architecture contracts as an instrument to govern implementation activities is particularly promoted by TOGAF

® (The Open Group 2009), considering

architecture contracts as ―joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture‖. It primarily draws a distinction between architecture design and development contracts (i.e., contract between architecture design and development partners), on the one hand, and business users’ architecture contracts (i.e., contract between architecting function and business users), on the other hand. According to TOGAF (The Open Group 2009), a governed approach to the management of contracts ensures a system of continuous monitoring of architecture-related activities in the organization.

As such, contracting may act as a reasonable governance approach within individual transformation projects of rather low architectural relevance. The fundamental drawback, however, is that in critical situations time and budget (as provided by the project sponsor) may be given preference to the disadvantage of specific architectural requirements set in such a contract. Furthermore, in cases of high architectural relevance, on the one hand, and a complex and dynamic project environment, on the other hand, closer support may be required to overcome these challenges and gain the necessary acceptance within such projects.

The “Guide” Mode

Higher architectural relevance and challenges as those described above represent a typical setting where the governance mode of guidance finds particular advantages. This is characterized by a high involvement of operational architecture management within the process of enterprise transformation. Thereby, transformation projects are provided with dedicated design and implementation support by the enterprise architecture function (Harmsen et al 2009). In fact, solution architects may guide the projects through a structured solution architecture process and thus provide detailed design guidance, or at least participate in regular architectural reviews and offer recommendations for further work to stay aligned with what has been defined in the to-be picture and, in particular, with any standards set.

The main benefits of applying this governance mode and making use of systematic solution architecture guidance, which incorporates aspects of standards management (as the practice of defining, maintaining, communicating, and monitoring the appropriate use of architectural standards), clearly are that it helps overcoming the main issues associated with the ―contract‖ mode (Slot et al 2009). However, it is restricted to single projects and

does not allow transformation governance on a wider scale; i.e., the direction of a portfolio of projects towards the envisioned to-be state.

The “Direct” Mode

As opposed to governance modes on the solution project level, the mode of direction provides systematic support for a whole set of projects. This includes the assurance of the mutual alignment of the transformation projects, the continual re-prioritization of transformation efforts, the management of corresponding dependencies, and the holistic management of implementation activities towards the achievement of the overall to-be state. Therefore, this governance mode does not involve operational support but draws upon aspects of strategic architecture management. Roadmapping is considered to be the main constituent in that context (Simon 2009b).

This governance mode, however, may be subject to the ―ivory tower‖ phenomenon (van der Raadt et al 2008); i.e., the enterprise architecture function may not be perceived of value since it does not actively participate in projects that actually deliver change. This may of course jeopardize the acceptance of architectural transformation governance. All-in-all, this may result in a need of a governance mode combining strategic and operational aspects and further addressing the continuous, sustainable, and enterprise-wide aspect of transformation governance.

The “Align” Mode

Given a significant transformation governance role of both strategic and operational architecture management, the mode of alignment may be considered the most challenging, but also the most promising and sophisticated one. This is due to the fact that it combines several faces of enterprise architecture management, including the solution architecture and the roadmapping faces. Most importantly, however, there is the business architecture face, which is supposed to serve as an instrument to keep overall control of the enterprise transformation from strategy into action (Ross et al 2006). In fact, business architecture models that address not only procedural and organizational but also strategic aspects may be used to inject changes into the corporate culture, to better cope with new requirements and to continuously drive and align the enterprise towards the key objectives and the developed target state (Aier et al 2008a), on both a strategic and an operational level. Specifically, they allow change requests to be evaluated against the target business model, and decisions to be made with the necessary alignment and accountability. Further, the defined fundamentals of the business can be properly


communicated and made understandable, which helps to assure that everyone moves in the same direction.

As already indicated above, enterprise transformation thus takes place on different levels (Harmsen et al 2009); i.e., on the project level, on a portfolio level, and on the overall enterprise level. Accordingly, architectural transformation governance may also span these levels, with different faces of enterprise architecture management being involved. These faces constitute the nature of transformation governance; i.e., its strategic and operational nature (see Figure 3). While solution architecture activities represent a form of operational governance, roadmapping can be considered as an instrument of strategic governance. Business architecture management embodies both strategic and operational governance aspects. These different architectural faces outlined are depicted in greater detail in the following sections.

Figure 3: Enterprise Architecture Faces in Strategic and Operational Governance

LEAVING THE IVORY TOWER: ON THE IMPORTANCE OF SOLUTION ARCHITECTING

Reducing itself to work within the ―ivory tower‖ only may be considered as one of the main reasons of failure of any enterprise architecture practice (van der Raadt et al 2008). To really bridge the gap from strategy to action and to provide transformation governance where actual implementation activities take place, it is advisable to be involved deeply at the operational level; i.e., in solution projects delivering change to the enterprise. It is there where solution architects as part of the enterprise architecture function take on a vital role (Slot et al 2009).

Solution architects are supposed to support the architectural solution design and implementation on behalf of the enterprise architecture function, thereby assuring the compliance with architectural principles. This support can have different forms, from few or regular reviews to ongoing guidance within a systematic solution architecture process that stretches across the identification of the functional scope and requirements of architectural design, the development and evaluation of architectural solution scenarios, the documentation of the architectural solution, the actual implementation, and, finally, harvesting gained experiences during implementation and the initial phase of operations.

There are different mechanisms for assuring the compliance with architectural principles. On the one

hand, architects may have veto rights over designed solutions or may at least impose budgetary obligations on projects that do not sufficiently meet the identified architectural requirements and that do not provide reasonable justifications for any deviations. On the other hand, projects may also be incentivized by promising financial rewards for conforming designs (Buckl et al 2010). In case of lacking communication and advice prior to any review activities, however, architects may fail in gaining the necessary acceptance and may be stuck in the perception of being ―black sheriffs‖, who inquire into conformity without adequately specified and communicated standards (Niemann 2008). Getting back to the notion of guidance, the existence of solution architects without proper engagement in projects may not significantly contribute to overcoming the ―ivory tower‖ phenomenon. Instead, a ―proactive‖ advisory approach is required. First and foremost, this applies to the standards management part of solution architecting (Boh & Yellin 2006; Schmidt 2009), embodied either by the solution architect itself or by a separate reference architect or standards manager (Buckl et al 2010).

In development projects of architectural relevance, standards management should play a key role (Simon 2009a). That is because it answers questions like: What are the standard components available? What principles do I have to adhere to? Which reference architectures may suit my needs? A properly categorized and communicated portfolio of standards can serve as the basis for answering these questions. This standards portfolio (act! 2010c) may encompass various architectural layers (Winter & Fischer 2007); e.g., business architecture, application architecture, and infrastructure architecture, in all of which different types of standards can be defined (see Figure 4):

Building Blocks: Fundamental architectural objects; e.g., technical components, business activities

Patterns: Valid combinations of building blocks; e.g., platforms, reference architectures

Methodologies: Methodological descriptions and guidelines to be applied

Directives: Principles, rules, and general guidelines that are to be adhered to

Despite communication, advice, and assistance within the process of architectural design, the selected architectural solution may eventually not comply with defined standards. During architectural reviews, enterprise architecture management is therefore asked to evaluate how to deal with any non-compliance. In fact, one has to determine whether a deviation from a standard is reasonable and should be accepted as an exception (at least temporally), or whether corrective action needs to be taken to create a new architectural

Roadmapping

Solution Architecture

Strategic

Governance

Operational

Governance

Business

Architecture


design. To sum up, solution architecting is a means of guiding individual transformation projects towards the defined goals.

Figure 4: Standards Portfolio – A High-Level Structure (adopted from Simon, 2009a)

ROADMAPPING AS A FACILITATOR OF SYSTEMATIC CHANGE

In order to not only govern transformation at the project level, but to also provide systematic direction for a program or even portfolio of projects contributing to an overarching transformation goal, enterprise architecture management may provide substantial assistance by applying roadmapping mechanisms. Roadmaps (Buckl et al 2009) come into play as soon as the enterprise architecture planning process has determined a target scenario to be implemented, identified gaps with respect to the current state, and adequately grouped and translated them into projects. Based on that, roadmaps typically define the project deliverables necessary to implement the target scenario, set up a corresponding time schedule, and define planned states as intermediate steps towards the target state.

The establishment and maintenance of this time schedule is subject to a set of contingency factors (Simon 2009b; Simon et al 2010) that may have a significant impact on the approach to roadmapping and on the design of the final roadmap:

Internal dependencies: Projects in the roadmap may have dependencies with one another; e.g., the start of project B may require the completion of project A, and project C may conflict with project D.

External dependencies: Projects in the roadmap may also have dependencies with other projects not in scope of the transformation initiative. They may also be subject to uncertainties regarding technological and regulatory developments and may thus need to be postponed.

Agility requirements: A high degree of required agility may result in a higher prioritization of projects that increase standardization and are therefore able to improve the time-to-market.

Project decidability: Often only a minor part of the budget is assigned to investments going beyond housekeeping (Niemann 2005; Niemann 2006). That is why one may differentiate between mandatory and ―lights-on‖ projects (Simon et al 2010), both of which are non-decidable, and innovation projects, which are decidable. In case of time pressure, non-decidable projects may find themselves prioritized.

Benefit expectation: Based on cultural values and market requirements, there may be enterprise-specific expectations with respect to benefit realization. This may have a significant impact on the importance of quick wins and the significance of corresponding projects.

Resistance to change: Quick wins are to be taken into account due to another reason. Enterprise transformation is likely to be subject to internal resistance to change. Projects delivering quick wins can demonstrate immediate value and mitigate the risk of transformation failure.

Competitive strategy: A factor of particular importance is the competitive strategy. In case this entails a strong need for differentiation; for example, projects related to distinctive business processes are likely to be attributed with higher priority.

Risk aversion: A project’s size and the amount of changes implemented through it are among the main determinants of its complexity. The more risk aversion the enterprise embodies, the less complex projects tend to be, for example.

Budget & resource availability: Of course, also budget and resource availability at a certain point in time are likely to have an impact on how complex projects are and on when they are to be carried out.

In consideration of these contingency factors and based on the relationships captured within the enterprise architecture, architectural roadmaps help to govern the transformation portfolio as a whole and to synchronize it with further project activities within the enterprise (Fischer et al 2005). This can also be broken down to individual application systems affected by the transformation using so-called evolution fact sheets (act! 2010a), describing the evolution of individual application systems along the different stages of the defined roadmap. The highest level of quality and, most importantly, sustainability of architectural transformation

• Infrastructure principle

• Infrastructure rule

• Deployment

method

• Operational guidelines

• Architecture

development method

• Application principle

• Application rule

• Test method

• Software engineering

method

• Architecture

development method

• Business principle

• Business rule

• Process modeling

technique

• Architecture

development method

• Platforms

• Infra-

structure

compo-

nent

• Device

• Reference

archi-

tecture

• Library

• Frame-

work

• Application

building

block

• SOP

• Usage

scenario

• Job

description

• Process

component

• Reporting

path

Architecture Domain

Lifecycle

Standards

categories

Directives Methodologies

Business

Architecture

Application

Architecture

Infrastructure

Architecture

Patterns

Building

Blocks


governance, however, may only be reached by a thorough management of the business architecture.

BUSINESS ARCHITECTURE AS THE KEY FOR INJECTING SUSTAINABLE CHANGE INTO THE ENTERPRISE

A business architecture is a structured description of the business (Österle et al 2007; Riege et al 2008) containing the business strategy, the business model, and the business organization (act! 2010b):

Business strategy: The business strategy captures the strategic context of the business; i.e., mission, vision, goals/ objectives, strategies, principles, drivers, constraints, and risks. It explains why the business operates in a certain way.

Business model: The business model brings the high-level strategic concepts down to earth. In essence, it expresses the fundamental business logic and represents the entire system of delivering value to customers and earning profits from these activities. As such, it can be considered a blueprint of the business strategy (Osterwalder & Pigneur 2010). Thus, the value proposition, financial model, products/services, markets, and the whole architecture of value creation (e.g., business partners, customer interfaces, value chain configuration) are among the primary elements making up the business model.

Business organization: The business organization includes those elements that are necessary to execute the business model. In particular, this covers the business processes, the organizational structure, and the information entities, as well as their aggregation into business capabilities.

Unfortunately, enterprises often stop short of extending the notion of business architecture beyond the business organization to also include the business strategy and the business model (Aier et al 2008b; Schönherr 2008). Still, there seem to be many who perceive business architecture as the practice of documenting and analyzing business processes only (Griffith 2010). In search of any reasons for this, the ―lamp-post story‖ may provide the answer, describing a man searching for a lost object under a lamp-post in a dark night, although this object has been lost somewhere else where the light is worse. One may come to the conclusion that business architecture activities often center on business processes and organizational structures because these are the activities which architects are apparently familiar with and in which they have gained considerable experiences during the past years.

However, it is a structured description of the business strategy and the future business model that most likely serves as the key lever to inject sustainable change into the enterprise. In fact, it is only then that business architecture may unfold its real value. This potential also seems widely acknowledged by many IT professionals, whose perception is that business architecture is implemented only to a small extent of what they would really need (Leganza 2010). Providing structured views of the business, business architecture can be considered the governance cockpit of transformation. It facilitates communication and provides a common picture of the envisioned business (Aier et al 2008a; Winter 2003). Further, it takes greater alignment and accountability into decision-making by creating transparency of what are the fundamentals of the business (Winter & Fischer 2007) and of what are corresponding responsibilities. All-in-all, this may help to ensure following the defined transformation path.

Change requests can be challenged by asking how this would affect the business model and whether this conforms to the business model (Riege et al 2008). In addition, architecture principles can be used to effectively carry business objectives, strategies, and the overall business model into the organization, for example. Eventually, transformation projects can be assessed on a continual basis with respect to how they affect the enterprise’s business capabilities (Aier et al 2008a) – a term which has found itself increasingly discussed in both literature and practice (Brits et al 2007), though not properly and commonly defined and most often not sufficiently delimited from IT capabilities yet. In general, however, a business capability can be considered an enterprise’s ability to execute a defined and repeatable pattern of activities and produce a desired outcome (e.g., product, service). It is based on a specific set of business processes, organizational units, and information objects (act! 2010a). As such, business capabilities complement business strategy and model in extending traditional business architecture efforts that mainly focus on process engineering or organizational design activities. Business architecture can then be leveraged on a broader scale and may considerably advance architectural transformation governance.

SUMMARY AND CONCLUSION

In summary, enterprise architecture management offers several faces that may assist business and IT managers in coming to grips with enterprise transformation, allowing adequate governance on both a strategic and an operational level. These faces – i.e., solution architecting, roadmapping, and business architecting – find themselves represented to a different extent in four general modes of architectural transformation governance: Contract, Guide, Direct, and Align. For practitioners seeking specific architectural support in


transformation governance, these modes provide a means for identifying enterprise architecture management faces that need to be adopted. While operational guidance may require the implementation of a solution architecture process being facilitated by a set of tailored tools (checklists, templates, fact sheets), strategic direction is where roadmapping becomes a crucial issue. For overall alignment, there is a need for a comprehensive approach to business architecture management.

With that in mind, this article teaches us the benefits and restrictions of applying the identified modes and wearing the corresponding architectural faces respectively. All-in-all, governance may be significantly facilitated and empowered based on enterprise architecture management as a cornerstone of enterprise transformation. Central to this are business architecture models going beyond the documentation of business processes and organizational entities. It is this approach in which solution architecture and roadmapping activities are to be embedded to assure an approach to transformation governance that thoroughly integrates the different levels of enterprise transformation (project, portfolio, and enterprise level).

ABOUT THE AUTHOR

Daniel Simon ([email protected]) is a Senior Consultant with act! consulting, specializing in enterprise architecture management. In his role he supports international clients in establishing, optimizing, and performing enterprise architecture management. He holds a diploma degree in information systems from the University of Cologne, Germany, and is currently a PhD candidate with a research focus on enterprise architecture management. He is a member of The Open Group Association of Enterprise Architects (AOGEA) and is TOGAF 9 Certified.

REFERENCES

act!: Glossar A-B (2010a); available at www.act-consulting.de/ea-forum/glossar/a-b.

act!: Glossar G-I (2010b); available at www.act-consulting.de/ea-forum/glossar/g-i.

act!: Glossar Q-Z (2010c); available at www.act-consulting.de/ea-forum/glossar/q-z.

Aier S., Maletta F., Riege C., Stucki K., Frank A.: Aufbau und Einsatz der Geschäftsarchitektur bei der AXA Winterthur – Ein minimal invasiver Ansatz, Proceedings of DW2008: Synergien durch Integration und Informationslogistik (2008a).

Aier S., Riege C., Winter R: Unternehmensarchitektur – Literaturüberblick und Stand der Praxis, Wirtschaftsinformatik 50(4), pp292-304 (2008b).

Albers S.: Configurations of Alliance Governance Systems, Schmalenbach Business Review (62) (2010).

Boh W.F., Yellin D.: Using Enterprise Architecture Standards in Managing Information Technology, Journal of Management Information Systems, Vol. 23, No. 3 (2006).

Brits J., Botha G.H.K., Herselman M.E.: Conceptual Framework for Modeling Business Capabilities, Proceedings of the Informing Science and IT Education Joint Conference (2007).

Buckl S., Ernst A.M., Matthes F., Schweda C.M.: Visual Roadmaps for Managed Enterprise Architecture Evolution, Proceedings of the 1

st International Workshop on Enterprise

Architecture Challenges and Responses (WEACR 2009).

Buckl S., Dierl T., Matthes F., Schweda C.M.: A Modeling Language for Describing Enterprise Architecture Management Methods, Proceedings of Modellierung betrieblicher Informationssysteme (MobIS 2010).

Fischer F., Matthes F., Wittenburg A.: Improving IT Management at the BMW Group by Integrating Existing IT Management Processes, Proceedings of the 9

th IEEE

International EDOC Enterprise Computing Conference (2005).

Fischer R., Aier S., Winter R.: A Federated Approach to Enterprise Architecture Model Maintenance, Proceedings of 2

nd

the International Workshop on EMISA (2007).

Friedman T.L.: The World is Flat, Farrar, Straus & Giroux, New York (2005).

Griffith M.: Embracing the Actionable: Business Architecture, Architecture & Governance Magazine (6:2) (2010).

Harmsen F., Proper H.A., Kok N.: Informed Governance of Enterprise Transformations, Advances in Enterprise Engineering II, Lecture Notes in Business Information Processing, Vol. 28, pp155-180 (2009).

Hevner A., March T., Park J., Ram S.: Design Science in Information Systems Research, MIS Quarterly (28)1, pp75–105 (2004).

Kappelman L., McGinnis T., Pettite A., Salmans B., Sidorova A.: Enterprise Architecture: Charting the Territory for Academic Research, Proceedings of AMCIS (2008).

Leganza G.: Topic Overview: Information Architecture, Forrester Research (2010).

Matthes F, Buckl S., Leitel J., Schweda C.M.: Enterprise Architecture Management Tool Survey 2008, TU Munich, Chair for Informatics 19 (sebis), Germany (2008).

Niemann K.D.: From Enterprise Architecture to IT Governance: Elements of Effective IT Management, Vieweg+Teubner, Wiesbaden (2006).

Niemann K.D.: IT Governance and Enterprise Architecture – Impact of IT Cost Reduction on Innovation Power, Journal of Enterprise Architecture (1:1) (2005).


http://www.act-consulting.de/ea-forum/glossar/a-b/

http://www.act-consulting.de/ea-forum/glossar/g-i/

http://www.act-consulting.de/ea-forum/glossar/q-z/


Niemann K.D.: Enterprise Architecture Management and its Role in IT Governance and IT Investment Planning, Advances in Government Enterprise Architecture, Edited by Saha P. (2008).

Österle H., Winter R., Höning F., Kurpjuweit S., Osl P.: Business Engineering: Core-Business-Metamodell, WISU – Das Wirtschaftsstudium, Vol. 36, No. 2, pp191-194 (2007).

Osterwalder A., Pigneur Y.: Business Model Generation, Wiley, Hoboken, New Jersey (2010).

Riege C., Stutz M., Winter R.: Geschäftsanalyse im Kontext der Unternehmensarchitektur, HMD – Praxis der Wirtschaftsinformatik (262) (2008).

Ross J.W., Weill P., Robertson D.C.: Enterprise Architecture as Strategy – Creating a Foundation for Business Execution, Harvard Business School Press, Boston (2006).

Schekkerman J.: Trends in Enterprise Architecture 2004: How are Organizations Processing? Institute for Enterprise Architecture Developments (2004).

Schmidt C.: Management Komplexer IT-Architekturen, Gabler Verlag, Wiesbaden (2009).

Schönherr M.: Towards a Common Terminology in the Discipline of Enterprise Architecture, Proceedings of the International Conference on Service-Oriented Computing Workshops, pp400-414 (2008).

Simon D., Fischbach K., Schoder D.: Application Portfolio Management – An Integrated Framework and a Software Tool

Evaluation Approach, Communications of the Association for Information Systems (26:3) (2009).

Simon D.: EAM: Realize Benefits Using the Standards Portfolio, Architecture & Governance Magazine (5:8) (2009a).

Simon D.: Application Landscape Transformation and the Role of Enterprise Architecture Frameworks, Proceedings of Workshop: MDD, SOA und IT-Management (2009b).

Slot R., Dedene G., Maes R.: Business Value of Solution Architecture, Advances in Enterprise Engineering II, Lecture Notes in Business Information Processing, Vol. 28, pp84-108 (2009).

The Open Group: TOGAF Version 9 Enterprise Edition (2009).

Van der Raadt B., Schouten S., Van Vliet H.: Stakeholder Perception of Enterprise Architecture, Software Architecture, Lecture Notes in Computer Science, Vol. 5292/2008, pp19-34 (2008).

Winter R.: Business Strategy Modeling in the Information Age, Proceedings of the 3

rd international Web Conference, Perth

(2002).

Winter R., Fischer R.: Essential Layers, Artifacts, and Dependencies of Enterprise Architecture, Journal of Enterprise Architecture (May 2007).


Article

Delivering Business Value Through Enterprise Architecture

By Toomas Tamm, Peter B. Seddon, Graeme Shanks, and Peter Reynolds

This is an abridged version of the article titled ―How Does Enterprise Architecture Add Value to Organizations?‖, originally published in the Communications of the Association for Information Systems (Tamm et al 2011). The current version was created with the aim of sharing the findings with the practitioner community. For the full academic version, please refer to the original article.

Abstract

There is a substantial interest and investment in enterprise architecture worldwide, exemplified by the number of enterprise architecture-related professional bodies, consulting services, frameworks, methodologies, and the increasing prevalence of full-time enterprise architecture teams. It may seem surprising in this context, therefore, that the value of enterprise architecture is still poorly understood. Organizations cite difficulties in justifying their enterprise architecture investments and anecdotal evidence suggests that the existence and funding of the enterprise architecture function is often based more on the beliefs of the incumbent management team than on demonstrated value. Although there is no shortage of enterprise architecture benefit claims, explanations of why and how enterprise architecture leads to the proposed benefits are fragmented and incomplete. This article aims to take a step towards improving the understanding of the value of enterprise architecture by focusing on how it leads to organizational benefits. Through a careful review of the existing practitioner and academic literature, the article consolidates knowledge on enterprise architecture benefits and refines the explanations by drawing on relevant IS and management theory. The resultant EA Benefits Model (EABM) proposes that enterprise architecture leads to organizational benefits through its impact on four key benefit enablers: Organizational Alignment, Information Availability, Resource Portfolio Optimization, and Resource Complementarity. The article concludes with a discussion of some potential avenues for future research, which could build on the findings of this study.

Keywords

Enterprise Architecture, IT Architecture, IT Planning, Strategic Planning, IT Infrastructure, Business Benefits

INTRODUCTION

Since the concept of enterprise architecture first appeared around the early 1990s (Zachman 1987; Richardson et al 1990),

1 the field has rapidly evolved

and captured the interest of organizations worldwide. This is exemplified by the number of various enterprise architecture-related professional organizations (e.g., CAEAP, GEAO, The Open Group, ZIFA, etc.), government initiatives (e.g., FEAF, DoDAF, GEA, MoDAF, etc.), service offerings of large global management consulting firms,

2 the continuing evolution

of a number of frameworks and methodologies, and perhaps most importantly, by the increasing prevalence

1 Zachman’s (1987) article on Information Systems Architecture is often

regarded as the seminal work on enterprise architecture. However, the term ―enterprise architecture‖ (introduced to emphasize the necessity for a more business-oriented planning approach) appears to have been used for the first time by Richardson et al (1990). 2 Examples include Accenture, BCG, Capgemini, Deloitte, Ernst &

Young, Fujitsu, Gartner, IBM, and KPMG.

of full-time enterprise architecture teams (Obitz & Babu 2009). All of this suggests that organizations around the world spend a considerable amount of time and effort on enterprise architecture.

As an organizational role, enterprise architecture is positioned between IT and business strategy formulation on the one hand, and project-focused solution architecting on the other. Enterprise architecture is the definition and representation of a high-level view of an enterprise’s business processes and IT systems, their inter-relationships, and the extent to which these processes and systems are shared by different parts of the enterprise. Two key components of enterprise architecture are the planning process, and the direct and tangible outputs of that planning process; i.e., enterprise architecture documentation.

Therefore, the high-level value proposition of enterprise architecture is to enable an organization to move towards strategy enactment by translating the broader principles, capabilities, and goals defined in the strategies into systems and processes that help the


enterprise to realize these goals. In addition to defining the desired future state of the organization’s business processes and IT systems, enterprise architecture also involves providing a roadmap for achieving this target from the current state.

How is enterprise architecture delivering on its value proposition and what are the specific business benefits it brings to organizations? It may seem surprising, but after two decades the value of enterprise architecture remains poorly understood and the answer to these questions remains mixed. In contrast to the clear interest in the domain, an increasing number of organizations cite difficulties in justifying their enterprise architecture investments (Aziz & Obitz 2007; Obitz & Babu 2009) and anecdotal evidence suggests that the existence and funding of the enterprise architecture function is often based more on the beliefs of the incumbent management team than on demonstrated value. Academic research and guidance on the topic also remains scarce.

3 Although there is no shortage of

enterprise architecture benefit claims in existing literature, there are only fragmented and incomplete explanations of why and how it leads to the proposed benefits.

This article aims to take a step towards improving the understanding of the value of enterprise architecture by focusing on: How does enterprise architecture lead to organizational benefits? Through a careful literature review, the article consolidates the fragmented knowledge on enterprise architecture benefits and refines the explanations by drawing on relevant IS and management theory. The resultant EA Benefits Model (EABM) proposes that enterprise architecture leads to organizational benefits through its impact on four key benefit enablers: Organizational Alignment, Information Availability, Resource Portfolio Optimization, and Resource Complementarity. The article concludes with a discussion of some potential avenues for future research, which could build on the findings of this study.

RESEARCH APPROACH

This was a literature-based study, aimed at improving the existing knowledge on enterprise architecture benefits through integrating the existing fragmented knowledge on the topic. To develop an overview of the existing literature and its benefits, two search approaches were employed. First, a systematic search approach was used to look for key publications on enterprise architecture, using the Google Scholar and Scopus databases. The search yielded 4,392 unique results, which were then ranked based on average

3 One indicator of the lack of high-quality research on the topic is that,

since 1990, only three enterprise architecture-focused articles have been published in the six highest-regarded IS journals (AIS nd).

annual citation count to identify the most influential publications. The top 50 EA-focused publications were analyzed in-depth.

In parallel, an exploratory search using Google and reference lists of studies identified through the systematic approach was used to find additional insightful publications; e.g., practitioner-focused studies (which are not indexed by Google Scholar), studies that refer to enterprise architecture with a different term,

4 and

very recent studies for which a citation count is not yet available. This complementary search led to the inclusion of 17 further insightful publications (e.g., Aziz & Obitz 2007; Kettinger et al 2010; Obitz & Babu 2009; Salmans & Kappelman 2010).

In all, 213 benefit claims were recorded, which could be broadly grouped into the 12 themes listed in the first row of Table 1 Error! Reference source not found.below. The focus then turned to the primary question of interest: How does enterprise architecture lead to these benefits? We focused on identifying the underlying benefit enablers—factors which could be clearly seen as enterprise architecture outcomes, and that in turn are known to have the potential to deliver organizational benefits. We also drew on IS and management theory to enhance the identified concepts and explanations. The result of this process, which passed through four major iterations and numerous smaller refinements, is the EA Benefits Model (EABM), described in-depth after the literature review section.

LITERATURE REVIEW

This section provides a summary of the current state of knowledge on enterprise architecture benefits in published literature. As noted earlier, there is no shortage of enterprise architecture benefit claims in literature. Table 1 summarizes the benefit claims from the literature review, including a recent enterprise architecture benefits survey (Salmans & Kappelman 2010), and compares it with a few influential practitioner-oriented sources.

Some of the most commonly cited benefits in academic studies (listed in the first row of Table 1) were: (1) increased responsiveness and guidance to change, (2) improved decision-making, (3) improved communication and collaboration, (4) reduced costs, and (5) business-IT alignment.

A comparison with practitioner-oriented sources reveals a high agreement between authors about the reduction of costs, particularly of IT costs, as a tangible enterprise

4 The following terms were considered potentially relevant: IS/IT

architecture, enterprise service-oriented architecture (enterprise SOA), IS/IT platform, business architecture, strategic architecture, strategic capabilities architecture, business platform, architecture framework, and enterprise integration architecture.


architecture benefit. Increased capability to change, improved alignment between business and IT, and business process improvements are also mentioned repeatedly by academic as well as practitioner sources.

Table 1: Organizational Benefits from Enterprise Architecture Reported in Literature

5

Academic Studies

Systematic Literature Review (50 studies)

(1) Increased responsiveness and guidance to change

(2) Improved decision-making

(3) Improved communication & collaboration

(4) Reduced (IT) costs

(5) Business-IT alignment

(6) Improved business processes

(7) Improved IT systems

(8) Re-use of resources

(9) Improve integration

(10) Reduce risk

(11) Regulatory compliance

(12) Provides stability

SIM EA Survey 2007

(Salmans & Kappelman 2010)

(1) Improves interoperability between information systems

(2) Improves utilization of IT

(3) Aligns business objectives with IT investments

(4) More effective use of IT resources

(5) Better situational awareness

(6) More responsive to change

(7) Improves organizational communications and information sharing

(8) Assists with organizational governance

(9) Improves ROI from IT spending

(10) Less wasted time/money on projects which do not support business goals/objectives

(11) More effective at meeting business goals

(12) Improves IS security across the business

(13) Better collaboration within organization

(14) Improves communications between the organization and IT department

(15) Reduces IT complexity

(16) Reduces organizational stovepipes

(17) Faster development and implementation of new IS

(18) Standardizes organizational performance measures

(19) Improves communications within organization

5 The benefits from the literature review, Infosys, and SIM survey are

ranked based on how often they were mentioned by authors/respondents. The benefits from Zachman (2001) are listed in the order presented by the author, though it is not clear whether any ranking was implied.

Professional Sources

Infosys EA Survey 2007

(Aziz & Obitz 2007)

(1) Reduced IT cost

(2) Higher business and process flexibility

(3) Improved customer satisfaction

(4) Enabling of business and process change

(5) Better business-IT alignment

Infosys EA Survey 2009

(Obitz & Babu 2009)

(1) Improved customer satisfaction

(2) Reduced IT cost

(3) Business process improvement/ standardization

(4) Better business-IT alignment

(5) Higher business and process flexibility

TOGAF® 9

(The Open Group 2009)

(1) More efficient IT operations

(2) Lower IT costs

(3) Maximum ROI from existing IT

(4) Reduced risk for future IT investments

(5) Reduced IT complexity

(6) Faster, simpler, and cheaper procurement

Zachman International

(Zachman 2001)

(1) Alignment enabler

(2) Integration enabler

(3) Change enabler

(4) Reduced time-to-market

Despite the numerous benefit claims, very few studies provide explanations about how enterprise architecture leads to these benefits and evidence to back the claims and explanations is even scarcer. The analysis of the provided explanations revealed the need to distinguish clearly between (a) benefits flowing directly from enterprise architecture (i.e., the planning process and resultant artifacts), and (b) the subsequent impact of enterprise architecture on the real-world state of the organization. This distinction is often overlooked (Zachman 2010), but it leads to two distinct pathways from enterprise architecture to organizational benefits, described below.

Benefits from Enterprise Architecture

Some benefits may flow directly from enterprise architecture. These benefits relate to the increased knowledge about the organization and its goals (e.g., a better understanding of the business processes or the organization’s current IT systems as a result of the enterprise architecture analysis), which can provide the basis for better-informed decisions.

This pathway has received very little attention in existing literature, possibly because of lower visibility and difficulties in measuring the benefits from planning, as they tend to be less tangible. Only one publication that focused on benefits from enterprise architecture planning was found (Bernard 2005). Bernard suggests that a standardized planning approach (i.e., a common


analysis and documentation methodology) applied across business unit and departmental boundaries leads to integrated and improved information about the organization’s resources. This, in turn, enables better communication and common understanding between different stakeholders and helps to reduce re-work and duplicated efforts. Ultimately, Bernard (2005) claims, this leads to better and faster decisions, reduced cycle times, improved (IT) performance, and lower costs.

The underlying benefit enabler here is a better understanding and increased access to information about the organization itself, emanating from the planning process and stored in the enterprise architecture artifacts. It should be noted, however, that although Bernard (2005) proposes a clear link between enterprise architecture and benefits, no empirical evidence (e.g., examples from case studies) are presented to support these claims.

Benefits from an Enterprise Architecture-Guided Operating Platform

Most of the enterprise architecture benefits discussed in the literature depend on the enactment of the enterprise architecture plans. This is not surprising since the key purpose of enterprise architecture is to guide the building of an improved operating platform; i.e., the IT systems and digitized business processes that support or automate an organization’s core capabilities (Ross et al 2006 p4).

6 However, the operating platform can exist

and evolve regardless of enterprise architecture—every organization has processes and systems, but not all organizations engage in enterprise architecture planning. Therefore, to demonstrate value, enterprise architecture has to either enable the organization (a) to build an operating platform that would otherwise not have been possible, or (b) to improve the delivery of the platform in some way (e.g., faster, cheaper, or with increased likelihood of success).

A prevalent claim in existing studies is that an enterprise architecture-guided operating platform is likely to have a higher level of standardization and integration (e.g., Bernard 2005; Boh & Yellin 2006; Ross & Westerman 2004; Spewak & Hill 1992). However, the various studies tend to diverge in the ultimate benefit claims and the discussion of related underlying mechanisms. For example, it has been argued that it is through building consensus and a homogenous (standardized) architecture that enterprise architecture enables an enterprise to achieve improved information flows and reduced IT costs (Richardson et al 1990). Another suggestion is that enterprise architecture enables a firm

6 The definition of ―operating platform‖ has been adapted from Ross et

al (2006) ―foundation for execution‖.

to achieve well-planned and tightly integrated systems, leading to more reliable systems and data and to increased re-use, which ultimately results in higher responsiveness, better decisions, service improvements, reduced costs, and higher employee morale (Spewak & Hill 1992). More recently, it has been claimed that by driving increased standardization, integration, and componentization, enterprise architecture enables an organization to improve operational excellence, customer intimacy, product leadership, and strategic agility (Ross et al 2006).

There are three notable issues with the existing explanations. First, the ultimate benefit claims and the proposed mechanisms in the various studies are quite different. Second, the role that enterprise architecture plays in leading to the operating platform improvements is often not thoroughly discussed. Third, it is essential to understand that having an enterprise architecture plan is far from a guarantee of implementation success (Boh & Yellin 2006). As the operating platform improvements proposed in the enterprise architecture plans are implemented through a series of projects, all the usual project success factors apply; e.g., top management support, change management, and project management, among many others (Finney & Corbett 2007; Parr et al 1999). In addition, proper IT governance is of central importance to ensure that the various projects follow the enterprise architecture guidelines (Boh & Yellin 2006; Ross et al 2006; Weill & Ross 2004). Due to the duration and cost, enterprise architecture implementations are also more likely to be subject to unexpected changes in business priorities, emerging financial constraints, or loss of interest (Armour et al 1999; Richardson et al 1990; Segars & Grover 1996; Spewak & Hill 1992). Finally, due to the aim of enterprise-wide optimization, which can often mean trade-offs in local optimization and autonomy, enterprise architecture implementations are very likely to be hampered by organizational politics (Janssen & Hjort-Madsen 2007; Kettinger et al 2010; Segars & Grover 1996).

Reflecting on the Literature

Three key conclusions can be drawn from the findings of the literature review. First, it is important to distinguish between benefits that can flow from enterprise architecture directly and benefits that can be achieved only through the implementation of the enterprise architecture plans; i.e., from an enterprise architecture-guided operating platform. Due to the high uncertainty in progressing from plans to implementation, it seems likely that enterprise architecture’s impact on benefits that are contingent on implementation is somewhat weaker than on benefits that can be derived from the enterprise architecture plans directly.


Second, a considerable amount of collective knowledge on the benefits of enterprise architecture exists. However, these benefit claims and related explanations are fragmented. Integrating this existing knowledge can therefore provide a valuable step towards enhancing the understanding of how enterprise architecture leads to organizational benefits.

Third, gathering further evidence to substantiate the benefit claims and explanations is essential. Not only do the existing claims lack empirical validation, but due to the lack of studies focusing on a careful explanation of enterprise architecture benefits, it seems likely that some benefits or explanations may have been overlooked.

The following section takes a step towards enhancing knowledge on how enterprise architecture leads to organizational benefits by proposing the EA Benefits Model (EABM). The EABM integrates the existing explanations in the enterprise architecture literature and draws on relevant IS and management theory to enhance these explanations. It suggests that it is through its impact on four key benefit enablers that enterprise architecture delivers organizational benefits. Although the current study does not address the third concern above, the proposed model provides a useful starting platform for future field studies.

THE EA BENEFITS MODEL (EABM)

The EA Benefits Model (EABM) presented in Figure 1 synthesizes the findings from the literature review. The model proposes that it is through the impact of enterprise architecture on four key benefit enablers—Organizational Alignment, Information Availability, Resource Portfolio Optimization, and Resource Complementarity—that enterprise architecture leads to organizational benefits. The term ―benefit enablers‖ emphasizes that these outcomes are not benefits per se, but are factors which have been demonstrated in earlier research to have a high potential for enabling organizational benefits.

Figure 1: EA Benefits Model (EABM)

Definitions of the EABM concepts are summarized in Table 2 and discussed in detail in the following sections. The thickness of the arrows from EA to Benefit Enablers

denotes the suggested strength of the relationship, based on how reliant a given benefit enabler is on the enactment of the enterprise architecture plans. This acknowledges the high uncertainties involved in progressing from enterprise architecture to implementation discussed above. The least strong (dotted) lines indicate that Resource Portfolio Optimization and Resource Complementarity are entirely dependent on at least partial enactment of enterprise architecture plans. Information Availability is partly contingent on enactment, and is presented as a thin line. Finally, Organizational Alignment may to a large extent be achieved through the enterprise architecture planning activities and resultant documentation per se, and is therefore represented as a thick line.

Table 2: Definitions of the EABM Concepts7

Enterprise Architecture

The definition and representation of a high-level view of an enterprise’s business processes and IT systems, their inter-relationships, and the extent to which these processes and systems are shared by different parts of the enterprise.

Organizational Benefits

Outcomes that contribute directly to organizational performance, including lower costs, increased revenue, competitive differentiation, more accurate decisions, strategic agility, etc.

Benefit Enablers

Organizational Alignment

The extent to which an organization’s subunits share a common understanding of its strategic goals, and contribute towards achieving these goals.

Information Availability

The extent of useful, high-quality information accessible to organizational decision-makers.

Resource Portfolio Optimization

The extent to which an organization leverages its existing resources, invests in resources that target performance gaps, and minimizes unnecessary investments in duplicated resources.

Resource Complementarity

The extent to which the organization’s resources synergistically support the pursuit of its strategic goals.

The following discussion of the EABM begins with enterprise architecture. The four sections that follow draw on both the review of enterprise architecture literature as well as broader IS and management theory

7 These definitions are ours, though they have been adapted from the

existing literature on the related concepts.

Enterprise

Architecture

Resource Complementarity

Resource Portfolio Optimisation

Information Availability

Organisational Alignment

Organisational

Benefits

Benefit Enablers


to define the four benefit enablers, and explain how these relate to organizational benefits from enterprise architecture.

ENTERPRISE ARCHITECTURE

Enterprise architecture is the definition and representation of a high-level view of an enterprise’s business processes and IT systems, their inter-relationships, and the extent to which these processes and systems are shared by different parts of the enterprise. Two key components of enterprise architecture are the planning process, and the direct and tangible outputs of that planning process; i.e., enterprise architecture documentation.

It is clear that not all enterprise architecture efforts are equal, and only high-quality enterprise architecture efforts are positioned to make a positive organizational impact. A high-quality enterprise architecture is one that provides a vision for the future operating platform that is well-aligned with the organization’s strategic goals, complemented by an optimal roadmap for moving towards that vision, based on an accurate understanding of the current operating platform. Enterprise architecture quality depends on the quality of the planning process and is embedded in the resultant documentation.

It is important to note that a high-quality enterprise architecture has to strike an appropriate balance among scope, detail, and cost (Spewak & Hill 1992). After the scope and depth of planning reaches a certain threshold, investing more resources and effort in the planning is likely to lead to diminishing returns. Eventually, the marginal improvements in the accuracy and amount of information captured in the plans will no longer be able to offset the required investments.

ORGANIZATIONAL ALIGNMENT

Organizational Alignment is the extent to which an organization’s subunits share a common understanding of its strategic goals and contribute towards achieving these goals. The alignment between business and IT, an aspect of Organizational Alignment, has received extensive attention (Chan & Reich 2007a,b). The underlying claim of the business-IT alignment literature is that IT strategies and the resultant deliverables should be closely informed by, and aligned with, business strategies and processes (Henderson & Venkatraman 1993). This is to ensure that the IT systems in which an organization invests provide the best possible support for the strategic needs of the business.

However, it is not only alignment between business and IT that is a challenge in large, complex organizations. Alignment is not only a challenge across all functional areas (e.g., between Sales and Marketing), sometimes referred to as horizontal alignment, but also between the

corporate level and various Strategic Business Units (SBUs) (Reynolds et al 2010).

Organizational Benefits from Organizational Alignment

Organizational Alignment in general, as well as its sub-dimension of business-IT alignment, have been found to be related to improved organizational performance (Chan et al 2006; Kearns & Lederer 2003; Miller 1986; Porter 1996; Sabherwal & Chan 2001). Firms with high Organizational Alignment may achieve a better total ROI through the reduction of incoherent or duplicated efforts, and achieve their strategic goals with minimal overhead.

Improving Organizational Alignment through Enterprise Architecture

Both enterprise architecture planning as well as related improvements in the operating platform have the potential to improve Organizational Alignment. The enterprise architecture planning activity itself requires cross-organizational dialog and input. As enterprise architecture is not only concerned with IT systems, but begins with an understanding of the business processes that these systems need to support, it has the potential to bring IT in closer alignment with the business goals (Gregor et al 2007; Ross 2003). The objective of greater business-IT alignment is also among the top reasons why organizations invest in enterprise architecture (Aziz & Obitz 2007; Obitz & Babu 2009).

Because the business analysis undertaken during enterprise architecture planning spans different departments and/or business units, there is potential for it to have a positive impact not only on business and IT alignment, but also on other dimensions of Organizational Alignment. The basis for this broader impact is the facilitation of dialog and identification of inter-dependencies between the various parts of the enterprise (Segars & Grover 1996). The increased understanding of the process inter-dependencies and potential synergies provides a better basis for identifying the stakeholders that may be affected by, and should be consulted about, a given process or technology change (Bernard 2005). The relevant people can be involved early in the decision-making process, allowing for potential conflicts to be identified and resolved early, which may have a positive impact on collaboration and collective decision-making (Richardson et al 1990).

The awareness that enterprise architecture creates about the dependencies may also be used to ensure the alignment between performance measures of employees, which can further contribute to collaboration (Pereira & Sousa 2004). The set of agreed-upon enterprise architecture principles also provides objective decision-making criteria, which in turn can help to avoid costly, prolonged, or repeated arguments. Therefore,


enterprise architecture reduces the subjectivity of the decision-making process (Johnson et al 2007; Spewak & Hill 1992) and brings the business and IT investment decisions in closer alignment to the organizational goals, as opposed to the personal agendas of individual key stakeholders.

INFORMATION AVAILABILITY

Information Availability is defined as the extent of useful, high-quality information accessible to organizational decision-makers. Information quality does not only encompass accuracy, but also aspects such as relevance, completeness, timeliness, interpretability, and accessibility (Lee et al 2002; Wang & Strong 1996). These dimensions suggest that in order to improve Information Availability and quality, the purpose of the information needs to be considered (e.g., the measure of timeliness can be substantially different in strategic and operational decision-making).

Organizational Benefits From Information Availability

Information is widely recognized as a key organizational asset. Access to better information—when coupled with enhanced capabilities to interpret that information—may serve as an important source of competitive advantage (Davenport & Harris 2007; Davenport et al 2010). For example, improved information about the customers and the marketplace enables better targeted product development, sales, and marketing efforts (Davenport & Harris 2007), leading in turn to increased revenues.

Improving Information Availability through Enterprise Architecture

The information underpinning an organization’s knowledge base consists of data about an organization’s interactions with the outside world (i.e., clients, suppliers, and business transactions) and information about the organization itself (i.e., primarily related to organizational processes). Enterprise architecture has the potential to improve the availability of both types of information. The improved information about organizational processes primarily flows directly from enterprise architecture. Through the business and system analysis performed as part of the enterprise architecture planning, previously undocumented information about the organization’s processes may be captured (Bernard 2005). The whole-of-enterprise analysis approach may even reveal inter-dependencies or inefficiencies that were previously not only undocumented, but also unknown. This information will be captured in the current state documentation of enterprise architecture and will help to enhance and retain organizational knowledge about its processes. Even if the enterprise architecture vision and roadmaps are later not followed, this documentation in itself may

prove valuable for informing organizational decision-making.

In contrast, improved availability of information about business transactions, customers, and vendors is primarily contingent on the enactment of enterprise architecture plans. This information is normally captured in an organization’s databases. Enterprise architecture can help to improve the availability of this information by guiding the building of an improved operating platform that, in turn, provides better information to decision-makers in the organization. First, enterprise architecture has been suggested to improve the sharing of information through more carefully planned integration between the organization’s information systems (Boh & Yellin 2006; Ross et al 2006; Spewak & Hill 1992). In addition to identifying and helping to standardize the interfaces and messaging between different applications, enterprise architecture may also facilitate information sharing by advocating common data definitions and structures (Boh & Yellin 2006; Spewak & Hill 1992). Second, as will be discussed in the following section, an enterprise architecture-guided operating platform is likely to have lower complexity and fewer components, contributing to increased reliability of the operating platform (Pereira & Sousa 2004; Ross et al 2006). This has a positive impact on information accessibility. Finally, by identifying and helping to reduce the number of redundant data stores, enterprise architecture may also have a positive impact on data accuracy (Venkatesh et al 2007).

RESOURCE PORTFOLIO OPTIMIZATION

Resource Portfolio Optimization is defined as the extent to which an organization leverages its existing resources, invests in resources that target performance gaps, and minimizes unnecessary investments in duplicated resources. Resources can be defined as ―all assets, capabilities, organizational processes, firm attributes, information, knowledge, etc. controlled by the firm‖ (Barney 1991 p101). In relation to enterprise architecture, three types of resources are primarily of interest: human resources, IT, and organizational processes. Optimization could, therefore, involve the removal of duplicated or non-value-adding technology or human resources, and/or replacing them with resources that are more efficient in assisting with the achievement of organizational goals.

Organizational Benefits from Resource Portfolio Optimization

The organizational benefits from Resource Portfolio Optimization mainly relate to reduced costs and higher efficiencies, which translate to a better ROI from the organization’s resources. Process optimization, an aspect of Resource Portfolio Optimization, has been


found to have the potential to not only deliver substantial cost savings, but also to improve quality and reliability of product and service delivery (Davenport & Short 1990; Hammer & Champy 1994; Harrington 1991).

Optimizing the Resource Portfolio through Enterprise Architecture

Enterprise architecture can help to identify areas where either resource gaps or overlaps occur and to provide recommendations on how to improve on the existing state (Bernard 2005; Pereira & Sousa 2004). While it is likely that areas of under-investment make themselves known through the related business impact, areas of over-investment may be much less visible. If each business unit with similar needs invests in its own systems, the costs incurred are likely to be significantly higher than when using a single, shared system. However, if the systems are working fine and the costs are manageable, the organization may remain unaware of the opportunity for cost-cutting by leveraging economies of scale.

By looking across the verticals and horizontals of an organization when documenting the current state during enterprise architecture planning, resource overlaps will become apparent (Boh & Yellin 2006). Existing studies suggest that enterprise architecture, therefore, contributes to building a more standardized IT platform with fewer technologies, leading in turn to simplified interfaces, higher reliability through reduced operating platform complexity, and lower maintenance and support costs (Boh & Yellin 2006; Hjort-Madsen 2006; Richardson et al 1990; Ross et al 2006; Spewak & Hill 1992; Venkatesh et al 2007).

Enterprise architecture may also help to promote the decoupling of monolithic systems to smaller components, which facilitates both re-use as well as flexibility of reconfiguring or replacing the components as required (Janssen & Hjort-Madsen 2007; Ross et al 2006). Componentization helps in optimizing the resource portfolio by reducing the overlaps between individual components and simplifying the replacement of components that no longer meet business needs or are more costly to maintain than newer alternatives. Also, the knowledge about the purpose and inter-dependencies of the components captured in enterprise architecture documentation makes the replacement process considerably easier and less risky (Iyer & Gottlieb 2004). Finally, the awareness about the components, the stage of their lifecycle, and business impact can also help to better channel investments to resources with the highest value potential in the case of financial constraints (Segars & Grover 1996).

Through the business analysis that precedes the evaluation of the IT systems, enterprise architecture can

also contribute to the identification of suboptimal business processes and use of human resources (Bernard 2005; Boh & Yellin 2006; Pereira & Sousa 2004). It has also been suggested that as a result of the enterprise-wide optimization, the organization may be able to shift the focus of its business processes from a department or business unit-centric view to increased customer focus, as it gains the ability to share a single view of its customers across the different organizational units (Ross et al 2006; Venkatesh et al 2007).

It is necessary to note that while enterprise architecture plans may have a direct positive effect on the benefit enablers discussed earlier (Organizational Alignment and Information Availability), the benefits from Resource Portfolio Optimization are contingent on the implementation of these plans, or at least parts thereof.

RESOURCE COMPLEMENTARITY

Resource Complementarity is defined as the extent to which the organization’s resources synergistically support the pursuit of its strategic goals. It is a widely accepted view in strategic management that the basis for a firm’s sustained competitive advantage comes from its control of a set of resources which are rare, valuable, inimitable, difficult to substitute, and relatively immobile (Barney 1991). While it is very difficult to find individual resources that meet these criteria, once embedded in organizational processes in unique combinations with other resources, these desirable characteristics become easier to achieve (Brynjolfsson & Saunders 2010; Grant 1996). A major difficulty in imitating complex resource configurations stems from causal ambiguity; i.e., it may not be clear which components or interactions underpin the organization’s success (Lippman & Rumelt 1982; Reed & DeFillippi 1990).

Therefore, the competitive advantage of organizations tends to rely not on individual resources but on unique combinations of complementary resources. The mechanism which helps to make use of these combined resources is sometimes referred to as capabilities—human-based skills and processes that enable an organization to deploy other resources in order to achieve desired goals (Amit & Schoemaker 1993). Capabilities are developed over time through the creation, exchange, and retention of information, and are grounded in the skills, knowledge, and processes of the organization. Therefore, they cannot be readily sourced from the market (Amit & Schoemaker 1993).

Organizational Benefits from Resource Complementarity

The major organizational benefit from Resource Complementarity is, therefore, potential competitive differentiation from achieving a mutually reinforcing resource configuration that is difficult to replicate


(Brynjolfsson & Saunders 2010). The exact tangible benefits from Resource Complementarity are dependent on the competitive strategy of the organization, which determines the desirable resource configuration to pursue. It has been suggested that the three key ways in which organizations can compete are a focus on: (1) operational excellence (reliable, conveniently accessible, and low-cost products/services); (2) customer intimacy (highly personalized products and services); or (3) product leadership (innovative, ―state-of-the-art‖ products/services) (Treacy & Wiersema 1993). For a company pursuing operational excellence, the result of Resource Complementarity could be a superior cost position, achieved through combining resources in a way that cuts overheads to a minimum while retaining the desired product/service standards. On the other hand, a company pursuing a customer-intimate strategy would want to make sure that its resources complement each other in a way that delivers a single view of the customer, helps to gather superior customer information and feedback, and ensures consistency of customer service organization-wide.

Increasing Resource Complementarity through Enterprise Architecture

The primary mechanism through which enterprise architecture helps an organization to improve Resource Complementarity is through the identification of the potential enterprise-wide synergies, and by providing recommendations on how to leverage these synergies. Indeed, it has been suggested that the fragmentation of resources is inevitable if proper measures are not taken to ensure complementarity, and that the key mechanism in ensuring complementarity is the development of:

―… a corporate-wide strategic architecture that establishes objectives for competence building. A strategic architecture is a roadmap of the future that identifies which core competencies to build and their constituent technologies.‖ (Prahalad & Hamel 1990 p89)

Many of the mechanisms through which enterprise architecture can help to enhance Resource Complementarity are similar to those discussed in relation to Resource Portfolio Optimization. Both depend on the organization-wide analysis and identification of resources and their inter-dependencies. Both benefit from the reduction of overlaps between resources achieved through componentization. However, while the primary focus of Resource Portfolio Optimization is on reducing redundancy related to resource duplication and overlaps and improving the quality of these resources, Resource Complementarity focuses on leveraging synergies between the resources and combining them in ways that enhance performance and are difficult for

competitors to replicate.8 Improvements in a system can

stem from either the introduction of superior components (component innovation) or an enhanced reconfiguration of components (architectural innovation) (Henderson & Clark 1990). Resource Portfolio Optimization focuses on the former, whereas Resource Complementarity focuses on the latter. Therefore, in proposing the EABM, Resource Complementarity and Optimization are treated as two distinct benefit enablers. However, similar to Resource Portfolio Optimization, the achievement of Resource Complementarity is contingent on the implementation of enterprise architecture.

IS ENTERPRISE ARCHITECTURE EQUALLY VALUABLE FOR ALL ORGANIZATIONS?

An important question related to understanding the value of enterprise architecture is whether all organizations can expect to get similar benefits, or whether these vary from organization to organization based on certain internal or environmental characteristics. Reflecting on the four benefit enablers in EABM, as well as existing enterprise architecture research, suggest that some organizations under some circumstances may be better positioned to benefit from enterprise architecture investment than others.

For example, it has been suggested that larger organizations with more complex IT environments may expect to benefit more from enterprise architecture than those whose operating platform is relatively simple and well-understood (Bernard 2005). The benefit enablers discussed earlier appear to support this proposition. First, large and more complex organizations are likely to have a more diverse resource portfolio. This means that they may be able to derive more benefits from Resource Portfolio Optimization. Second, large organizations with complex structures are more likely to experience problems with alignment, increasing the potential for improving Organizational Alignment.

The quality of the existing operating platform is another factor suggested in earlier research to affect the extent of potential benefits from enterprise architecture (Bernard 2005). For example, high redundancy or quality issues provide larger potential gains from Resource Portfolio Optimization. Also, the performance gaps may leave more opportunities for improvements in Information Availability.

8 There is a subtle but important difference between Organizational

Alignment and Resource Complementarity in the EABM. Organizational Alignment (Porter’s (1996) ―first-order fit‖) relates to shared understanding and simple consistency between the activities of the organizational units and the corporate strategy. Resource Complementarity (Porter’s (1996) ―second-order fit‖) occurs when resources synergistically reinforce each other. These reinforcing effects coupled by the difficulty in imitating such combinations, lead to different organizational benefits from the two benefit enablers.


Another important factor is the organization’s operating model (Ross et al 2006). According to Ross et al, a firm’s operating model is determined by two independent choices—the level of desired standardization (commonality of processes and systems), and integration (sharing of data) across the organization. Organizations with low levels of standardization and integration can benefit from enterprise architecture if they choose to standardize or integrate certain aspects of their foundation (Ross et al 2006 pp56–57). It is implicit in this argument that the higher the level of desired standardization and/or integration, the higher the extent of potential benefits that an organization can expect from enterprise architecture. In terms of the EABM, standardization is closely related to Resource Portfolio Optimization, and integration to both Information Availability and Organizational Alignment.

It has also been argued that the higher the rate of organizational change, the greater the benefits from enterprise architecture (Spewak & Hill 1992). This is probably based on the claim that enterprise architecture can improve an organization’s flexibility and change capability. Both Resource Portfolio Optimization and Information Availability help to explain why organizations undergoing larger changes may benefit more from enterprise architecture. Understanding of the inter-dependencies of processes and IT systems (an aspect of Information Availability) becomes more essential when an organization needs to start making changes to these components. Also, the fewer inter-dependencies and components there are (i.e., the more optimized the resource portfolio), the cheaper and less risky it is to make changes to the environment.

There are also environmental factors, which may affect the extent of potential benefits from enterprise architecture. For example, the legislation and regulations governing a particular industry can be an important factor. In some cases enterprise architecture may simplify compliance (Ross et al 2006; Winter & Fischer 2006), whereas in others it can even be mandatory (e.g., Clinger-Cohen Act in the US), making enterprise architecture an ―organizational benefit‖ per se. The information intensity of a given industry appears also likely to affect the extent of potential benefits from enterprise architecture. Specifically, Information Availability is more critical for organizations that rely heavily on information in providing products or services to their customers or for whom information is the key product or service they provide.

AVENUES FOR FUTURE RESEARCH

The EA Benefits Model (EABM) and related discussion provides insights for academics and practitioners interested in enterprise architecture, and serves as a platform for future studies. There are numerous valuable

research opportunities to further improve the understanding of enterprise architecture benefits. Possibly the most significant shortcoming of existing research is the lack of evidence to support the various benefit claims. Although this study has taken a step towards improving the theoretical explanation of the benefit claims, field studies remain essential. Is the EABM complete? Are there better ways to group the benefit enablers? Are there any inter-relationships between the benefit enablers? How to measure the value of enterprise architecture? These are examples of some questions that future studies could help to find answers to.

CONCLUSION

Through a careful review of enterprise architecture literature and related academic theory, this study provides an enhanced explanation of how enterprise architecture leads to organizational benefits. The EA Benefits Model (EABM) posits that it is through improvements in Organizational Alignment, Information Availability, Resource Complementarity, and Resource Portfolio Optimization that enterprise architecture leads to organizational benefits. These benefits may include lower costs, higher strategic agility, and a more reliable operating platform. Although enterprise architecture may deliver benefits to any organization, it appears that large organizations with a complex IT environment, and those whose business model favors high levels of organization-wide standardization and integration, may be best positioned to benefit. Finally, we would like to emphasize that much work remains in improving the understanding of the value of enterprise architecture and future studies on the theme would be valuable for both practice and theory alike.

ABOUT THE AUTHORS

Toomas Tamm ([email protected]) is a PhD Candidate in the Department of Information Systems at the University of Melbourne. His research focuses on understanding if and how organizations can benefit from enterprise architecture planning.

Peter B. Seddon ([email protected]) is a Professor in the Department of Information Systems at the University of Melbourne. His research interests include enterprise systems, IT management, IT outsourcing, business analytics, organizational processes, evaluation and alignment, and accounting information systems.

Graeme Shanks ([email protected]) is an Australian Professorial Fellow in the Department of Information Systems at the University of Melbourne. His research interests focus on business analytics, the implementation and impact of information systems, data quality, and conceptual modeling.





Peter Reynolds ([email protected]) is a Research Scientist at MIT CISR. Peter’s research focuses on how firms drive value from IT through business and IT strategy, organizational design, IT-based business transformation, and mergers in IT.

REFERENCES

Alhanasiadis I.N.: Towards a Virtual Enterprise Architecture for the Environmental Sector, in Protogeros N. (Ed.) Agent and Web Service Technologies in Virtual Enterprises, Chapter XV, Hershey, PA: IGI Global, pp256–266 (2008).

Ambler S.W., Nalbone J., Vizdos M.J.: The Enterprise Unified Process: Extending the Rational Unified Process, Upper Saddle River, NJ: Prentice Hall PTR, Chapter 9 (2005).

Amit R., Schoemaker P.J.: Strategic Assets and Organizational Rent, Strategic Management Journal (14)1, pp33–46 (1993).

Armour F.J., Kaisler S., Liu S.: Building an Enterprise Architecture Step by Step, IT Professional (1)4, pp31–39 (1999).

Association for Information Systems (nd), Senior Scholars’ Basket of Journals (current April 5, 2011); refer to: http://home.aisnet.org/displaycommon.cfm?an=1&subarticlenbr=346.

Aziz S., Obitz T.: Enterprise Architecture is Maturing, Infosys Enterprise Architecture Survey 2007, Survey, Infosys (current April 5, 2011); refer to: www.infosys.com/offerings/IT-services/architecture-services/ea-survey/Documents/ea-maturing.pdf.

Barnett W., Presley A., Johnson M., Liles D.H.: An Architecture for the Virtual Enterprise, 1994 IEEE International Conference on Systems, Man, and Cybernetics, San Antonio, TX (1), pp506–511 (1994).

Barney J.: Firm Resources and Sustained Competitive Advantage, Journal of Management 17(1), pp99–120 (1991).

Bernard S.A.: An Introduction to Enterprise Architecture, 2nd Edition, Bloomington, IN: AuthorHouse (2005).

Bernus P., Nemes L.: A Framework to Define a Generic Enterprise Reference Architecture and Methodology, Computer Integrated Manufacturing Systems (9)3, pp179–191 (1996).

Bernus P., Nemes L., Williams T.J. (Eds.): Architectures for Enterprise Integration, London, New York: Chapman & Hall (1996).

Bernus P., Nemes L., Schmidt G. (Eds.): Handbook on Enterprise Architecture, Heidelberg, Germany: Springer-Verlag (2003).

Boh W., Yellin D.: Using Enterprise Architecture Standards in Managing Information Technology, Journal of Management Information Systems (23)3, pp163–207 (2006).

Boster M., Liu S., Thomas R.: Getting the Most from your Enterprise Architecture, IT Professional (July–August), pp43–50 (2000).

Braun C., Winter R.: A Comprehensive Enterprise Architecture Metamodel and its Implementation using a Metamodeling Platform, Proceedings of the Workshop on Enterprise Modeling and Information Systems Architectures, Verlag Ritter, Austria: Klagenfurt 2005, pp64–79 (2005).

Brynjolfsson E., Saunders A.: Wired for Innovation, Cambridge, MA: The MIT Press (2010).

Carlock P., Fenton R.: System of Systems (SoS) Enterprise Systems Engineering for Information-Intensive Organizations, Systems Engineering (4)4 (2001).

Chan Y.E., Reich B.H.: IT Alignment: What have we Learned?, Journal of Information Technology (22)4, pp297–315 (2007a).

Chan Y.E., Reich B.H.: IT Alignment: An Annotated Bibliography, Journal of Information Technology (22)4, pp316–396 (2007b).

Chan Y.E., Sabherwal R., Thatcher J.B.: Antecedents and Outcomes of Strategic IS Alignment: An Empirical Investigation, IEEE Transactions on Engineering Management (51)3, pp27–47 (2006).

Chen D., Vallespir B., Doumeingts G.: GRAI Integrated Methodology and its Mapping onto Generic Enterprise Reference Architecture and Methodology, Computers in Industry (33)2–3, pp387–394 (1997).

Chen D., Doumeingts G., Vernadat F.B.: Architectures for Enterprise Integration and Interoperability: Past, Present and Future, Computers in Industry (59)7, pp647–659 (2008).

Cummins F.A.: Enterprise Integration: An Architecture for Enterprise Application and Systems Integration, Hoboken, NJ: John Wiley & Sons (2002).

Davenport T.H., Harris J.G.: Competing on Analytics: The New Science of Winning, Cambridge, MA: Harvard Business School Press (2007).

Davenport T.H., Harris J.G., Morison, T.: Analytics at Work: Smarter Decisions, Better Results, Cambridge, MA: Harvard Business Press (2010).

Davenport T.H., Short J.E.: The New Industrial Engineering: Information Technology and Business Process Redesign, Sloan Management Review (31)4, pp11–27 (1990).

El Sawy O.A., Malhotra A., Gosain, S., Young K.M.: IT-Intensive Value Innovation in the Electronic Economy: Insights from Marshall Industries, MIS Quarterly (23)3, pp305–335 (1999).

Finney S., Corbett M.: ERP Implementation: A Compilation and Analysis of Critical Success Factors, Business Process Management Journal (13)3, pp329–347 (2007).

Grant R.M.: Toward a Knowledge-Based Theory of the Firm, Strategic Management Journal (17)Winter Special Issue, pp109–122 (1996).

Gregor S., Hart D., Martin N.: Enterprise Architectures: Enablers of Business Strategy and IS/IT Alignment in


http://home.aisnet.org/displaycommon.cfm?an=1&subarticlenbr=346

http://home.aisnet.org/displaycommon.cfm?an=1&subarticlenbr=346

http://www.infosys.com/offerings/IT-services/architecture-services/ea-survey/Documents/ea-maturing.pdf




Government, Information Technology & People (20)2, pp96–120 (2007).

Guijarro L.: Interoperability Frameworks and Enterprise Architectures in E-Government Initiatives in Europe and the United States, Government Information Quarterly (24)1, pp89–101 (2007).

Hammer M., Champy J.: Re-engineering the Corporation: A Manifesto for Business Revolution, New York, NY: HarperBusiness (1994).

Harmon P., Rosen M., Guttman M.: Developing E-Business Systems and Architectures: A Manager's Guide, Burlington, MA: Morgan Kaufmann, Chapter 6, pp141–167 (2001).

Harrington H.J.: Business Process Improvement: The Breakthrough Strategy for Total Quality, Productivity, and Competitiveness, New York: McGraw-Hill Professional (1991).

Hay D.C.: Requirements Analysis: From Business Views to Architecture, Upper Saddle River, NJ: Prentice Hall PTR (2003).

Henderson J.C., Venkatraman N.: Strategic Alignment: Leveraging Information Technology for Transforming Organizations, IBM Systems Journal (32)1, pp4–16 (1993).

Henderson R.M., Clark K.B.: Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms, Administrative Science Quarterly (35)1, pp9–30 (1990).

Hoque F.: E-Enterprise: Business Models, Architecture, and Components, New York: Cambridge University Press, Chapter 6, pp173–201 (2000).

Humphries M., Hawkins M.W., Dy M.C.: Data Warehousing: Architecture and Implementation, Upper Saddle River, NJ: Prentice Hall PTR, Chapter 1 (1999).

Iyer B., Gottlieb R.: The Four-Domain Architecture: An Approach to Support Enterprise Architecture Design, IBM Systems Journal (43)3, pp587–597 (2004).

Janssen M., Hjort-Madsen K.: Analyzing Enterprise Architecture in National Governments: The Cases of Denmark and the Netherlands, Proceedings of the 40th Hawaii International Conference on System Sciences, pp218a (2007).

Johnson P., Ekstedt M.: Enterprise Architecture: Models and Analyses for Information Systems Decision-Making, Lund, Sweden: Studentlitteratur (2007).

Johnson P., Ekstedt M., Silva E., Plazaola L.: Using Enterprise Architecture for CIO Decision-Making: On the Importance of Theory, Proceedings of the 2nd Annual Conference on Systems Engineering Research (CSER) (2004).

Johnson P., Lagerström R., Närman P., Simonsson M.: Enterprise Architecture Analysis with Extended Influence Diagrams, Information Systems Frontiers (9)2–3, pp163–180 (2007).

Jonkers H., van Buuren R., Arbab F., de Boer F., Bonsangue M., Bosma H., ter Doest H., Groenewegen L.,

Scholten J.G., Hoppenbrouwers S., Iacob M.E., Janssen W., Lankhorst M., van Leeuwen D., Proper E., Stam A., van der Torre L., van Zanten G.V.: Towards a Language for Coherent Enterprise Architecture Descriptions, Proceedings of the 7th IEEE International Enterprise Distributed Object Computing Conference (EDOC), pp28–37 (2003).

Jonkers H., Lankhorst M.M., van Buuren R., Hoppenbrouwers S.J.B.A., Bonsangue M., van der Torre L.: Concepts for Modeling Enterprise Architectures, International Journal of Cooperative Information Systems (13)3, pp257–287 (2004).

Kaisler S., Armour F.J., Valivullah M.: Enterprise Architecting: Critical Problems, Proceedings of the 38th Annual Hawaii International Conference on System Sciences, pp224b (2005).

Kappelman L.A. (Ed.): The SIM Guide to Enterprise Architecture, New York, NY: CRC Press (2010).

Kearns G.S., Lederer A.L.: A Resource-Based View of Strategic IT Alignment: How Knowledge Sharing Creates Competitive Advantage, Decision Sciences (34)1, pp1–29 (2003).

Kettinger W.J., Marchand D.A., Davis J.M.: Designing Enterprise IT Architectures to Optimize Flexibility and Standardization in Global Business, MIS Quarterly Executive (9)2, pp95–113 (2010).

King W.R.: Creating a Strategic Capabilities Architecture, Information Systems Management (12)1 (1995).

Kosanke K., Vernadat F.B., Zelm M.: CIMOSA: Enterprise Engineering and Integration, Computers in Industry (40)2–3, pp83–97 (1999).

Lankhorst M.M.: Enterprise Architecture at Work: Modeling, Communication, and Analysis, Heidelberg, Germany: Springer-Verlag (2005).

Lee Y.W., Strong D.M., Kahn B.K., Wang R.Y.: AIMQ: A Methodology for Information Quality Assessment, Information & Management (40)2, pp133–146 (2002).

Liles D., Presley A.: Enterprise Modeling Within an Enterprise Engineering Framework, in Charnes J.M. et al (Eds.), Proceedings of the 1996 Winter Simulation Conference, pp993–999 (1996).

Lindström Å., Johnson P., Johansson E., Ekstedt M., Simonsson M.: A Survey on CIO Concerns—Do Enterprise Architecture Frameworks Support Them?, Information Systems Frontiers (8)2, pp81–90 (2006).

Lippman S.A., Rumelt R.P.: Uncertain Imitability: An Analysis of Interfirm Differences in Efficiency Under Competition, The Bell Journal of Economics (13)2, pp418–438 (1982).

McGovern J., Sims O., Jain A., Little M.: Enterprise Service-Oriented Architectures: Concepts, Challenges, Recommendations, New York, NY: Springer (2006).


McGovern J., Ambler S.W., Stevens M.E., Linn J., Sharan V., Jo E.K.: A Practical Guide to Enterprise Architecture, Upper Saddle River, NJ: Prentice Hall (2004).

Miller D.: Configurations of Strategy and Structure: Towards a Synthesis, Strategic Management Journal (7)3, pp233–249 (1986).

Obitz T., Babu K.M.: Enterprise Architecture Expands its Role in Strategic Business Transformation: Infosys Enterprise Architecture Survey 2008/2009, Survey, Infosys (2009); refer to: www.infosys.com/offerings/IT-services/architecture-services/ea-survey/Pages/index.aspx (current April 5 2011).

O’Rourke C., Fishman N., Selkow W.: Enterprise Architecture Using the Zachman Framework, Boston, MA: Thomson Course Technology (2003).

Parr A.N., Shanks G.G., Darke P.: Identification of Necessary Factors for Successful Implementation of ERP Systems, Proceedings of the IFIP TC8 WG8.2, pp99–120 (1999).

Pereira C.M., Sousa P.: A Method to Define an Enterprise Architecture using the Zachman Framework, Proceedings of the 2004 ACM Symposium on Applied Computing, pp1366–1371 (2004).

Peristeras V., Tarabanis K.: Towards an Enterprise Architecture for Public Administration using a Top-Down Approach, European Journal of Information Systems (9)4, pp252–260 (2000).

Perks C., Beveridge T.: Guide to Enterprise IT Architecture, New York: Springer (2003).

Porter M.E.: What Is a Strategy?, Harvard Business Review (74)6, pp61–78 (1996).

Prahalad C., Hamel G.: The Core Competence of the Corporation, Harvard Business Review (68)3, pp79–91 (1990).

Pulkkinen M.: Systemic Management of Architectural Decisions in Enterprise Architecture Planning. Four Dimensions and Three Abstraction Levels, HICSS '06: Proceedings of the 39th Annual Hawaii International Conference on System Sciences, pp179a–179a (2006).

Reed R., DeFillippi R.J.: Causal Ambiguity, Barriers to Imitation, and Sustainable Competitive Advantage, The Academy of Management Review (15)1, pp88–102 (1990).

Reynolds P., Thorogood A., Yetton P.: Allocation of IT Decision Rights in Multi-Business Organizations: What Decisions, Who Makes them, and When are they Taken?, ICIS 2010 Proceedings, Paper 169 (2010).

Richardson G., Jackson B., Dickson G.: A Principles-Based Enterprise Architecture: Lessons from Texaco and Star Enterprise, MIS Quarterly (14)4, pp385–403 (1990).

Ross J.W.: Creating a Strategic IT Architecture Competency: Learning in Stages, MIS Quarterly Executive (2)1, pp31–43 (2003).

Ross J.W., Westerman G.: Preparing for Utility Computing: The Role of IT Architecture and Relationship Management, IBM Systems Journal (43)1, pp5–19 (2004).

Ross J.W., Weill P., Robertson D.C.: Enterprise Architecture As Strategy: Creating a Foundation for Business Execution, Boston, MA: Harvard Business School Press (2006).

Ruh W.A., Maginnis F.X., Brown W.J.: Enterprise Application Integration: A Wiley Tech Brief, Hoboken, NJ: John Wiley & Sons, Chapter 7, pp131–151 (2001).

Sabherwal R., Chan Y.E.: Alignment Between Business and IS Strategies: A Study of Prospectors, Analyzers, and Defenders, Information Systems Research (12)1, pp11–33 (2001).

Salmans B., Kappelman L.A.: The State of EA: Progress, Not Perfection, in Kappelman L.A. (Ed.): The SIM Guide to Enterprise Architecture, pp165–217 (2010).

Schekkerman J.: How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework, 3rd Edition, Bloomington, IN: Trafford (2006).

Segars A.H., Grover V.: Designing Company-Wide Information Systems: Risk Factors and Coping Strategies, Long Range Planning (29)3, pp381–392 (1996).

Sowa J., Zachman J.A.: Extending and Formalizing the Framework for Information-Systems Architecture, IBM Systems Journal (31)3, pp590–616 (1992).

Spewak S.H., Hill S.C.: Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology, Hoboken, NJ: John Wiley & Sons (1992).

Tamm T., Seddon P.B., Shanks G., Reynolds P.: How Does Enterprise Architecture Add Value to Organizations?, Communications of the Association for Information Systems (28), Article 10, pp141–168 (2011).

Tapscott D., Caston A.: Paradigm Shift: The New Promise of Information Technology, New York, NY: McGraw-Hill (1993).

The Open Group: The Open Group Architecture Framework (TOGAF), Version 9 (2009).

Treacy M., Wiersema F.: Customer Intimacy and Other Value Disciplines, Harvard Business Review (71), pp84–93 (1993).

Venkatesh V., Bala H., Venkatraman S., Bates J.: Enterprise Architecture Maturity: The Story of the Veterans Health Administration, MIS Quarterly Executive (6)2, pp79–90 (2007).

Vernadat F.: Interoperable Enterprise Systems: Principles, Concepts, and Methods, Annual Reviews in Control (31)1, pp137–145 (2007).

Wang R.W., Strong D.M.: Beyond Accuracy: What Data Quality Means to Data Consumers, Journal of Management Information Systems (12)4, pp5–34 (1996).

Wegmann A.: On the Systemic Enterprise Architecture Methodology (SEAM), International Conference on Enterprise Information Systems (ICEIS), pp483–490 (2003).

http://www.infosys.com/offerings/IT-services/architecture-services/ea-survey/Pages/index.aspx

http://www.infosys.com/offerings/IT-services/architecture-services/ea-survey/Pages/index.aspx


Weill P., Ross J.W.: IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Cambridge, MA: Harvard Business School Press (2004).

Whitman L., Ramachandran K., Ketkar V.: A Taxonomy of a Living Model of the Enterprise, Proceedings of the 2001 Winter Simulation Conference, pp848–855 (2001).

Winter R., Fischer R.: Essential Layers, Artifacts, and Dependencies of Enterprise Architecture, Proceedings of the 10th IEEE Conference on International Enterprise Distributed Object Computing Workshops, pp30 (2006).

Woods D., Mattern T.: Enterprise SOA: Designing IT for Business Innovation, Cambridge, MA: O'Reilly (2006).

Youngs R., Redmond-Pyle D., Spaas P., Kahan E.: A Standard for Architecture Description, IBM Systems Journal (38)1, pp32–50 (1999).

Zachman J.A.: A Framework for Information Systems Architecture, IBM Systems Journal (26)3, pp276–292 (1987).

Zachman J.A.: Enterprise Architecture: The Issue of the Century, Database Programming and Design (1997).

Zachman J.A.: You Can't ‖Cost-Justify‖ Architecture, Zachman International (2001); refer to: www.aeablogs.org/eakd/files/ You_Cant_Justify_Architecture.pdf (current April 5 2011).

Zachman J.A.: Architecture Is Architecture Is Architecture, in Kappelman L.A. (Ed.): The SIM Guide to Enterprise Architecture, pp37–45 (2010).

http://www.aeablogs.org/eakd/files/%20You_Cant_Justify_Architecture.pdf

http://www.aeablogs.org/eakd/files/%20You_Cant_Justify_Architecture.pdf


Article

Context-Awareness in Collaboration Architecture: A Conceptual Model for an Enterprise

By Abhijit Sur

Abstract

Collaboration is essential within an organization to connect the right group of people to share knowledge and solve business problems. As enterprises strive to deploy a collaboration platform to capture and distribute ―collective user value‖, they now face another challenge – how to make this platform efficient and productive. This article discusses the role of context-awareness within a collaboration framework. It outlines how a collaboration platform that is aware of the context for collaboration will have capabilities of adapting the collaboration experience. Outlining attributes that define context for enterprise collaboration, we have built a conceptual delivery platform for collaboration services. We present four architecture principles that would enable a collaboration platform to be context-aware. A key consideration of this article is to include business processes within the realm of enterprise collaboration.

Keywords

Enterprise, Architecture, Communication, Collaboration, Context, Context-awareness

INTRODUCTION

The term context-aware was first used in mobile distributed computing systems [1], where context-aware software was required to be adaptive, based on the changing execution environment of the user and the device from which the application was being accessed. Most recent research on context has been based on relevance of context-awareness for session-based (synchronous) communications [2, 3]. However, when it comes to collaboration within an enterprise, we would encounter scenarios that need not be session-based (such as use of emails, enterprise blogs, and wikis). The latter scenarios are often referred to as asynchronous collaboration. This article outlines a conceptual context-aware platform for an enterprise collaboration framework – how it can capture context of collaboration and use it to tailor user experience.

This article proposes the use of context to enhance collaboration experience within an enterprise. Enterprises regard collaboration as highly essential to capture and distribute collective user value. In a survey of 101 US-based IT and business decision-makers, Forrester found that collaboration tools and technology are transformative in nature and have the potential to foster a competitive advantage [4]. This article proposes four architecture principles as guidelines that would enable a collaboration platform to collect, abstract, and utilize context for an enhanced collaboration experience within an enterprise.

The rest of the article is laid out as follows. We commence our discussion in Enterprise Collaboration

with a brief explanation of enterprise collaboration and its relevance in today’s enterprises. Context-Awareness and its Role in Enterprise Collaboration explains the role of context-awareness in enterprise collaboration. In doing so, we introduce attributes that would define context in a collaboration scenario. Collaboration Architecture – A Reference Model outlines a layered reference model for a platform that would deliver and execute collaboration services in an enterprise. We show the role of each layer on how it enables a collaboration platform to be context-aware – e.g., collect context information, utilize context information, etc. Architecture Principles for Context-Aware Collaboration Platform presents four architecture principles that would enable context-awareness in an enterprise platform. Conclusions provides a brief summary and scope of future work.

ENTERPRISE COLLABORATION

Enterprise collaboration is a process where people and business processes

1 within an enterprise ecosystem

work together towards the realization of common goals and objectives. Collaboration helps an enterprise meet multiple objectives. It can serve as a tool for innovation and development of communities. An enterprise can

1 Clarification of terminology: Most IT projects include people,

process, and technology; and collaboration is no different. However, this article discusses an extended role of business processes within the realm of collaboration. Business process, as defined in this article (unless specified otherwise), refers to business processes within an organization that play the role of a collaborating agent and not the collaboration process.


take advantage of collective intelligence through collaboration with different entities (suppliers, partners, employees, etc.). Collaboration can also help knowledge workers achieve higher efficiency during the process of sharing knowledge and execution of enterprise processes. Ultimately, as shown in Figure 1, collaboration objectives should tie in with the broader business objectives of an enterprise. The degree of association would guide architects in defining tools needed to establish a collaboration platform.

Figure 1: Association between Collaboration and Business Objectives

Enterprise managers rely on their technical departments (IT, Engineering, etc.) to provide a collaboration platform that would ultimately help them achieve their goals in a more effective and time-efficient manner. Based on the responsibilities, collaboration requirements would vary for each group, such as video conference solution, document sharing solution for managing sales leads, etc. Enterprise architects need to keep these specific collaboration requirements in mind while designing an enterprise collaboration platform.

CONTEXT-AWARENESS AND ITS ROLE IN ENTERPRISE COLLABORATION

Context, as discussed in this article, refers to a set of attributes that can enable a differentiated experience. The context information can be used to allocate resources for a collaboration session, personalize it based on preferences of the users and choice of devices. Context can also be used to adapt the type of services that would be used during the collaborative session.

This article draws a distinction between collaboration and a communication session. A communication session is a synchronous exchange of information; however, collaboration need not always be so. As discussed in [5], collaboration scenarios can be grouped into four scenarios – same time and same place, same time and different place, different time and same place, different time and different place. The first two scenarios can be termed as synchronous collaboration, and it would

essentially involve a communication session. Context parameters such as communication channel type (wireless or wired medium) would contribute to the context of such a session. On the other hand, the third and fourth scenarios (which deal with different times) can be referred to as non-synchronous collaboration. Non-synchronous collaboration would rely on resources such as email and blogs (just to name a few). For such non-synchronous collaboration, we would rely on attributes such as content tags to define the context.

Figure 2 presents a pictorial view of the context parameters for the enterprise entities that are relevant for collaboration – Enterprise User, Business Processes, and Enterprise Resources (communication channels, applications, hardware, etc.). The following list outlines the parameters that would define context for enterprise collaboration:

1. User Identity and Profile

a. Relationship with Enterprise

b. User Preferences

2. Collaboration Session/Channel Parameters

a. Device Profile

b. Communication Channel

c. Metadata of Media

3. Collaboration Tags

a. Tags for content/resource (wiki, blog)

b. Tags for followers (follow a team, an employee,

vendor, or discussion)

4. Collaboration Service Enablers

a. Presence Status

b. Location

Figure 2: Context Parameters for Collaboration Entities

The remainder of this section explains these attributes in more detail.

Co

llab

ora

tio

n O

bje

ctiv

es

Innovation

Knowledge Sharing

Business Process Efficiency

Development of Communities

Bu

sin

ess

Ob

ject

ive

s

Revenue Growth

Increased quality customer/partner

experience

Shorter Go-to Market Time

Increased Profitability

Innovation

Knowledge Sharing

Business Process Efficiency

Development of Communities

Increased quality customer/partner

experience

Shorter Go-to Market Time

Increased Profitability

Revenue Growth

Session Parameters

Business Process

Enterprise Resources

Interact

Interact

Interact

Enterprise User

Communicate

Interact

Identity, Profile

Presence, Location

Followers

Tags

Channel Parameters

Channel Parameters

Define Context

Define Context

Define Context

Enterprise Entity

Context Attribute

Legend

Event Correlation


User Identity and Profile

User identity and profile attributes refer to relatively static information about a user. They play a crucial role in authenticating a user and authorizing the use of enterprise services with the help of predefined access rights. A user can be employee, contractor, business partner, etc. The relationship of a user to an enterprise (e.g., position and role of an employee) would define access privileges to services and enterprise resources (communication and information sources). Together with enterprise guidelines for participation, a collaboration platform would act as an enforcement point and authorize rights of use for different collaboration tools and services to the user. When two enterprises operate in a federated model, collaboration platforms need to incorporate several architectural considerations, such as a federated identity management model to establish and enforce access rights of users.

User profile also includes communication preferences (on how to be contacted) that play a critical role in setting up the context for a collaboration session. For example, a service technician, who is mostly on the road, would prefer to be contacted by SMS/MMS and not email. So any workflow process that requires sending an email to the user would need to convert the email into an SMS/MMS format. Most organizations today ignore the individual preferences of a user and use a brute force method by setting up a general guideline; e.g., send email to all technicians. This problem can be solved by providing a very high-level virtualized service (as depicted in Figure 3) – Establish Communication with User. This service in turn relies on many abstracted services, such as: send SMS, send MMS, set up a three-way call, leave voicemail, etc. Based on the context, the service invokes the right communication channel.

Collaboration Session/Channel Parameters

Collaboration session/channel parameters include details such as device profile and channel type. Device profile

2 would determine supported media formats that a

device can receive. A mobile device that cannot receive multimedia (MMS) messages should only be sent text (SMS) messages. Similarly, if communication is over a congested wireless network (high dropped packets), the session should only implement a voice call and not include video session. Channel information is important not only for synchronous communications but even for scenarios where (say) a user needs to update an

2 It is possible that an enterprise uses a device profile for

authentication as well (and not just authorization). For example, devices not registered with an enterprise will not be authorized to access enterprise applications.

enterprise blog – is she connected within the enterprise network or updating it from an enterprise VPN?

Figure 3: Use-Case Model – Establish Communication with User

Collaboration Tags

A user can now take advantage of enterprise resources (such as blogs, forums, and wikis) for helping to get relevant data in an efficient fashion. Users can add keywords to tag content that can be used for subsequent retrieval purposes. Tags serve as metadata for content, providing context information for the resource (blog, wiki). This would help employees to locate a document or media content more efficiently. In addition to search, tags enable more meaningful content distribution and syndication. For example, a particular user group would like to be informed when blogs with certain tags are posted or updated.

Social networks allow users to follow their friends and contacts within their community. COTS tools are available that extend this concept to enterprise collaboration networks as well. Using this technology, enterprise users can follow documents, conversations, business processes, or enterprise applications and people/groups within their community. This becomes a very effective mechanism in syndication of knowledge and information within an enterprise.

Collaboration Service Enablers

Collaboration service enablers refer to attributes such as location and presence status that can be used to define context. Several technology and architecture principles are used to abstract location and presence status information from multiple end-points (desk phone, cell phone, and computer) in the network layer and expose the information (for example, through web services). Applications can invoke SOAP or REST

3 messages to

3 Representational State Transfer.


retrieve the information. For example, a person with ―busy‖ status would mean that calls should directly be sent to his voicemail. The concept of presence can be further refined with ―rich presence‖ information. For instance, busy state could imply either the person is busy in a meeting with her boss or busy working on a document or simply enjoying lunch. An employee may have different communication preferences in each of these scenarios.

COLLABORATION ARCHITECTURE – A REFERENCE MODEL

Context attributes don’t reside at a single point within an enterprise; they are distributed throughout the architecture platform. This section outlines a conceptual layered architecture framework that can collect, expose, and utilize context attributes to provide efficient and productive collaboration. Figure 4 presents a high-level service delivery platform for collaboration services. It’s a generic reference framework; vendors in this space will have their own specific representation of collaboration architecture. The role of each layer in a context lifecycle is presented in Figure 5.

Figure 5: Platform for Collaboration Services

The lowermost layer, Physical Layer, includes network and connectivity resources. An enterprise may own the entire network access/transport layer or rely on partners to provide the network resources (wireless, LAN/WAN). The physical layer includes network resources such as location and presence information of a mobile user. These could be provided by third parties, such as Communication Service Provider (CSP). The Physical Layer also includes enterprise information systems – such as payroll, user profile databases, sales and commission, etc. Physical layer attributes such as medium of communication, users’ network attributes (wireless coverage, location and presence information) contribute to defining context. On the same note, a

business service, based on the context, can request allocation of physical resources for collaboration as well.

Abstraction Layer exposes network, communication, and enterprise resources as atomic services that can be invoked by the service layer. It contributes to collaboration in two ways. First of all, it abstracts network data of a user such as location and presence – that define the context of a user. Secondly, it provides abstracted core network services that can be easily invoked by the service layer (based on the context of the session). A few examples would be services such as Send SMS and Send MMS.

Service Layer is the core layer within a delivery platform. Service enablers encompass service utility components that provide common services, such as identity management, authentication, authorization, and accounting across all services. In an extended enterprise

4 scenario wherein two enterprises offer

collaboration services, authentication is enabled through federated identity management, relying on a negotiation approach between the enterprise networks.

Service Registry and Repository enables service discovery during a collaboration session (based on the context of the collaboration session). It plays a key role in allowing the visibility of services and data based on the context and privacy preferences of the user and enterprise. As highlighted in [6], context and semantic technologies play a crucial role for enabling a secure service discovery solution for enterprise users and processes.

Enterprises, based on their core business, would have different IT applications that would fall under the category of Enterprise Services. For instance, a software development company would have a collaboration application for version control of the code base; a company whose workforce needs to be scheduled for dispatch to customer calls would have an enterprise application for managing dispatch. It would also include general enterprise applications such as email and calendar tools for collaboration.

Communication Services provide several capabilities to communicate amongst users – such as instant messaging, telephony, video conference, SMS, and MMS. An enterprise may have to rely on other CSPs to provide some of these capabilities. Media Services, in a way, can be viewed as a service enabler; however, it is kept as a separate category. It includes services such as transcoding and watermarking. Meta-data of media defines context and how it can be used to invoke

4 Extended enterprise refers to an enterprise network beyond the

boundary of a single enterprise. It can include the public Internet or a peer/partner enterprise network.

Abstraction Layer (Network and Resources)

NetworkAccess/

Transport

EIS Resources

Network Services (QoS, Resource

Allocation)

Enterprise Network and Resources LayerPartner and Third Party (CSP) Physical Infrastructure Network and Resource Layer

Service Execution and Orchestration Layer

Presentation layer

Data Feeds (RSS/ATOM)

Services (SOAP/REST)

Widgets

Assets for Client Mashup

Serv

ice

Man

agem

ent

Service Layer

Media Services

Service Enablers

Communication Services

Enterprise Services

Service Registry and Repository

Collaboration Services (Group Editing, Publishing, Search, Folksonomy)

User Interface for Mobile, PDA, Desktop, Terminal

Collaboration ApplicationsOperationsSales/MKTGCRM

Physical layer


different media services. Finally, the service layer includes Collaboration Services for the users of the platform. It would include applications that enable collaboration, such as a wiki platform and folksonomy application for tagging.

Figure 6: Role of Service Layer for Content-Awareness

Services within Service Layer can be executed as atomic services or they could be composed into composite services. Service Execution and Orchestration Layer provides the capability of executing composite services. It relies on an underlying Business Process Management (BPM) tool. This layer forms the basis of collaboration between process and people of an organization. Based on the outcome of a process, say failure of an order provisioning workflow, the service orchestration layer could, for example, initiate a collaboration session between the technician and a care representative.

Presentation Layer deals with final delivery of content to the user on all possible screens – desktop, laptop, PDA, mobile handset (enterprise guidelines and user preferences will also dictate choice of device). The front-end could be a heavyweight client, as in a client-server framework or a lightweight rich Internet application (RIA) front end. This layer would also include tools that can enhance the collaboration experience.

An example of such a toolkit is an enterprise mashup. Mashups, based on Web 2.0 principles and technologies, are used to solve immediate specific needs of an enterprise. Enterprise mashups (created by users) combine network services, enterprise applications, and information sources (that are provided/exposed by the platform) into a lightweight web application. Mashups can also combine enterprise data with data/services from the public Internet (say Google Maps). For example, a recruiter in a placement agency builds a simple mashup by using the street address (exposed as a service from the enterprise) and overlaying the information on Google Maps.

Mashups help an organization achieve cost reduction and productivity, innovation, and growth [7]. The

collaboration platform has to provide a mashup builder to its workforce, so that users can build mashups by wiring data and services together. The value of a collaboration platform increases significantly if it exposes the services (RESTful services) and data sources (as RSS/ATOM feeds) that can be easily consumed by these lightweight mashups. Enterprise mashups fill the void of long tail [8] of situational applications that enterprises cannot afford to build and deploy using their standard SDLC

5

approach. They provide tools and capabilities to users so that they can build applications to collaborate with one another.

Integrating all the layers of a delivery platform is the Service Management Layer that manages a service once it is deployed. It would include capabilities such as service analytics. This layer would provide enterprise managers with a visibility on the efficiency of the collaboration tools and platform performance metrics. The intention is to associate these metrics to enterprise KPIs, providing insight as to how the transactions related to collaboration meet the business objectives of an enterprise. For example, is a forum/wiki a better asynchronous method for communication than email or mail distribution? When should the collaboration platform put the onus on the sender/source of information versus the seeker? Which forums are more effective in an enterprise than others? In a nutshell, the service layer needs to be integrated with business intelligence, data management, and reporting systems within an enterprise to help measure and analyze these metrics and provide a feedback loop to the service layer to pro-actively respond to incidents.

ARCHITECTURE PRINCIPLES FOR CONTEXT-AWARE COLLABORATION PLATFORM

A flexible collaboration platform provides opportunities to innovate, share knowledge, and support operations within a ―borderless enterprise‖. This section discusses four key architecture principles that can help enterprises leverage context-awareness in their collaboration platform, thereby enabling people and processes to efficiently collaborate with one another. The guidelines presented here are not new within the realm of enterprise architecture; however, together they are powerful in establishing a context-aware collaboration platform.

Principle 1: SOA and REST Principles for Context-Awareness

Service Oriented Architecture (SOA) provides an architecture pattern that requires solution logic to be implemented in the form of loosely-coupled and re-

5 Software Development Life Cycle.


usable services. Strictly speaking, service-oriented design paradigm is not concerned with the context of a service; however, we can use the underlying SOA principles in two ways to provide a context-aware platform. Based on the context, appropriate services (given their loosely-coupled and re-usable nature) can be invoked with the help of a standards-based messaging service (e.g., SOAP/HTTP). In addition, context information (such as presence, location) can be exposed as web services (e.g., Parlay/X web service) through standardized service contracts. A platform can also adopt the REST style (or Restful SOA) to expose services and context information as resources that can be addressed through URLs.

Services built using the SOA paradigm can be modeled as entity services, task services, and utility services. Entity service pertains to a specific functional entity, such as employee, whereas a task service can span the functional boundaries of multiple entities and is often used as a controller/orchestrator service. Utility service provides re-usable functionality that is agnostic of an entity. Figure 6 represents an example of a service model on how services can be designed to provide and utilize context within a collaboration platform.

Figure 7: Sample SOA-Based Service Model for Implementing Context-Awareness

Principle 2: Enhancing Business Process Management for Collaboration

Generally, collaboration is associated with people. However, this article has taken the approach to extend collaboration beyond people

6 of an enterprise to include

business processes. Business process is an equally crucial player for enterprise collaboration. It is important to understand that a collaboration session need not be initiated solely by a human. A business process can also

6 People can include (depending on an enterprise’s policy) employees,

business partners, and customers.

initiate a collaboration session. Figure 7 (Option III) depicts an example of how an automated business process can initiate a collaboration process.

Figure 8: Business Process as an Agent of Collaboration

Event Driven Architecture (EDA) style has been gaining ground in the business process management domain. Often it is related with SOA. However, there are two significant differences with SOA.

EDA provides the capability to decouple the source of an event and the event handler. It also provides the capability to correlate multiple events, generate derived events, and subsequently process them.

7 The

correlation of events can generate context of a business process and enable the BPM process orchestrator to adapt the collaboration process accordingly.

Figure 8 presents one possible business layer model that we have built to help visualize enterprise collaboration. We have chosen the ArchiMate modeling language since it provides a mechanism to model business, applications, and infrastructure viewpoints and a visualization of their inter-relationships.

As we can see in Figure 9, both business processes and events (such as alert notifications) can create a need for collaboration between users (represented as roles). The collaboration is realized through collaboration services that are made available to the platform users. The collaboration is governed and managed through enterprise policies, one of them being context-awareness policy. The reader is encouraged to refer to [9] for additional details on ArchiMate language.

7 This capability, however, is associated with Complex Event

Processing (CEP), which is one of the categories of EDA.

Task Centric Service

Utility Service

Context of an Entity

Entity Centric Service

Define Context of an entity (e.g. Define user’s relationship to enterprise = “Employee”)

Consume Context of an entity for executing a service on an entity (e.g. Send message to

an employee based on user’s communication preference)

Provide Context of an Entity (e.g. Update

Location and Presence status of user)

Consume Context of an entity for

executing a service (e.g. Authorize a

user based on user’s relationship

to enterprise)

Consume Context of an Entity for a specific business process (On-

boarding process of an employee – assign assets based on role

in a company)

Scenario: Customer places a order on an online laptop retail site. However, after the order has been submitted, the order handling process detects an error in the loading of the additional software onto the hard disk of the laptop.

Option I

Order Handling process generates a trouble ticket which gets assigned to a

person

Option II

In addition to generating a trouble

ticket, Order Handling process sends an email blast to the Help Desk

Option III

In addition to generating a trouble

ticket, Order Handling process posts an

automated blog post with the pre - defined tags. Employees who have opted to receive RSS feeds on the tags

also get notified.

Increasing degree of collaboration


Figure 9: An Architecture Model for Enterprise Collaboration with Business Processes

Principle 3: Folksonomy for Collaborative Tagging

Folksonomy is a key part of the Web 2.0 architecture and relies on a free form annotation of web resources done by its users, without the constraints of a predefined taxonomy [10]. Given its free-form and flat hierarchical structure, folksonomy aims to make the web more ―semantic‖. However, this lack of structure can be seen as ―search noise‖ and conflict with official taxonomies within an enterprise [11]. Thus, enterprises need to have a business and technical strategy for striking a happy medium balance and let folksonomy and an official taxonomy complement each other. The final technical solution should be able to avoid ―search noise‖ by preventing users from adding tags that don’t provide any relevance (e.g., prevent adding ―stupid‖ as a tag for a non-relevant post).

An enterprise can opt for an enterprise Content Management System (CMS) that provides a layer for managing meta-data (tags) or integrate their existing

CMS with a tag management system. The final solution would require the following strategic (business and technical) steps:

1. Develop a governance model on who can create and manage tags – is it the content producer or consumer or both (maybe employing a rating scheme on the relevance of each tag)?

2. Develop a strategy on whether there should be a formal ontology layer underneath the folksonomy tag layer that would map the popular user tags to a more formal tag cloud.

Principle 4: Meta-Data of Digital Media for Context Information

Meta-data continues to be a crucial factor to provide context information even for digital media content. Based on the consumers and channels that are available for the digital media content, it needs to be re-purposed such as transcoded, watermarked, etc. As explained in [12], one way of achieving this is to make the Enterprise Service


Bus (ESB) media-aware. (ESB, a critical component of SOA architecture, connects service requestors and service providers through its message mediation capabilities. It also needs to perform conversions of messaging protocols and message interaction patterns, based on the capabilities of the service requestor and provider.) A standard ESB performs four functions on messages – mediation, transformation, dynamic routing, and persistence. A media-aware ESB extends the same four functions to media objects. This can be achieved by ―building intelligence‖ into the ESB to examine the meta-data of the media content and dynamically invoke processes and/or route media to the most appropriate channel or process for that particular media object.

CONCLUSIONS

As organizations are adapting themselves to a ―flatter world‖, the underlying landscape of enterprise collaboration has been changing. The emergence and proliferation of Web 2.0-based technologies have

spurred enterprises to provide an underlying platform that would enable their distributed workforce to collaborate efficiently. Collaboration is essential to create and syndicate core competencies within an enterprise and its partners. This article has discussed a technology framework that will allow an enterprise to use context

information to provide a differentiated collaboration experience.

As a part of our ongoing research, we intend to study how context-awareness affects the efficiency and effectiveness of the collaboration process through the study of enterprise metrics, such as cost of transactions facilitated by collaboration.

ABOUT THE AUTHOR

Abhijit Sur is a Principal Solution Architect with more than 15 years of experience at architecting, designing, and implementing large-scale projects within the telecommunications industry. He received his MS in Statistics from the Indian Institute of Technology (IIT) at Kanpur (India) and his MS in Telecommunications from the University of Colorado at Boulder (USA). He has led the development of ―rich presence‖ and digital media solutions, enabling communication service providers to deploy collaboration services for the consumer and enterprise markets. He can be contacted at [email protected].

ACKNOWLEDGEMENTS

The author thanks Steve Mannel (Global Industry Executive, Media & Communications at Salesforce.com) for his attention to detail while reviewing this article. The author also thanks Marc Lankhorst (Novay, Enschede, The Netherlands) for reviewing the ArchiMate model.

REFERENCES

[1] Schilit B. et al: Context-Aware Computing Application, IEEE Workshop on Mobile Computing Systems and Applications (WMCSA), Santa Cruz, CA, USA, pp89-101 (1994).

[2] Sun J. & Sauvola, Jaakko: Towards a Conceptual Model for Context-Aware Adaptive Services, Proceedings of the Fourth International Conference on Parallel and Distributed Computing, Applications and Technologies (PDCAT), pp90-94 (2003).

[3] Henricksen K., Indulska J., Rakotonirainy A.: Modeling Context Information in Pervasive Computing Systems, Pervasive Computing, Lecture Notes in Computer Science, Vol. 2414, pp79-117 (2002).

[4] Forrester: The Right Collaboration Architecture Drives Business Transformation (2009).

[5] Liesenberg P.: Architecting Collaborative Applications, ebizQ, 04/16/2009; refer to: www.ebizq.net/topics/enterprise_integration_architecture/ features/11186.html.

[6] Toninelli A., Montanari R., Corradi A.: Enabling Secure Service Discovery in Mobile Healthcare Enterprise Networks, IEEE Wireless Communications, pp24-32 (June 2009).

[7] The Business Case for Enterprise Mashups, IBM (2008).

[8] Anderson C.:The Long Tail, Wired Magazine (October 2004); refer to: www.wired.com/wired/archive/12.10/tail.html.

[9] Lankhorst M. et al: Enterprise Architecture at Work, Springer (2009).

[10] Wu X., Zhang L., Yu Y.: Exploring Social Annotations for the Semantic Beb, in WWW ’06: Proceedings of the 15th international Conference on the World Wide Web, New York, NY, USA, ACM Press, pp417-426 (2006).

[11] Johnston K.: Folksonomies, Collaborative Filtering, and e-Business: Is Enterprise 2.0 One Step Forward and Two Steps Back?, The Electronic Journal of Knowledge Management, Volume 5, Issue 4, pp411-418.

[12] Sur A., Schaffa F. et al: Extending the Service Bus for Successful and Sustainable IPTV Services, IEEE Communications Magazine, pp96-103 (August 2008).


http://www.ebizq.net/topics/enterprise_integration_architecture/%20features/11186.html

http://www.ebizq.net/topics/enterprise_integration_architecture/%20features/11186.html

http://www.wired.com/wired/archive/12.10/tail.html


Article

Evaluating the Effectiveness of Reference Models in Federating Enterprise Architectures

By Jeffery A. Wilson, Thomas Mazzuchi, and Shahram Sarkani

Abstract

Reference models to federate enterprise architectures across multiple agencies are investigated as a means to provide greater mission effectiveness and increased efficiencies. While heuristic and qualitative approaches to federating enterprise architectures have led to the increased use of reference models, their actual effectiveness and value have not been quantified.

Federal departments and agencies are under increasing pressure to provide effective government and citizen services with improved efficiency. Enterprise architectures are used to align agencies’ strategic goals and business objectives to resources. As agencies collaborate with each other to achieve better strategic performance and resource savings, the ability to share information about their enterprise architectures is critical to their success.

The expected effectiveness of reference models in federating enterprise architectures was quantified employing the classical method of expert judgment. A structured discussion instrument to evaluate reference models was developed and piloted using well-established guidelines for expert judgment. The resulting instrument was used in structured discussions with architects and engineers who are members of an architecture working group across multiple federal government agencies. Reference models were determined to be effective for federating enterprise architectures where participating agencies align their component architectures to the common taxonomy provided by the reference models.

Keywords

Enterprise Architecture, Reference Model, Expert Judgment

INTRODUCTION

Within Federal government and industry, leaders strive to provide effective and efficient services. Given mandates such as the Clinger-Cohen Act and the need for good resource management, managers are investigating how to improve enterprises by identifying and analyzing potential duplicative investments, capability gaps, and opportunities for collaboration within and across agencies. Within the Federal government, this cross-agency analysis is being accomplished through the use of reference models within the Federal Enterprise Architecture (FEA) (OMB 2007a). With the FEA, the Office of Management and Budget (OMB):

―… is attempting to provide federal agencies and other decision-makers with a common frame of reference or taxonomy for informing agencies’ individual enterprise architecture efforts and their planned and ongoing investment activities, and to do so in a way that identifies opportunities for avoiding duplication of effort and launching initiatives to establish and implement common, re-usable, and interoperable solutions across agency boundaries.‖ (GAO 2004 p2).

Architecture frameworks are used to describe architectures in their ―as-is‖ and ―to-be‖ states along with transition and sequencing plans. Multiple architecture frameworks are used by various departments and

agencies to describe their enterprise architectures and programs. The researcher is a participant within a group of enterprise architects and engineers working to improve mission effectiveness and efficiency by federating architectures across multiple agencies. The federation method employed within the working group is based on the Global Information Grid (GIG) Architecture Federation Strategy and uses a 10-layer architecture reference model traceable to the FEA. The 10-layer architecture model uses concepts from the Enterprise Architecture Cube

TM (Bernard 2005) and the ISO Model

of Architecture for Open Systems Interconnection (OSI) (Zimmermann 1980). The 10-layer model (Figure 1) incorporates Operational Drivers such as strategic vision, policies, people, and processes in the upper layers and uses a taxonomy in the lower layers contained in the Operational Services & Content and Undercarriage Services to categorize technical services. Three vertical overlays of Management, Data, and Security cross the horizontal layers incorporating pertinent aspects for enterprise emphasis.

The expert judgment classical method has been used to elicit expert opinion to quantify the effectiveness and efficiency of reference models in federating enterprise architectures. The reference model approach was


evaluated for shared, interdependent missions and shared applications/infrastructure. The quantification of reference model effectiveness for enterprise federation can assist the refinement of enterprise architecture practice. Reference models were determined to be an effective practice within this study for federating enterprise architectures. Future studies are recommended to validate the results of this expert judgment research.

Figure 1: 10-Layer Architecture Reference Model

ENTERPRISE ARCHITECTURE

Enterprise architectures describe complex environments composed of people, process, and technology and are used to improve strategic alignment of IT investments to mission (business) goals. Bernard (2005 p31) defines enterprise architecture as:

―… the analysis and documentation of an enterprise in its current and future states from an integrated strategy, business, and technology perspective‖.

The OMB (2007b pA-1) defines enterprise architecture as:

―… a management practice for aligning resources to improve business performance and help agencies better execute their core missions. An enterprise architecture describes the current and future state of the agency, and lays out a plan for transitioning from the current state to the desired future state.‖

These definitions share the concepts of alignment with the business processes, direction of resources, and transition from a current state to future state.

Architecture Frameworks and Reference Models

Zachman (1987) espoused the need to describe information systems within a framework enabling architecture descriptions from a set of views representing different perspectives. Multiple architecture frameworks have been developed and are in use to

provide a structure to describe enterprise architectures. The Government Accountability Office (GAO 2003) (formerly General Accounting Office) survey of federal agencies identified different frameworks that agencies use to describe their architectures. These included the Federal Enterprise Architecture Framework (FEAF), the Federal Enterprise Architecture Program Management Office (FEAPMO) Reference Models, the Zachman Framework, the Treasury Enterprise Architecture Framework (TEAF), the National Institute of Standards and Technology Framework (NIST framework), the Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Framework, and the Department of Defense Architecture Framework (DoDAF).

Morganwalp (2002) identified five desirable features of an enterprise architecture framework: encompasses enterprise-wide views, facilitates systems integration, driven by or founded upon business requirements, flexible enough to support frequent changes in technology and/or business, and comprehensive. Given the various frameworks used by different agencies the ability to create enterprise-wide views (when the enterprise boundary extends to include multiple agencies) and collaborate can be limited by language and inability to translate between frameworks. Rechtin (2000 p45) noted that even similar organizations have troubles communicating because ―each organization has a different culture, a structure of beliefs, and behavior patterns and practices‖. Within the GIG Architecture Federation Strategy (DoD 2007) these challenges are recognized given the large size of the DoD enterprise comprising multiple organizations and elements with different frameworks and vocabularies used to describe their architectures. Winter and Fischer (2006) describe and demonstrate through the use of case studies an approach of using layering and appropriate level of abstraction to provide broad views when comparing enterprise architecture and this concept is incorporated within this research.

FEA Reference Models

The FEA reference models were included in the GAO survey (2003), but they differ in that the FEA reference models represent a taxonomy with which agencies align or map their enterprise architectures. Reference models provide a means to compare disparate architecture framework products. The FEA (OMB 2007a p5): ―consists of a set of interrelated ―reference models‖ designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across agencies‖. The five inter-related FEA reference models are the Performance Reference Model (PRM), Business Reference Model (BRM), Service Component Reference


Model (SRM), Technical Reference Model (TRM), and Data Reference Model (DRM).

An anticipated benefit of a reference model approach is the ability of individual agencies/programs that use different architecture frameworks to describe their enterprise architecture within a common taxonomy. The GIG Architecture Federation Strategy approach and FEA involve aligning component architectures within a common framework of semantic understanding (DoD 2007). By using a common taxonomy/framework, reference models anticipate overcoming some of the communication barriers noted by Rechtin (2000). Federation is differentiated from integration in that the former’s objective is to enable the interoperability between disparate architectures versus integrating them into a single enterprise architecture. Fischer et al (2007) note that the federated approach to enterprise architecture models provides a valuable tool for insights into current and future architectures not available before by bringing participating architectures together and that the element architecture owner acceptance is very high since they maintain ownership of their respective architectures.

10-Layer Architecture Reference Model

The 10-Layer Architecture Reference Model is intended to facilitate federation of agency enterprises through a common language that supports cross-agency reporting and decision-making. The 10-Layer Architecture Reference Model (Figure 1) is being used by the participating agencies and programs to improve future versions of the FEA reference models for their community of interest. The 10-layer model was in use within one of the participating agencies prior to being selected and adapted for use within the community of interest.

The model incorporates Operational Drivers such as strategic vision, policies/doctrine, people, capabilities, and processes in the upper layers to guide a business-driven approach to the federated architecture. Layer 10, Operational Objectives and Policies, relates to both internal and external objectives and policies which guide the enterprise and drive the required capabilities. Layer 9, Capability Areas and Threads, describes enterprise capability areas and threads that make service calls to instances or activities and integrates/orchestrates the service delivery to complete the thread. Layer 8, Enterprise Activities and Exchanges, provides or calls on a set of services at the same level or from lower layers to perform the functions or requirements of a thread and could be performed by human or a machine/expert system. Layer 8 contains business component modeling and services which are equivalent to the FEA BRM (business functions) and the FEA SRM (service

components independent of business functions). Layers 7 and 6 represent Operational Services and Content for software performing specific activities and repositories of operational content. Layers 5 through 1 represent Undercarriage Services which are enterprise-wide software and hardware services using shared networks and facilities. The lower layers provide the foundation for the higher levels which execute the technical and business services based on the strategic vision, policies, and processes. The model includes vertical overlays/domains for emphasis of the Data/Information, Security, and Management aspects of the enterprise.

This layered view is consistent with the layered view presented by Lankhorst (2005) and Maier & Rechtin (2009). Consistent with Lankhorst (2005), the lower levels may directly interact with any of the higher layers. The layered presentation of each of the participating agencies when brought together can be thought of as similar in structure to the Enterprise Architecture Cube

TM

(Bernard 2005) with each of the agency’s layered views being considered an architecture segment.

MEASURES OF EFFECTIVENESS FOR ASSESSING REFERENCE MODELS

Effectiveness measures and assessment frameworks were reviewed to apply to the evaluation of reference models for federating enterprise architectures. The GAO’s Information Technology Investment Management (ITIM) Framework and OMB’s Enterprise Architecture Management Maturity Framework (EAMMF) have value measures and assessment frameworks applicable to IT and enterprise architecture maturity. These measures, while applicable to measuring the maturity of an IT or enterprise architecture program, were determined to not be applicable to this study on federating architectures. Buchanan (in Morganwalp & Sage 2004) provides a list of financial and business benefits that should result from a high-quality enterprise architecture. Morganwalp (2002) used these benefits as qualitative measures to evaluate an enterprise architecture framework and development process. These benefits used by Morganwalp were found to be applicable to the assessment of reference models for federating enterprise architectures and were used as shown in Table 1 with the expert judgment classical method.

Two modifications were made to adapt these benefits as measures for use within this research based upon a pilot evaluation with three enterprise architects. First, the Financial Efficiency benefit of ―Re-use‖ was evaluated at the subdivisions of Re-use of Hardware Components, Re-use of Software Components, and Re-use of Methods. Second, the Business Effectiveness benefit of ―Alignment‖ was evaluated at the subdivisions of Tighter Alignment of Business Strategy and Architecture Process Stream of Logic. The rationale to use these


subdivisions was based on the pilot evaluation participants’ belief that meaningful differences may exist within those divisions in the quantitative evaluation of reference models.

Table 1: Financial Efficiency and Business Effectiveness Enterprise Architecture Measures

(Adapted by authors from Morganwalp & Sage (2004) as noted in text.)

Financial Efficiency

1. Re-use of Hardware Components

Infrastructure subassemblies

Common client platforms for well-defined types of users

Servers run as multiple instances of a single image

1. Re-use of Software Components

System software components

Middleware components

Business-specific components

Application components and variants

Architecture technical domains

2. Re-use of Methods

Architecture analysis and process model

Object-oriented business and software engineering methods

System and software test methods

Engineering tool methods

3. Reduced Time-to-Delivery

Application delivery can leverage common infrastructure services

Business objects and components do not need to be rebuilt

Subcontractors can predict infrastructure capability and IT management skills

Integration framework minimize engineering time requirements

4. More Efficient Program Management

Programs manage portfolios of IT work products

Program disciplines are enhanced though re-use of methods

Emphasis is on leading, not lagging, program indicators

5. Reduced Support Costs

Reduced complexity

More rigorous ―lab-based design‖

More accurate, integrated data

6. Lower Acquisition Costs

Smaller set of components

Enhanced negotiating leverage

Visibility of legacy and future architecture for reducing risk

Financial Efficiency

7. Technical Adaptability

Geographic range of architecture extended

Range of data types expanded

Scalability

Extensibility

Portability

Interoperability

Business Effectiveness

1. Tighter Alignment to Business Strategy

Architecture process is top-down, business strategic-driven, and future-oriented

Value opportunities are tested and analyzed

2. Architecture Process Stream of Logic

Environmental trend analysis identifies threats and opportunities

Business strategy requirements identify strategic intent and business architecture

Information requirements identify what information is required for strategic success

Architecture requirements identify what technical functionality is required to supply the information

Enterprise application portfolio and infrastructure requirements identify how the technical functionality will be provided

Enterprise program management identifies the most efficient delivery plan

3. Knowledge Development

Business managers are educated about IT

IT managers are educated about business

Financial and architecture methods interoperate

Information requirements and architecture are formalized

Information is user-focused, not simply a data element

4. More Sophisticated Asset Management

Resource allocations are based on business strategic value

Emphasis is on leading not lagging, indicators of strategic success

5. Reduced Decision Risks

Time saving in strategic planning

Architecture artifacts describing the theory of the business and improving consensual decision-making

More rigorous strategy-based decision-making

More accurate market, competitive, and operational calculus


Business Effectiveness

6. Tighter Strategic Alignment with Partners

Roles within the integrated value chain modeled and negotiated

Business engagement rules formalized and automated

Visibility of business models for reducing risk

7. Business Adaptability

Sensitivity to future and technology trends

Digital innovation

Replacement of physical goods movement with sharing of information

Identification of opportunities for strategic alliances

Speed of decision-making and implementation

EXPERT JUDGMENT

Expert judgment has been used to quantify risks and make assessments within fields such as nuclear safety (Cooke 1991), reliability (Mazzuchi et al 2008), and information security (Ryan et al 2011). Based on the authors’ literature review, this is the first time that expert judgment techniques have been used to evaluate the effectiveness of reference models in federating enterprise architectures. To judge the success of models and frameworks by cause-and-effect is difficult given the timeframes involved (multiple years and planning cycles) and multiple intervening events (changing world events, organizational budget changes, leadership changes, etc.). The ability of expert judgment to quantify effectiveness was leveraged within this study to quantify the effectiveness of the use of architecture reference models to inform future enterprise federation activities.

For this research, the classical method described by Cooke (1991) and Ryan et al (2011) was selected for the elicitation and combining of expert judgment. Within the classical method:

―… experts provide a distribution for unknown quantities by specifying 5th, 50th, and 95th percentile values for the quantities of interest‖ (Ryan et al 2011 p3)

The unknown quantities within this research pertain to the effectiveness of reference models in federating enterprise architectures. The individual expert’s judgments are combined with the other experts using weights:

―… derived from the experts’ responses to a set of seed variables whose values [realizations] are known by the analyst and which are used to ―calibrate‖ the accuracy of the expert’s opinions‖ (Ryan et al 2011 p3)

The 90% confidence interval represents the expert’s judgment of the potential outcomes given surrounding ambiguities.

The 16 experts within this study were selected out of an architecture working group using reference models to

ensure that a cross-section of the participating agencies was represented. The use of 16 experts and nine seed variables is consistent with both empirical studies and simulations of expert judgment using the classical method (Gehris 2008).

The working group participants were selected by their agencies to represent and support them and include government and contractors with extensive experience in and training on enterprise architectures and systems engineering.

The expert elicitation followed the guidelines of Cooke and Goossens (1999) and was conducted via structured one-on-one, face-to-face discussions. The discussion instrument and data collection sheet was piloted with three enterprise architects. The discussion instrument contains seed variables (Table 2) pertinent to enterprise architectures and questions based on the enterprise architecture measures (Table 1) discussed in the preceding section.

Selection of seed variables was complicated by the high level of abstraction used within reference models and the limited quantification within academic and publicly available information. Each expert was asked to provide what he/she believes to be the realization for each seed variable along with a range that would incorporate the realization with high confidence (5%, 95%).

Table 2: Discussion Instrument − Seed Variables and Realizations

Seed Variable Realiz-ation Reference

XX% of performance goals were met within recent Government Performance and Results Act assessment reports.

72% OMB (2009); www.ExpectMore. gov

XX% of 2008 IT industry survey respondents indicated they were currently working on a Service-Oriented Architecture (SOA) project.

55% Architecture & Governance (2008)

XX% of 2008 IT industry survey respondents indicated "a common, scalable information repository" as an important tool for IT planning success.

75% Architecture & Governance (2008)

XX% of IT projects are on OMB's Management Watch List of poorly planned and/or poorly performing.

41% GAO (2007)

XX% of companies have digitized their core processes.

34% Ross (2006 p2)


Seed Variable Realiz-ation Reference

Those companies who digitized their core processes have XX% lower IT costs than competitors.

25% Ross (2006 p2)

XX% of system engineers responded that system integration is improved as a result of an increase in open system-orientation.

51% Jain et al (2008 p217)

XX% of applications are application islands characterized by ad hoc deployment of enterprise applications and disordered intercommunications between applications.

31% Wu et al (2007 p445)

An enterprise approach to applications provided by service-based architectures has been found to provide XX% cost savings.

17% Wu et al (2007 p445)

Calibration scores and information scores for each expert were determined using the classical method by comparing the responses to the realizations. The expert’s calibration score is based on where the responses fall compared to the realizations (bins of 0-5%, 5-50%, 50-95%, and 95-100% are used in this research). The closer the expert’s responses fall to the realizations, the higher his/her calibration score given more responses would be in the 5-50% and 50-95% bins. The more responses fall into the 0-5% and 95-100% bins (i.e., the expert response did not include the realization), the lower the calibration score. The expert’s information score is a measure of how certain he or she is in their responses. Large ranges will result in a low information score and small ranges will result in a high information score. The expert’s calibrated weight is the product of their calibration and information scores normalized so the weights sum to one. Table 3 summarizes the calibration scores, information scores, un-normalized weights, and normalized calibrated weights. Expert 8 received the highest weight and several experts (5, 11, 12, and 13) received zero weight. It is not unusual for the classical method to assign zero weight to experts (Ryan et al 2011).

Table 3: Expert Scores and Weights for Seed Variables

Expert Calibration

Score Information

Score

Un-Normalized

Weight Calibrated

Weight

1 0.037 0.881 0.033 0.022

2 0.048 0.808 0.039 0.027

3 0.593 0.389 0.230 0.157

Expert Calibration

Score Information

Score

Un-Normalized

Weight Calibrated

Weight

4 0.200 0.773 0.155 0.105

5 0.000 1.407 0.000 0.000

6 0.005 1.422 0.007 0.005

7 0.200 1.072 0.214 0.146

8 0.254 1.187 0.302 0.205

9 0.037 0.938 0.035 0.024

10 0.164 0.953 0.156 0.106

11 0.000 1.477 0.000 0.000

12 0.000 1.033 0.000 0.000

13 0.000 1.349 0.000 0.000

14 0.154 0.538 0.083 0.056

15 0.014 0.895 0.012 0.008

16 0.254 0.796 0.202 0.138

The experts were then queried on how three different scenarios affected the expected outcomes for the enterprise architecture measures (Table 1). An excerpt of the EA Measures section of the Discussion Instrument is shown in Table 4 for the measure Tighter Alignment to Business Strategy. This example will be followed through the article to demonstrate how the expert judgment classical method was applied.

Stepping through Table 4, the experts were asked to provide an expected number of Communities of Interest that would achieve tighter alignment to business strategy after 100 different Communities of Interest engagements to federate enterprise architectures within three scenarios of (1) reference models not used, (2) reference models used within federated space, and (3) reference models used within federated space and at each agency. The term ―Communities of Interest‖ was used to signify a group of agencies working together based on mission/business goals to federate their enterprises. To allow the experts to use numbers rather than probabilities on a single event and to summarize how other extenuating circumstances could affect the outcome, the experts were asked to consider each measure in 100 Communities of Interest (Cooke & Goossens 1999). The experts were asked to provide the 5%, 50%, and 95% values for the number of Communities of Interest that would achieve tighter alignment, not how much tighter the alignment would be over the three scenarios. Responses to both the seed variables (discussed previously) and the research questions were recorded and analyzed using both equal weights and calibrated weights (based on seed variables) using an EXCEL

TM spreadsheet from Ryan et


al (2011) adapted for the number of seed variables and experts within this study.

Figure 2 demonstrates graphically how the responses are combined using calibrated weights to develop the

resulting combined distribution for Scenario 2. To simplify the graph only distributions for experts 3, 7, 8, and 16 are shown, but the combined distribution is the result of calibrated weights of all the experts.

Table 4: Discussion Instrument − Excerpt of EA Measures

Figure 2: Expert Judgment Cumulative Distribution Function for Tighter Alignment of Business Strategy in Scenario 2

Measure 5% 50% 95% 5% 50% 95% 5% 50% 95%

Tighter Alignment to Business Strategy

· Architecture process is top-down, business-

strategic-driven, and future-oriented

· Value opportunities are tested and analyzed

Given 100 Communities of Interest

Scenario 1

If reference models are

not used within the

federated space, then X

will ______

Scenario 2 Scenario 3

If community reference

models are used within

the federated space ,

then X will ______

If community reference

models are used within

the federated space and

at each agency, then X

will ______


RESULTS

The results for each EA Measure were compared using both calibrated weights (from the seed variables) and equal weights. The raw data and combined results for the Tighter Alignment to Business Strategy measure are shown in Table 5. Combined with the calibrated weights, the 50% value for Scenarios 1, 2, and 3 are 20.5%, 38.2%, and 46.9% respectively. This is interpreted as reference models having an approximate 18% impact going from Scenario 1 to 2 and having an approximate 9% impact going from Scenario 2 to 3. Over the 15 measures, the equally weighted runs tended to show greater impact of reference models than the calibrated runs. Generally, the experts found reference models to have a positive impact for the EA Measures although some individual experts judged the reference models to have either a negative or no impact such as seen with Expert #15 in Table 5 (expert judged no distribution change across scenarios).

Table 5: Individual Expert Assessments and Combined Results for Tighter Alignment to Business Strategy

Tighter Alignment to Business Strategy

Scenario 1 Scenario 2 Scenario 3

Expert Expert Input Expert Input Expert Input

# 5% 50% 95% 5% 50% 95% 5% 50% 95%

1 5.0 10.0 20.0 30.0 40.0 50.0 50.0 70.0 85.0

2 5.0 15.0 25.0 20.0 30.0 40.0 50.0 60.0 70.0

3 10.0 20.0 30.0 40.0 50.0 60.0 70.0 75.0 80.0

4 25.0 30.0 35.0 35.0 40.0 45.0 40.0 45.0 50.0

5 30.0 40.0 50.0 30.0 40.0 50.0 75.0 85.0 95.0

6 60.0 70.0 80.0 60.0 70.0 80.0 70.0 85.0 90.0

7 30.0 40.0 50.0 50.0 60.0 75.0 70.0 80.0 90.0

8 0.0 2.5 5.0 15.0 20.0 25.0 25.0 37.5 50.0

9 30.0 50.0 60.0 40.0 65.0 75.0 75.0 80.0 90.0

10 10.0 15.0 20.0 10.0 20.0 30.0 20.0 35.0 50.0

11 30.0 40.0 50.0 40.0 50.0 60.0 50.0 60.0 70.0

12 30.0 40.0 50.0 50.0 60.0 70.0 60.0 70.0 80.0

13 0.0 5.0 10.0 5.0 10.0 15.0 10.0 15.0 20.0

14 0.0 5.0 10.0 5.0 15.0 25.0 5.0 15.0 25.0

15 0.0 20.0 40.0 0.0 20.0 40.0 0.0 20.0 40.0

16 20.0 30.0 40.0 30.0 40.0 60.0 30.0 40.0 60.0

Combined

Equal Weights

1.4 26.7 69.6 7.3 40.0 73.5 10.3 58.1 89.2

Calibrated Weights

0.8 20.5 49.9 11.2 38.2 71.0 14.7 46.9 86.8

Table 6 summarizes the calibrated results for all of the EA Measures across the three scenarios. Looking at the 50% values across the scenarios, a positive impact is seen for each of the measures. By using reference models within the federated space, an average of 15% more of the Communities of Interest would see improvements in their EA Measures over those that did not use reference models (average difference between Scenario 1 & 2). Using reference models within the federated space and at each agency, an average of 28% more of the Communities of Interest would see improvements in their EA Measures (average difference between Scenario 1 & 3). The 5% and 95% levels represent the range that the experts expect in the variability of the measure to other influences or in application. As the scenarios went from Scenario 1 through 3, the variability increased. The rationale provided by the experts for this increased variability is that while the reference models would have a positive impact, the effects of other influences such as leadership, governance, and incentives had the effect of a slight increase in variability. Leadership providing a compelling vision and ability to tie enterprise efforts to the federated mission over the timeframes required for implementing changes was mentioned as an important variable in performance.

Table 6: Expert Judgment Results for Reference Model Use in Federating Enterprise Architectures

Calibrated Weights

Financial Efficiency Measures Scenario 5% 50% 95%

1. Re-use of Hardware Components

1 5.2 21.2 58.5

2 12.8 34.7 71.2

3 13.3 53.8 84.3

2. Re-use of Software Components

1 3.1 22.0 47.5

2 13.1 34.6 67.8

3 18.1 49.2 82.8

3. Re-use of Methods 1 4.9 20.0 45.3

2 5.2 36.5 72.1

3 12.5 50.2 86.4

4. Reduced Time-to-Delivery

1 1.1 13.6 46.8

2 8.8 27.6 71.2

3 11.7 39.4 85.6

5. More Efficient Program Management

1 0.8 12.1 47.4

2 3.4 23.1 72.6

3 3.9 33.1 85.6

6. Reduced Support Costs

1 1.1 11.6 56.8

2 9.0 23.2 57.6


Calibrated Weights

3 13.8 32.7 85.6

7. Lower Acquisition Costs

1 0.6 9.8 55.2

2 6.3 23.8 56.9

3 10.5 36.4 85.5

8. Technical Adaptability 1 1.1 13.0 56.9

2 6.7 36.3 66.5

3 7.4 51.5 84.2

Business Effectiveness Measures Scenario 5% 50% 95%

1. Tighter Alignment to Business Strategy

1 0.8 20.5 49.9

2 11.2 38.2 71.0

3 14.7 46.9 86.8

2. Architecture Process Stream of Logic

1 0.8 18.8 42.2

2 12.4 31.2 58.7

3 18.4 50.0 80.2

3. Knowledge Development

1 3.6 17.8 75.8

2 11.3 35.7 79.4

3 13.1 42.0 91.5

4. More Sophisticated Asset Management

1 3.1 20.8 42.9

2 9.0 36.1 65.9

3 9.4 43.0 86.4

5. Reduced Decision Risks

1 3.1 25.8 73.1

2 6.2 38.9 74.2

3 7.5 54.2 85.8

6. Tighter Strategic Alignment With Partners

1 0.8 18.1 42.4

2 15.3 42.0 64.9

3 20.1 58.2 86.4

7. Business Adaptability 1 4.2 26.4 55.9

2 15.3 40.3 65.4

3 20.1 55.8 85.9

CONCLUSIONS AND RECOMMENDATIONS FOR FUTURE STUDY

Reference models were found in this research to increase effectiveness and efficiencies in federating enterprise architectures across multiple agencies. Quantitative measures using the classical method of expert judgment were used to evaluate the reference models’ expected effect on the ability of agencies to federate with other agencies and programs.

Unique in this research is adaptation of the classical method for expert judgment to the quantification of expected benefits of reference models in federating

enterprise architectures. The federation method employed within this research incorporates concepts from the Federal Enterprise Architecture, GIG Architecture Federation Strategy, Enterprise Architecture Cube

TM, and the ISO Model of Architecture for Open

Systems Interconnection (OSI). As reference models are used across agencies to federate their enterprise architectures, case studies should become available in the future to validate the expected benefits of using reference models.

ABOUT THE AUTHORS

Jeff Wilson ([email protected]) is a doctoral candidate in Systems Engineering at the George Washington University within the School of Engineering and Applied Science. He received an MS in Electrical Engineering from the Air Force Institute of Technology and a BS in Electrical Engineering from the US Air Force Academy. This article is based on his dissertation research.

Dr. Thomas Mazzuchi ([email protected]) is a professor of Engineering Management and Operations Research at the George Washington University. Dr. Mazzuchi holds a DSc from the George Washington University as well. His research interests include reliability and risk analysis, Bayesian inference, quality control, stochastic models of operations research, and time series analysis.

Dr. Shahram Sarkani ([email protected]) joined the faculty of the School of Engineering and Applied Science of the George Washington University in 1986 after earning his PhD from Rice University. Since 2001, he has served as faculty advisor for Off-Campus Programs in the Department of Engineering Management and Systems Engineering.

REFERENCES

Bernard S.A.: An Introduction to Enterprise Architecture, Second Edition, Author House, Bloomington, IN (2005).

Cooke R.M.: Experts in Uncertainty: Opinion and Subjective Probability in Science, Oxford University Press, New York (1991).

Cooke R.M., Goossens L.J.H.: Procedures Guide for Structured Expert Judgment, Nuclear Science and Technology, Delft University of Technology: Delft, Netherlands (1999).

DoD: Global Information Grid (GIG) Architecture Federation Strategy, Arlington: US Department of Defense (2007).

Fischer R., Aier S., Winter R.: A Federated Approach to Enterprise Architecture Model Maintenance (2007); refer to: ben.iwi.unisg.ch/fileadmin/if/downloads/Artikel/2007/ Fischer.Aier.Winter.EA-Maintenance.2007.pdf.

Gehris R.: A Simulation Study of the Classical Method of Expert Judgment Combination: How Many Seeds and How Many Experts?, DSc Dissertation, The George Washington University (2008).





GAO: Information Technology: Leadership Remains Key to Agencies Making Progress on Enterprise Architecture Efforts, US General Accounting Office (2003).

GAO: Information Technology: The Federal Enterprise Architecture and Agencies’ Enterprise Architectures are Still Maturing, US General Accounting Office (2004).

Jain R., Chandrasekaran A., Elias G., Cloutier R.: Exploring the Impact of Systems Architecture and Systems Requirements on Systems Integration Complexity, IEEE Systems Journal, Vol. 2, No. 2, pp209-223 (2008).

Lamis J.: The 2008 A&G Reader Survey: The Rise of Strategic IT Planning and Executive Involvement, Architecture & Governance (2008); refer to: www.architectureandgovernance.com/articles.

Lankhors, M.M. (Ed): Enterprise Architecture at Work: Modelling, Communication, and Analysis, Springer, Berlin (2005).

Maier M.W., Rechtin E.: The Art of Systems Architecting, Third Edition, CRC Press, Taylor & Francis Group, Boca Raton (2009).

Mazzuchi T.A., Linzey W.G., Bruning A.: A Paired Comparison Experiment for Gathering Expert Judgment for an Aircraft Wiring Risk Assessment, Reliability Engineering & System Safety, Vol. 93, No. 5, pp722-731 (2008).

Morganwalp J.M., Sage A.P.: Enterprise Architecture Measures of Effectiveness, International Journal of Technology Policy and Management, Vol. 4, No. 1, pp81-94 (2004).

Morganwalp J.M.: A System of Systems-Focused Enterprise Architectural Framework, PhD Dissertation, George Mason University (2002).

OMB: FEA Consolidated Reference Model (CRM) Version 2.3, US Office of Management and Budget (2007a).

OMB: FEA Practice Guidance, US Office of Management and Budget (2007b).

OMB: The FY 2008 Performance Report of the Federal Government, US Office of Management and Budget (2009).

Rechtin E.: Systems Architecting of Organizations: Why Eagles Can't Swim, CRC Press, Boca Raton (2000).

Ross J.W., Weill P., Robertson D.C.: Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, Harvard Business School Press, Boston (2006).

Ryan J.C.H., Mazzuchi T.A., Ryan D.J., Lopez de la Cruz J., Cooke R.: Quantifying Information Security Risks using Expert Judgment Elicitation, Accepted, Article in Press, Computers & Operations Research (2011).

Winter R., Fischer R., Essential Layers, Artifacts, and Dependencies of Enterprise Architecture, Enterprise Distributed Object Computing Conference Workshops, EDOCW '06, 10th IEEE International (2006).

Wu R., Lin F., Yuan S., Liang K.: A Reference Model and Integration Framework for Building Enterprise Computing Platform, International Journal of Technology Management, Vol. 38, No. 4, pp439-462 (2007).

Zachman J.A.: A Framework for Information Systems Architecture, IBM Systems Journal, Vol. 26, No. 3, pp276-292 (1987).

Zimmermann H.: OSI Reference Model – The ISO Model of Architecture for Open Systems Interconnection, IEEE Transactions on Communications, Vol. 28, No. 4, pp425-432 (1980).

http://www.architectureandgovernance.com/articles


Article

EA Heavy and EA Light: Two Examples of Successful Enterprise Architecture

By Inji Wijegunaratne, Peter Evans-Greenwood, and George Fernandez

Abstract

Often literature reports on unsuccessful attempts at enterprise architecture. Many exercises do not progress beyond their initial stages, losing momentum during their execution, or they run to conclusion without delivering the promised benefits.

This article reports on a significant experience by the authors—engaged as consultants to two Australian-based multinational companies—during the execution of two very different, successful enterprise architecture projects that managed to deliver and demonstrate tangible benefits to the respective organizations. Although both projects included important IT technical components, their success was based on enterprise architecture teams that clearly understood the business objectives, linked the enterprise architecture activities directly to them, and clearly communicated the benefits in business terms. We argue that to engage and maintain support an enterprise architecture exercise must have a business purpose that is clearly understood by all stakeholders, and it must be carefully tailored to the intended purpose, both in terms of effort and deliverables, and no more. Our discussion includes the strategy, methods, and tools used by the enterprise architecture teams to conduct each engagement, and a discussion of the results and lessons learnt.

INTRODUCTION

Over the last ten years, enterprise architecture has received significant attention by researchers and practitioners. According to a study by the Institute for Enterprise Architecture Developments (IFEAD), 66% of the respondents consider enterprise architecture as an important element of their strategic governance processes (Schekkerman 2005). Another study conducted in 2006 among Swiss and German companies reveals that 38 from 51 interviewed companies are either currently implementing enterprise architecture models, or are already using enterprise architecture models (Bucher et al 2006). This focus has resulted in significant, but very diverse, efforts from individuals (e.g., Zachman), industry bodies (e.g., The Open Group), Governments, and allied entities (US Federal Government, US Department of Defense), while most major IT consulting companies have developed enterprise architecture practices and methodologies.

However, despite how much has been written on enterprise architecture during this period, there is very little help for the enterprise architecture professional on what constitutes, and how to run, a successful enterprise architecture project. The existing literature is full of what passes for practical advice—―understand the limitations‖, ―identify bottlenecks‖, ―good communication with the business‖—but they provide scant guidance on the practicalities of implementing their advice. If you are an enterprise architect faced with the prospect of doing enterprise architecture, how do you actually go about running an enterprise architecture project? How do you set the scope? Where do you start? What problems are

you likely to find? How can you avoid them? What tools and methods can you use? How do you communicate with the business, and what could you communicate to the business, to ensure that they are onside for the duration?

Starting, first, with Zachman’s definition, ―A representation of the functioning enterprise‖ (Zachman 2003), we see that whether it is apparent of not, any functioning enterprise possesses, if not an architecture, some kind of functional structure. Thus, initially the challenge of the enterprise architect in a functioning enterprise is to uncover this structure and represent it in a manner that stakeholders can comprehend. Since the final aim of enterprise architecture is to shift the organization from the ―as-is‖ state to some desired ―to-be‖ state (Fischer et al 2007) it is necessary to capture and maintain architectural artifacts of the enterprise to express and represent these states. However, the task of accurately describing an enterprise and the way it works is a very complex, difficult undertaking (see, for example, Mintzberg (1979)).

Indeed, given the sheer size, complexity, and dynamic nature of modern organizations—―during the architecture development process uncertainty and incomplete knowledge are crucial‖ (Saha 2004, p4)—it may even be argued to be unfeasible. Hence, it is not surprising that enterprise architects experience significant confusion, and that the adoption rate of enterprise architecture and its reported benefits do not appear to be uniformly promising (Infosys 2007; Lapkin 2009a). It is often too easy for the enterprise architecture project team to get caught in producing enterprise representations, and


forget that their real aim is to produce and demonstrate tangible benefits for the business. But if documenting the organization in ―excruciating level of detail‖ as espoused by Zachman (Zachman 2003) is not practical, what is the extent and depth appropriate for enterprise architecture?

The answer lies in that not all enterprise architecture projects have the same drivers and goals. We believe that it is counterproductive to spend an inordinate amount of effort creating and maintaining enterprise descriptions that do not serve a direct business purpose. Also, it is often said that enterprise architecture is concerned with enterprise evolution, and this is usually taken to indicate that enterprise architecture efforts are always focused on a major enterprise transformation. Some comprehensive approaches—e.g., TOGAF (TOGAF 2009)—may implicitly reinforce this mindset. We argue, however, that this is not necessarily so; instead we agree with Doucet et al that enterprise architecture encompasses any approach, large or small, to promote coherence into the current management practice of the enterprise (Doucet et al 2009). Hence, our ―purpose test‖:

1. The raison d’être for enterprise architecture must stem from, and be kept aligned to, a business purpose.

2. The level and detail of the enterprise descriptions must be tailored to be sufficient for its intended purpose.

To support our statements, this article compares and contrasts two very different, successful enterprise architecture exercises carried out by the authors as external consultants to two Australian-based multinationals:

EA Heavy: An engagement for an FMCG (Fast Moving Consumer Goods) company headquartered in Australia. The enterprise architecture engagement was initiated by a direct report of the CIO and performed over a period of approximately six months by a team of ten staff working full time. Initially, the purpose was articulated as: ―The current architecture evolved through several years of acquisitions and business unit integrations […] The result has been an extremely complex landscape with

application and data duplication, process complexity, and inefficiency […] inhibiting flexibility, agility, and innovation‖.

EA Light: Carried out in six weeks by a team of two external consultants, for an Australian financial services group, to build on existing business-as-usual via initiatives aligned with the strategic goals of the business. The main requirement was to build a chain of evidence connecting actions back to business drivers to align the IT project portfolio with the organization’s overall business strategy.

These examples are documented here for the purpose of our analysis. They are not a complete, detailed account of the two assignments.

THE “EA HEAVY” PROJECT

The enterprise architecture engagement was initiated by the IT division, by a direct report of the CIO. The IT stakeholders engaged a team of external consultants to carry out a collaborative enterprise architecture exercise, with the engagement encompassing the entire group. The assignment was performed over a period of approximately six months by a team of ten full-time staff.

Figure 1 shows the sequence of steps for the EA Heavy project. The left-hand side shows the initial phase of the process, including the development of the current logical, conceptual, and physical models. The American Productivity & Quality Center (APQC) process framework was used as the basis for the classification of business processes necessary to support the logical model. APQC is a taxonomy of business processes that makes possible analysis of organizational performance within an organization and between organizations. The taxonomy is organized into 12 categories of business processes, comprising five categories of operating processes, and seven of support processes (shown in Figure 2). Each category contains processes representing the operations of a single business function within the organization, providing organizations with a framework for benchmarking each function, and monitoring its improvement.


Figure 1: Steps in the EA Heavy Approach

Figure 2: American Productivity and Quality Center (APQC) Framework (Reference Framework in EA Heavy) (www.apqc.org/portal/apqc/site)

http://www.apqc.org/portal/apqc/site


Figure 3 shows a sample APQC framework customized at the process group level, developed for the engagement. The figure shows a partially populated model with logical information system components—i.e., collections of related business services—provisioning process groups relevant to the enterprise. This was used to produce the logical-to-physical mapping activities, such as the two process groups in process category 3, ―Market and sell products and services‖, indicating their current (How many applications support the component today?) and intended target (How many should there be?), as shown in Figure 4. It can be seen from the figure that the logical to physical mapping for current and target provided very significant opportunities for rationalization (from 14 to one as shown).

This information was fed into a main collaborative event involving the stakeholders and facilitated by the enterprise architecture team.

A broad range of stakeholders were involved along the process, to ensure their understanding of, and support of, the project, including the review and acceptance as the final step of the enterprise architecture exercise before initiating the program of work.

Figure 3: Customized APQC Framework

Table 1 shows our three-step approach, also depicted in Figure 1: a) initial work by the enterprise architecture team; b) a facilitated event; c) first cut of the initiatives. The table classifies and summarizes the activities, their features, and their outcomes.

Figure 4: Mapping of Logical Components to Physical Applications – Current State and Target State (EA Heavy)


Table 1: Description of Activities: Significant Features of the Activities and their Outcomes (EA Heavy)

Key Features Outcome

Context Summarize business context: scope, mission, and objectives.

EA context document

Develop current state analysis In-depth assessment of the current IT estate. Assesses key aspects; e.g., numbers of servers and applications; functional coverage and non-functional behaviour, user/IT assessments and against industry benchmarks.

Current state assessment

Develop logical model Defined as set of business services, representing discrete re-usable functions, mapped onto the APQC model (Figure 2).

Logical model for enterprise architecture

Develop current physical model Logical components associated with applications. See Figure 4.

Current physical enterprise architecture model

Facilitated Event

Major analytical activity: facilitated by external consultants, where key business and IT work co-operatively with the enterprise architecture project team.

1. Validate inputs

Current physical architecture is validated

Current state analysis is presented and implications (especially of the ―do nothing‖ option) are communicated

Validated current physical model.

2. Develop target physical model

Target state developed:

Duplicate physical solutions rationalized to do via a single application

Use of existing (underutilized) solutions expanded

Point solutions retired

Bespoke or heavily customized solutions in non-differentiating areas such as Finance & HR retired. Customized APQC.

Target physical model for enterprise architecture

3. Develop initial transformation roadmap

Develop first cut roadmap in terms of a list of initiatives, their precedence relationships, and order of implementation.

Roadmap initiatives; high-level costings

Refine deliverables Target state plus first-cut roadmap refined. Refined deliverables

Package and present results Appropriate packages of the deliverables produced, tailored to the target audiences.

Enterprise architecture documentation for the enterprise architecture team/division

Executive/management/staff presentation

Enterprise architecture models in the tool


Figure 5: Steps in the EA Light Approach (EA Light)

Table 2: Description of Activities: Significant Features of the Activities and their Outcomes (EA Light)


Develop high-level business services architecture (BSA)

At a high level, identify the business services and how they interact. Big picture view of how the business operates. Decompose just enough: with level 0 being the context (the three businesses of the group and how they interact in this case) maximum decomposition to level 3. Figure 7 shows a sample deliverable.

BSA for the three businesses of the group in scope for this study

Classify business services (heat map)

Business services classified based on business value into four categories, from less to most important:

Manage to minimize cost

Manage to an SLA

Invest opportunistically

Market changing – invest to drive change and differentiation in the market

Each category is given a distinctive color, to present the business services in an easily comprehensible format. See Figure 8.

Heat map of business services in BSA

Develop strategy map A strategy map comprises:

Business drivers: Overall business drivers for the organization (from business strategy)

Customer view: How the IT department would show the business (its customer) that IT is moving toward the company’s strategic business goals

Internal view: How the IT department would deliver the customer view

Actions: The concrete actions that IT will undertake to

A partially complete strategy map containing:

Business drivers

Supporting customer view

Supporting internal view



realize the strategies in the internal view. The actions are not identified at this stage of the process.

The business view was identified from the business strategy, and the customer view and internal view developed. The initiatives are identified later. See Figure 6 for an example.

Develop scenarios to exercise the business services

Scenarios developed to exercise the BSA:

Business as usual (BAU) scenarios – exercising key E2E business processes

Stretch scenarios: ―stress testing‖ the BSA

Walking through a scenario exercises one or more services in the BSA. ―What happens if‖ scenarios must be traceable to one or more of the business drivers.

Adequate coverage – mix between BAU and stretch, and traceability to the business drivers must be ensured.

A set of BAU and stretch scenarios

Collate summary information on IT estate and existing initiatives

List of existing initiatives

Use a lightweight survey to gather information on the existing IT estate

Intention: use for reference purposes at the facilitated event

List of existing initiatives

Summary information on existing IT estate

Facilitated Event

An event, facilitated by external consultants, where key business and IT represent-atives work co-operatively to produce the outputs.

1. Validate strategy map, BSA, heat map

Validate the inputs:

Strategy map

Business services architecture

Heat map

Validated inputs

2. Exercise the scenarios to determine initiatives

In groups, walk through each scenario, exercising the relevant business services and understanding the consequences. Explore how you would change the IT estate to support different scenarios where additional IT support is needed, or where IT needs to be changed. When the IT estate is found deficient or wanting, a new initiative is created to rectify the problem.

3. Classify and prioritize the initiatives to identify a three-year program

A first-cut road-map in terms of a list of initiatives (costed at a high level), their precedence relationships, and order of implementation is developed out of this exercise.

Set of initiatives

Refine the initiatives The initiatives are scoped and costed (still at a high level) but in a little more detail.

Set of initiatives (refined)

Package and present deliverables Final report is produced Final report + work products for the strategy map, BSA, heat map, Initiatives documentation in the selected enterprise architecture tool

The target state, initially developed at the facilitated event, was refined along with the costs and benefits. The prioritized set of initiatives to move today’s enterprise to the rationalized state—including a five-year transformation program—was accepted by the

enterprise, and they are currently implementing the program.

THE “EA LIGHT” PROJECT

During the 2006/2007 financial year, the lines of business of this financial services group released their


new strategic goals, prompting the IT department to review its established program of work. The challenge was to find a method that would build on existing business-as-usual and top-line initiatives to align with the new strategic goals, and build a chain of evidence connecting actions back to business drivers. All this within a very short period of time to provide a tangible output that could be presented to the business executives.

The external consultants undertook the assignment, and (with assistance from IT and business stakeholders) delivered the required outcomes within a period of six weeks. Figure 5 shows the main activities undertaken, and the relationships between them. The same three-step pattern of (1) initial work; (2) facilitated event and review; and (3) acceptance is shown in Figure 5 and Table 2. The table shows the different activities undertaken, their key features, and their outcomes.

Several strategies and tools were used for this exercise, as inputs to a facilitated event. These are discussed further in the following sections:

Strategy Maps were used to establish direct links between the business drivers and the actions that IT should carry out to deliver the goals.

A ―just-enough‖ decomposition of a Business Services Architecture was developed, with a maximum decomposition to Level 3.

A Heat Map, a classification of business services according to their value, was produced.

STRATEGY MAPS

The strategy map was based on the work of Kaplan and Norton (Kaplan & Norton 2004), which we customized for IT purposes. Our map components are summarized in Table 3.

In our conception of the strategy map for enterprise architecture, the business is the customer of the IT department. The overall business drivers, part of the business strategy, sit at the top of the map. Underneath, the Customer View expresses how the IT department will demonstrate to the business that they are moving to achieve these objectives. The Internal View is related to how the IT department will deliver the Customer View. Finally, the Initiatives lists the concrete actions that IT will undertake to execute the Internal View. Figure 6 shows our strategy map for two of the enterprise business drivers.

Figure 6: Example Strategy Map (EA Light)


Table 3: Strategy Map Components (EA Light)

Construct Description Example (Figure 6)

Business View Business drivers Depicts two of the overall business drivers sourced from their business strategy

Customer View How the IT department would demonstrate to the business that the IT estate are moving toward the company’s strategic business goals

Shows the ―Customer View‖ for the two business drivers

Internal View How the IT department would organize itself to deliver the Customer View

Shows the ―Internal View‖ for the Customer View components

Initiatives List the concrete actions that IT will undertake to execute on the strategies in the Internal View

Shows the initiatives to realize the ―higher‖ components of the strategy map

Using a strategy map in this way it was possible to establish a direct link between the strategic business drivers and the initiatives that will form part of the program of work for the transformation.

THE BUSINESS SERVICES ARCHITECTURE (BSA)

Our Business Services Architecture (BSA) representation follows and extends the work of Jones (Jones 2006). The business services represent what the business does and delivers, and what is required to meet business goals. Where an application represents large areas of functionality across the business, the BSA worked with the business to align our understanding of the IT estate with the business activities it is intended to support. As such, it may become a clear language of communication between the business and IT.

Figure 7 shows the decomposition of the funds management business. Following our premise of ―producing just enough‖, Level 3 decomposition was sufficient for the purposes of our exercise. The first indicates the process, while the second shows the hierarchy of the business services.

PRIORITIZING IT INVESTMENTS: HEAT MAP

There are several frameworks that can be used to prioritize investment in the IT estate, such as the one in illustrated in Figure 8 (adapted from Jones (op cit)). A four-quadrant classification is used here, stating Business Value and Business Impact. Investments priorities, from highest to lowest, are: (1) market differentiation; (2) return on investment; (3) cost minimization; and (4) Service Level Agreement (SLA).


Figure 7: Business Service Architecture – Level 2 and 3: Funds Management (EA Light)

Figure 9 shows the resulting investment Heat Map, showing in different colours the priority of investments according to the framework. As the first activity, these three input elements, Strategy Map, Business Services Architecture, and Heat Map were validated during the facilitated event described in Table 2.

After validation of the three inputs above, the facilitated event walked through Business as Usual (BAU) and ―stretch‖ scenarios exercising the relevant business services. This explores how the IT estate is able to

support the different scenarios, and where additional IT support or changes may be needed. When the IT estate is found deficient, a new initiative should be created to rectify the problem. A sample of the scenarios used in the facilitated event is shown in Figure 10.

As shown in Table 2 and Figure 5, the prioritized list of initiatives developed at the facilitated event was subsequently refined. This list was accepted by the enterprise, and they are currently implementing the program.


Figure 8: Business Value Classification (EA Light)

Figure 9: Heat Map (EA Light)


Figure 10: Scenarios (EA Light)

DISCUSSION: LESSONS LEARNED

We argued previously for a ―purpose test‖ with two-fold criteria:

1. The raison d’être for enterprise architecture must stem from, and be kept aligned to, a business purpose.

2. The level and detail of the enterprise descriptions must be tailored to be sufficient for its intended purpose.

The two case studies, involving two starkly different levels of detail, clearly illustrate the purpose test.

Lesson 1: Understand the business purpose

The purpose of the EA Light exercise was alignment, of IT with the strategic goals of the business. The purpose was clear and well understood by the consultants and IT stakeholders. The challenge here was to move IT away from its technical comfort zone and into thinking of alignment in terms of answers to business objectives and problems. The mechanisms used to achieve this included the strategy map, which presented a very clear traceability mechanism to the business objectives, and the scenarios that were exercised during the facilitated event, which were business scenarios that required an IT response (see also ―Lesson 5‖).

The terms of reference of the EA Heavy were expressed in terms of the gains via rationalization: ―reduce complexity, improve flexibility and interoperability, improve service levels, and lower the cost to serve.‖ The challenge with EA Heavy was to:

Produce evidence in support of the terms of reference; i.e., to show the cost to the business of the current, very complex IT estate.

Properly communicate the message to develop a common understanding of the problem and generate momentum for solving it.

This was done through the current state assessment, which depicted the problem clearly and unambiguously and then by communicating this to stakeholders both formally and informally (see below).

Lesson 2: Understand and deliver what business and IT stakeholders actually want

In both cases, the ultimate purpose was to identify a set of initiatives according to the purpose of each exercise. In EA Heavy, the initiatives would serve to align the IT division more closely with the strategic drivers of the business; in EA Light the initiatives would rationalize and simplify the IT estate, yielding significant savings in operational expenditure. The approaches and the interim artifacts produced in the two exercises—albeit very different—nevertheless shared a common characteristic:


they were only a means to the end of establishing the initiatives. The final form of the target IT estate was of very little interest to the senior business and IT stakeholders, as opposed to the benefits that the initiatives would bring: better alignment with business drivers in EA Light; savings through rationalization in EA Heavy. In both engagements, the enterprise architecture teams were keenly fixed on this goal, and avoided being seduced by producing artifacts along the way, unless they directly served a business purpose. To summarize, stakeholders need the following:

Where the problem is not clear or commonly understood: present the problem and the do-nothing consequences articulated in clear, business (preferably dollar) terms.

Establish a set of initiatives to achieve the goal/s (whether it is better alignment, cost optimization, etc.), and the benefits, also preferably expressed in dollar terms (see ―Lesson 3‖ below).

This is a lesson that enterprise architecture practitioners should not miss. There are many examples of enterprise architecture failures in which producing glossy diagrams of the target state ends up becoming the goal. This typically leaves business stakeholders cold; indeed, we argue that the technical artifacts of enterprise architecture, in themselves, do no generate enthusiasm or support for the change initiatives that may be recommended.

Lesson 3: Communicate benefits in business terms

Management is understandably averse to releasing funds where the business benefit cannot be clearly perceived: so always couch the benefits in business terms. We agree with Lapkin: ―Define a value proposition specific to the enterprise, and articulate it in business terms‖ (Lapkin 2009a p12), and Strassman: ―Computer investments must show as enhancements to a business plan‖ (Strassman 1997 p3). A benefit originating in IT should be couched in business terms, as clearly demonstrated by EA Heavy, where the team’s brief was confined to rationalization.

The team worked with the business to streamline provisioning of the business services via a rationalized set of application functions and supporting infrastructure. However, any significant efficiency gain—as in this case rationalization of a key set of business services from 14 different applications to one, or consolidating the server infrastructure—having a positive bearing on CAPEX/OPEX (Capital Expenditure/Operational Expenditure) is of interest to the highest echelons of the enterprise. By couching these in the right terms, in EA Heavy the extent of duplication and the current costs became clear, as did the very significant rationalization opportunities and the gains these would bring. The team

pressed the rationalization message home to IT and business executives, using the savings dollar figures effectively to solidify support, acceptance, and enthusiasm for a critical, significant transformation program with an estimated cost well in excess of $100M over five years.

Lesson 4: Tailor effort to the intended purpose and management expectations

The two projects show a wide variation of effort:

The EA Light exercise was carried out in six weeks by a team of two external consultants.

EA Heavy was a far more substantial affair, involving the entire group of the multi-national; performed over a period of approximately six months by a team of ten staff—internal staff plus external consultants—working full time.

Our measure of success is that the output was not only accepted, but it has been used to initiate programs of work. Therefore, both in scoping and designing an engagement, as well as in responding to an established scope definition, it is imperative to understand the purpose and tailor the effort and the output to stakeholder expectations and no more, to avoid the enterprise architecture exercise losing momentum and support along the way.

With the engagement in progress, the enterprise architecture team constantly communicated that they were delivering value for money by: (a) constantly reporting progress to stakeholders, including the percentage task completion of project management, and what was being uncovered; (b) establishing credibility by ―brown bag‖ sessions on affiliated subjects; (c) most importantly, by facilitated events engaging stakeholders as active participants in key decisions.

Lesson 5: Leverage the richness of the potential enterprise architecture space

There was a significant difference in starting assumptions for the two approaches. EA Heavy operated under terms of reference that channelled the project towards delivering a rationalized IT estate. Consequently, it was not possible to explore other solution spaces, such as how IT can support strategic business intentions. In the event though, we were able to show very considerable financial gains through rationalization that, as described above, fuelled a large transformation program.

EA Light, on the other hand, did not start with any such assumptions. This enabled the team to explore a richer solution space, including BPO (Business Process Outsourcing) and SaaS (Software as a Service), to be able to deliver a more complete set of solutions—which


may or may not involve technology installations—to the business challenges presented. Two slightly different points should be highlighted here:

IT staff must be cognizant of non-IT aspects in enterprise architecture. The natural inclination of IT staff and management is to think of an enterprise architecture roadmap primarily in terms of IT application or infrastructure change. However, changes to the business architecture will be necessary for the enterprise to change position within the business landscape. We were cognizant of EA Light’s terms of reference as the IT division’s response to the business strategy. However, recognizing the natural bias amongst IT staff and management, an explicit attempt was made to step outside their familiar concerns.

A holistic approach makes it possible to explore a wider solution space and possibly develop a more appropriate—higher value—solution for the enterprise. The techniques used in EA Light were tailored to explore this; for example, three categories were created for initiatives: application, infrastructure (the traditional IT ground), plus people and process, and the scenarios shaped to trigger discussion in this third area as well. Some of the ―softer‖ aspects were encapsulated in initiatives such as facilitated organizational learning, streamlining of internal IT processes, capturing internal knowledge, and succession planning.

Capturing these softer aspects in current IT frameworks is a challenge. The Zachman framework offers slots—but not techniques—in its taxonomy to include them. However, research is starting to recognize and try to address these aspects within the strategy. For enterprise architecture to become more than IT change, these non-technical aspects of the enterprise should be included together with the more tangible IT and process aspects. This is an important area for further research.

CONCLUSIONS

These two enterprise architecture exercises deliver very important lessons, which can be summarized as follows.

Follow the principle of parsimony:

Carefully tailor the methodology used to the purpose of the exercise

Where possible, use existing artifacts, including non-technical artifacts, and only develop new artifacts when really required

Decompose, describe, illustrate, just enough for the purpose of the exercise

Work together with, and deliver to, the business:

Always involve stakeholders in the process

Communicate the benefits in business terms, and clearly articulate the consequences of doing nothing, as the business will invest in a new IT function only if this clearly provides more benefits than the status quo

Produce a prioritized list of IT initiatives directly linked to enterprise drivers and business outcomes

Use the priority list above to produce the transformation program

ABOUT THE AUTHORS

Inji Wijegunaratne is an IT consultant with over 25 years of IT experience, in the past 12 years focusing on enterprise architecture and IT architecture leadership. He has occupied IT architecture management positions in the corporate sector, and consulting positions at Deloitte, IBM, and Capgemini. He is currently with Infosys Australia. Inji holds Doctoral and Master’s degrees in Information Systems from London University and a Bachelor’s degree in Electronic Engineering from the University of Essex, UK.

Peter Evans-Greenwood provides business and technology consulting to executives across a range of industries. His 20 years of experience working between business and technology have seen him work across the full breadth of industry, with leadership roles in global players such as Deutsche Post DHL, and Capgemini through to innovative startups, including the Australian Artificial Intelligence Institute and Agentis.

George Fernandez is an Associate Professor at the School of Computer Science and Information Technology at RMIT University (Australia), currently teaching Enterprise Architecture and eCommerce and Enterprise Systems. George has more than 30 years of experience in Computing and Information Systems, working in academia, private industry, and government organizations. He is an active researcher, and often presents technical seminars in academic and industry forums. His research interests include Distributed Computing, Enterprise Systems, and Enterprise Integration.


REFERENCES

Bucher T., Fischer R., Kurpjuweit S., Winter R.: Analysis and Application Scenarios of Enterprise Architecture – An Exploratory Study, Proceedings, EDOC Workshop on Trends in Enterprise Architecture Research (TEAR 2006), within the Tenth IEEE International EDOC Conference (EDOC 2006), Hong Kong (2006).

Doucet G., Gotze J., Saha P., Bernard S.: Coherency Management – Architecting the Enterprise for Alignment, Agility and Assurance, AuthorHouse, Bloomington, Indiana, ISBN: 978-1-4389-9606-6 (2009).

Fischer R., Aier S., Winter R.: A Federated Approach to Enterprise Architecture Model Maintenance, Proceedings of the 2nd International Workshop on Enterprise Modeling and Information Systems Architectures (EMISA 2007), St. Goar, Germany October 8-9, (2007).

Aziz S., Obits T.: Enterprise Architecture is Maturing, Infosys Enterprise Architecture Report, October (2007); refer to: www.infosys.com/offerings/IT-services/architecture-services/ea-survey/Documents/ea-maturing.pdf.

Jones S.: Enterprise SOA Adoption Strategies, C4 Media (2006).

Kaplan R.S., Norton D.P.: Measuring the Strategic Readiness of Intangible Assets, Harvard Business Review, February (2004).

Lapkin A.: Five Questions the CIO should be Asking about Enterprise Architecture, Gartner Research Report, ID Number G00167384, 29 April (2009).

Lapkin A.: Key Issues for Enterprise Architecture, Gartner Research Report ID Number G00166589, 27 March (2009).

Mintzberg H.: The Structuring of Organizations, Englewood Cliffs, Prentice-Hall (1979).

A Real Options Perspective to Enterprise Architecture as an Investment Activity, Technical Report, National University of Singapore (2004).

Schekkerman J.: Trends in Enterprise Architecture 2005: How are Organizations Progressing?, Institute for Enterprise Architecture Developments, Amersfoort (2005).

Strassman P.: The Squandered Computer, The Information Economic Press, New Canaan, Connecticut, (1997).

The Open Group: TOGAF Version 9 "Enterprise Edition"; refer to: www.opengroup.org/togaf.

Zachman Framework (2003); refer to: www.intervista-institute.com/articles/zachman-by-kull.php.



http://www.opengroup.org/togaf/

http://www.intervista-institute.com/articles/zachman-by-kull.php

http://www.intervista-institute.com/articles/zachman-by-kull.php


Article

“The business” does not exist! Why Enterprise Architecture is often a mission impossible

By Piet Jan Baarda

Abstract

Successful application of enterprise architecture is not easy. Many books and articles have been written on the subject. They describe how alignment with ―the business‖ is essential and subsequently delve into architecture frameworks, procedures, organization, governance, and the required skill set. This article will show that in general there is no such thing as ―the business‖ and how this represents the major obstacle for successful enterprise architecture and mature IT.

Keywords

Enterprise Architecture, Business-to-Business Alignment, Governance, SOA

USE OF THE PHRASE “THE BUSINESS”

When working on architecture and IT in general the phrase ―the business‖ is used very often.

Some examples:

―Our architecture principles support the business vision …‖

―We will align with the business strategy …‖

―IT should be a business enabler …‖

―The business wants a single customer view …‖

―The business needs this application in production in three months time …‖

―The business wants to reduce the number of screens in this application …‖

―For this project the business cannot afford to take architecture into account, we will focus on time and budget, maybe next time we fix the architecture …‖

…

It is assumed that all these statements are made by the same entity: ―the business‖. When statements by ―the business‖ seem to contradict earlier statements by ―the business‖ we think this is a matter of progressive deeper understanding, that the pros and cons have been weighed and that more recent statements by ―the business‖ overrule earlier statements.

Many architects are frustrated when their grand vision and architecture framework is accepted by ―the business‖, but when it comes to actual application of the architecture principles in projects there is never time or budget to do it right.

The particular project focuses on its own goals (that does not include things like re-use, coherence, consistency, and other enterprise-level interests) and cannot be bothered by taking future generations or other projects into account. If you are lucky you get the promise: maybe next time or in the next release.

Also, when designing the user interface the information quality takes second stage compared to ease-of-use for ―the business‖ users consulted. It seems the scope of the project and the overall architecture of the IT landscape has been taken into account in any statement by business representatives. The normal pattern in projects is a narrowing scope from enterprise via project to end user. Ultimately it is the users performing the acceptance test that have to be satisfied.

For IT, it is easiest to behave as if there is indeed one business entity speaking with a single tongue.

All-in-all, the result is the fragmented IT landscape that many find normal and take as a fact of life. Even when the enterprise architecture function has been introduced and is fully functional, often its effect on the IT landscape is very limited.

The explanation is simple: ―the business‖ does not exist.

THE THREE FACES OF “THE BUSINESS”

The diagram below shows a pattern that exists in many organizations. Three separate faces of ―the business‖ can be recognized.


Figure 9: The Three Faces of “the Business”

1. Top Management: Top management recognizes the importance of enterprise architecture as a way to increase coherence and agility, reduce complexity, and thus reap the associated financial effects. The enterprise architecture role is introduced together with procedures on how to interact with the development process and what artifacts will be produced. Typically, the enterprise architects formulate reference architectures describing the principles to use during development to ensure the strategy of the organization is supported in a coherent and agile way. To limit the design space for the individual projects they typically produce Project Start Architectures (PSAs). Top management discusses business initiatives, budget, and timelines with their business subordinates. They receive regular reports on progress in these terms and manage any deviations from the planned activities and spent. As architecture is in place there is no need for top management to put coherence and agility on the agenda for discussion with their business subordinates.

2. Project Principals: Individual projects are launched based on specific business cases. Often annual budgets have already been assigned to organizational units based on historic information and expected developments. Project principals provide input for project managers to plan and execute the project. Business analysts provide detailed business input where required. They report progress to top management in terms of time and money. In some cases project analysts review the input from the enterprise architects. They apply the input where it does not endanger the timelines and

budget through what is perceived as extra work or extra management complexity introduced by enterprise architects. Re-use often complicates project management as other parties will need to be involved. Also developing components positioned for re-use requires extra attention to develop and manage. Coherence often means applying information and technology standards that may again require extra attention. Project managers and project principals, therefore, strongly prefer autonomous single solutions. Following enterprise architecture advice often presents a risk for achieving the project goals as agreed with top management (time, money). As top management does not ask for a contribution to coherence and agility the enterprise architecture input is often wasted. Top management as well as project principals and project managers do not see enterprise architects representing top management (= enterprise-level) interests. They are seen as ―bad news‖; notorious worrywarts obstructing progress, and spoiling the fun in general.

3. System Users: Ultimately, it is business system users that accept the system. They provide the detailed input for the system design and perform the business acceptance testing before the new system can be put in production. Their main worry is their colleagues who will protest if their position or comfort is compromised. Their life must be made easier with the new system. Projects making life harder for system users are therefore hard to implement although there may exist a very attractive business case with strategic goals. On the other hand, projects that make life very much easier for end users are also difficult, as they form a threat for the end-user community as a whole – layoffs may be around the corner. ―The business‖ project principal also focuses on these aspects: the users must use the system no matter what. The result is that the project is within budget, on time, and with happy users. What more can you want? Well, quite a lot actually! This way of working has led us to the fragmented IT landscapes that are commonly found.

This pattern is presented here in black and white to clearly show its nature. Of course, in practice many gray tones may be recognized. This pattern gives an explanation why so many enterprise architecture initiatives have little effect on the IT landscape. It remains as fragmented, costly, and hard to change as before. It frequently even gets worse.

The pattern does provide insight into where essential changes need to be done to make enterprise architecture successful. Not as a goal in itself, but to improve the situation and move in the direction of the

System Users

Project Principals

Top

Management

Enterprise

Architecture1

Project Management

Development Teams

2

3

Operations

Project

Principals

„Win‟

System Users

„Win‟

$

$


coherent, cost-effective, and agile environment an organization needs to thrive.

In the ideal world ―the business‖ would exist. ―The business‖ really would speak with one tongue. Managers would make sure that their subordinates do the important things in line with their goals and explicitly translated into subordinate goals. This is ultimately reflected in the appraisals for the individuals involved and the associated bonuses.

WHY IS IT DIFFERENT?

Compared to other areas in an organization IT is often perceived as a special case where raising cost and increasing complexity is unavoidable. Still, there is no reason to think IT is generally managed with a lower quality than other parts of the enterprise. It is safe to assume that generally management quality is the same across the board. But, ultimately, it is top management that is responsible for any aspect of the organization including its IT department. IT and IT personnel are not things that are forced upon an organization. The organization is the master of its own destiny. You might say to top management: ―You are caught in a prison of your own devise‖ (Jim Morrison & The Doors 1968) when they are complaining about IT.

Simply put, any organization gets the IT it deserves. Just like it gets the personnel it deserves, the logistics it deserves, the customers it deserves, the manufacturing capability it deserves, the profit it deserves, and so on.

In these cases it is self-evident that management must ensure that the organization does the right things at the right time in the right way. Only in IT the department is blamed instead of top management:

―… IT makes things too complicated …‖ ―… IT does not speak the same language …‖ ―… IT hinders progress, they are anything but agile …‖ ―… IT architects must sell their ideas better to projects …‖

But, of course is it up to top management to hire the right people and ensure that the right things happen.

The following quote illustrates the issue very well:

―If we buy a bicycle to improve our personal transport, can we blame the bicycle when the situation does not improve if we just walk next to it?‖ (Jan Hoogervorst presentation)

The thing that really makes IT different is the fact that earlier IT decisions are not as easily undone as most non-IT decisions.

For example, changing an organization structure can be done relatively easily without any traces of the earlier structure. Bad selling products are replaced by products that do sell. Bad forklifts are replaced by better ones, etc. In IT, bad decisions are often not erased. Instead the IT landscape is extended with new solutions with the existing solutions firmly remaining in place. Often the IT

landscape shows the full history of IT decisions made through the years – the good decisions and the bad ones.

In short, IT is a special case as its history is dragged along, where in other subject areas older mistakes are easily replaced with new ones.

The phenomenon described here is part of a bigger picture with ―enterprise governance‖ and ―IT governance‖. It is just that IT as a business area of interest seems to be especially sensitive for the reasons sketched above.

Much has been written on enterprise and IT governance. Many approaches focus on the structural side of things and describe frameworks, decision rights, processes, and all kinds of boards. They seem to suggest that as soon as the decision-making framework has been implemented the desired IT developments will follow automatically. This has been noted before (Hoogervorst 2007). We agree and are convinced that the focus should not be on structure but on content. The content part is what it is all about; it must be determined what the desired IT developments are together with explicit actions that need to be done.

The remainder of this article will focus on this content and practical ways of how to go about achieving it. Not in any exhaustive way though; the main goal is to create a new mindset for enterprise architects.

There are some specific things we can do. It all starts with awareness, first as an enterprise architect, second as business decision-makers on IT subjects. But first we will describe how to survive as an enterprise architect in a fragmented business world.

ENTERPRISE ARCHITECTURE IN A FRAGMENTED BUSINESS WORLD

Given a three-faced business situation, enterprise architecture still can work on improving the situation and making sure that the different business interests are met in a balanced way. When there is a conflict of interests this must be discussed in an open and transparent way. Very often this is not done and the solution is left to chance. Many architects working in an organization for a long time and wanting to survive have found a way to handle this. Often by ducking and reacting on the most recent instruction of ―the business‖, no matter which of the three flavors of business is providing this instruction. Others get frustrated and leave the organization for better pastures. Of course it is the responsibility of ―the business‖ to speak with one tongue, and when they don’t it is not IT that is to blame. Ducking is a way to survive and avoid getting seen as a Don Quixote fighting windmills that are unseen by business. Others accept this label and struggle on until they retire. The professional way is for an architect to recognize the


limited maturity of the organization and find ways to make it slowly move towards the next level. A good relation with top management, the level above the project principals, is crucial to make any progress. Maybe at some point top management will start making demands on their business subordinates in other terms than projects, time, and money. When that happens you may see the light at the end of the tunnel. Even then this may prove to be fragile and depending on local heroes instead of a firm engrained phenomenon.

TOWARDS A SINGLE BUSINESS

Again, we will not try to find the general solution, but find a few simple ideas that may improve the situation and may trigger further growth. This big missing thing at the business side of the equation is content. In general business management is well aware of what is wrong with their IT. But have a simplified view of the world that is reinforced by IT vendors and many consultancy organizations as well.

In short, they are sold to the idea that for every problem a specific IT solution exists:

Want customer intimacy? Buy a CRM solution.

Want agility? Buy an ESB.

Want integration (finally)? Buy a best-of-breed EAI solution (sigh).

Want scalability? Put it in the Cloud.

…

It is also very safe for an IT department to let business managers suggest a specific vendor. It is safe because in that case business has a high threshold for critique on the new system; they selected it themselves. That threshold would be very low if business suggests Siebel, but IT decides to implement Baan instead. That is how the world works. Why take any risks as an IT department by suggesting another solution than what business proposes?

Figure 10: A Single Business Face as Prerequisite for Mature IT

Still this pattern can be broken when business introduces discussions on non-functional aspects of IT solutions, with aspects like agility, information quality, and efficiency.

The solution is of course for top management to determine the right goals and indicators and manage the organization as an integrated whole accordingly; business-to-business alignment. The power is and should be in the line organization and changes need to be applied to make enterprise architecture deliver on its promises. Probably this involves more than ―just‖ architecture and is part of improving maturity in a broad sense. A single business face is seen as a prerequisite for mature IT.

We do not suggest in any way for management to micro-manage IT in a top-down fashion. Strategy remains something for the top; the operational translation in successful implementations is typically done bottom-up. This does not mean though that top management can afford to only discuss time and money when ―managing‖ IT.

It is a matter of also defining what non-functional properties the IT landscape should have in order to be a business enabler instead of a roadblock – properties like agility, consistency, data quality, coherence, re-usability, etc. Not in IT terms but in business terms. These properties should be present in a measurable way. When not measurable they are reduced to hollow phrases: ―Do you want agility?‖ ―Yes! (followed by silence)‖. The challenge is to translate these properties into specific actions, instead of sound bites.

Most straightforward is applying, what I call, the Mastenbroek approach (Mastenbroek 1997).

For example:

A top manager who has introduced the architecture team demands that her (business) subordinates contribute by asking each of them: ―What can you do to reduce complexity?‖

One of the answers given might be: ―By removing redundant information stores and preventing the introduction of new ones.‖

The top manager then asks: ―And how can we measure that?‖

When satisfied with the answers given she may state: ―OK, that is what we will do. Your appraisal depends on reducing complexity with an improvement of 50% for the coming year (measured in the suggested way).‖

Each subordinate will do the same to their subordinates. In this case by asking: ―What can you do to make sure 50% of the redundant

Enterprise

Architecture

Project Management

Development Teams

Operations

System Users

Project Principals

Top

Management

1Content

(Enterprise Architecture)

+

$


information stores are removed and no new ones are introduced?‖

and so forth

Or another scenario:

Top management wants to be better prepared for acquisitions. And asks each of its subordinates: ―What can you do to make us better prepared for acquisitions?‖

One of them states: ―By defining and implementing a set of services that allow us to integrate any acquisition without disrupting our business processes.‖

―How can we measure that?‖ Well … these services are business building blocks and IT artifacts at the same time. A new acquisition means changing the internals of these services only. So … ‖To start with, by showing the definitions and implementations of these business services as autonomous pieces of software …‖ and ―… and of course then the proof of the pudding by showing that our next acquisition can be integrated without changing or re-implementing our processes.‖

1 (SOA in

straightforward business terms instead of the latest IT hype).

―OK we’ll talk after the next acquisition!‖. But first: ―Keep me posted on the status of the business service portfolio. You need to convince me and demonstrate that our business processes are indeed isolated from acquisitions before we talk bonus.‖

For some, who are used to complex structural architecture and governance approaches, this may seem much too simplistic. We are convinced that is not the case and there is no need to make it more complex than this. The main difference is that business keeps architectural content in the line organization and refrains from making it an IT architecture exercise only. This means a move for enterprise architecture from IT into the mainstream business domain.

This is a first step into business-to-business alignment and making business start to behave as one in IT matters. The distinction between business and IT will blur as a side effect.

But, in the meantime, it is very important to be aware there is no such thing as ―the business‖.

With that awareness open discussion can start on how to improve the situation.

1 This is one of the SOA scenario’s mentioned in Your SOA Needs a

Business Case (Baarda 2008).

ABOUT THE AUTHOR

Piet Jan Baarda ([email protected]) is a Senior Information Architect at Sogeti Nederland BV.

REFERENCES

Baarda: Your SOA Needs a Business Case (2008); refer to: www.via-nova-architectura.org/files/magazine/Baarda.pdf.

Hoogervorst J.: Enterprise Governance & Architectuur, ICT Bibliotheek, Den Haag (2007).

Jim Morrison & The Doors: Unhappy Girl from Strange Days, Elektra Records (1968).

Mastenbroek W.: Verandermanagement, Holland Business Publications (1997).

http://www.via-nova-architectura.org/files/magazine/Baarda.pdf


Article

Streamlining IT Application Selection and Integration with a Standard Modeling Language

By Iver Band

Abstract

IT customers, application providers, and system integrators generally do not use standard representations to describe either application requirements or proposals to satisfy them. The resulting ambiguity exposes application selection and integration processes, however well-structured and executed, to error and delay. Adoption of the ArchiMate

® visual

modeling language, an Open Group standard, would therefore increase the efficiency and effectiveness of the business application marketplace.

WHY ISN’T IT EASIER TO SELECT AND INTEGRATE APPLICATIONS?

By now, IT customer organizations should find selecting and integrating a major packaged or hosted application a lot easier than it actually is. Standards for common IT components, assemblies, and services are mature or steadily maturing, as are standards frameworks for many industries and functions. Tools and APIs for all phases of application development are generally rich, full-featured, and increasingly well-integrated. Custom development of entire applications has become less necessary for IT groups due to a wide variety of mature software packages and a growing number of hosted applications. Traditional IT challenges such as agile software development, project management, information security, and operations management are supported by broadly recognized methods and bodies of knowledge.

However, when IT customers select and integrate a major application involving diverse user communities and legacy applications, the pace of work often accelerates as the pace of accomplishment slows to a crawl. Much of this difficulty stems from the complexity and ambiguity of integrating the contributions of stakeholders with diverse perspectives, responsibilities, and intentions. To select applications, customers and their consultants typically use structured methods that collect and weigh application and vendor attributes against prioritized or weighted current and expected requirements. Some even construct conceptual models of their current and desired states. However, since the same words or pictures can mean different things to different people, ambiguity is unavoidable. As a result, it is often difficult to predict the progress or ultimate impact of selection processes due to instability and misunderstandings concerning application scope, requirements, and key stakeholders. Selection teams

can resolve these ambiguities, but often only after lots of churn and rework.

Involving application providers only intensifies this challenge. Crafting an RFP, answering respondents’ questions, and clarifying their responses all add additional perspectives and agendas, as does system integrator selection and subsequent collaboration. Indeed, many vendors task very different people with initial relationship-building, responding to RFIs and RFPs, and delivering formal customer presentations. The customer must therefore reconcile a variety of graphic, written, and spoken material from different sources.

HOW CAN APPLICATION SELECTION AND INTEGRATION BECOME EASIER?

What could be done to enhance the certainty, efficiency, and velocity of the IT applications marketplace? Participants could use standard representations of IT application supply and demand that use graphics as well as text. Both customers and vendors could use ArchiMate, The Open Group standard visual modeling language for enterprise architecture, to represent business, data, application, and technology architectures, as well as architectures that combine and relate these layers. As of this writing, the ArchiMate 2.0 extensions for expressing motivations and implementation plans are nearing ratification, and some enterprise architecture practitioners are working with them already.

If customers modeled their conceptual application architectures and application requirements using ArchiMate, application providers could respond in kind. Certainly, free-form customer-supplier interaction would still be necessary, but a commonly understood model would organize and focus these exchanges. Customers could better orient application providers with models that associate requirements with broader concerns and key


stakeholders, as well as critical business capabilities and processes. Customers requiring implementation plans could tie requirements and conceptual system architectures to specific projects within broader programs.

Application providers could respond by elaborating customer models with their proposed applications and integration approaches. Both customers and application providers would benefit from the precision and re-usability of these models. Customers and their system integrators would have a head start on their target application architectures, and application providers could re-use them for subsequent proposals. The selection process would also prepare customers and system integrators to expedite application integration by building on a shared model.

ArchiMate can be easily styled or extended to meet the needs of particular industries, functions, organizations, or methodologies. Modelers can add metadata to the objects represented by its symbols, and can even add or replace symbols. In these cases, the extending party just needs to provide a reference that explains its styles or extensions to its trading partners. Eventually, the mapping of ArchiMate to the Object Management Group (OMG) XML Metadata Interchange (XMI) standard will allow direct translation of ArchiMate models into other languages.

IT CUSTOMER ORGANIZATIONS CAN LEAD THE WAY

ArchiMate 1.0 is a recent (2009) standard, and many in the IT industry have not even heard of it, but IT customers have the power to drive mainstream adoption. They can use ArchiMate in their application selection and integration efforts, and require or encourage vendors to respond in kind.

ArchiMate is fairly intuitive, and diagrams with well-labeled symbols are therefore broadly comprehensible with minimal introduction. The language is supported by a number of major modeling tools, and is compatible with a wide range of architecture development methodologies. I have used ArchiMate diagrams with vendor representatives as well as senior executives in both IT and user organizations, and have found that they work at least as well as diagrams with non-standard graphics. Also, it is easy to identify ArchiMate symbols by annotating them the first time they are used, or by providing simple legends or even brief verbal explanations. Therefore, vendors should not be afraid to take the initiative to use ArchiMate diagrams in proposals and project deliverables, even if the customer has not requested it. Enterprise architects and other professional modelers, however, should prepare themselves with self-study or formal training. Also, a wide range of IT professionals and influential user

representatives should receive basic instruction in reading ArchiMate diagrams.

If more IT customers, application providers, and system integrators embrace ArchiMate, they will increase the effectiveness and efficiency of their own organizations, their trading partners, and ultimately the IT applications marketplace. Verifying these improvements could be the subject of future research as ArchiMate gains broader acceptance.

ABOUT THE AUTHOR

Iver Band is an enterprise architect at Standard Insurance Company, where he works on next-generation customer service solutions as well as enterprise architecture methodology and tools. He also participates in The Open Group ArchiMate Forum. Iver joined Standard Insurance in 2008 after 16 years at HP, where his roles included software and IT engineering, architecture, and management. At HP, he was also the second Visiting Technologist at HP Labs, where he led the development of a patented method for managing network access control.


Book Reviews

121 Things I Learned in Business Architecture School?

101 Things I Learned in Architecture School Matthew Frederick, The MIT Press, 2007. ISBN: 978-0-262-06266-4

101 Things I Learned in Business School Michael W. Preis with Matthew Frederick, Grand Central Publishing, 2010. ISBN: 978-0-446-55028-4

REVIEW BY LEN FEHSKENS

One of the things I’ve learned in the school of hard knocks is that it often helps to remind oneself of the obvious, as the obvious is too often overlooked as not worthy of consideration. These little books, though not explicitly intended to, remind us of the obvious.

Nor are they intended to be comprehensive treatments of their subjects, and as such, I found the few bad reviews they received on Amazon.com hilarious in their cluelessness. Only the clueless could imagine that a small book titled ―101 Things I Learned …‖ would effectively summarize, never mind obviate, an entire undergraduate and graduate education. But set your expectations appropriately, and I think you’ll find them worth a periodic revisit.

These two books are part of a series that now comprises five books, the first of which was ―… Architecture …‖. Matthew Frederick, that book’s author, is the common thread; he illustrates the other volumes, using the same architectural drafting style. The books are all in the same format, with a 5.2‖ high by 7.4‖ wide format, a little less than an inch thick. The other three volumes cover culinary, fashion, and film school.

Enterprise architecture is increasingly viewed as some sort of intersection or integration of business and architecture, so the real question for a review in this journal is what, if any, relevance do these two books, especially together, have for an enterprise architect? They are, after all, not intended for an audience of enterprise architects, but for students respectively of civil (building) architecture and business.

The answer to that question is suggested by the authors’ notes that introduce each book.

From ―… Architecture …‖:

―This book aims to firm up the foundation of the architecture studio by providing rallying points upon which the design process may thrive. The following lessons in design, drawing, creative process, and presentation first came to me as barely discernible glimmers through the fog of my own education.‖

From ―… Business …‖:

―While business schools provide specific information, skills, and tools for tomorrow’s business people, they more importantly should instill a desire and proficiency for learning beyond the classroom. Furthermore, there is no single discipline called business; it is, rather, a broad field of endeavor encompassing such diverse disciplines as accounting, communications, economics, finance, leadership, management, marketing, operations, psychology, sociology, and strategy.‖

Except maybe for drawing (and I could make a case for its inclusion if pressed), these enumerated concerns are all also concerns for enterprise architects. How many of the 101 sometimes very brief essays on these concerns in each of these books say something of potential use to a practicing enterprise architect? I did a simple count to find out, and it turns out it’s a little more than half of them. My categorization was necessarily subjective, but certainly no more arbitrary than the choice of 101 as a bound. It was 53 (or so) for ―… Architecture …‖, and 68 (or so) for ―… Business …‖. Hence, the 121 in the title of this review. Your mileage may (almost certainly will) vary, of course.

Some examples. The ―… Business …‖ book starts out with a definition of business that ought to be required reading for anyone who wants to talk about business architecture:

―Business is the exchange of entities to which value has been assigned.‖

Business is not about value creation. Business is not an enterprise’s processes. Architectures that address these concerns are not ―business architectures‖. They are value creation architectures or process architectures. While they are certainly supportive of business, they are not what a ―business person‖ would likely expect business architecture to be, if said ―business person‖ did not vanish at the mention of the ―a-word‖.

Then there are items like The Rule of 72, which, though it may be useful for anyone who has occasion to make a quick estimate of the doubling time of compound


interest, is probably something an enterprise architect can survive without.

Similarly, from the ―… Architecture …‖ book, a statement like:

―If you can’t explain your ideas to your grandmother in terms that she understands, you don’t know your subject well enough.‖

is something that every enterprise architect ought to embrace as a first principle. On the other hand, while the fact that ―Windows look dark in the daytime‖ may be a fascinating cocktail party conversational gambit, it’s again not something an enterprise architect needs desperately to know.

I have long argued that the successful enterprise architect’s competencies are a synthesis of competencies from many other disciplines, integrated with and by an architectural perspective. I also noted in an earlier JEA book review that I am always looking for ways to extend the way I think about enterprise architecture, and that these often come from outside the discipline. These books are a case in point – I think their real value to an enterprise architect comes from the exercise of asking which of the 101 things in each of these books is relevant to enterprise architecture, and more importantly, how.

Len Fehskens is the Vice President, Skills and Capabilities for The Open Group. He is responsible for The Open Group's activities relating to the professionalization of the discipline of enterprise architecture.

IT Architecture: Essential Practice for IT Business Solutions

Beijer, Peter & Theo de Klerk, Lulu.com, 2010 (xviii + 217 pages). ISBN 978-1-4457-0603-0

REVIEW BY LEN FEHSKENS

First, I have to address my objectivity in reviewing this book. I know the authors; they were colleagues of mine at HP Services and remain personal friends. I wrote the foreword to this book, and am mentioned in it in several places. While I have no financial interest in this book’s success, its content was an integral part of the last seven years of my career at Compaq Professional

Services and HP Services, and I have an obvious interest in the promotion of its ideas. You have been warned – take what I say with an appropriately sized grain of salt.

This book is about HP Services’ IT architecture method (HP Global Method for IT Strategy and Architecture, or

ITSA), and the concepts underlying it. While originally intended as a method for developing solution architectures (as should be apparent from the title), the thoughtful reader may realize that it is much more generally applicable. At HP Services, we often used ITSA as a general problem-solving method.

What distinguishes ITSA from most other solution architecture methods, and thus distinguishes this book from most other books about IT architecture, is best summarized by quoting myself from the book’s foreword:

―Most of these methods are project management lifecycle models for architecture projects; they say what things you should do or produce in what order, but they say little about how to do or produce these things. Only a few of these methods are heuristics for producing architectural work products; ITSA is one of these few.‖

Structurally, the book comprises a foreword, a preface, 16 chapters, 6 appendices, an ―About the Authors‖ section, and an index. It includes 49 figures and 15 tables.

Each chapter starts with an aptly chosen epigraph or two, and a concise summary of the chapter’s content.

The content of the book is heavily derived from the training materials used to teach ITSA to HP Services solution architects. The ―Architecture Concept‖ was taught in a week-long intensive workshop combining lectures and a role-playing exercise in which the class participated over the entire week. The ―Architecture Blueprint‖ was taught in a virtual classroom spanning four days of four hours each. Both the Architecture Concept and Architecture Blueprint are covered in the book.

As I am already intimately familiar with the details of ITSA, and specifically with these training materials, it is hard for me to judge how well the book does in explaining the method to the uninitiated. The only thing missing from the book that I think played an important factor in the success of the week-long workshop is the role-playing exercise. Still, I am confident that the book can provide a thoughtful reader with a usable understanding of the ideas of the method.

What are those ideas? From the book:

Business Drivers are business conditions or pressures that motivate to seek a solution.

Business Goals are objectives of the solution; i.e., what the solution must accomplish in business terms.

Business Metrics define the goals in measurable terms so they indicate the degree to which goals are achieved.

Principles are a fundamental approach or means for achieving a goal; they are timeless, show how


the solution is meant to work, and constrain decisions about the solution and its realization.

Models represent essential properties of some aspect(s) of the solution; they promote understanding by making important things obvious and facilitate reasoning about the solution (analysis).

Standards are well-defined conventions or measures with which a solution must comply; they are used to constrain and/or evaluate the development and implementation of a solution.

The ITSA Architecture Concept organizes the architectural elements of principles, models, and standards into four views: business (why?), functional (what?), technical (how?), and implementation (with what?), as depicted in Figure 6 from the book:

Figure 6: The Four Views with Architectural Elements

Please note that these ―views‖ are not exactly the views of IEEE 1471/ISO 42010; the ITSA terminology predates these standards for the ―architectural description of software-intensive systems‖. This structure of architectural elements is motivated by and evaluated against drivers, goals, and metrics. It’s also important to understand that the ―implementation‖ view includes deployment, operation, maintenance, evolution, and retirement of the architected entity; ITSA treats a solution as considerably more than a software application and its execution platform.

ITSA emphasizes the role of principles much more heavily than most architectural methods; it devotes three chapters totaling 35 pages to principles, compared to a single chapter of 8 pages devoted to models. Architectural principles are used to tie the four views of the ITSA architecture concept together, as depicted by Figure 20 from the book:

Figure 20: ITSA Goal-Means Hierarchy of Principles

Note that this is not a process or workflow diagram; it is an information structure diagram. ITSA as a method provides guidance and heuristics for building this information structure.

The value of this information structure is that when properly defined it provides a seamless chain of motivation and justification for every design decision, rooted in the top-level business drivers and goals. There are no ―leaps of faith‖, and the architects and stakeholders can be confident that the architecture specifies, to borrow a tag line from a Nissan advertising campaign from some years back, ―everything you need and nothing you don’t‖.

As if that weren’t enough, the book further describes how these architectural elements can be used to create an execution plan for project managing the implementation (again, in the broadest sense) of the architected entity. The architecture blueprint, derived from the architecture concept, bridges the gap from the purely architectural domain to the domain of project planning, management, and execution. Figure 35 from the book illustrates this connection.

My experience using ITSA in real-world situations is that it dramatically improves the likelihood of a project being successful, not only from the project management perspective (―on time, on budget, on spec‖), but more importantly from the stakeholder satisfaction perspective – it’s not success to do an excellent job of delivering the wrong solution. If you want to learn how to do this, and incidentally why principles deserve to play at least as large a role in architecture as models currently do, I cannot imagine a better place to go than this book.

Why should a book about solution architecture be of interest to enterprise architects?

As a solution architecture method, ITSA complements rather than competes with the methods and frameworks familiar to enterprise architects.


Figure 35: The Big Picture from Initial Architecture to Solution Project

Enterprise architectures are rarely implemented in their entirety as a single project. Indeed, I am repeatedly surprised by the vigor with which some enterprise architects reject the idea of a ―project‖ as having anything to do with enterprise architecture, sometimes to the point of disqualifying an effort as enterprise architecture if it is described in any way as a project. Be that as it may, at some point for an enterprise architecture to be realized, someone has to execute projects – i.e., bounded efforts – that implement operational (as opposed to conceptual) solutions to actual business problems, needs, and opportunities.

An enterprise architecture is supposed to provide a context for these solutions that ensures that they are not, at best, well architected silos. Doing so means that the enterprise architecture must take account of what the architectures of these solutions require of that context. I suspect that many enterprise architecture efforts (almost said ―projects‖) fail because their output is not usable in a practical sense to bridge the gap between the enterprise level and the solution level.

What this book provides for enterprise architects is a comprehensive overview of what a fit-for-purpose solution architecture looks like. While it does not spell out in detail what is required of an enterprise architecture as context, this should be something a competent enterprise architect can infer.

The ultimate value of this book for an enterprise architect is thus what follows after reading it, the exercise ―left to the reader‖.

Len Fehskens is the Vice President, Skills and Capabilities for The Open Group. He is responsible for The Open Group's activities relating to the professionalization of the discipline of enterprise architecture.

Journal of Enterprise Architecturelibrary.nic.in/e-journalNew/JEAMagazines/JEA_2011-2.pdfFEATURES...

Documents

Transcript of Journal of Enterprise Architecturelibrary.nic.in/e-journalNew/JEAMagazines/JEA_2011-2.pdfFEATURES...