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
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 john@gotzespace.dk.
Article Submissions: Authors may submit properly formatted manuscripts to the JEA Chief Editor at john@gotzespace.dk 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.
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 john@gotzespace.dk.
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 john@gotzespace.dk.
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 Enterprise As-Is Enterprise
Transformation Governance
To-Be Enterprise To-Be Enterprise
As-Is Picture
To-Be Picture
Align
Qualityof StrategicArchitecture Management in Transformation Governance HighLow
High Low
Quality of Operational Architecture Management in Transformation Governance
Direct
Guide
Contract
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 (ds@act-consulting.de) 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 1st 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 9th IEEE
International EDOC Enterprise Computing Conference (2005).
Fischer R., Aier S., Winter R.: A Federated Approach to Enterprise Architecture Model Maintenance, Proceedings of 2nd 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).
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 3rd international Web Conference, Perth (2002).
Winter R., Fischer R.: Essential Layers, Artifacts, and
Dependencies of Enterprise Architecture, Journal of Enterprise Architecture (May 2007).
© Journal of Enterprise Architecture – May 2011
© Journal of Enterprise Architecture – May 2011
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.
