Enterprise Architecture

www.aeajournal.org

Journal of Enterprise Architecture

May 2011, Volume 7, Number 2

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

Journal of Enterprise Architecture

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

Associate Editors

Andy Blumenthal William W. Krauter, PhD CTO, Bureau of Alcohol, Tobacco, Firearms and Explosives Senior Architect, Lockheed Martin Corporation Tyson Brooks, PMP Haiping Luo, PhD School of Information Studies, Syracuse University International Trade Administration, US Dept. of Commerce Dick Burk Stephen Marley, PhD Enterprise Architect Harris Corporation Brian Cameron Thomas J. Mowbray, PhD Professor & Executive Director, Center for EA, PA State University TASC, Inc. Larry DeBoever George Paras assureEV Managing Director, EADirections Gary Doucet Pallab Saha, PhD Treasury Board Secretariat, Government of Canada Professor of Information Systems, National University of Singapore Robert Ellinger, PhD Cathy Sowell Northrop Grumman Corporation President, Custom Enterprise Solutions, LLC Len Fehskens Torben Tambo VP, Skills and Capabilities, The Open Group Associate Professor, Aarhus University Institute of Business & Technology John Grasso, PhD Michael Tiemann School of Computer Science, Carnegie Mellon University Enterprise Architecture Consultant Kristian Hjort-Madsen, PhD Pat Turner Manager, Accenture Director, Centre for EA & Research Management, Griffith University Michelle Kaarst-Brown, PhD Tim Westbrock Associate Professor, Information Studies, Syracuse University Managing Director, EADirections Leon Kappelman, PhD John Zachman College of Business, University of North Texas 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.

2 © Journal of Enterprise Architecture – May 2011

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

Shorter Articles is our new section with, well, shorter articles, opinions. In his half-short article, Piet Jan Baard Editor’s Corner argues that ―the business‖ does not exist, and in his short article, Iver Band suggests application vendors and By John Gøtze developers adapt ArchiMate®. Welcome to the May 2011 issue of the Journal of Last, but not least, Len Fehskens presents two book Enterprise Architecture. reviews, of three books. As always, Len's reviews are sharp and informative. This number’s Architect in the Spotlight is Adrian Apthorp, who is one of the most inspiring enterprise Regular readers will notice we do not have a regular architects I have the pleasure of knowing. Adrian is case story in this issue. That is because we didn’t get Head of EA for DHL Express Europe. any case submissions. I blame all the non-disclosure agreements we all have to live with. Yet, I know there The articles in this number cover a wide range of are so many stories and experiences out there. The contemporary and emerging issues in our discipline. irony is that sharing the stories and experiences often Daniel Simon distinguishes between four general modes become good branding in a world where transparency of architectural transformation governance and presents and openness is increasingly valued by decision- the different faces of enterprise architecture makers. management prevalent in these modes. So I dare you all to share your enterprise architecture Toomas Tamm, Peter B. Seddon, Graeme Shanks, and stories and experiences! You can reach me on Peter Reynolds aim to take a step towards improving the [email protected]. 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- ABOUT THE EDITOR aware. Dr. John Gøtze is program manager at the IT University Inji Wijegunaratne, Peter Evans-Greenwood, and of Copenhagen and lecturer at Copenhagen Business George Fernandez present two very different, successful School. He is also a partner in EA Fellows, and runs enterprise architecture projects, described as EA Heavy Carnegie Mellon University’s EA Certification program in and EA Light, that managed to deliver and demonstrate Europe. tangible benefits to the respective organizations.

4 © Journal of Enterprise Architecture – May 2011

WHAT IS THE GREATEST CHALLENGE FACING ENTERPRISE ARCHITECTURE TODAY? Architect in the Spotlight I think the challenge is really the same one that has been facing enterprise architecture for a long time. Adrian Apthorp Enterprise architecture has somewhat of an identity crisis. Much of this comes from the label and others’ I am currently the European Head of Enterprise perception of enterprise architecture and the space in Architecture at DHL Express having served in a number which many enterprise architectures find themselves. of regional and global architecture roles with DHL over Architecture seems to equate to technical in many the last 22 years. Before moving into architecture I people's minds and although ―enterprise‖ should imply a worked in IT development and support. Progressively whole enterprise perspective many enterprise over the years I have moved further away from the architectures operate only in the world of IT. physical circuits and electrons I studied at university (I studied electrical and electronic engineering). As a Also as a relatively young discipline I have come to sponsored student with Marconi Radar I was debugging wonder if enterprise architecture is really a separate multi-layer circuit boards. However, as an MIET and discipline or a set of tools for the management toolkit. I Chartered Engineer I have retained some of these roots certainly hold to the view that if enterprise architecture is and try to bring general engineering principles to about the architecture of the enterprise then it needs to enterprise architecture. be embedded in it and applied by more than a specialist team of architects. Originally from the UK I am now somewhat of a world citizen having lived and worked in Singapore (I married a In conclusion I wouldn't be surprised if enterprise Singaporean), Brussels, Prague, and now Germany. architecture morphs and splits off in different directions When I get the opportunity I enjoy sailing; there must be in the future. We're already seeing this with the focus on a connection in navigating the waters, the globe, and the Business Architecture in the last couple of years. enterprise. WHAT IS THE NEXT BIG THING IN ENTERPRISE HOW DID YOU BECOME INVOLVED WITH ARCHITECTURE? ENTERPRISE ARCHITECTURE? The fusion of enterprise architecture with other This was really through a number of chance management practices is an exciting prospect. I see circumstances starting with my first DHL interview. The steps in this direction with, for example, the extensions interview was with Nigel Green (co-author of Lost in of TOGAF to embrace program and project Translation and VPEC-T) who even though he didn’t management. Indeed, traditionally enterprise have a role for me thought I was worth having around architecture is discussed and gets applied for change and persuaded one of his colleagues to hire me. management. However, for enterprise architecture to become truly embedded in the enterprise it has to Then my first significant project after joining DHL was to become relevant in the other aspects of enterprise integrate and manage the initial deployments of our management; direction setting and operation of the internal message broker (before third-party products enterprise. For example, how do our enterprise were available) in Singapore and Japan. This is architecture models link to operational constructs, such deployed globally and still today is the IT backbone of as the chart of accounts, or to training materials? the Express business. Apart from the exposure to working with different cultures this also gave me insights Therefore, steps to develop synergies between the into the significance of aligning business process and practices of these areas of management and enterprise semantics to ensure information systems integration in architecture hold the key to really establishing the role of highly distributed systems. enterprise architecture. An internal white paper that I wrote based on what I'd One other area that I think holds some potential, and learnt (describing how to use formal methods to relates to this, is the development of enterprise configure the routing of messages) got noticed and I was architecture patterns and anti-patterns. For example, co-opted for a global IT strategy initiative. what patterns are employed to enable agility in an enterprise? 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 WOULD YOU SAY TO SOMEONE WHAT IS IT LIKE BEING A HEAD OF ENTERPRISE CONSIDERING MAKING ENTERPRISE ARCHITECTURE? ARCHITECTURE THEIR CAREER AREA? (AND TO It's a balancing act. SOMEONE HAVING AN ENTERPRISE First, as senior professionals we have a management ARCHITECTURE CAREER?) responsibility to discharge and indeed need to operate Communicate, communicate, communicate. Enterprise within the governance structure of an organization in architecture has its own unique vernacular, but we need order to establish the enterprise architecture. On the to communicate with our stakeholders in the language other hand, as architects we have both a need and they understand, not the language of ―artifacts‖. tendency to get embroiled in the content. It's very easy Indeed, one of the roles of an enterprise architect is as a to get stuck into the content and forget the management translator: devices required to establish and maintain the architecture.  Between the language of business, information, and technology Secondly, there is a need from both an experience and credibility point of view to engage in solution  Between high-level management decisions and architecture. However, of course this needs to be concrete design decisions balanced by ensuring the enterprise architecture is in  Between a vision and the concrete actions to place and being kept up-to-date. realize it 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 This section aims to bring recognition to a variety of capabilities, processes, and how they are contributors to the enterprise architecture field – from realized with business design and IT early pioneers, to current practitioners beginning their infrastructure, etc.) is being used to shape and careers, to experts from other fields that influence plan a major change program, and being told enterprise architecture – and is intended to show the rich that is absolutely the right way to go about it. diversity of backgrounds and views that the enterprise architecture community enjoys. 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.

6 © Journal of Enterprise Architecture – May 2011

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

architecture management prevalent in these contexts: INTRODUCTION solution architecting, roadmapping, and business According to Friedman (2005): architecting. This will be based on an integrated view of enterprise transformation and enterprise architecture ‖… every morning in Africa, a gazelle wakes up. It knows it must run faster than the fastest lion or it will be killed. Every management, which is constructed according to the morning a lion wakes up. It knows it must outrun the slowest design science paradigm (Hevner 2004). In particular, gazelle or it will starve to death. It doesn’t matter whether you this approach assimilates experiences from various are a lion or a gazelle. When the sun comes up, you’d better project assignments and previous research alike and be running.‖ extends the latter in that it puts key architectural Translated to the business world, it is this environment activities into the context of enterprise transformation. A that many enterprises have found themselves being part central aspect of this is the division of enterprise of and that speaks to the ever-present necessity to architecture management into strategic and operational transform. Such a transformation, however, needs to be architecture management, as to be introduced in the thoroughly planned and governed (Buckl et al 2009; following section. Schmidt 2009). CONCEPTUAL FOUNDATION: TRANSFORMATION During the past years, enterprise architecture has IN THE LIGHT OF ENTERPRISE ARCHITECTURE become widely acknowledged as a significant facilitator MANAGEMENT of systematic decision-making (Kappelman et al 2008). In simple words, the process of enterprise transformation In short, an enterprise architecture is a structured and can be structured based on a picture approach; i.e., aligned collection of plans for the integrated capturing the current enterprise in the form of an as-is representation of the business and IT landscape of the picture, then designing a to-be picture based on that, enterprise, in past, current, and future states (Niemann and finally implementing this to-be picture and thereby 2008). As such, enterprise architecture can be used as making this picture the new reality. This is in line with the guiding framework for enterprise transformation three major goals of enterprise architecture initiatives (Schekkerman 2004; Simon 2009b). As for the final (Fischer et al 2007): transformation execution, however, there are different governance approaches that can be taken, each of  Documentation and communication of the as-is which has a certain level of strategic and operational architecture quality.  Support for the design of the to-be architecture Having said this, this article suggests four general  Support for projects that transform as-is into to-be modes of architectural transformation governance and architectures sheds light on the different faces of enterprise

8 © Journal of Enterprise Architecture – May 2011

To that end, enterprise architecture management within transformation governance. In other words, they captures all those processes, methods, tools, and indicate a quality of architectural support in responsibilities that are necessary to build a holistic and transformation governance, on both a strategic and an integrated view of the enterprise and to allow for a operational level. Given these two dimensions, the continually aligned steering of business and IT (Niemann resulting modes include contracting, on the one hand, 2008; Matthes et al 2008). As such, enterprise and the ―active‖ approaches of operational guidance, architecture management deals with different strategic direction, and enterprise alignment (as the one architectural layers. In particular, these include business combining strategic and operational attributes), on the architecture, information architecture, application other hand. architecture, and technology architecture (The Open Transformation Governance Group 2009). Across these layers, enterprise architecture management is of both strategic and As-Is Enterprise To-Be Enterprise operational nature (Niemann 2008). Strategic As-Is Enterprise To-Be Enterprise 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 As-Is To-Be Picture Picture 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 Figure 1: Governance within Enterprise Transformation architecture management may act as facilitators of (adopted from Simon 2009b) enterprise transformation. Within the process of enterprise transformation, governance aspects become particularly relevant when it High 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, Direct Align mechanisms, and processes used to coordinate and Governance monitor the transformation process at different levels of granularity (Albers 2010). In particular, the actual Architecture 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 Strategic resistance. This is where enterprise architecture of management may play a crucial role. There are different approaches to architectural governance though, which Contract Guide can be taken. Essentially, this is based on the degree of Quality strategic and operational architecture management involved. The application of operational architecture in Transformation Management management, on the one hand, may be the appropriate Low means to assure that specific architectural solutions are Low High designed and implemented according to the specified Quality of Operational Architecture transformation requirements. Strategic architecture Management in Transformation Governance management, on the other hand, addresses the ―big picture‖ and may support the governance of the Figure 2: Enterprise Architecture Governance Modes transformation initiative as a whole. The “Contract” Mode ENTERPRISE ARCHITECTURE GOVERNANCE MODES OF ENTERPRISE TRANSFORMATION A low quality of both strategic and operational architecture management within the process of With the conceptual foundation for enterprise enterprise transformation is where governance may architecture-based transformation governance being set, primarily make use of contracts to capture relevant four general governance modes can be distinguished architectural requirements, principles, and standards that (see Figure 2). These modes reflect the relevance of individual solution projects need to consider. Using strategic and operational architecture management

architecture contracts as an instrument to govern does not allow transformation governance on a wider implementation activities is particularly promoted by scale; i.e., the direction of a portfolio of projects towards TOGAF® (The Open Group 2009), considering the envisioned to-be state. architecture contracts as ―joint agreements between development partners and sponsors on the deliverables, The “Direct” Mode quality, and fitness-for-purpose of an architecture‖. It primarily draws a distinction between architecture design As opposed to governance modes on the solution and development contracts (i.e., contract between project level, the mode of direction provides systematic architecture design and development partners), on the support for a whole set of projects. This includes the one hand, and business users’ architecture contracts assurance of the mutual alignment of the transformation (i.e., contract between architecting function and business projects, the continual re-prioritization of transformation users), on the other hand. According to TOGAF (The efforts, the management of corresponding Open Group 2009), a governed approach to the dependencies, and the holistic management of management of contracts ensures a system of implementation activities towards the achievement of the continuous monitoring of architecture-related activities in overall to-be state. Therefore, this governance mode the organization. does not involve operational support but draws upon aspects of strategic architecture management. As such, contracting may act as a reasonable Roadmapping is considered to be the main constituent in governance approach within individual transformation that context (Simon 2009b). projects of rather low architectural relevance. The fundamental drawback, however, is that in critical This governance mode, however, may be subject to the situations time and budget (as provided by the project ―ivory tower‖ phenomenon (van der Raadt et al 2008); sponsor) may be given preference to the disadvantage i.e., the enterprise architecture function may not be of specific architectural requirements set in such a perceived of value since it does not actively participate in contract. Furthermore, in cases of high architectural projects that actually deliver change. This may of course relevance, on the one hand, and a complex and dynamic jeopardize the acceptance of architectural transformation project environment, on the other hand, closer support governance. All-in-all, this may result in a need of a may be required to overcome these challenges and gain governance mode combining strategic and operational the necessary acceptance within such projects. aspects and further addressing the continuous, sustainable, and enterprise-wide aspect of The “Guide” Mode transformation governance.

Higher architectural relevance and challenges as those The “Align” Mode described above represent a typical setting where the governance mode of guidance finds particular Given a significant transformation governance role of advantages. This is characterized by a high involvement both strategic and operational architecture management, of operational architecture management within the the mode of alignment may be considered the most process of enterprise transformation. Thereby, challenging, but also the most promising and transformation projects are provided with dedicated sophisticated one. This is due to the fact that it combines design and implementation support by the enterprise several faces of enterprise architecture management, architecture function (Harmsen et al 2009). In fact, including the solution architecture and the roadmapping solution architects may guide the projects through a faces. Most importantly, however, there is the business structured solution architecture process and thus provide architecture face, which is supposed to serve as an detailed design guidance, or at least participate in instrument to keep overall control of the enterprise regular architectural reviews and offer recommendations transformation from strategy into action (Ross et al for further work to stay aligned with what has been 2006). In fact, business architecture models that address defined in the to-be picture and, in particular, with any not only procedural and organizational but also strategic standards set. aspects may be used to inject changes into the corporate culture, to better cope with new requirements The main benefits of applying this governance mode and and to continuously drive and align the enterprise making use of systematic solution architecture guidance, towards the key objectives and the developed target which incorporates aspects of standards management state (Aier et al 2008a), on both a strategic and an (as the practice of defining, maintaining, communicating, operational level. Specifically, they allow change and monitoring the appropriate use of architectural requests to be evaluated against the target business standards), clearly are that it helps overcoming the main model, and decisions to be made with the necessary issues associated with the ―contract‖ mode (Slot et al alignment and accountability. Further, the defined 2009). However, it is restricted to single projects and fundamentals of the business can be properly

10 © Journal of Enterprise Architecture – May 2011

communicated and made understandable, which helps hand, architects may have veto rights over designed to assure that everyone moves in the same direction. solutions or may at least impose budgetary obligations As already indicated above, enterprise transformation on projects that do not sufficiently meet the identified thus takes place on different levels (Harmsen et al architectural requirements and that do not provide 2009); i.e., on the project level, on a portfolio level, and reasonable justifications for any deviations. On the other on the overall enterprise level. Accordingly, architectural hand, projects may also be incentivized by promising transformation governance may also span these levels, financial rewards for conforming designs (Buckl et al with different faces of enterprise architecture 2010). In case of lacking communication and advice management being involved. These faces constitute the prior to any review activities, however, architects may fail nature of transformation governance; i.e., its strategic in gaining the necessary acceptance and may be stuck and operational nature (see Figure 3). While solution in the perception of being ―black sheriffs‖, who inquire architecture activities represent a form of operational into conformity without adequately specified and governance, roadmapping can be considered as an communicated standards (Niemann 2008). Getting back instrument of strategic governance. Business to the notion of guidance, the existence of solution architecture management embodies both strategic and architects without proper engagement in projects may operational governance aspects. These different not significantly contribute to overcoming the ―ivory architectural faces outlined are depicted in greater detail tower‖ phenomenon. Instead, a ―proactive‖ advisory in the following sections. approach is required. First and foremost, this applies to the standards management part of solution architecting Strategic (Boh & Yellin 2006; Schmidt 2009), embodied either by Governance Roadmapping the solution architect itself or by a separate reference Business architect or standards manager (Buckl et al 2010). Architecture Operational In development projects of architectural relevance, Governance Solution Architecture standards management should play a key role (Simon 2009a). That is because it answers questions like: What Figure 3: Enterprise Architecture Faces in Strategic and are the standard components available? What principles Operational Governance do I have to adhere to? Which reference architectures LEAVING THE IVORY TOWER: ON THE may suit my needs? A properly categorized and IMPORTANCE OF SOLUTION ARCHITECTING communicated portfolio of standards can serve as the basis for answering these questions. This standards Reducing itself to work within the ―ivory tower‖ only may portfolio (act! 2010c) may encompass various be considered as one of the main reasons of failure of architectural layers (Winter & Fischer 2007); e.g., any enterprise architecture practice (van der Raadt et al business architecture, application architecture, and 2008). To really bridge the gap from strategy to action infrastructure architecture, in all of which different types and to provide transformation governance where actual of standards can be defined (see Figure 4): implementation activities take place, it is advisable to be involved deeply at the operational level; i.e., in solution  Building Blocks: Fundamental architectural projects delivering change to the enterprise. It is there objects; e.g., technical components, business where solution architects as part of the enterprise activities architecture function take on a vital role (Slot et al 2009).  Patterns: Valid combinations of building blocks; Solution architects are supposed to support the e.g., platforms, reference architectures architectural solution design and implementation on  Methodologies: Methodological descriptions and behalf of the enterprise architecture function, thereby guidelines to be applied assuring the compliance with architectural principles. This support can have different forms, from few or  Directives: Principles, rules, and general regular reviews to ongoing guidance within a systematic guidelines that are to be adhered to solution architecture process that stretches across the Despite communication, advice, and assistance within identification of the functional scope and requirements of the process of architectural design, the selected architectural design, the development and evaluation of architectural solution may eventually not comply with architectural solution scenarios, the documentation of defined standards. During architectural reviews, the architectural solution, the actual implementation, enterprise architecture management is therefore asked and, finally, harvesting gained experiences during to evaluate how to deal with any non-compliance. In fact, implementation and the initial phase of operations. one has to determine whether a deviation from a There are different mechanisms for assuring the standard is reasonable and should be accepted as an compliance with architectural principles. On the one exception (at least temporally), or whether corrective action needs to be taken to create a new architectural

design. To sum up, solution architecting is a means of  Agility requirements: A high degree of required guiding individual transformation projects towards the agility may result in a higher prioritization of defined goals. projects that increase standardization and are

Lifecycle Building therefore able to improve the time-to-market. Directives Methodologies Patterns Blocks  Project decidability: Often only a minor part of the budget is assigned to investments going Standards beyond housekeeping (Niemann 2005; Niemann categories • SOP • Process modeling • Usage • Process 2006). That is why one may differentiate between Business • Business principle technique scenario component Architecture • Business rule • Architecture • Job • Reporting mandatory and ―lights-on‖ projects (Simon et al development method description path 2010), both of which are non-decidable, and • Library • Test method • Frame- • Software engineering • Reference • Application principle work innovation projects, which are decidable. In case Application method archi- • Application rule • Application Architecture • Architecture tecture building development method of time pressure, non-decidable projects may find block themselves prioritized. • Deployment • Infra- method structure • Infrastructure principle Infrastructure • Operational guidelines • Platforms compo- • Infrastructure rule Architecture • Architecture nent  Benefit expectation: Based on cultural values development method • Device and market requirements, there may be enterprise-specific expectations with respect to Architecture Domain benefit realization. This may have a significant Figure 4: Standards Portfolio – A High-Level Structure impact on the importance of quick wins and the (adopted from Simon, 2009a) significance of corresponding projects. ROADMAPPING AS A FACILITATOR OF  Resistance to change: Quick wins are to be SYSTEMATIC CHANGE taken into account due to another reason. Enterprise transformation is likely to be subject to In order to not only govern transformation at the project internal resistance to change. Projects delivering level, but to also provide systematic direction for a quick wins can demonstrate immediate value and program or even portfolio of projects contributing to an mitigate the risk of transformation failure. overarching transformation goal, enterprise architecture management may provide substantial assistance by  Competitive strategy: A factor of particular applying roadmapping mechanisms. Roadmaps (Buckl importance is the competitive strategy. In case et al 2009) come into play as soon as the enterprise this entails a strong need for differentiation; for architecture planning process has determined a target example, projects related to distinctive business scenario to be implemented, identified gaps with respect processes are likely to be attributed with higher to the current state, and adequately grouped and priority. translated them into projects. Based on that, roadmaps  Risk aversion: A project’s size and the amount typically define the project deliverables necessary to of changes implemented through it are among implement the target scenario, set up a corresponding the main determinants of its complexity. The time schedule, and define planned states as more risk aversion the enterprise embodies, the intermediate steps towards the target state. less complex projects tend to be, for example. The establishment and maintenance of this time  Budget & resource availability: Of course, also schedule is subject to a set of contingency factors budget and resource availability at a certain point (Simon 2009b; Simon et al 2010) that may have a in time are likely to have an impact on how significant impact on the approach to roadmapping and complex projects are and on when they are to be on the design of the final roadmap: carried out.  Internal dependencies: Projects in the roadmap In consideration of these contingency factors and based may have dependencies with one another; e.g., on the relationships captured within the enterprise the start of project B may require the completion architecture, architectural roadmaps help to govern the of project A, and project C may conflict with transformation portfolio as a whole and to synchronize it project D. with further project activities within the enterprise  External dependencies: Projects in the roadmap (Fischer et al 2005). This can also be broken down to may also have dependencies with other projects individual application systems affected by the not in scope of the transformation initiative. They transformation using so-called evolution fact sheets (act! may also be subject to uncertainties regarding 2010a), describing the evolution of individual application technological and regulatory developments and systems along the different stages of the defined may thus need to be postponed. roadmap. The highest level of quality and, most importantly, sustainability of architectural transformation

12 © Journal of Enterprise Architecture – May 2011

governance, however, may only be reached by a However, it is a structured description of the business thorough management of the business architecture. strategy and the future business model that most likely serves as the key lever to inject sustainable change into BUSINESS ARCHITECTURE AS THE KEY FOR the enterprise. In fact, it is only then that business INJECTING SUSTAINABLE CHANGE INTO THE architecture may unfold its real value. This potential also ENTERPRISE seems widely acknowledged by many IT professionals, A business architecture is a structured description of the whose perception is that business architecture is business (Österle et al 2007; Riege et al 2008) implemented only to a small extent of what they would containing the business strategy, the business model, really need (Leganza 2010). Providing structured views and the business organization (act! 2010b): of the business, business architecture can be considered the governance cockpit of transformation. It facilitates  Business strategy: The business strategy communication and provides a common picture of the captures the strategic context of the business; envisioned business (Aier et al 2008a; Winter 2003). i.e., mission, vision, goals/ objectives, strategies, Further, it takes greater alignment and accountability into principles, drivers, constraints, and risks. It decision-making by creating transparency of what are explains why the business operates in a certain the fundamentals of the business (Winter & Fischer way. 2007) and of what are corresponding responsibilities. All-  Business model: The business model brings the in-all, this may help to ensure following the defined high-level strategic concepts down to earth. In transformation path. essence, it expresses the fundamental business Change requests can be challenged by asking how this logic and represents the entire system of would affect the business model and whether this delivering value to customers and earning profits conforms to the business model (Riege et al 2008). In from these activities. As such, it can be addition, architecture principles can be used to considered a blueprint of the business strategy effectively carry business objectives, strategies, and the (Osterwalder & Pigneur 2010). Thus, the value overall business model into the organization, for proposition, financial model, products/services, example. Eventually, transformation projects can be markets, and the whole architecture of value assessed on a continual basis with respect to how they creation (e.g., business partners, customer affect the enterprise’s business capabilities (Aier et al interfaces, value chain configuration) are among 2008a) – a term which has found itself increasingly the primary elements making up the business discussed in both literature and practice (Brits et al model. 2007), though not properly and commonly defined and  Business organization: The business most often not sufficiently delimited from IT capabilities organization includes those elements that are yet. In general, however, a business capability can be necessary to execute the business model. In considered an enterprise’s ability to execute a defined particular, this covers the business processes, and repeatable pattern of activities and produce a the organizational structure, and the information desired outcome (e.g., product, service). It is based on a entities, as well as their aggregation into business specific set of business processes, organizational units, capabilities. and information objects (act! 2010a). As such, business Unfortunately, enterprises often stop short of extending capabilities complement business strategy and model in the notion of business architecture beyond the business extending traditional business architecture efforts that organization to also include the business strategy and mainly focus on process engineering or organizational the business model (Aier et al 2008b; Schönherr 2008). design activities. Business architecture can then be Still, there seem to be many who perceive business leveraged on a broader scale and may considerably architecture as the practice of documenting and advance architectural transformation governance. analyzing business processes only (Griffith 2010). In SUMMARY AND CONCLUSION search of any reasons for this, the ―lamp-post story‖ may provide the answer, describing a man searching for a In summary, enterprise architecture management offers lost object under a lamp-post in a dark night, although several faces that may assist business and IT managers this object has been lost somewhere else where the light in coming to grips with enterprise transformation, is worse. One may come to the conclusion that business allowing adequate governance on both a strategic and architecture activities often center on business an operational level. These faces – i.e., solution processes and organizational structures because these architecting, roadmapping, and business architecting – are the activities which architects are apparently familiar find themselves represented to a different extent in four with and in which they have gained considerable general modes of architectural transformation experiences during the past years. governance: Contract, Guide, Direct, and Align. For practitioners seeking specific architectural support in

transformation governance, these modes provide a Albers S.: Configurations of Alliance Governance Systems, means for identifying enterprise architecture Schmalenbach Business Review (62) (2010). management faces that need to be adopted. While Boh W.F., Yellin D.: Using Enterprise Architecture Standards in operational guidance may require the implementation of Managing Information Technology, Journal of Management a solution architecture process being facilitated by a set Information Systems, Vol. 23, No. 3 (2006). of tailored tools (checklists, templates, fact sheets), strategic direction is where roadmapping becomes a Brits J., Botha G.H.K., Herselman M.E.: Conceptual crucial issue. For overall alignment, there is a need for a Framework for Modeling Business Capabilities, Proceedings of comprehensive approach to business architecture the Informing Science and IT Education Joint Conference (2007). management. With that in mind, this article teaches us the benefits and Buckl S., Ernst A.M., Matthes F., Schweda C.M.: Visual Roadmaps for Managed Enterprise Architecture Evolution, restrictions of applying the identified modes and wearing st the corresponding architectural faces respectively. All-in- Proceedings of the 1 International Workshop on Enterprise Architecture Challenges and Responses (WEACR 2009). all, governance may be significantly facilitated and empowered based on enterprise architecture Buckl S., Dierl T., Matthes F., Schweda C.M.: A Modeling management as a cornerstone of enterprise Language for Describing Enterprise Architecture Management transformation. Central to this are business architecture Methods, Proceedings of Modellierung betrieblicher models going beyond the documentation of business Informationssysteme (MobIS 2010). processes and organizational entities. It is this approach Fischer F., Matthes F., Wittenburg A.: Improving IT in which solution architecture and roadmapping activities Management at the BMW Group by Integrating Existing IT are to be embedded to assure an approach to Management Processes, Proceedings of the 9th IEEE transformation governance that thoroughly integrates the International EDOC Enterprise Computing Conference (2005). different levels of enterprise transformation (project, portfolio, and enterprise level). Fischer R., Aier S., Winter R.: A Federated Approach to Enterprise Architecture Model Maintenance, Proceedings of 2nd ABOUT THE AUTHOR the International Workshop on EMISA (2007). Daniel Simon ([email protected]) is a Senior Friedman T.L.: The World is Flat, Farrar, Straus & Giroux, New Consultant with act! consulting, specializing in enterprise York (2005). architecture management. In his role he supports Griffith M.: Embracing the Actionable: Business Architecture, international clients in establishing, optimizing, and Architecture & Governance Magazine (6:2) (2010). performing enterprise architecture management. He holds a diploma degree in information systems from the Harmsen F., Proper H.A., Kok N.: Informed Governance of University of Cologne, Germany, and is currently a PhD Enterprise Transformations, Advances in Enterprise candidate with a research focus on enterprise Engineering II, Lecture Notes in Business Information architecture management. He is a member of The Open Processing, Vol. 28, pp155-180 (2009). Group Association of Enterprise Architects (AOGEA) Hevner A., March T., Park J., Ram S.: Design Science in and is TOGAF 9 Certified. Information Systems Research, MIS Quarterly (28)1, pp75–105 (2004). REFERENCES Kappelman L., McGinnis T., Pettite A., Salmans B., act!: Glossar A-B (2010a); available at Sidorova A.: Enterprise Architecture: Charting the Territory for www.act-consulting.de/ea-forum/glossar/a-b. Academic Research, Proceedings of AMCIS (2008). act!: Glossar G-I (2010b); available at Leganza G.: Topic Overview: Information Architecture, www.act-consulting.de/ea-forum/glossar/g-i. Forrester Research (2010). act!: Glossar Q-Z (2010c); available at Matthes F, Buckl S., Leitel J., Schweda C.M.: Enterprise www.act-consulting.de/ea-forum/glossar/q-z. Architecture Management Tool Survey 2008, TU Munich, Chair for Informatics 19 (sebis), Germany (2008). Aier S., Maletta F., Riege C., Stucki K., Frank A.: Aufbau und Einsatz der Geschäftsarchitektur bei der AXA Winterthur – Ein Niemann K.D.: From Enterprise Architecture to IT Governance: minimal invasiver Ansatz, Proceedings of DW2008: Synergien Elements of Effective IT Management, Vieweg+Teubner, durch Integration und Informationslogistik (2008a). Wiesbaden (2006).

Aier S., Riege C., Winter R: Unternehmensarchitektur – Niemann K.D.: IT Governance and Enterprise Architecture – Literaturüberblick und Stand der Praxis, Wirtschaftsinformatik Impact of IT Cost Reduction on Innovation Power, Journal of 50(4), pp292-304 (2008b). Enterprise Architecture (1:1) (2005).

14 © Journal of Enterprise Architecture – May 2011

Niemann K.D.: Enterprise Architecture Management and its Evaluation Approach, Communications of the Association for Role in IT Governance and IT Investment Planning, Advances Information Systems (26:3) (2009). in Government Enterprise Architecture, Edited by Saha P. (2008). Simon D.: EAM: Realize Benefits Using the Standards Portfolio, Architecture & Governance Magazine (5:8) (2009a). Österle H., Winter R., Höning F., Kurpjuweit S., Osl P.: Business Engineering: Core-Business-Metamodell, WISU – Simon D.: Application Landscape Transformation and the Role Das Wirtschaftsstudium, Vol. 36, No. 2, pp191-194 (2007). of Enterprise Architecture Frameworks, Proceedings of Workshop: MDD, SOA und IT-Management (2009b). Osterwalder A., Pigneur Y.: Business Model Generation, Wiley, Hoboken, New Jersey (2010). Slot R., Dedene G., Maes R.: Business Value of Solution Architecture, Advances in Enterprise Engineering II, Lecture Riege C., Stutz M., Winter R.: Geschäftsanalyse im Kontext Notes in Business Information Processing, Vol. 28, pp84-108 der Unternehmensarchitektur, HMD – Praxis der (2009). Wirtschaftsinformatik (262) (2008). The Open Group: TOGAF Version 9 Enterprise Edition (2009). Ross J.W., Weill P., Robertson D.C.: Enterprise Architecture as Strategy – Creating a Foundation for Business Execution, Van der Raadt B., Schouten S., Van Vliet H.: Stakeholder Harvard Business School Press, Boston (2006). Perception of Enterprise Architecture, Software Architecture, Lecture Notes in Computer Science, Vol. 5292/2008, pp19-34 Schekkerman J.: Trends in Enterprise Architecture 2004: How (2008). are Organizations Processing? Institute for Enterprise Architecture Developments (2004). Winter R.: Business Strategy Modeling in the Information Age, Proceedings of the 3rd international Web Conference, Perth Schmidt C.: Management Komplexer IT-Architekturen, Gabler (2002). Verlag, Wiesbaden (2009). Winter R., Fischer R.: Essential Layers, Artifacts, and Schönherr M.: Towards a Common Terminology in the Dependencies of Enterprise Architecture, Journal of Enterprise Discipline of Enterprise Architecture, Proceedings of the Architecture (May 2007). 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

16 © 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

of full-time enterprise architecture teams (Obitz & Babu INTRODUCTION 2009). All of this suggests that organizations around the Since the concept of enterprise architecture first world spend a considerable amount of time and effort on appeared around the early 1990s (Zachman 1987; enterprise architecture. Richardson et al 1990),1 the field has rapidly evolved As an organizational role, enterprise architecture is and captured the interest of organizations worldwide. positioned between IT and business strategy formulation This is exemplified by the number of various enterprise on the one hand, and project-focused solution architecture-related professional organizations (e.g., architecting on the other. Enterprise architecture is the CAEAP, GEAO, The Open Group, ZIFA, etc.), definition and representation of a high-level view of an government initiatives (e.g., FEAF, DoDAF, GEA, enterprise’s business processes and IT systems, their MoDAF, etc.), service offerings of large global inter-relationships, and the extent to which these management consulting firms,2 the continuing evolution processes and systems are shared by different parts of of a number of frameworks and methodologies, and the enterprise. Two key components of enterprise perhaps most importantly, by the increasing prevalence architecture are the planning process, and the direct and tangible outputs of that planning process; i.e., enterprise architecture documentation. 1 Zachman’s (1987) article on Information Systems Architecture is often Therefore, the high-level value proposition of enterprise regarded as the seminal work on enterprise architecture. However, the term ―enterprise architecture‖ (introduced to emphasize the necessity architecture is to enable an organization to move for a more business-oriented planning approach) appears to have been towards strategy enactment by translating the broader used for the first time by Richardson et al (1990). principles, capabilities, and goals defined in the 2 Examples include Accenture, BCG, Capgemini, Deloitte, Ernst & strategies into systems and processes that help the Young, Fujitsu, Gartner, IBM, and KPMG.

enterprise to realize these goals. In addition to defining annual citation count to identify the most influential the desired future state of the organization’s business publications. The top 50 EA-focused publications were processes and IT systems, enterprise architecture also analyzed in-depth. involves providing a roadmap for achieving this target In parallel, an exploratory search using Google and from the current state. reference lists of studies identified through the How is enterprise architecture delivering on its value systematic approach was used to find additional proposition and what are the specific business benefits it insightful publications; e.g., practitioner-focused studies brings to organizations? It may seem surprising, but after (which are not indexed by Google Scholar), studies that two decades the value of enterprise architecture remains refer to enterprise architecture with a different term,4 and poorly understood and the answer to these questions very recent studies for which a citation count is not yet remains mixed. In contrast to the clear interest in the available. This complementary search led to the domain, an increasing number of organizations cite inclusion of 17 further insightful publications (e.g., Aziz & difficulties in justifying their enterprise architecture Obitz 2007; Kettinger et al 2010; Obitz & Babu 2009; investments (Aziz & Obitz 2007; Obitz & Babu 2009) and Salmans & Kappelman 2010). anecdotal evidence suggests that the existence and In all, 213 benefit claims were recorded, which could be funding of the enterprise architecture function is often broadly grouped into the 12 themes listed in the first row based more on the beliefs of the incumbent of Table 1 Error! Reference source not found.below. management team than on demonstrated value. The focus then turned to the primary question of interest: Academic research and guidance on the topic also 3 How does enterprise architecture lead to these benefits? remains scarce. Although there is no shortage of We focused on identifying the underlying benefit enterprise architecture benefit claims in existing enablers—factors which could be clearly seen as literature, there are only fragmented and incomplete enterprise architecture outcomes, and that in turn are explanations of why and how it leads to the proposed known to have the potential to deliver organizational benefits. benefits. We also drew on IS and management theory to This article aims to take a step towards improving the enhance the identified concepts and explanations. The understanding of the value of enterprise architecture by result of this process, which passed through four major focusing on: How does enterprise architecture lead to iterations and numerous smaller refinements, is the EA organizational benefits? Through a careful literature Benefits Model (EABM), described in-depth after the review, the article consolidates the fragmented literature review section. knowledge on enterprise architecture benefits and refines the explanations by drawing on relevant IS and LITERATURE REVIEW management theory. The resultant EA Benefits Model This section provides a summary of the current state of (EABM) proposes that enterprise architecture leads to knowledge on enterprise architecture benefits in organizational benefits through its impact on four key published literature. As noted earlier, there is no benefit enablers: Organizational Alignment, Information shortage of enterprise architecture benefit claims in Availability, Resource Portfolio Optimization, and literature. Table 1 summarizes the benefit claims from Resource Complementarity. The article concludes with a the literature review, including a recent enterprise discussion of some potential avenues for future architecture benefits survey (Salmans & Kappelman research, which could build on the findings of this study. 2010), and compares it with a few influential practitioner- oriented sources. RESEARCH APPROACH Some of the most commonly cited benefits in academic This was a literature-based study, aimed at improving studies (listed in the first row of Table 1) were: (1) the existing knowledge on enterprise architecture increased responsiveness and guidance to change, (2) benefits through integrating the existing fragmented improved decision-making, (3) improved communication knowledge on the topic. To develop an overview of the and collaboration, (4) reduced costs, and (5) business-IT existing literature and its benefits, two search alignment. approaches were employed. First, a systematic search approach was used to look for key publications on A comparison with practitioner-oriented sources reveals enterprise architecture, using the Google Scholar and a high agreement between authors about the reduction Scopus databases. The search yielded 4,392 unique of costs, particularly of IT costs, as a tangible enterprise results, which were then ranked based on average 4 The following terms were considered potentially relevant: IS/IT architecture, enterprise service-oriented architecture (enterprise SOA), 3 One indicator of the lack of high-quality research on the topic is that, IS/IT platform, business architecture, strategic architecture, strategic since 1990, only three enterprise architecture-focused articles have capabilities architecture, business platform, architecture framework, been published in the six highest-regarded IS journals (AIS nd). and enterprise integration architecture.

18 © Journal of Enterprise Architecture – May 2011

architecture benefit. Increased capability to change, Professional Sources improved alignment between business and IT, and Infosys EA (1) Reduced IT cost business process improvements are also mentioned Survey 2007 (2) Higher business and process flexibility repeatedly by academic as well as practitioner sources. (Aziz & Obitz (3) Improved customer satisfaction Table 1: Organizational Benefits from Enterprise 2007) (4) Enabling of business and process 5 Architecture Reported in Literature change (5) Better business-IT alignment Academic Studies Infosys EA (1) Improved customer satisfaction Systematic (1) Increased responsiveness and guidance Survey 2009 (2) Reduced IT cost Literature to change (Obitz & Babu (3) Business process improvement/ Review (2) Improved decision-making 2009) standardization (50 studies) (3) Improved communication & collaboration (4) Better business-IT alignment (4) Reduced (IT) costs (5) Higher business and process flexibility (5) Business-IT alignment ® (6) Improved business processes TOGAF 9 (1) More efficient IT operations (7) Improved IT systems (The Open (2) Lower IT costs (8) Re-use of resources Group 2009) (3) Maximum ROI from existing IT (9) Improve integration (4) Reduced risk for future IT investments (10) Reduce risk (5) Reduced IT complexity (11) Regulatory compliance (6) Faster, simpler, and cheaper (12) Provides stability procurement SIM EA Survey (1) Improves interoperability between Zachman (1) Alignment enabler 2007 information systems International (2) Integration enabler (Salmans & (2) Improves utilization of IT (Zachman (3) Change enabler Kappelman (3) Aligns business objectives with IT 2001) (4) Reduced time-to-market 2010) investments Despite the numerous benefit claims, very few studies (4) More effective use of IT resources provide explanations about how enterprise architecture (5) Better situational awareness leads to these benefits and evidence to back the claims (6) More responsive to change and explanations is even scarcer. The analysis of the (7) Improves organizational communications provided explanations revealed the need to distinguish and information sharing (8) Assists with organizational governance clearly between (a) benefits flowing directly from (9) Improves ROI from IT spending enterprise architecture (i.e., the planning process and (10) Less wasted time/money on projects resultant artifacts), and (b) the subsequent impact of which do not support business enterprise architecture on the real-world state of the goals/objectives organization. This distinction is often overlooked (11) More effective at meeting business (Zachman 2010), but it leads to two distinct pathways goals from enterprise architecture to organizational benefits, (12) Improves IS security across the described below. business (13) Better collaboration within organization Benefits from Enterprise Architecture (14) Improves communications between the organization and IT department Some benefits may flow directly from enterprise (15) Reduces IT complexity architecture. These benefits relate to the increased (16) Reduces organizational stovepipes knowledge about the organization and its goals (e.g., a (17) Faster development and better understanding of the business processes or the implementation of new IS organization’s current IT systems as a result of the (18) Standardizes organizational enterprise architecture analysis), which can provide the performance measures basis for better-informed decisions. (19) Improves communications within organization This pathway has received very little attention in existing literature, possibly because of lower visibility and difficulties in measuring the benefits from planning, as 5 The benefits from the literature review, Infosys, and SIM survey are they tend to be less tangible. Only one publication that ranked based on how often they were mentioned by focused on benefits from enterprise architecture authors/respondents. The benefits from Zachman (2001) are listed in planning was found (Bernard 2005). Bernard suggests the order presented by the author, though it is not clear whether any that a standardized planning approach (i.e., a common ranking was implied.

analysis and documentation methodology) applied to achieve well-planned and tightly integrated systems, across business unit and departmental boundaries leads leading to more reliable systems and data and to to integrated and improved information about the increased re-use, which ultimately results in higher organization’s resources. This, in turn, enables better responsiveness, better decisions, service improvements, communication and common understanding between reduced costs, and higher employee morale (Spewak & different stakeholders and helps to reduce re-work and Hill 1992). More recently, it has been claimed that by duplicated efforts. Ultimately, Bernard (2005) claims, this driving increased standardization, integration, and leads to better and faster decisions, reduced cycle times, componentization, enterprise architecture enables an improved (IT) performance, and lower costs. organization to improve operational excellence, The underlying benefit enabler here is a better customer intimacy, product leadership, and strategic understanding and increased access to information agility (Ross et al 2006). about the organization itself, emanating from the There are three notable issues with the existing planning process and stored in the enterprise explanations. First, the ultimate benefit claims and the architecture artifacts. It should be noted, however, that proposed mechanisms in the various studies are quite although Bernard (2005) proposes a clear link between different. Second, the role that enterprise architecture enterprise architecture and benefits, no empirical plays in leading to the operating platform improvements evidence (e.g., examples from case studies) are is often not thoroughly discussed. Third, it is essential to presented to support these claims. understand that having an enterprise architecture plan is far from a guarantee of implementation success (Boh & Benefits from an Enterprise Architecture-Guided Yellin 2006). As the operating platform improvements Operating Platform proposed in the enterprise architecture plans are implemented through a series of projects, all the usual Most of the enterprise architecture benefits discussed in project success factors apply; e.g., top management the literature depend on the enactment of the enterprise support, change management, and project management, architecture plans. This is not surprising since the key among many others (Finney & Corbett 2007; Parr et al purpose of enterprise architecture is to guide the building 1999). In addition, proper IT governance is of central of an improved operating platform; i.e., the IT systems importance to ensure that the various projects follow the and digitized business processes that support or enterprise architecture guidelines (Boh & Yellin 2006; automate an organization’s core capabilities (Ross et al 6 Ross et al 2006; Weill & Ross 2004). Due to the duration 2006 p4). However, the operating platform can exist and cost, enterprise architecture implementations are and evolve regardless of enterprise architecture—every also more likely to be subject to unexpected changes in organization has processes and systems, but not all business priorities, emerging financial constraints, or organizations engage in enterprise architecture planning. loss of interest (Armour et al 1999; Richardson et al Therefore, to demonstrate value, enterprise architecture 1990; Segars & Grover 1996; Spewak & Hill 1992). has to either enable the organization (a) to build an Finally, due to the aim of enterprise-wide optimization, operating platform that would otherwise not have been which can often mean trade-offs in local optimization and possible, or (b) to improve the delivery of the platform in autonomy, enterprise architecture implementations are some way (e.g., faster, cheaper, or with increased very likely to be hampered by organizational politics likelihood of success). (Janssen & Hjort-Madsen 2007; Kettinger et al 2010; A prevalent claim in existing studies is that an enterprise Segars & Grover 1996). architecture-guided operating platform is likely to have a higher level of standardization and integration (e.g., Reflecting on the Literature Bernard 2005; Boh & Yellin 2006; Ross & Westerman 2004; Spewak & Hill 1992). However, the various studies Three key conclusions can be drawn from the findings of tend to diverge in the ultimate benefit claims and the the literature review. First, it is important to distinguish discussion of related underlying mechanisms. For between benefits that can flow from enterprise example, it has been argued that it is through building architecture directly and benefits that can be achieved consensus and a homogenous (standardized) only through the implementation of the enterprise architecture that enterprise architecture enables an architecture plans; i.e., from an enterprise architecture- enterprise to achieve improved information flows and guided operating platform. Due to the high uncertainty in reduced IT costs (Richardson et al 1990). Another progressing from plans to implementation, it seems likely suggestion is that enterprise architecture enables a firm 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 6 The definition of ―operating platform‖ has been adapted from Ross et architecture plans directly. al (2006) ―foundation for execution‖.

20 © Journal of Enterprise Architecture – May 2011

Second, a considerable amount of collective knowledge denotes the suggested strength of the relationship, on the benefits of enterprise architecture exists. based on how reliant a given benefit enabler is on the However, these benefit claims and related explanations enactment of the enterprise architecture plans. This are fragmented. Integrating this existing knowledge can acknowledges the high uncertainties involved in therefore provide a valuable step towards enhancing the progressing from enterprise architecture to understanding of how enterprise architecture leads to implementation discussed above. The least strong organizational benefits. (dotted) lines indicate that Resource Portfolio Third, gathering further evidence to substantiate the Optimization and Resource Complementarity are entirely benefit claims and explanations is essential. Not only do dependent on at least partial enactment of enterprise the existing claims lack empirical validation, but due to architecture plans. Information Availability is partly the lack of studies focusing on a careful explanation of contingent on enactment, and is presented as a thin line. enterprise architecture benefits, it seems likely that some Finally, Organizational Alignment may to a large extent benefits or explanations may have been overlooked. be achieved through the enterprise architecture planning activities and resultant documentation per se, and is The following section takes a step towards enhancing therefore represented as a thick line. knowledge on how enterprise architecture leads to 7 organizational benefits by proposing the EA Benefits Table 2: Definitions of the EABM Concepts Model (EABM). The EABM integrates the existing Enterprise The definition and representation of a explanations in the enterprise architecture literature and Architecture high-level view of an enterprise’s draws on relevant IS and management theory to business processes and IT systems, enhance these explanations. It suggests that it is their inter-relationships, and the extent through its impact on four key benefit enablers that to which these processes and systems enterprise architecture delivers organizational benefits. are shared by different parts of the Although the current study does not address the third enterprise. concern above, the proposed model provides a useful Organizational Outcomes that contribute directly to starting platform for future field studies. Benefits organizational performance, including lower costs, increased revenue, THE EA BENEFITS MODEL (EABM) competitive differentiation, more The EA Benefits Model (EABM) presented in Figure 1 accurate decisions, strategic agility, synthesizes the findings from the literature review. The etc. model proposes that it is through the impact of Benefit Enablers enterprise architecture on four key benefit enablers— Organizational The extent to which an organization’s Organizational Alignment, Information Availability, Alignment subunits share a common Resource Portfolio Optimization, and Resource understanding of its strategic goals, Complementarity—that enterprise architecture leads to and contribute towards achieving these organizational benefits. The term ―benefit enablers‖ goals. emphasizes that these outcomes are not benefits per se, Information The extent of useful, high-quality but are factors which have been demonstrated in earlier Availability information accessible to research to have a high potential for enabling organizational decision-makers. organizational benefits. Resource Portfolio The extent to which an organization Beneﬁt Enablers Optimization leverages its existing resources, invests in resources that target Organisational Alignment performance gaps, and minimizes unnecessary investments in duplicated

Information resources. Availability Enterprise Organisational Resource The extent to which the organization’s Architecture Beneﬁts Resource Portfolio Complementarity resources synergistically support the Optimisation pursuit of its strategic goals.

Resource The following discussion of the EABM begins with Complementarity enterprise architecture. The four sections that follow draw on both the review of enterprise architecture Figure 1: EA Benefits Model (EABM) literature as well as broader IS and management theory Definitions of the EABM concepts are summarized in Table 2 and discussed in detail in the following sections. 7 These definitions are ours, though they have been adapted from the The thickness of the arrows from EA to Benefit Enablers existing literature on the related concepts.

to define the four benefit enablers, and explain how corporate level and various Strategic Business Units these relate to organizational benefits from enterprise (SBUs) (Reynolds et al 2010). architecture. Organizational Benefits from Organizational Alignment ENTERPRISE ARCHITECTURE Enterprise architecture is the definition and Organizational Alignment in general, as well as its sub- representation of a high-level view of an enterprise’s dimension of business-IT alignment, have been found to business processes and IT systems, their inter- be related to improved organizational performance relationships, and the extent to which these processes (Chan et al 2006; Kearns & Lederer 2003; Miller 1986; and systems are shared by different parts of the Porter 1996; Sabherwal & Chan 2001). Firms with high enterprise. Two key components of enterprise Organizational Alignment may achieve a better total ROI architecture are the planning process, and the direct and through the reduction of incoherent or duplicated efforts, tangible outputs of that planning process; i.e., enterprise and achieve their strategic goals with minimal overhead. architecture documentation. Improving Organizational Alignment through Enterprise It is clear that not all enterprise architecture efforts are Architecture equal, and only high-quality enterprise architecture efforts are positioned to make a positive organizational Both enterprise architecture planning as well as related impact. A high-quality enterprise architecture is one that improvements in the operating platform have the provides a vision for the future operating platform that is potential to improve Organizational Alignment. The well-aligned with the organization’s strategic goals, enterprise architecture planning activity itself requires complemented by an optimal roadmap for moving cross-organizational dialog and input. As enterprise towards that vision, based on an accurate understanding architecture is not only concerned with IT systems, but of the current operating platform. Enterprise architecture begins with an understanding of the business processes quality depends on the quality of the planning process that these systems need to support, it has the potential and is embedded in the resultant documentation. to bring IT in closer alignment with the business goals It is important to note that a high-quality enterprise (Gregor et al 2007; Ross 2003). The objective of greater architecture has to strike an appropriate balance among business-IT alignment is also among the top reasons scope, detail, and cost (Spewak & Hill 1992). After the why organizations invest in enterprise architecture (Aziz scope and depth of planning reaches a certain threshold, & Obitz 2007; Obitz & Babu 2009). investing more resources and effort in the planning is Because the business analysis undertaken during likely to lead to diminishing returns. Eventually, the enterprise architecture planning spans different marginal improvements in the accuracy and amount of departments and/or business units, there is potential for information captured in the plans will no longer be able it to have a positive impact not only on business and IT to offset the required investments. alignment, but also on other dimensions of Organizational Alignment. The basis for this broader ORGANIZATIONAL ALIGNMENT impact is the facilitation of dialog and identification of Organizational Alignment is the extent to which an inter-dependencies between the various parts of the organization’s subunits share a common understanding enterprise (Segars & Grover 1996). The increased of its strategic goals and contribute towards achieving understanding of the process inter-dependencies and these goals. The alignment between business and IT, an potential synergies provides a better basis for identifying aspect of Organizational Alignment, has received the stakeholders that may be affected by, and should be extensive attention (Chan & Reich 2007a,b). The consulted about, a given process or technology change underlying claim of the business-IT alignment literature (Bernard 2005). The relevant people can be involved is that IT strategies and the resultant deliverables should early in the decision-making process, allowing for be closely informed by, and aligned with, business potential conflicts to be identified and resolved early, strategies and processes (Henderson & Venkatraman which may have a positive impact on collaboration and 1993). This is to ensure that the IT systems in which an collective decision-making (Richardson et al 1990). organization invests provide the best possible support The awareness that enterprise architecture creates for the strategic needs of the business. about the dependencies may also be used to ensure the However, it is not only alignment between business and alignment between performance measures of IT that is a challenge in large, complex organizations. employees, which can further contribute to collaboration Alignment is not only a challenge across all functional (Pereira & Sousa 2004). The set of agreed-upon areas (e.g., between Sales and Marketing), sometimes enterprise architecture principles also provides objective referred to as horizontal alignment, but also between the decision-making criteria, which in turn can help to avoid costly, prolonged, or repeated arguments. Therefore,

22 © Journal of Enterprise Architecture – May 2011

enterprise architecture reduces the subjectivity of the prove valuable for informing organizational decision- decision-making process (Johnson et al 2007; Spewak & making. Hill 1992) and brings the business and IT investment In contrast, improved availability of information about decisions in closer alignment to the organizational goals, business transactions, customers, and vendors is as opposed to the personal agendas of individual key primarily contingent on the enactment of enterprise stakeholders. architecture plans. This information is normally captured INFORMATION AVAILABILITY in an organization’s databases. Enterprise architecture can help to improve the availability of this information by Information Availability is defined as the extent of useful, guiding the building of an improved operating platform high-quality information accessible to organizational that, in turn, provides better information to decision- decision-makers. Information quality does not only makers in the organization. First, enterprise architecture encompass accuracy, but also aspects such as has been suggested to improve the sharing of relevance, completeness, timeliness, interpretability, and information through more carefully planned integration accessibility (Lee et al 2002; Wang & Strong 1996). between the organization’s information systems (Boh & These dimensions suggest that in order to improve Yellin 2006; Ross et al 2006; Spewak & Hill 1992). In Information Availability and quality, the purpose of the addition to identifying and helping to standardize the information needs to be considered (e.g., the measure of interfaces and messaging between different applications, timeliness can be substantially different in strategic and enterprise architecture may also facilitate information operational decision-making). sharing by advocating common data definitions and structures (Boh & Yellin 2006; Spewak & Hill 1992). Organizational Benefits From Information Availability Second, as will be discussed in the following section, an enterprise architecture-guided operating platform is likely Information is widely recognized as a key organizational to have lower complexity and fewer components, asset. Access to better information—when coupled with contributing to increased reliability of the operating enhanced capabilities to interpret that information—may platform (Pereira & Sousa 2004; Ross et al 2006). This serve as an important source of competitive advantage has a positive impact on information accessibility. (Davenport & Harris 2007; Davenport et al 2010). For Finally, by identifying and helping to reduce the number example, improved information about the customers and of redundant data stores, enterprise architecture may the marketplace enables better targeted product also have a positive impact on data accuracy development, sales, and marketing efforts (Davenport & (Venkatesh et al 2007). Harris 2007), leading in turn to increased revenues. RESOURCE PORTFOLIO OPTIMIZATION Improving Information Availability through Enterprise Architecture Resource Portfolio Optimization is defined as the extent to which an organization leverages its existing The information underpinning an organization’s resources, invests in resources that target performance knowledge base consists of data about an organization’s gaps, and minimizes unnecessary investments in interactions with the outside world (i.e., clients, suppliers, duplicated resources. Resources can be defined as ―all and business transactions) and information about the assets, capabilities, organizational processes, firm organization itself (i.e., primarily related to organizational attributes, information, knowledge, etc. controlled by the processes). Enterprise architecture has the potential to firm‖ (Barney 1991 p101). In relation to enterprise improve the availability of both types of information. The architecture, three types of resources are primarily of improved information about organizational processes interest: human resources, IT, and organizational primarily flows directly from enterprise architecture. processes. Optimization could, therefore, involve the Through the business and system analysis performed as removal of duplicated or non-value-adding technology or part of the enterprise architecture planning, previously human resources, and/or replacing them with resources undocumented information about the organization’s that are more efficient in assisting with the achievement processes may be captured (Bernard 2005). The whole- of organizational goals. of-enterprise analysis approach may even reveal inter- dependencies or inefficiencies that were previously not Organizational Benefits from Resource Portfolio only undocumented, but also unknown. This information Optimization will be captured in the current state documentation of The organizational benefits from Resource Portfolio enterprise architecture and will help to enhance and Optimization mainly relate to reduced costs and higher retain organizational knowledge about its processes. efficiencies, which translate to a better ROI from the Even if the enterprise architecture vision and roadmaps organization’s resources. Process optimization, an are later not followed, this documentation in itself may aspect of Resource Portfolio Optimization, has been

found to have the potential to not only deliver substantial also contribute to the identification of suboptimal cost savings, but also to improve quality and reliability of business processes and use of human resources product and service delivery (Davenport & Short 1990; (Bernard 2005; Boh & Yellin 2006; Pereira & Sousa Hammer & Champy 1994; Harrington 1991). 2004). It has also been suggested that as a result of the enterprise-wide optimization, the organization may be Optimizing the Resource Portfolio through Enterprise able to shift the focus of its business processes from a Architecture department or business unit-centric view to increased customer focus, as it gains the ability to share a single Enterprise architecture can help to identify areas where view of its customers across the different organizational either resource gaps or overlaps occur and to provide units (Ross et al 2006; Venkatesh et al 2007). recommendations on how to improve on the existing state (Bernard 2005; Pereira & Sousa 2004). While it is It is necessary to note that while enterprise architecture likely that areas of under-investment make themselves plans may have a direct positive effect on the benefit known through the related business impact, areas of enablers discussed earlier (Organizational Alignment over-investment may be much less visible. If each and Information Availability), the benefits from Resource business unit with similar needs invests in its own Portfolio Optimization are contingent on the systems, the costs incurred are likely to be significantly implementation of these plans, or at least parts thereof. higher than when using a single, shared system. RESOURCE COMPLEMENTARITY However, if the systems are working fine and the costs are manageable, the organization may remain unaware Resource Complementarity is defined as the extent to of the opportunity for cost-cutting by leveraging which the organization’s resources synergistically economies of scale. support the pursuit of its strategic goals. It is a widely accepted view in strategic management that the basis By looking across the verticals and horizontals of an for a firm’s sustained competitive advantage comes from organization when documenting the current state during its control of a set of resources which are rare, valuable, enterprise architecture planning, resource overlaps will inimitable, difficult to substitute, and relatively immobile become apparent (Boh & Yellin 2006). Existing studies (Barney 1991). While it is very difficult to find individual suggest that enterprise architecture, therefore, resources that meet these criteria, once embedded in contributes to building a more standardized IT platform organizational processes in unique combinations with with fewer technologies, leading in turn to simplified other resources, these desirable characteristics become interfaces, higher reliability through reduced operating easier to achieve (Brynjolfsson & Saunders 2010; Grant platform complexity, and lower maintenance and support 1996). A major difficulty in imitating complex resource costs (Boh & Yellin 2006; Hjort-Madsen 2006; configurations stems from causal ambiguity; i.e., it may Richardson et al 1990; Ross et al 2006; Spewak & Hill not be clear which components or interactions underpin 1992; Venkatesh et al 2007). the organization’s success (Lippman & Rumelt 1982; Enterprise architecture may also help to promote the Reed & DeFillippi 1990). decoupling of monolithic systems to smaller Therefore, the competitive advantage of organizations components, which facilitates both re-use as well as tends to rely not on individual resources but on unique flexibility of reconfiguring or replacing the components as combinations of complementary resources. The required (Janssen & Hjort-Madsen 2007; Ross et al mechanism which helps to make use of these combined 2006). Componentization helps in optimizing the resources is sometimes referred to as capabilities— resource portfolio by reducing the overlaps between human-based skills and processes that enable an individual components and simplifying the replacement organization to deploy other resources in order to of components that no longer meet business needs or achieve desired goals (Amit & Schoemaker 1993). are more costly to maintain than newer alternatives. Capabilities are developed over time through the Also, the knowledge about the purpose and inter- creation, exchange, and retention of information, and are dependencies of the components captured in enterprise grounded in the skills, knowledge, and processes of the architecture documentation makes the replacement organization. Therefore, they cannot be readily sourced process considerably easier and less risky (Iyer & from the market (Amit & Schoemaker 1993). Gottlieb 2004). Finally, the awareness about the components, the stage of their lifecycle, and business Organizational Benefits from Resource Complementarity impact can also help to better channel investments to resources with the highest value potential in the case of The major organizational benefit from Resource financial constraints (Segars & Grover 1996). Complementarity is, therefore, potential competitive Through the business analysis that precedes the differentiation from achieving a mutually reinforcing evaluation of the IT systems, enterprise architecture can resource configuration that is difficult to replicate

24 © Journal of Enterprise Architecture – May 2011

(Brynjolfsson & Saunders 2010). The exact tangible competitors to replicate.8 Improvements in a system can benefits from Resource Complementarity are dependent stem from either the introduction of superior components on the competitive strategy of the organization, which (component innovation) or an enhanced reconfiguration determines the desirable resource configuration to of components (architectural innovation) (Henderson & pursue. It has been suggested that the three key ways in Clark 1990). Resource Portfolio Optimization focuses on which organizations can compete are a focus on: (1) the former, whereas Resource Complementarity focuses operational excellence (reliable, conveniently accessible, on the latter. Therefore, in proposing the EABM, and low-cost products/services); (2) customer intimacy Resource Complementarity and Optimization are treated (highly personalized products and services); or (3) as two distinct benefit enablers. However, similar to product leadership (innovative, ―state-of-the-art‖ Resource Portfolio Optimization, the achievement of products/services) (Treacy & Wiersema 1993). For a Resource Complementarity is contingent on the company pursuing operational excellence, the result of implementation of enterprise architecture. Resource Complementarity could be a superior cost position, achieved through combining resources in a way IS ENTERPRISE ARCHITECTURE EQUALLY that cuts overheads to a minimum while retaining the VALUABLE FOR ALL ORGANIZATIONS? desired product/service standards. On the other hand, a An important question related to understanding the value company pursuing a customer-intimate strategy would of enterprise architecture is whether all organizations want to make sure that its resources complement each can expect to get similar benefits, or whether these vary other in a way that delivers a single view of the from organization to organization based on certain customer, helps to gather superior customer information internal or environmental characteristics. Reflecting on and feedback, and ensures consistency of customer the four benefit enablers in EABM, as well as existing service organization-wide. enterprise architecture research, suggest that some organizations under some circumstances may be better Increasing Resource Complementarity through Enterprise positioned to benefit from enterprise architecture Architecture investment than others. The primary mechanism through which enterprise For example, it has been suggested that larger architecture helps an organization to improve Resource organizations with more complex IT environments may Complementarity is through the identification of the expect to benefit more from enterprise architecture than potential enterprise-wide synergies, and by providing those whose operating platform is relatively simple and recommendations on how to leverage these synergies. well-understood (Bernard 2005). The benefit enablers Indeed, it has been suggested that the fragmentation of discussed earlier appear to support this proposition. resources is inevitable if proper measures are not taken First, large and more complex organizations are likely to to ensure complementarity, and that the key mechanism have a more diverse resource portfolio. This means that in ensuring complementarity is the development of: they may be able to derive more benefits from Resource Portfolio Optimization. Second, large organizations with ―… a corporate-wide strategic architecture that establishes complex structures are more likely to experience objectives for competence building. A strategic architecture is a roadmap of the future that identifies which core competencies problems with alignment, increasing the potential for to build and their constituent technologies.‖ (Prahalad & Hamel improving Organizational Alignment. 1990 p89) The quality of the existing operating platform is another Many of the mechanisms through which enterprise factor suggested in earlier research to affect the extent architecture can help to enhance Resource of potential benefits from enterprise architecture Complementarity are similar to those discussed in (Bernard 2005). For example, high redundancy or quality relation to Resource Portfolio Optimization. Both depend issues provide larger potential gains from Resource on the organization-wide analysis and identification of Portfolio Optimization. Also, the performance gaps may resources and their inter-dependencies. Both benefit leave more opportunities for improvements in from the reduction of overlaps between resources Information Availability. achieved through componentization. However, while the primary focus of Resource Portfolio Optimization is on reducing redundancy related to resource duplication and 8 There is a subtle but important difference between Organizational overlaps and improving the quality of these resources, Alignment and Resource Complementarity in the EABM. Resource Complementarity focuses on leveraging Organizational Alignment (Porter’s (1996) ―first-order fit‖) relates to shared understanding and simple consistency between the activities of synergies between the resources and combining them in the organizational units and the corporate strategy. Resource ways that enhance performance and are difficult for 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 research opportunities to further improve the model (Ross et al 2006). According to Ross et al, a understanding of enterprise architecture benefits. firm’s operating model is determined by two independent Possibly the most significant shortcoming of existing choices—the level of desired standardization research is the lack of evidence to support the various (commonality of processes and systems), and benefit claims. Although this study has taken a step integration (sharing of data) across the organization. towards improving the theoretical explanation of the Organizations with low levels of standardization and benefit claims, field studies remain essential. Is the integration can benefit from enterprise architecture if EABM complete? Are there better ways to group the they choose to standardize or integrate certain aspects benefit enablers? Are there any inter-relationships of their foundation (Ross et al 2006 pp56–57). It is between the benefit enablers? How to measure the implicit in this argument that the higher the level of value of enterprise architecture? These are examples of desired standardization and/or integration, the higher the some questions that future studies could help to find extent of potential benefits that an organization can answers to. expect from enterprise architecture. In terms of the EABM, standardization is closely related to Resource CONCLUSION Portfolio Optimization, and integration to both Through a careful review of enterprise architecture Information Availability and Organizational Alignment. literature and related academic theory, this study It has also been argued that the higher the rate of provides an enhanced explanation of how enterprise organizational change, the greater the benefits from architecture leads to organizational benefits. The EA enterprise architecture (Spewak & Hill 1992). This is Benefits Model (EABM) posits that it is through probably based on the claim that enterprise architecture improvements in Organizational Alignment, Information can improve an organization’s flexibility and change Availability, Resource Complementarity, and Resource capability. Both Resource Portfolio Optimization and Portfolio Optimization that enterprise architecture leads Information Availability help to explain why organizations to organizational benefits. These benefits may include undergoing larger changes may benefit more from lower costs, higher strategic agility, and a more reliable enterprise architecture. Understanding of the inter- operating platform. Although enterprise architecture may dependencies of processes and IT systems (an aspect deliver benefits to any organization, it appears that large of Information Availability) becomes more essential organizations with a complex IT environment, and those when an organization needs to start making changes to whose business model favors high levels of these components. Also, the fewer inter-dependencies organization-wide standardization and integration, may and components there are (i.e., the more optimized the be best positioned to benefit. Finally, we would like to resource portfolio), the cheaper and less risky it is to emphasize that much work remains in improving the make changes to the environment. understanding of the value of enterprise architecture and future studies on the theme would be valuable for both There are also environmental factors, which may affect practice and theory alike. the extent of potential benefits from enterprise architecture. For example, the legislation and regulations ABOUT THE AUTHORS governing a particular industry can be an important Toomas Tamm ([email protected]) is a factor. In some cases enterprise architecture may PhD Candidate in the Department of Information simplify compliance (Ross et al 2006; Winter & Fischer Systems at the University of Melbourne. His research 2006), whereas in others it can even be mandatory (e.g., focuses on understanding if and how organizations can Clinger-Cohen Act in the US), making enterprise benefit from enterprise architecture planning. architecture an ―organizational benefit‖ per se. The information intensity of a given industry appears also Peter B. Seddon ([email protected]) is a likely to affect the extent of potential benefits from Professor in the Department of Information Systems at enterprise architecture. Specifically, Information the University of Melbourne. His research interests Availability is more critical for organizations that rely include enterprise systems, IT management, IT heavily on information in providing products or services outsourcing, business analytics, organizational to their customers or for whom information is the key processes, evaluation and alignment, and accounting product or service they provide. information systems. Graeme Shanks ([email protected]) is an AVENUES FOR FUTURE RESEARCH Australian Professorial Fellow in the Department of The EA Benefits Model (EABM) and related discussion Information Systems at the University of Melbourne. His provides insights for academics and practitioners research interests focus on business analytics, the interested in enterprise architecture, and serves as a implementation and impact of information systems, data platform for future studies. There are numerous valuable quality, and conceptual modeling.

26 © Journal of Enterprise Architecture – May 2011

Peter Reynolds ([email protected]) is a Research Braun C., Winter R.: A Comprehensive Enterprise Architecture Scientist at MIT CISR. Peter’s research focuses on how Metamodel and its Implementation using a Metamodeling firms drive value from IT through business and IT Platform, Proceedings of the Workshop on Enterprise Modeling strategy, organizational design, IT-based business and Information Systems Architectures, Verlag Ritter, Austria: Klagenfurt 2005, pp64–79 (2005). transformation, and mergers in IT. Brynjolfsson E., Saunders A.: Wired for Innovation, Cambridge, REFERENCES MA: The MIT Press (2010).

Alhanasiadis I.N.: Towards a Virtual Enterprise Architecture for Carlock P., Fenton R.: System of Systems (SoS) Enterprise the Environmental Sector, in Protogeros N. (Ed.) Agent and Systems Engineering for Information-Intensive Organizations, Web Service Technologies in Virtual Enterprises, Chapter XV, Systems Engineering (4)4 (2001). Hershey, PA: IGI Global, pp256–266 (2008). Chan Y.E., Reich B.H.: IT Alignment: What have we Learned?, Ambler S.W., Nalbone J., Vizdos M.J.: The Enterprise Unified Journal of Information Technology (22)4, pp297–315 (2007a). Process: Extending the Rational Unified Process, Upper Saddle River, NJ: Prentice Hall PTR, Chapter 9 (2005). Chan Y.E., Reich B.H.: IT Alignment: An Annotated Bibliography, Journal of Information Technology (22)4, pp316– Amit R., Schoemaker P.J.: Strategic Assets and Organizational 396 (2007b). Rent, Strategic Management Journal (14)1, pp33–46 (1993). Chan Y.E., Sabherwal R., Thatcher J.B.: Antecedents and Armour F.J., Kaisler S., Liu S.: Building an Enterprise Outcomes of Strategic IS Alignment: An Empirical Architecture Step by Step, IT Professional (1)4, pp31–39 Investigation, IEEE Transactions on Engineering Management (1999). (51)3, pp27–47 (2006).

Association for Information Systems (nd), Senior Scholars’ Chen D., Vallespir B., Doumeingts G.: GRAI Integrated Basket of Journals (current April 5, 2011); refer to: Methodology and its Mapping onto Generic Enterprise http://home.aisnet.org/displaycommon.cfm?an=1&subarticlenbr Reference Architecture and Methodology, Computers in =346. Industry (33)2–3, pp387–394 (1997).

Aziz S., Obitz T.: Enterprise Architecture is Maturing, Infosys Chen D., Doumeingts G., Vernadat F.B.: Architectures for Enterprise Architecture Survey 2007, Survey, Infosys (current Enterprise Integration and Interoperability: Past, Present and April 5, 2011); refer to: www.infosys.com/offerings/IT- Future, Computers in Industry (59)7, pp647–659 (2008). services/architecture-services/ea-survey/Documents/ea- maturing.pdf. Cummins F.A.: Enterprise Integration: An Architecture for Enterprise Application and Systems Integration, Hoboken, NJ: Barnett W., Presley A., Johnson M., Liles D.H.: An Architecture John Wiley & Sons (2002). for the Virtual Enterprise, 1994 IEEE International Conference on Systems, Man, and Cybernetics, San Antonio, TX (1), Davenport T.H., Harris J.G.: Competing on Analytics: The New pp506–511 (1994). Science of Winning, Cambridge, MA: Harvard Business School Press (2007). Barney J.: Firm Resources and Sustained Competitive Advantage, Journal of Management 17(1), pp99–120 (1991). Davenport T.H., Harris J.G., Morison, T.: Analytics at Work: Smarter Decisions, Better Results, Cambridge, MA: Harvard Bernard S.A.: An Introduction to Enterprise Architecture, 2nd Business Press (2010). Edition, Bloomington, IN: AuthorHouse (2005). Davenport T.H., Short J.E.: The New Industrial Engineering: Bernus P., Nemes L.: A Framework to Define a Generic Information Technology and Business Process Redesign, Enterprise Reference Architecture and Methodology, Computer Sloan Management Review (31)4, pp11–27 (1990). Integrated Manufacturing Systems (9)3, pp179–191 (1996). El Sawy O.A., Malhotra A., Gosain, S., Young K.M.: IT- Bernus P., Nemes L., Williams T.J. (Eds.): Architectures for Intensive Value Innovation in the Electronic Economy: Insights Enterprise Integration, London, New York: Chapman & Hall from Marshall Industries, MIS Quarterly (23)3, pp305–335 (1996). (1999).

Bernus P., Nemes L., Schmidt G. (Eds.): Handbook on Finney S., Corbett M.: ERP Implementation: A Compilation and Enterprise Architecture, Heidelberg, Germany: Springer-Verlag Analysis of Critical Success Factors, Business Process (2003). Management Journal (13)3, pp329–347 (2007).

Boh W., Yellin D.: Using Enterprise Architecture Standards in Grant R.M.: Toward a Knowledge-Based Theory of the Firm, Managing Information Technology, Journal of Management Strategic Management Journal (17)Winter Special Issue, Information Systems (23)3, pp163–207 (2006). pp109–122 (1996).

Boster M., Liu S., Thomas R.: Getting the Most from your Gregor S., Hart D., Martin N.: Enterprise Architectures: Enterprise Architecture, IT Professional (July–August), pp43– Enablers of Business Strategy and IS/IT Alignment in 50 (2000).

Government, Information Technology & People (20)2, pp96– Scholten J.G., Hoppenbrouwers S., Iacob M.E., Janssen W., 120 (2007). Lankhorst M., van Leeuwen D., Proper E., Stam A., van der Torre L., van Zanten G.V.: Towards a Language for Coherent Guijarro L.: Interoperability Frameworks and Enterprise Enterprise Architecture Descriptions, Proceedings of the 7th Architectures in E-Government Initiatives in Europe and the IEEE International Enterprise Distributed Object Computing United States, Government Information Quarterly (24)1, pp89– Conference (EDOC), pp28–37 (2003). 101 (2007). Jonkers H., Lankhorst M.M., van Buuren R., Hammer M., Champy J.: Re-engineering the Corporation: A Hoppenbrouwers S.J.B.A., Bonsangue M., van der Torre L.: Manifesto for Business Revolution, New York, NY: Concepts for Modeling Enterprise Architectures, International HarperBusiness (1994). Journal of Cooperative Information Systems (13)3, pp257–287 (2004). Harmon P., Rosen M., Guttman M.: Developing E-Business Systems and Architectures: A Manager's Guide, Burlington, Kaisler S., Armour F.J., Valivullah M.: Enterprise Architecting: MA: Morgan Kaufmann, Chapter 6, pp141–167 (2001). Critical Problems, Proceedings of the 38th Annual Hawaii International Conference on System Sciences, pp224b (2005). Harrington H.J.: Business Process Improvement: The Breakthrough Strategy for Total Quality, Productivity, and Kappelman L.A. (Ed.): The SIM Guide to Enterprise Competitiveness, New York: McGraw-Hill Professional (1991). Architecture, New York, NY: CRC Press (2010).

Hay D.C.: Requirements Analysis: From Business Views to Kearns G.S., Lederer A.L.: A Resource-Based View of Architecture, Upper Saddle River, NJ: Prentice Hall PTR Strategic IT Alignment: How Knowledge Sharing Creates (2003). Competitive Advantage, Decision Sciences (34)1, pp1–29 (2003). Henderson J.C., Venkatraman N.: Strategic Alignment: Leveraging Information Technology for Transforming Kettinger W.J., Marchand D.A., Davis J.M.: Designing Organizations, IBM Systems Journal (32)1, pp4–16 (1993). Enterprise IT Architectures to Optimize Flexibility and Standardization in Global Business, MIS Quarterly Executive Henderson R.M., Clark K.B.: Architectural Innovation: The (9)2, pp95–113 (2010). Reconfiguration of Existing Product Technologies and the Failure of Established Firms, Administrative Science Quarterly King W.R.: Creating a Strategic Capabilities Architecture, (35)1, pp9–30 (1990). Information Systems Management (12)1 (1995).

Hoque F.: E-Enterprise: Business Models, Architecture, and Kosanke K., Vernadat F.B., Zelm M.: CIMOSA: Enterprise Components, New York: Cambridge University Press, Chapter Engineering and Integration, Computers in Industry (40)2–3, 6, pp173–201 (2000). pp83–97 (1999).

Humphries M., Hawkins M.W., Dy M.C.: Data Warehousing: Lankhorst M.M.: Enterprise Architecture at Work: Modeling, Architecture and Implementation, Upper Saddle River, NJ: Communication, and Analysis, Heidelberg, Germany: Springer- Prentice Hall PTR, Chapter 1 (1999). Verlag (2005).

Iyer B., Gottlieb R.: The Four-Domain Architecture: An Lee Y.W., Strong D.M., Kahn B.K., Wang R.Y.: AIMQ: A Approach to Support Enterprise Architecture Design, IBM Methodology for Information Quality Assessment, Information Systems Journal (43)3, pp587–597 (2004). & Management (40)2, pp133–146 (2002).

Janssen M., Hjort-Madsen K.: Analyzing Enterprise Liles D., Presley A.: Enterprise Modeling Within an Enterprise Architecture in National Governments: The Cases of Denmark Engineering Framework, in Charnes J.M. et al (Eds.), and the Netherlands, Proceedings of the 40th Hawaii Proceedings of the 1996 Winter Simulation Conference, International Conference on System Sciences, pp218a (2007). pp993–999 (1996).

Johnson P., Ekstedt M.: Enterprise Architecture: Models and Lindström Å., Johnson P., Johansson E., Ekstedt M., Analyses for Information Systems Decision-Making, Lund, Simonsson M.: A Survey on CIO Concerns—Do Enterprise Sweden: Studentlitteratur (2007). Architecture Frameworks Support Them?, Information Systems Frontiers (8)2, pp81–90 (2006). Johnson P., Ekstedt M., Silva E., Plazaola L.: Using Enterprise Architecture for CIO Decision-Making: On the Importance of Lippman S.A., Rumelt R.P.: Uncertain Imitability: An Analysis Theory, Proceedings of the 2nd Annual Conference on of Interfirm Differences in Efficiency Under Competition, The Systems Engineering Research (CSER) (2004). Bell Journal of Economics (13)2, pp418–438 (1982).

Johnson P., Lagerström R., Närman P., Simonsson M.: McGovern J., Sims O., Jain A., Little M.: Enterprise Service- Enterprise Architecture Analysis with Extended Influence Oriented Architectures: Concepts, Challenges, Diagrams, Information Systems Frontiers (9)2–3, pp163–180 Recommendations, New York, NY: Springer (2006). (2007).

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

28 © Journal of Enterprise Architecture – May 2011

McGovern J., Ambler S.W., Stevens M.E., Linn J., Sharan V., Ross J.W., Westerman G.: Preparing for Utility Computing: The Jo E.K.: A Practical Guide to Enterprise Architecture, Upper Role of IT Architecture and Relationship Management, IBM Saddle River, NJ: Prentice Hall (2004). Systems Journal (43)1, pp5–19 (2004).

Miller D.: Configurations of Strategy and Structure: Towards a Ross J.W., Weill P., Robertson D.C.: Enterprise Architecture Synthesis, Strategic Management Journal (7)3, pp233–249 As Strategy: Creating a Foundation for Business Execution, (1986). Boston, MA: Harvard Business School Press (2006).

Obitz T., Babu K.M.: Enterprise Architecture Expands its Role Ruh W.A., Maginnis F.X., Brown W.J.: Enterprise Application in Strategic Business Transformation: Infosys Enterprise Integration: A Wiley Tech Brief, Hoboken, NJ: John Wiley & Architecture Survey 2008/2009, Survey, Infosys (2009); refer Sons, Chapter 7, pp131–151 (2001). to: www.infosys.com/offerings/IT-services/architecture- services/ea-survey/Pages/index.aspx (current April 5 2011). Sabherwal R., Chan Y.E.: Alignment Between Business and IS Strategies: A Study of Prospectors, Analyzers, and Defenders, O’Rourke C., Fishman N., Selkow W.: Enterprise Architecture Information Systems Research (12)1, pp11–33 (2001). Using the Zachman Framework, Boston, MA: Thomson Course Technology (2003). Salmans B., Kappelman L.A.: The State of EA: Progress, Not Perfection, in Kappelman L.A. (Ed.): The SIM Guide to Parr A.N., Shanks G.G., Darke P.: Identification of Necessary Enterprise Architecture, pp165–217 (2010). Factors for Successful Implementation of ERP Systems, Proceedings of the IFIP TC8 WG8.2, pp99–120 (1999). Schekkerman J.: How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Pereira C.M., Sousa P.: A Method to Define an Enterprise Architecture Framework, 3rd Edition, Bloomington, IN: Trafford Architecture using the Zachman Framework, Proceedings of (2006). the 2004 ACM Symposium on Applied Computing, pp1366– 1371 (2004). Segars A.H., Grover V.: Designing Company-Wide Information Systems: Risk Factors and Coping Strategies, Long Range Peristeras V., Tarabanis K.: Towards an Enterprise Planning (29)3, pp381–392 (1996). Architecture for Public Administration using a Top-Down Approach, European Journal of Information Systems (9)4, Sowa J., Zachman J.A.: Extending and Formalizing the pp252–260 (2000). Framework for Information-Systems Architecture, IBM Systems Journal (31)3, pp590–616 (1992). Perks C., Beveridge T.: Guide to Enterprise IT Architecture, New York: Springer (2003). Spewak S.H., Hill S.C.: Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology, Porter M.E.: What Is a Strategy?, Harvard Business Review Hoboken, NJ: John Wiley & Sons (1992). (74)6, pp61–78 (1996). Tamm T., Seddon P.B., Shanks G., Reynolds P.: How Does Prahalad C., Hamel G.: The Core Competence of the Enterprise Architecture Add Value to Organizations?, Corporation, Harvard Business Review (68)3, pp79–91 (1990). Communications of the Association for Information Systems (28), Article 10, pp141–168 (2011). Pulkkinen M.: Systemic Management of Architectural Decisions in Enterprise Architecture Planning. Four Dimensions and Tapscott D., Caston A.: Paradigm Shift: The New Promise of Three Abstraction Levels, HICSS '06: Proceedings of the 39th Information Technology, New York, NY: McGraw-Hill (1993). Annual Hawaii International Conference on System Sciences, pp179a–179a (2006). The Open Group: The Open Group Architecture Framework (TOGAF), Version 9 (2009). Reed R., DeFillippi R.J.: Causal Ambiguity, Barriers to Imitation, and Sustainable Competitive Advantage, The Treacy M., Wiersema F.: Customer Intimacy and Other Value Academy of Management Review (15)1, pp88–102 (1990). Disciplines, Harvard Business Review (71), pp84–93 (1993).

Reynolds P., Thorogood A., Yetton P.: Allocation of IT Decision Venkatesh V., Bala H., Venkatraman S., Bates J.: Enterprise Rights in Multi-Business Organizations: What Decisions, Who Architecture Maturity: The Story of the Veterans Health Makes them, and When are they Taken?, ICIS 2010 Administration, MIS Quarterly Executive (6)2, pp79–90 (2007). Proceedings, Paper 169 (2010). Vernadat F.: Interoperable Enterprise Systems: Principles, Richardson G., Jackson B., Dickson G.: A Principles-Based Concepts, and Methods, Annual Reviews in Control (31)1, Enterprise Architecture: Lessons from Texaco and Star pp137–145 (2007). Enterprise, MIS Quarterly (14)4, pp385–403 (1990). Wang R.W., Strong D.M.: Beyond Accuracy: What Data Quality Ross J.W.: Creating a Strategic IT Architecture Competency: Means to Data Consumers, Journal of Management Learning in Stages, MIS Quarterly Executive (2)1, pp31–43 Information Systems (12)4, pp5–34 (1996). (2003). Wegmann A.: On the Systemic Enterprise Architecture Methodology (SEAM), International Conference on Enterprise Information Systems (ICEIS), pp483–490 (2003).

Weill P., Ross J.W.: IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Cambridge, Zachman J.A.: A Framework for Information Systems MA: Harvard Business School Press (2004). Architecture, IBM Systems Journal (26)3, pp276–292 (1987).

Whitman L., Ramachandran K., Ketkar V.: A Taxonomy of a Zachman J.A.: Enterprise Architecture: The Issue of the Living Model of the Enterprise, Proceedings of the 2001 Winter Century, Database Programming and Design (1997). Simulation Conference, pp848–855 (2001). Zachman J.A.: You Can't ‖Cost-Justify‖ Architecture, Zachman Winter R., Fischer R.: Essential Layers, Artifacts, and International (2001); refer to: www.aeablogs.org/eakd/files/ Dependencies of Enterprise Architecture, Proceedings of the You_Cant_Justify_Architecture.pdf (current April 5 2011). 10th IEEE Conference on International Enterprise Distributed Zachman J.A.: Architecture Is Architecture Is Architecture, in Object Computing Workshops, pp30 (2006). Kappelman L.A. (Ed.): The SIM Guide to Enterprise Woods D., Mattern T.: Enterprise SOA: Designing IT for Architecture, pp37–45 (2010). 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).

30 © Journal of Enterprise Architecture – May 2011

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

with a brief explanation of enterprise collaboration and INTRODUCTION its relevance in today’s enterprises. Context-Awareness The term context-aware was first used in mobile and its Role in Enterprise Collaboration explains the role distributed computing systems [1], where context-aware of context-awareness in enterprise collaboration. In software was required to be adaptive, based on the doing so, we introduce attributes that would define changing execution environment of the user and the context in a collaboration scenario. Collaboration device from which the application was being accessed. Architecture – A Reference Model outlines a layered Most recent research on context has been based on reference model for a platform that would deliver and relevance of context-awareness for session-based execute collaboration services in an enterprise. We (synchronous) communications [2, 3]. However, when it show the role of each layer on how it enables a comes to collaboration within an enterprise, we would collaboration platform to be context-aware – e.g., collect encounter scenarios that need not be session-based context information, utilize context information, etc. (such as use of emails, enterprise blogs, and wikis). The Architecture Principles for Context-Aware Collaboration latter scenarios are often referred to as asynchronous Platform presents four architecture principles that would collaboration. This article outlines a conceptual context- enable context-awareness in an enterprise platform. aware platform for an enterprise collaboration framework Conclusions provides a brief summary and scope of – how it can capture context of collaboration and use it future work. to tailor user experience. This article proposes the use of context to enhance ENTERPRISE COLLABORATION collaboration experience within an enterprise. Enterprise collaboration is a process where people and Enterprises regard collaboration as highly essential to business processes1 within an enterprise ecosystem capture and distribute collective user value. In a survey work together towards the realization of common goals of 101 US-based IT and business decision-makers, and objectives. Collaboration helps an enterprise meet Forrester found that collaboration tools and technology multiple objectives. It can serve as a tool for innovation are transformative in nature and have the potential to and development of communities. An enterprise can foster a competitive advantage [4]. This article proposes four architecture principles as guidelines that would enable a collaboration platform to collect, abstract, and 1 Clarification of terminology: Most IT projects include people, utilize context for an enhanced collaboration experience process, and technology; and collaboration is no different. However, within an enterprise. this article discusses an extended role of business processes within the realm of collaboration. Business process, as defined in this article The rest of the article is laid out as follows. We (unless specified otherwise), refers to business processes within an commence our discussion in Enterprise Collaboration organization that play the role of a collaborating agent and not the collaboration process.

32 © Journal of Enterprise Architecture – May 2011

take advantage of collective intelligence through essentially involve a communication session. Context collaboration with different entities (suppliers, partners, parameters such as communication channel type employees, etc.). Collaboration can also help knowledge (wireless or wired medium) would contribute to the workers achieve higher efficiency during the process of context of such a session. On the other hand, the third sharing knowledge and execution of enterprise and fourth scenarios (which deal with different times) processes. Ultimately, as shown in Figure 1, can be referred to as non-synchronous collaboration. collaboration objectives should tie in with the broader Non-synchronous collaboration would rely on resources business objectives of an enterprise. The degree of such as email and blogs (just to name a few). For such association would guide architects in defining tools non-synchronous collaboration, we would rely on needed to establish a collaboration platform. attributes such as content tags to define the context. Figure 2 presents a pictorial view of the context Innovation Revenue Growth parameters for the enterprise entities that are relevant for collaboration – Enterprise User, Business Processes, Increased quality and Enterprise Resources (communication channels, Knowledge Increased quality Sharing customer/partner applications, hardware, etc.). The following list outlines Sharing experience experience the parameters that would define context for enterprise

Business Process collaboration: Business Process Shorter Go-to Efficiency Efficiency Market Time 1. User Identity and Profile

a. Relationship with Enterprise BusinessObjectives Development of Development of Increased b. User Preferences

Collaboration ObjectivesCollaboration Communities Communities Profitability 2. Collaboration Session/Channel Parameters a. Device Profile Figure 1: Association between Collaboration and Business Objectives b. Communication Channel c. Metadata of Media Enterprise managers rely on their technical departments 3. Collaboration Tags (IT, Engineering, etc.) to provide a collaboration platform that would ultimately help them achieve their goals in a a. Tags for content/resource (wiki, blog) more effective and time-efficient manner. Based on the b. Tags for followers (follow a team, an employee, responsibilities, collaboration requirements would vary vendor, or discussion) for each group, such as video conference solution, 4. Collaboration Service Enablers document sharing solution for managing sales leads, a. Presence Status etc. Enterprise architects need to keep these specific b. Location collaboration requirements in mind while designing an enterprise collaboration platform. Session Parameters CONTEXT-AWARENESS AND ITS ROLE IN Communicate Identity, ENTERPRISE COLLABORATION Enterprise Define Profile Legend User Context Presence, Context, as discussed in this article, refers to a set of Location Enterprise attributes that can enable a differentiated experience. Event Entity Correlation Channel The context information can be used to allocate Interact Context Parameters Attribute resources for a collaboration session, personalize it Channel Interact Define Parameters based on preferences of the users and choice of Context devices. Context can also be used to adapt the type of Tags services that would be used during the collaborative Business Interact Enterprise Define session. Process Resources Context Followers This article draws a distinction between collaboration Interact and a communication session. A communication session is a synchronous exchange of information; however, Figure 2: Context Parameters for Collaboration Entities collaboration need not always be so. As discussed in [5], The remainder of this section explains these attributes in collaboration scenarios can be grouped into four more detail. 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

User Identity and Profile enterprise blog – is she connected within the enterprise network or updating it from an enterprise VPN? 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 Figure 3: Use-Case Model – Establish Communication with a federated identity management model to establish and User enforce access rights of users. User profile also includes communication preferences Collaboration Tags (on how to be contacted) that play a critical role in A user can now take advantage of enterprise resources setting up the context for a collaboration session. For (such as blogs, forums, and wikis) for helping to get example, a service technician, who is mostly on the relevant data in an efficient fashion. Users can add road, would prefer to be contacted by SMS/MMS and not keywords to tag content that can be used for subsequent email. So any workflow process that requires sending an retrieval purposes. Tags serve as metadata for content, email to the user would need to convert the email into an providing context information for the resource (blog, SMS/MMS format. Most organizations today ignore the wiki). This would help employees to locate a document individual preferences of a user and use a brute force or media content more efficiently. In addition to search, method by setting up a general guideline; e.g., send tags enable more meaningful content distribution and email to all technicians. This problem can be solved by syndication. For example, a particular user group would providing a very high-level virtualized service (as like to be informed when blogs with certain tags are depicted in Figure 3) – Establish Communication with posted or updated. User. This service in turn relies on many abstracted services, such as: send SMS, send MMS, set up a three- Social networks allow users to follow their friends and way call, leave voicemail, etc. Based on the context, the contacts within their community. COTS tools are service invokes the right communication channel. available that extend this concept to enterprise collaboration networks as well. Using this technology, Collaboration Session/Channel Parameters enterprise users can follow documents, conversations, business processes, or enterprise applications and Collaboration session/channel parameters include people/groups within their community. This becomes a details such as device profile and channel type. Device very effective mechanism in syndication of knowledge profile2 would determine supported media formats that a and information within an enterprise. device can receive. A mobile device that cannot receive multimedia (MMS) messages should only be sent text Collaboration Service Enablers (SMS) messages. Similarly, if communication is over a congested wireless network (high dropped packets), the Collaboration service enablers refer to attributes such as session should only implement a voice call and not location and presence status that can be used to define include video session. Channel information is important context. Several technology and architecture principles not only for synchronous communications but even for are used to abstract location and presence status scenarios where (say) a user needs to update an 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 REST3 messages to 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. 3 Representational State Transfer.

34 © Journal of Enterprise Architecture – May 2011

retrieve the information. For example, a person with business service, based on the context, can request ―busy‖ status would mean that calls should directly be allocation of physical resources for collaboration as well. sent to his voicemail. The concept of presence can be Abstraction Layer exposes network, communication, and further refined with ―rich presence‖ information. For enterprise resources as atomic services that can be instance, busy state could imply either the person is invoked by the service layer. It contributes to busy in a meeting with her boss or busy working on a collaboration in two ways. First of all, it abstracts network document or simply enjoying lunch. An employee may data of a user such as location and presence – that have different communication preferences in each of define the context of a user. Secondly, it provides these scenarios. abstracted core network services that can be easily invoked by the service layer (based on the context of the COLLABORATION ARCHITECTURE – session). A few examples would be services such as A REFERENCE MODEL Send SMS and Send MMS. Context attributes don’t reside at a single point within an enterprise; they are distributed throughout the Service Layer is the core layer within a delivery platform. architecture platform. This section outlines a conceptual Service enablers encompass service utility components layered architecture framework that can collect, expose, that provide common services, such as identity and utilize context attributes to provide efficient and management, authentication, authorization, and accounting across all services. In an extended productive collaboration. Figure 4 presents a high-level 4 service delivery platform for collaboration services. It’s a enterprise scenario wherein two enterprises offer generic reference framework; vendors in this space will collaboration services, authentication is enabled through have their own specific representation of collaboration federated identity management, relying on a negotiation architecture. The role of each layer in a context lifecycle approach between the enterprise networks. is presented in Figure 5. Service Registry and Repository enables service discovery during a collaboration session (based on the Presentation layer Collaboration Applications context of the collaboration session). It plays a key role CRM Sales/MKTG Operations in allowing the visibility of services and data based on Assets for Client Mashup the context and privacy preferences of the user and User Interface for Mobile, PDA, Desktop, Data Feeds Services Terminal Widgets (RSS/ATOM) (SOAP/REST) enterprise. As highlighted in [6], context and semantic technologies play a crucial role for enabling a secure Service Execution and Orchestration Layer service discovery solution for enterprise users and Service Layer processes. Collaboration Services (Group Editing, Publishing, Search, Folksonomy) Enterprise Communication Media Services Enterprises, based on their core business, would have Services Services different IT applications that would fall under the

Service Registry and Repository Service Enablers Management Service category of Enterprise Services. For instance, a software Abstraction Layer (Network and Resources) development company would have a collaboration Physical layer application for version control of the code base; a Partner and Third Party Enterprise Network and Resources Layer Network Network Services company whose workforce needs to be scheduled for (CSP) Physical Infrastructure EIS Access/ (QoS, Resource Resources dispatch to customer calls would have an enterprise Network and Resource Layer Transport Allocation) application for managing dispatch. It would also include Figure 5: Platform for Collaboration Services general enterprise applications such as email and calendar tools for collaboration. The lowermost layer, Physical Layer, includes network and connectivity resources. An enterprise may own the Communication Services provide several capabilities to entire network access/transport layer or rely on partners communicate amongst users – such as instant to provide the network resources (wireless, LAN/WAN). messaging, telephony, video conference, SMS, and The physical layer includes network resources such as MMS. An enterprise may have to rely on other CSPs to location and presence information of a mobile user. provide some of these capabilities. Media Services, in a These could be provided by third parties, such as way, can be viewed as a service enabler; however, it is Communication Service Provider (CSP). The Physical kept as a separate category. It includes services such as Layer also includes enterprise information systems – transcoding and watermarking. Meta-data of media such as payroll, user profile databases, sales and defines context and how it can be used to invoke commission, etc. Physical layer attributes such as medium of communication, users’ network attributes (wireless coverage, location and presence information) 4 Extended enterprise refers to an enterprise network beyond the contribute to defining context. On the same note, a boundary of a single enterprise. It can include the public Internet or a peer/partner enterprise network.

different media services. Finally, the service layer collaboration platform has to provide a mashup builder to includes Collaboration Services for the users of the its workforce, so that users can build mashups by wiring platform. It would include applications that enable data and services together. The value of a collaboration collaboration, such as a wiki platform and folksonomy platform increases significantly if it exposes the services application for tagging. (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 SDLC5 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 Figure 6: Role of Service Layer for Content-Awareness collaboration tools and platform performance metrics. Services within Service Layer can be executed as The intention is to associate these metrics to enterprise atomic services or they could be composed into KPIs, providing insight as to how the transactions related composite services. Service Execution and to collaboration meet the business objectives of an Orchestration Layer provides the capability of executing enterprise. For example, is a forum/wiki a better asynchronous method for communication than email or composite services. It relies on an underlying Business mail distribution? When should the collaboration platform Process Management (BPM) tool. This layer forms the basis of collaboration between process and people of an put the onus on the sender/source of information versus organization. Based on the outcome of a process, say the seeker? Which forums are more effective in an enterprise than others? In a nutshell, the service layer failure of an order provisioning workflow, the service needs to be integrated with business intelligence, data orchestration layer could, for example, initiate a management, and reporting systems within an enterprise collaboration session between the technician and a care to help measure and analyze these metrics and provide representative. a feedback loop to the service layer to pro-actively Presentation Layer deals with final delivery of content to respond to incidents. the user on all possible screens – desktop, laptop, PDA, mobile handset (enterprise guidelines and user ARCHITECTURE PRINCIPLES FOR CONTEXT- preferences will also dictate choice of device). The front- AWARE COLLABORATION PLATFORM end could be a heavyweight client, as in a client-server A flexible collaboration platform provides opportunities to framework or a lightweight rich Internet application (RIA) innovate, share knowledge, and support operations front end. This layer would also include tools that can within a ―borderless enterprise‖. This section discusses enhance the collaboration experience. four key architecture principles that can help enterprises leverage context-awareness in their collaboration An example of such a toolkit is an enterprise mashup. platform, thereby enabling people and processes to Mashups, based on Web 2.0 principles and efficiently collaborate with one another. The guidelines technologies, are used to solve immediate specific needs of an enterprise. Enterprise mashups (created by presented here are not new within the realm of users) combine network services, enterprise enterprise architecture; however, together they are powerful in establishing a context-aware collaboration applications, and information sources (that are platform. provided/exposed by the platform) into a lightweight web application. Mashups can also combine enterprise data Principle 1: SOA and REST Principles for Context- with data/services from the public Internet (say Google Awareness Maps). For example, a recruiter in a placement agency builds a simple mashup by using the street address Service Oriented Architecture (SOA) provides an (exposed as a service from the enterprise) and architecture pattern that requires solution logic to be overlaying the information on Google Maps. implemented in the form of loosely-coupled and re- Mashups help an organization achieve cost reduction and productivity, innovation, and growth [7]. The 5 Software Development Life Cycle.

36 © Journal of Enterprise Architecture – May 2011

usable services. Strictly speaking, service-oriented initiate a collaboration session. Figure 7 (Option III) design paradigm is not concerned with the context of a depicts an example of how an automated business service; however, we can use the underlying SOA process can initiate a collaboration process. principles in two ways to provide a context-aware platform. Based on the context, appropriate services Scenario: Customer places a order on an online laptop (given their loosely-coupled and re-usable nature) can retail site. However, after the order has been submitted, the be invoked with the help of a standards-based order handling process detects an error in the loading of messaging service (e.g., SOAP/HTTP). In addition, the additional software onto the hard disk of the laptop. context information (such as presence, location) can be Option I Option II Option III exposed as web services (e.g., Parlay/X web service) through standardized service contracts. A platform can Order Handling In addition to In addition to process generates a generating a trouble generating a trouble also adopt the REST style (or Restful SOA) to expose trouble ticket which ticket, Order Handling ticket, Order Handling services and context information as resources that can gets assigned to a process sends an email process posts an be addressed through URLs. person blast to the Help Desk automated blog post with the pre - defined Services built using the SOA paradigm can be modeled tags. Employees who as entity services, task services, and utility services. have opted to receive RSS feeds on the tags Entity service pertains to a specific functional entity, also get notified. such as employee, whereas a task service can span the Increasing degree of collaboration functional boundaries of multiple entities and is often used as a controller/orchestrator service. Utility service Figure 8: Business Process as an Agent of Collaboration provides re-usable functionality that is agnostic of an entity. Figure 6 represents an example of a service Event Driven Architecture (EDA) style has been gaining model on how services can be designed to provide and ground in the business process management domain. utilize context within a collaboration platform. Often it is related with SOA. However, there are two significant differences with SOA. Entity Centric EDA provides the capability to decouple the source of an Service Consume Context of an entity for executing event and the event handler. It also provides the a service on an entity (e.g. Send message to Define Context of an entity (e.g. capability to correlate multiple events, generate derived 7 an employee based on user’s Define user’s relationship to communication preference) events, and subsequently process them. The enterprise = “Employee”) correlation of events can generate context of a business Provide Context of an Entity (e.g. Update process and enable the BPM process orchestrator to Location and Presence adapt the collaboration process accordingly. Utility status of user) Context of Task Centric Service Service Consume Context an Entity Consume Context of Figure 8 presents one possible business layer model of an entity for an Entity for a specific that we have built to help visualize enterprise executing a service business process (On- (e.g. Authorize a boarding process of collaboration. We have chosen the ArchiMate modeling user based on an employee – assign language since it provides a mechanism to model user’s relationship assets based on role to enterprise) in a company) business, applications, and infrastructure viewpoints and a visualization of their inter-relationships.

Figure 7: Sample SOA-Based Service Model for As we can see in Figure 9, both business processes and Implementing Context-Awareness events (such as alert notifications) can create a need for collaboration between users (represented as roles). The Principle 2: Enhancing Business Process Management for collaboration is realized through collaboration services Collaboration that are made available to the platform users. The collaboration is governed and managed through Generally, collaboration is associated with people. enterprise policies, one of them being context- However, this article has taken the approach to extend awareness policy. The reader is encouraged to refer to 6 collaboration beyond people of an enterprise to include [9] for additional details on ArchiMate language. 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, 7 This capability, however, is associated with Complex Event business partners, and customers. Processing (CEP), which is one of the categories of EDA.

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

CMS with a tag management system. The final solution Principle 3: Folksonomy for Collaborative Tagging would require the following strategic (business and technical) steps: Folksonomy is a key part of the Web 2.0 architecture and relies on a free form annotation of web resources 1. Develop a governance model on who can create done by its users, without the constraints of a predefined and manage tags – is it the content producer or taxonomy [10]. Given its free-form and flat hierarchical consumer or both (maybe employing a rating structure, folksonomy aims to make the web more scheme on the relevance of each tag)? ―semantic‖. However, this lack of structure can be seen 2. Develop a strategy on whether there should be a as ―search noise‖ and conflict with official taxonomies formal ontology layer underneath the folksonomy within an enterprise [11]. Thus, enterprises need to have tag layer that would map the popular user tags a business and technical strategy for striking a happy to a more formal tag cloud. medium balance and let folksonomy and an official taxonomy complement each other. The final technical Principle 4: Meta-Data of Digital Media for Context solution should be able to avoid ―search noise‖ by Information preventing users from adding tags that don’t provide any relevance (e.g., prevent adding ―stupid‖ as a tag for a Meta-data continues to be a crucial factor to provide non-relevant post). context information even for digital media content. Based on the consumers and channels that are available for the An enterprise can opt for an enterprise Content digital media content, it needs to be re-purposed such as Management System (CMS) that provides a layer for transcoded, watermarked, etc. As explained in [12], one managing meta-data (tags) or integrate their existing way of achieving this is to make the Enterprise Service

38 © Journal of Enterprise Architecture – May 2011

Bus (ESB) media-aware. (ESB, a critical component of REFERENCES SOA architecture, connects service requestors and service providers through its message mediation [1] Schilit B. et al: Context-Aware Computing Application, IEEE Workshop on Mobile Computing Systems and Applications capabilities. It also needs to perform conversions of (WMCSA), Santa Cruz, CA, USA, pp89-101 (1994). messaging protocols and message interaction patterns, based on the capabilities of the service requestor and [2] Sun J. & Sauvola, Jaakko: Towards a Conceptual Model for provider.) A standard ESB performs four functions on Context-Aware Adaptive Services, Proceedings of the Fourth messages – mediation, transformation, dynamic routing, International Conference on Parallel and Distributed and persistence. A media-aware ESB extends the same Computing, Applications and Technologies (PDCAT), pp90-94 four functions to media objects. This can be achieved by (2003). ―building intelligence‖ into the ESB to examine the meta- [3] Henricksen K., Indulska J., Rakotonirainy A.: Modeling data of the media content and dynamically invoke Context Information in Pervasive Computing Systems, processes and/or route media to the most appropriate Pervasive Computing, Lecture Notes in Computer Science, channel or process for that particular media object. Vol. 2414, pp79-117 (2002). [4] Forrester: The Right Collaboration Architecture Drives CONCLUSIONS Business Transformation (2009). As organizations are adapting themselves to a ―flatter [5] Liesenberg P.: Architecting Collaborative Applications, world‖, the underlying landscape of enterprise ebizQ, 04/16/2009; refer to: collaboration has been changing. The emergence and www.ebizq.net/topics/enterprise_integration_architecture/ proliferation of Web 2.0-based technologies have features/11186.html. spurred enterprises to provide an underlying platform that would enable their distributed workforce to [6] Toninelli A., Montanari R., Corradi A.: Enabling Secure Service Discovery in Mobile Healthcare Enterprise Networks, collaborate efficiently. Collaboration is essential to create IEEE Wireless Communications, pp24-32 (June 2009). and syndicate core competencies within an enterprise and its partners. This article has discussed a technology [7] The Business Case for Enterprise Mashups, IBM (2008). framework that will allow an enterprise to use context information to provide a differentiated collaboration [8] Anderson C.:The Long Tail, Wired Magazine (October 2004); refer to: www.wired.com/wired/archive/12.10/tail.html. experience. [9] Lankhorst M. et al: Enterprise Architecture at Work, As a part of our ongoing research, we intend to study Springer (2009). how context-awareness affects the efficiency and effectiveness of the collaboration process through the [10] Wu X., Zhang L., Yu Y.: Exploring Social Annotations for the Semantic Beb, in WWW ’06: Proceedings of the 15th study of enterprise metrics, such as cost of transactions international Conference on the World Wide Web, New York, facilitated by collaboration. NY, USA, ACM Press, pp417-426 (2006).

ABOUT THE AUTHOR [11] Johnston K.: Folksonomies, Collaborative Filtering, and Abhijit Sur is a Principal Solution Architect with more e-Business: Is Enterprise 2.0 One Step Forward and Two than 15 years of experience at architecting, designing, Steps Back?, The Electronic Journal of Knowledge Management, Volume 5, Issue 4, pp411-418. and implementing large-scale projects within the telecommunications industry. He received his MS in [12] Sur A., Schaffa F. et al: Extending the Service Bus for Statistics from the Indian Institute of Technology (IIT) at Successful and Sustainable IPTV Services, IEEE Kanpur (India) and his MS in Telecommunications from Communications Magazine, pp96-103 (August 2008). 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.

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

agencies to describe their enterprise architectures and INTRODUCTION programs. The researcher is a participant within a group Within Federal government and industry, leaders strive of enterprise architects and engineers working to to provide effective and efficient services. Given improve mission effectiveness and efficiency by mandates such as the Clinger-Cohen Act and the need federating architectures across multiple agencies. The for good resource management, managers are federation method employed within the working group is investigating how to improve enterprises by identifying based on the Global Information Grid (GIG) Architecture and analyzing potential duplicative investments, Federation Strategy and uses a 10-layer architecture capability gaps, and opportunities for collaboration within reference model traceable to the FEA. The 10-layer and across agencies. Within the Federal government, architecture model uses concepts from the Enterprise this cross-agency analysis is being accomplished Architecture CubeTM (Bernard 2005) and the ISO Model through the use of reference models within the Federal of Architecture for Open Systems Interconnection (OSI) Enterprise Architecture (FEA) (OMB 2007a). With the (Zimmermann 1980). The 10-layer model (Figure 1) FEA, the Office of Management and Budget (OMB): incorporates Operational Drivers such as strategic ―… is attempting to provide federal agencies and other vision, policies, people, and processes in the upper decision-makers with a common frame of reference or layers and uses a taxonomy in the lower layers taxonomy for informing agencies’ individual enterprise contained in the Operational Services & Content and architecture efforts and their planned and ongoing investment Undercarriage Services to categorize technical services. activities, and to do so in a way that identifies opportunities for Three vertical overlays of Management, Data, and avoiding duplication of effort and launching initiatives to Security cross the horizontal layers incorporating establish and implement common, re-usable, and interoperable pertinent aspects for enterprise emphasis. solutions across agency boundaries.‖ (GAO 2004 p2). Architecture frameworks are used to describe The expert judgment classical method has been used to architectures in their ―as-is‖ and ―to-be‖ states along with elicit expert opinion to quantify the effectiveness and transition and sequencing plans. Multiple architecture efficiency of reference models in federating enterprise frameworks are used by various departments and architectures. The reference model approach was

40 © Journal of Enterprise Architecture – May 2011

evaluated for shared, interdependent missions and provide a structure to describe enterprise architectures. shared applications/infrastructure. The quantification of The Government Accountability Office (GAO 2003) reference model effectiveness for enterprise federation (formerly General Accounting Office) survey of federal can assist the refinement of enterprise architecture agencies identified different frameworks that agencies practice. Reference models were determined to be an use to describe their architectures. These included the effective practice within this study for federating Federal Enterprise Architecture Framework (FEAF), the enterprise architectures. Future studies are Federal Enterprise Architecture Program Management recommended to validate the results of this expert Office (FEAPMO) Reference Models, the Zachman judgment research. 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 Figure 1: 10-Layer Architecture Reference Model troubles communicating because ―each organization has ENTERPRISE ARCHITECTURE a different culture, a structure of beliefs, and behavior patterns and practices‖. Within the GIG Architecture Enterprise architectures describe complex environments Federation Strategy (DoD 2007) these challenges are composed of people, process, and technology and are recognized given the large size of the DoD enterprise used to improve strategic alignment of IT investments to comprising multiple organizations and elements with mission (business) goals. Bernard (2005 p31) defines different frameworks and vocabularies used to describe enterprise architecture as: their architectures. Winter and Fischer (2006) describe ―… the analysis and documentation of an enterprise in its and demonstrate through the use of case studies an current and future states from an integrated strategy, business, approach of using layering and appropriate level of and technology perspective‖. abstraction to provide broad views when comparing The OMB (2007b pA-1) defines enterprise architecture enterprise architecture and this concept is incorporated as: within this research. ―… a management practice for aligning resources to improve business performance and help agencies better execute their FEA Reference Models core missions. An enterprise architecture describes the current and future state of the agency, and lays out a plan for The FEA reference models were included in the GAO transitioning from the current state to the desired future state.‖ survey (2003), but they differ in that the FEA reference These definitions share the concepts of alignment with models represent a taxonomy with which agencies align the business processes, direction of resources, and or map their enterprise architectures. Reference models transition from a current state to future state. provide a means to compare disparate architecture framework products. The FEA (OMB 2007a p5): Architecture Frameworks and Reference Models ―consists of a set of interrelated ―reference models‖ designed to facilitate cross-agency analysis and the Zachman (1987) espoused the need to describe identification of duplicative investments, gaps, and information systems within a framework enabling opportunities for collaboration within and across architecture descriptions from a set of views agencies‖. The five inter-related FEA reference models representing different perspectives. Multiple architecture are the Performance Reference Model (PRM), Business frameworks have been developed and are in use to Reference Model (BRM), Service Component Reference

Model (SRM), Technical Reference Model (TRM), and components independent of business functions). Layers Data Reference Model (DRM). 7 and 6 represent Operational Services and Content for An anticipated benefit of a reference model approach is software performing specific activities and repositories of the ability of individual agencies/programs that use operational content. Layers 5 through 1 represent different architecture frameworks to describe their Undercarriage Services which are enterprise-wide enterprise architecture within a common taxonomy. The software and hardware services using shared networks GIG Architecture Federation Strategy approach and FEA and facilities. The lower layers provide the foundation for involve aligning component architectures within a the higher levels which execute the technical and common framework of semantic understanding (DoD business services based on the strategic vision, policies, 2007). By using a common taxonomy/framework, and processes. The model includes vertical reference models anticipate overcoming some of the overlays/domains for emphasis of the Data/Information, communication barriers noted by Rechtin (2000). Security, and Management aspects of the enterprise. Federation is differentiated from integration in that the This layered view is consistent with the layered view former’s objective is to enable the interoperability presented by Lankhorst (2005) and Maier & Rechtin between disparate architectures versus integrating them (2009). Consistent with Lankhorst (2005), the lower into a single enterprise architecture. Fischer et al (2007) levels may directly interact with any of the higher layers. note that the federated approach to enterprise The layered presentation of each of the participating architecture models provides a valuable tool for insights agencies when brought together can be thought of as into current and future architectures not available before similar in structure to the Enterprise Architecture CubeTM by bringing participating architectures together and that (Bernard 2005) with each of the agency’s layered views the element architecture owner acceptance is very high being considered an architecture segment. since they maintain ownership of their respective architectures. MEASURES OF EFFECTIVENESS FOR ASSESSING REFERENCE MODELS 10-Layer Architecture Reference Model Effectiveness measures and assessment frameworks were reviewed to apply to the evaluation of reference The 10-Layer Architecture Reference Model is intended models for federating enterprise architectures. The to facilitate federation of agency enterprises through a GAO’s Information Technology Investment Management common language that supports cross-agency reporting (ITIM) Framework and OMB’s Enterprise Architecture and decision-making. The 10-Layer Architecture Management Maturity Framework (EAMMF) have value Reference Model (Figure 1) is being used by the measures and assessment frameworks applicable to IT participating agencies and programs to improve future and enterprise architecture maturity. These measures, versions of the FEA reference models for their while applicable to measuring the maturity of an IT or community of interest. The 10-layer model was in use enterprise architecture program, were determined to not within one of the participating agencies prior to being be applicable to this study on federating architectures. selected and adapted for use within the community of Buchanan (in Morganwalp & Sage 2004) provides a list interest. of financial and business benefits that should result from The model incorporates Operational Drivers such as a high-quality enterprise architecture. Morganwalp strategic vision, policies/doctrine, people, capabilities, (2002) used these benefits as qualitative measures to and processes in the upper layers to guide a business- evaluate an enterprise architecture framework and driven approach to the federated architecture. Layer 10, development process. These benefits used by Operational Objectives and Policies, relates to both Morganwalp were found to be applicable to the internal and external objectives and policies which guide assessment of reference models for federating the enterprise and drive the required capabilities. Layer enterprise architectures and were used as shown in 9, Capability Areas and Threads, describes enterprise Table 1 with the expert judgment classical method. capability areas and threads that make service calls to Two modifications were made to adapt these benefits as instances or activities and integrates/orchestrates the measures for use within this research based upon a pilot service delivery to complete the thread. Layer 8, evaluation with three enterprise architects. First, the Enterprise Activities and Exchanges, provides or calls on Financial Efficiency benefit of ―Re-use‖ was evaluated at a set of services at the same level or from lower layers the subdivisions of Re-use of Hardware Components, to perform the functions or requirements of a thread and Re-use of Software Components, and Re-use of could be performed by human or a machine/expert Methods. Second, the Business Effectiveness benefit of system. Layer 8 contains business component modeling ―Alignment‖ was evaluated at the subdivisions of Tighter and services which are equivalent to the FEA BRM Alignment of Business Strategy and Architecture (business functions) and the FEA SRM (service Process Stream of Logic. The rationale to use these

42 © Journal of Enterprise Architecture – May 2011

subdivisions was based on the pilot evaluation Financial Efficiency participants’ belief that meaningful differences may exist 7. Technical Adaptability within those divisions in the quantitative evaluation of reference models.  Geographic range of architecture extended  Range of data types expanded Table 1: Financial Efficiency and Business Effectiveness  Scalability Enterprise Architecture Measures  Extensibility (Adapted by authors from Morganwalp & Sage (2004) as noted  Portability in text.)  Interoperability Financial Efficiency

1. Re-use of Hardware Components Business Effectiveness  Infrastructure subassemblies  Common client platforms for well-defined types of 1. Tighter Alignment to Business Strategy users  Architecture process is top-down, business strategic-  Servers run as multiple instances of a single image driven, and future-oriented  Value opportunities are tested and analyzed 1. Re-use of Software Components  System software components 2. Architecture Process Stream of Logic  Middleware components  Environmental trend analysis identifies threats and  Business-specific components opportunities  Application components and variants  Business strategy requirements identify strategic intent and business architecture  Architecture technical domains  Information requirements identify what information is 2. Re-use of Methods required for strategic success  Architecture analysis and process model  Architecture requirements identify what technical  Object-oriented business and software engineering functionality is required to supply the information methods  Enterprise application portfolio and infrastructure  System and software test methods requirements identify how the technical functionality  Engineering tool methods will be provided  Enterprise program management identifies the most 3. Reduced Time-to-Delivery efficient delivery plan  Application delivery can leverage common infrastructure services 3. Knowledge Development  Business objects and components do not need to be  Business managers are educated about IT rebuilt  IT managers are educated about business  Subcontractors can predict infrastructure capability  Financial and architecture methods interoperate and IT management skills  Information requirements and architecture are  Integration framework minimize engineering time formalized requirements  Information is user-focused, not simply a data 4. More Efficient Program Management element  Programs manage portfolios of IT work products 4. More Sophisticated Asset Management  Program disciplines are enhanced though re-use of  Resource allocations are based on business strategic methods value  Emphasis is on leading, not lagging, program  Emphasis is on leading not lagging, indicators of indicators strategic success 5. Reduced Support Costs 5. Reduced Decision Risks  Reduced complexity  Time saving in strategic planning  More rigorous ―lab-based design‖  Architecture artifacts describing the theory of the  More accurate, integrated data business and improving consensual decision-making  More rigorous strategy-based decision-making 6. Lower Acquisition Costs  More accurate market, competitive, and operational  Smaller set of components calculus  Enhanced negotiating leverage  Visibility of legacy and future architecture for reducing risk

Business Effectiveness ensure that a cross-section of the participating agencies was represented. The use of 16 experts and nine seed 6. Tighter Strategic Alignment with Partners variables is consistent with both empirical studies and  Roles within the integrated value chain modeled and simulations of expert judgment using the classical negotiated method (Gehris 2008).  Business engagement rules formalized and automated The working group participants were selected by their  Visibility of business models for reducing risk agencies to represent and support them and include government and contractors with extensive experience 7. Business Adaptability in and training on enterprise architectures and systems  Sensitivity to future and technology trends engineering.  Digital innovation  Replacement of physical goods movement with The expert elicitation followed the guidelines of Cooke sharing of information and Goossens (1999) and was conducted via structured  Identification of opportunities for strategic alliances one-on-one, face-to-face discussions. The discussion  Speed of decision-making and implementation instrument and data collection sheet was piloted with three enterprise architects. The discussion instrument EXPERT JUDGMENT contains seed variables (Table 2) pertinent to enterprise architectures and questions based on the enterprise Expert judgment has been used to quantify risks and architecture measures (Table 1) discussed in the make assessments within fields such as nuclear safety preceding section. (Cooke 1991), reliability (Mazzuchi et al 2008), and information security (Ryan et al 2011). Based on the Selection of seed variables was complicated by the high authors’ literature review, this is the first time that expert level of abstraction used within reference models and judgment techniques have been used to evaluate the the limited quantification within academic and publicly effectiveness of reference models in federating available information. Each expert was asked to provide enterprise architectures. To judge the success of models what he/she believes to be the realization for each seed and frameworks by cause-and-effect is difficult given the variable along with a range that would incorporate the timeframes involved (multiple years and planning cycles) realization with high confidence (5%, 95%). and multiple intervening events (changing world events, Table 2: Discussion Instrument − Seed Variables and organizational budget changes, leadership changes, Realizations etc.). The ability of expert judgment to quantify effectiveness was leveraged within this study to quantify Realiz- the effectiveness of the use of architecture reference Seed Variable ation Reference models to inform future enterprise federation activities. XX% of performance goals 72% OMB (2009); were met within recent www.ExpectMore. gov For this research, the classical method described by Government Performance Cooke (1991) and Ryan et al (2011) was selected for the and Results Act assessment elicitation and combining of expert judgment. Within the reports. classical method: XX% of 2008 IT industry 55% Architecture & ―… experts provide a distribution for unknown quantities by survey respondents Governance (2008) specifying 5th, 50th, and 95th percentile values for the indicated they were currently quantities of interest‖ (Ryan et al 2011 p3) working on a Service- The unknown quantities within this research pertain to Oriented Architecture (SOA) the effectiveness of reference models in federating project. enterprise architectures. The individual expert’s XX% of 2008 IT industry 75% Architecture & judgments are combined with the other experts using survey respondents Governance (2008) weights: indicated "a common, scalable information ―… derived from the experts’ responses to a set of seed repository" as an important variables whose values [realizations] are known by the analyst tool for IT planning success. and which are used to ―calibrate‖ the accuracy of the expert’s opinions‖ (Ryan et al 2011 p3) XX% of IT projects are on 41% GAO (2007) OMB's Management Watch The 90% confidence interval represents the expert’s List of poorly planned and/or judgment of the potential outcomes given surrounding poorly performing. ambiguities. XX% of companies have 34% Ross (2006 p2) The 16 experts within this study were selected out of an digitized their core architecture working group using reference models to processes.

44 © Journal of Enterprise Architecture – May 2011

Realiz- Un- Seed Variable ation Reference Calibration Information Normalized Calibrated Expert Score Score Weight Weight Those companies who 25% Ross (2006 p2) digitized their core 4 0.200 0.773 0.155 0.105 processes have XX% lower 5 0.000 1.407 0.000 0.000 IT costs than competitors. 6 0.005 1.422 0.007 0.005 XX% of system engineers 51% Jain et al (2008 p217) responded that system 7 0.200 1.072 0.214 0.146 integration is improved as a 8 0.254 1.187 0.302 0.205 result of an increase in open system-orientation. 9 0.037 0.938 0.035 0.024 XX% of applications are 31% Wu et al (2007 p445) 10 0.164 0.953 0.156 0.106 application islands characterized by ad hoc 11 0.000 1.477 0.000 0.000 deployment of enterprise 12 0.000 1.033 0.000 0.000 applications and disordered intercommunications 13 0.000 1.349 0.000 0.000 between applications. 14 0.154 0.538 0.083 0.056 An enterprise approach to 17% Wu et al (2007 p445) 15 0.014 0.895 0.012 0.008 applications provided by service-based architectures 16 0.254 0.796 0.202 0.138 has been found to provide The experts were then queried on how three different XX% cost savings. scenarios affected the expected outcomes for the Calibration scores and information scores for each enterprise architecture measures (Table 1). An excerpt expert were determined using the classical method by of the EA Measures section of the Discussion Instrument comparing the responses to the realizations. The is shown in Table 4 for the measure Tighter Alignment to expert’s calibration score is based on where the Business Strategy. This example will be followed responses fall compared to the realizations (bins of 0- through the article to demonstrate how the expert 5%, 5-50%, 50-95%, and 95-100% are used in this judgment classical method was applied. research). The closer the expert’s responses fall to the Stepping through Table 4, the experts were asked to realizations, the higher his/her calibration score given provide an expected number of Communities of Interest more responses would be in the 5-50% and 50-95% that would achieve tighter alignment to business strategy bins. The more responses fall into the 0-5% and 95- after 100 different Communities of Interest engagements 100% bins (i.e., the expert response did not include the to federate enterprise architectures within three realization), the lower the calibration score. The expert’s scenarios of (1) reference models not used, (2) information score is a measure of how certain he or she reference models used within federated space, and (3) is in their responses. Large ranges will result in a low reference models used within federated space and at information score and small ranges will result in a high each agency. The term ―Communities of Interest‖ was information score. The expert’s calibrated weight is the used to signify a group of agencies working together product of their calibration and information scores based on mission/business goals to federate their normalized so the weights sum to one. Table 3 enterprises. To allow the experts to use numbers rather summarizes the calibration scores, information scores, than probabilities on a single event and to summarize un-normalized weights, and normalized calibrated how other extenuating circumstances could affect the weights. Expert 8 received the highest weight and outcome, the experts were asked to consider each several experts (5, 11, 12, and 13) received zero weight. measure in 100 Communities of Interest (Cooke & It is not unusual for the classical method to assign zero Goossens 1999). The experts were asked to provide the weight to experts (Ryan et al 2011). 5%, 50%, and 95% values for the number of Table 3: Expert Scores and Weights for Seed Variables Communities of Interest that would achieve tighter alignment, not how much tighter the alignment would be Un- over the three scenarios. Responses to both the seed Calibration Information Normalized Calibrated Expert Score Score Weight Weight variables (discussed previously) and the research questions were recorded and analyzed using both equal 1 0.037 0.881 0.033 0.022 weights and calibrated weights (based on seed TM 2 0.048 0.808 0.039 0.027 variables) using an EXCEL spreadsheet from Ryan et 3 0.593 0.389 0.230 0.157

al (2011) adapted for the number of seed variables and resulting combined distribution for Scenario 2. To experts within this study. simplify the graph only distributions for experts 3, 7, 8, Figure 2 demonstrates graphically how the responses and 16 are shown, but the combined distribution is the are combined using calibrated weights to develop the result of calibrated weights of all the experts.

Table 4: Discussion Instrument − Excerpt of EA Measures

Given 100 Communities of Interest

Scenario 1 Scenario 2 Scenario 3 If community reference If reference models are If community reference models are used within not used within the models are used within the federated space and federated space, then X the federated space , at each agency, then X will ______then X will ______will ______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

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

46 © Journal of Enterprise Architecture – May 2011

RESULTS Table 6 summarizes the calibrated results for all of the EA Measures across the three scenarios. Looking at the The results for each EA Measure were compared using 50% values across the scenarios, a positive impact is both calibrated weights (from the seed variables) and seen for each of the measures. By using reference equal weights. The raw data and combined results for models within the federated space, an average of 15% the Tighter Alignment to Business Strategy measure are more of the Communities of Interest would see shown in Table 5. Combined with the calibrated weights, improvements in their EA Measures over those that did the 50% value for Scenarios 1, 2, and 3 are 20.5%, not use reference models (average difference between 38.2%, and 46.9% respectively. This is interpreted as Scenario 1 & 2). Using reference models within the reference models having an approximate 18% impact federated space and at each agency, an average of 28% going from Scenario 1 to 2 and having an approximate more of the Communities of Interest would see 9% impact going from Scenario 2 to 3. Over the 15 improvements in their EA Measures (average difference measures, the equally weighted runs tended to show between Scenario 1 & 3). The 5% and 95% levels greater impact of reference models than the calibrated represent the range that the experts expect in the runs. Generally, the experts found reference models to variability of the measure to other influences or in have a positive impact for the EA Measures although application. As the scenarios went from Scenario 1 some individual experts judged the reference models to through 3, the variability increased. The rationale have either a negative or no impact such as seen with provided by the experts for this increased variability is Expert #15 in Table 5 (expert judged no distribution that while the reference models would have a positive change across scenarios). impact, the effects of other influences such as Table 5: Individual Expert Assessments and Combined leadership, governance, and incentives had the effect of Results for Tighter Alignment to Business Strategy a slight increase in variability. Leadership providing a

Tighter Alignment to Business Strategy compelling vision and ability to tie enterprise efforts to the federated mission over the timeframes required for Scenario 1 Scenario 2 Scenario 3 implementing changes was mentioned as an important Expert Expert Input Expert Input Expert Input variable in performance. # 5% 50% 95% 5% 50% 95% 5% 50% 95% Table 6: Expert Judgment Results for Reference Model 70.0 85.0 1 5.0 10.0 20.0 30.0 40.0 50.0 50.0 Use in Federating Enterprise Architectures 2 5.0 15.0 25.0 20.0 30.0 40.0 50.0 60.0 70.0 Calibrated Weights 3 10.0 20.0 30.0 40.0 50.0 60.0 70.0 75.0 80.0 Financial Efficiency 4 25.0 30.0 35.0 35.0 40.0 45.0 40.0 45.0 50.0 Measures Scenario 5% 50% 95% 5 30.0 40.0 50.0 30.0 40.0 50.0 75.0 85.0 95.0 1. Re-use of Hardware 1 5.2 21.2 58.5 Components 6 60.0 70.0 80.0 60.0 70.0 80.0 70.0 85.0 90.0 2 12.8 34.7 71.2 7 30.0 40.0 50.0 50.0 60.0 75.0 70.0 80.0 90.0 3 13.3 53.8 84.3 8 0.0 2.5 5.0 15.0 20.0 25.0 25.0 37.5 50.0 2. Re-use of Software 1 3.1 22.0 47.5 Components 9 30.0 50.0 60.0 40.0 65.0 75.0 75.0 80.0 90.0 2 13.1 34.6 67.8 35.0 50.0 10 10.0 15.0 20.0 10.0 20.0 30.0 20.0 3 18.1 49.2 82.8 60.0 70.0 11 30.0 40.0 50.0 40.0 50.0 60.0 50.0 3. Re-use of Methods 1 4.9 20.0 45.3 70.0 80.0 12 30.0 40.0 50.0 50.0 60.0 70.0 60.0 2 5.2 36.5 72.1 15.0 20.0 13 0.0 5.0 10.0 5.0 10.0 15.0 10.0 3 12.5 50.2 86.4 15.0 25.0 14 0.0 5.0 10.0 5.0 15.0 25.0 5.0 4. Reduced Time-to- 1 1.1 13.6 46.8 15 0.0 20.0 40.0 0.0 20.0 40.0 0.0 20.0 40.0 Delivery 2 8.8 27.6 71.2 16 20.0 30.0 40.0 30.0 40.0 60.0 30.0 40.0 60.0 3 11.7 39.4 85.6 Combined 5. More Efficient 1 0.8 12.1 47.4 Equal 1.4 26.7 69.6 7.3 40.0 73.5 10.3 Program Management Weights 58.1 89.2 2 3.4 23.1 72.6 Calibrated 0.8 20.5 49.9 11.2 38.2 71.0 14.7 Weights 46.9 86.8 3 3.9 33.1 85.6 6. Reduced Support 1 1.1 11.6 56.8 Costs 2 9.0 23.2 57.6

Calibrated Weights enterprise architectures. The federation method employed within this research incorporates concepts 3 13.8 32.7 85.6 from the Federal Enterprise Architecture, GIG 7. Lower Acquisition 1 0.6 9.8 55.2 Architecture Federation Strategy, Enterprise Architecture Costs TM 2 6.3 23.8 56.9 Cube , and the ISO Model of Architecture for Open Systems Interconnection (OSI). As reference models are 3 10.5 36.4 85.5 used across agencies to federate their enterprise 8. Technical Adaptability 1 1.1 13.0 56.9 architectures, case studies should become available in the future to validate the expected benefits of using 2 6.7 36.3 66.5 reference models. 3 7.4 51.5 84.2 ABOUT THE AUTHORS Business Effectiveness Measures Scenario 5% 50% 95% Jeff Wilson ([email protected]) is a doctoral candidate in Systems Engineering at the George Washington 1. Tighter Alignment to 1 0.8 20.5 49.9 Business Strategy University within the School of Engineering and Applied 2 11.2 38.2 71.0 Science. He received an MS in Electrical Engineering 3 14.7 46.9 86.8 from the Air Force Institute of Technology and a BS in Electrical Engineering from the US Air Force Academy. 2. Architecture Process 1 0.8 18.8 42.2 This article is based on his dissertation research. Stream of Logic 2 12.4 31.2 58.7 Dr. Thomas Mazzuchi ([email protected]) is a professor 3 18.4 50.0 80.2 of Engineering Management and Operations Research 3. Knowledge 1 3.6 17.8 75.8 at the George Washington University. Dr. Mazzuchi Development holds a DSc from the George Washington University as 2 11.3 35.7 79.4 well. His research interests include reliability and risk 3 13.1 42.0 91.5 analysis, Bayesian inference, quality control, stochastic models of operations research, and time series analysis. 4. More Sophisticated 1 3.1 20.8 42.9 Asset Management Dr. Shahram Sarkani ([email protected]) joined the 2 9.0 36.1 65.9 faculty of the School of Engineering and Applied Science 3 9.4 43.0 86.4 of the George Washington University in 1986 after 5. Reduced Decision 1 3.1 25.8 73.1 earning his PhD from Rice University. Since 2001, he Risks has served as faculty advisor for Off-Campus Programs 2 6.2 38.9 74.2 in the Department of Engineering Management and 3 7.5 54.2 85.8 Systems Engineering. 6. Tighter Strategic 1 0.8 18.1 42.4 REFERENCES Alignment With Partners 2 15.3 42.0 64.9 Bernard S.A.: An Introduction to Enterprise Architecture, 3 20.1 58.2 86.4 Second Edition, Author House, Bloomington, IN (2005). 7. Business Adaptability 1 4.2 26.4 55.9 Cooke R.M.: Experts in Uncertainty: Opinion and Subjective 2 15.3 40.3 65.4 Probability in Science, Oxford University Press, New York (1991). 3 20.1 55.8 85.9 Cooke R.M., Goossens L.J.H.: Procedures Guide for CONCLUSIONS AND RECOMMENDATIONS FOR Structured Expert Judgment, Nuclear Science and Technology, FUTURE STUDY Delft University of Technology: Delft, Netherlands (1999). Reference models were found in this research to DoD: Global Information Grid (GIG) Architecture Federation increase effectiveness and efficiencies in federating Strategy, Arlington: US Department of Defense (2007). enterprise architectures across multiple agencies. Fischer R., Aier S., Winter R.: A Federated Approach to Quantitative measures using the classical method of Enterprise Architecture Model Maintenance (2007); refer to: expert judgment were used to evaluate the reference ben.iwi.unisg.ch/fileadmin/if/downloads/Artikel/2007/ models’ expected effect on the ability of agencies to Fischer.Aier.Winter.EA-Maintenance.2007.pdf. federate with other agencies and programs. Gehris R.: A Simulation Study of the Classical Method of Unique in this research is adaptation of the classical Expert Judgment Combination: How Many Seeds and How method for expert judgment to the quantification of Many Experts?, DSc Dissertation, The George Washington expected benefits of reference models in federating University (2008).

48 © Journal of Enterprise Architecture – May 2011

GAO: Information Technology: Leadership Remains Key to OMB: FEA Practice Guidance, US Office of Management and Agencies Making Progress on Enterprise Architecture Efforts, Budget (2007b). US General Accounting Office (2003). OMB: The FY 2008 Performance Report of the Federal GAO: Information Technology: The Federal Enterprise Government, US Office of Management and Budget (2009). Architecture and Agencies’ Enterprise Architectures are Still Maturing, US General Accounting Office (2004). Rechtin E.: Systems Architecting of Organizations: Why Eagles Can't Swim, CRC Press, Boca Raton (2000). Jain R., Chandrasekaran A., Elias G., Cloutier R.: Exploring the Impact of Systems Architecture and Systems Requirements on Ross J.W., Weill P., Robertson D.C.: Enterprise Architecture as Systems Integration Complexity, IEEE Systems Journal, Vol. 2, Strategy: Creating a Foundation for Business Execution, No. 2, pp209-223 (2008). Harvard Business School Press, Boston (2006).

Lamis J.: The 2008 A&G Reader Survey: The Rise of Strategic Ryan J.C.H., Mazzuchi T.A., Ryan D.J., Lopez de la Cruz J., IT Planning and Executive Involvement, Architecture & Cooke R.: Quantifying Information Security Risks using Expert Governance (2008); refer to: Judgment Elicitation, Accepted, Article in Press, Computers & www.architectureandgovernance.com/articles. Operations Research (2011).

Lankhors, M.M. (Ed): Enterprise Architecture at Work: Winter R., Fischer R., Essential Layers, Artifacts, and Modelling, Communication, and Analysis, Springer, Berlin Dependencies of Enterprise Architecture, Enterprise (2005). Distributed Object Computing Conference Workshops, EDOCW '06, 10th IEEE International (2006). Maier M.W., Rechtin E.: The Art of Systems Architecting, Third Edition, CRC Press, Taylor & Francis Group, Boca Raton Wu R., Lin F., Yuan S., Liang K.: A Reference Model and (2009). Integration Framework for Building Enterprise Computing Platform, International Journal of Technology Management, Mazzuchi T.A., Linzey W.G., Bruning A.: A Paired Comparison Vol. 38, No. 4, pp439-462 (2007). Experiment for Gathering Expert Judgment for an Aircraft Wiring Risk Assessment, Reliability Engineering & System Zachman J.A.: A Framework for Information Systems Safety, Vol. 93, No. 5, pp722-731 (2008). Architecture, IBM Systems Journal, Vol. 26, No. 3, pp276-292 (1987). Morganwalp J.M., Sage A.P.: Enterprise Architecture Measures of Effectiveness, International Journal of Technology Zimmermann H.: OSI Reference Model – The ISO Model of Policy and Management, Vol. 4, No. 1, pp81-94 (2004). Architecture for Open Systems Interconnection, IEEE Transactions on Communications, Vol. 28, No. 4, pp425-432 Morganwalp J.M.: A System of Systems-Focused Enterprise (1980). Architectural Framework, PhD Dissertation, George Mason University (2002).

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

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.

you likely to find? How can you avoid them? What tools INTRODUCTION and methods can you use? How do you communicate Over the last ten years, enterprise architecture has with the business, and what could you communicate to received significant attention by researchers and the business, to ensure that they are onside for the practitioners. According to a study by the Institute for duration? Enterprise Architecture Developments (IFEAD), 66% of Starting, first, with Zachman’s definition, ―A the respondents consider enterprise architecture as an representation of the functioning enterprise‖ (Zachman important element of their strategic governance 2003), we see that whether it is apparent of not, any processes (Schekkerman 2005). Another study functioning enterprise possesses, if not an architecture, conducted in 2006 among Swiss and German some kind of functional structure. Thus, initially the companies reveals that 38 from 51 interviewed challenge of the enterprise architect in a functioning companies are either currently implementing enterprise enterprise is to uncover this structure and represent it in architecture models, or are already using enterprise a manner that stakeholders can comprehend. Since the architecture models (Bucher et al 2006). This focus has final aim of enterprise architecture is to shift the resulted in significant, but very diverse, efforts from organization from the ―as-is‖ state to some desired ―to- individuals (e.g., Zachman), industry bodies (e.g., The be‖ state (Fischer et al 2007) it is necessary to capture Open Group), Governments, and allied entities (US and maintain architectural artifacts of the enterprise to Federal Government, US Department of Defense), while express and represent these states. However, the task most major IT consulting companies have developed of accurately describing an enterprise and the way it enterprise architecture practices and methodologies. works is a very complex, difficult undertaking (see, for However, despite how much has been written on example, Mintzberg (1979)). enterprise architecture during this period, there is very Indeed, given the sheer size, complexity, and dynamic little help for the enterprise architecture professional on nature of modern organizations—―during the architecture what constitutes, and how to run, a successful enterprise development process uncertainty and incomplete architecture project. The existing literature is full of what knowledge are crucial‖ (Saha 2004, p4)—it may even be passes for practical advice—―understand the limitations‖, argued to be unfeasible. Hence, it is not surprising that ―identify bottlenecks‖, ―good communication with the enterprise architects experience significant confusion, business‖—but they provide scant guidance on the and that the adoption rate of enterprise architecture and practicalities of implementing their advice. If you are an its reported benefits do not appear to be uniformly enterprise architect faced with the prospect of doing promising (Infosys 2007; Lapkin 2009a). It is often too enterprise architecture, how do you actually go about easy for the enterprise architecture project team to get running an enterprise architecture project? How do you caught in producing enterprise representations, and set the scope? Where do you start? What problems are

50 © Journal of Enterprise Architecture – May 2011

forget that their real aim is to produce and demonstrate application and data duplication, process tangible benefits for the business. But if documenting the complexity, and inefficiency […] inhibiting organization in ―excruciating level of detail‖ as espoused flexibility, agility, and innovation‖. by Zachman (Zachman 2003) is not practical, what is the  EA Light: Carried out in six weeks by a team of extent and depth appropriate for enterprise architecture? two external consultants, for an Australian The answer lies in that not all enterprise architecture financial services group, to build on existing projects have the same drivers and goals. We believe business-as-usual via initiatives aligned with the that it is counterproductive to spend an inordinate strategic goals of the business. The main amount of effort creating and maintaining enterprise requirement was to build a chain of evidence descriptions that do not serve a direct business purpose. connecting actions back to business drivers to Also, it is often said that enterprise architecture is align the IT project portfolio with the concerned with enterprise evolution, and this is usually organization’s overall business strategy. taken to indicate that enterprise architecture efforts are These examples are documented here for the purpose always focused on a major enterprise transformation. of our analysis. They are not a complete, detailed Some comprehensive approaches—e.g., TOGAF account of the two assignments. (TOGAF 2009)—may implicitly reinforce this mindset. We argue, however, that this is not necessarily so; THE “EA HEAVY” PROJECT instead we agree with Doucet et al that enterprise The enterprise architecture engagement was initiated by architecture encompasses any approach, large or small, the IT division, by a direct report of the CIO. The IT to promote coherence into the current management stakeholders engaged a team of external consultants to practice of the enterprise (Doucet et al 2009). Hence, carry out a collaborative enterprise architecture exercise, our ―purpose test‖: with the engagement encompassing the entire group. 1. The raison d’être for enterprise architecture must The assignment was performed over a period of stem from, and be kept aligned to, a business approximately six months by a team of ten full-time staff. purpose. Figure 1 shows the sequence of steps for the EA Heavy 2. The level and detail of the enterprise project. The left-hand side shows the initial phase of the descriptions must be tailored to be sufficient for process, including the development of the current its intended purpose. logical, conceptual, and physical models. The American To support our statements, this article compares and Productivity & Quality Center (APQC) process contrasts two very different, successful enterprise framework was used as the basis for the classification of architecture exercises carried out by the authors as business processes necessary to support the logical external consultants to two Australian-based model. APQC is a taxonomy of business processes that multinationals: makes possible analysis of organizational performance within an organization and between organizations. The  EA Heavy: An engagement for an FMCG (Fast taxonomy is organized into 12 categories of business Moving Consumer Goods) company processes, comprising five categories of operating headquartered in Australia. The enterprise processes, and seven of support processes (shown in architecture engagement was initiated by a direct Figure 2). Each category contains processes report of the CIO and performed over a period of representing the operations of a single business function approximately six months by a team of ten staff within the organization, providing organizations with a working full time. Initially, the purpose was framework for benchmarking each function, and articulated as: ―The current architecture evolved monitoring its improvement. through several years of acquisitions and business unit integrations […] The result has been an extremely complex landscape with

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)

52 © Journal of Enterprise Architecture – May 2011

Figure 3 shows a sample APQC framework customized A broad range of stakeholders were involved along the at the process group level, developed for the process, to ensure their understanding of, and support engagement. The figure shows a partially populated of, the project, including the review and acceptance as model with logical information system components—i.e., the final step of the enterprise architecture exercise collections of related business services—provisioning before initiating the program of work. 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 Figure 3: Customized APQC Framework be?), as shown in Figure 4. It can be seen from the figure that the logical to physical mapping for current and Table 1 shows our three-step approach, also depicted in target provided very significant opportunities for Figure 1: a) initial work by the enterprise architecture rationalization (from 14 to one as shown). team; b) a facilitated event; c) first cut of the initiatives. The table classifies and summarizes the activities, their This information was fed into a main collaborative event features, and their outcomes. involving the stakeholders and facilitated by the enterprise architecture team.

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 EA context document objectives.

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

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

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

Facilitated Event 1. Validate  Current physical architecture is validated Validated current physical Major analytical inputs  Current state analysis is presented and model. activity: facilitated implications (especially of the ―do nothing‖ option) by external are communicated consultants, where key 2. Develop Target state developed: Target physical model for business and IT target physical  Duplicate physical solutions rationalized to do via a enterprise architecture work co- model single application operatively with  Use of existing (underutilized) solutions expanded the enterprise  Point solutions retired architecture Bespoke or heavily customized solutions in non- project team. differentiating areas such as Finance & HR retired. Customized APQC. 3. Develop initial Develop first cut roadmap in terms of a list of initiatives, Roadmap initiatives; high- transformation their precedence relationships, and order of level costings roadmap implementation.

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

Package and present results Appropriate packages of the deliverables produced, Enterprise architecture tailored to the target audiences. documentation for the enterprise architecture team/division Executive/management/staff presentation Enterprise architecture models in the tool

54 © Journal of Enterprise Architecture – May 2011

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)

Key Features Outcome

Develop high-level business At a high level, identify the business services and how they BSA for the three businesses of services architecture (BSA) interact. Big picture view of how the business operates. the group in scope for this study 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.

Classify business services (heat Business services classified based on business value into Heat map of business services in map) four categories, from less to most important: BSA  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.

Develop strategy map A strategy map comprises: A partially complete strategy map  Business drivers: Overall business drivers for the containing: organization (from business strategy)  Business drivers  Customer view: How the IT department would show  Supporting customer view the business (its customer) that IT is moving toward  Supporting internal view 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

Key Features Outcome 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 Scenarios developed to exercise the BSA: A set of BAU and stretch business services  Business as usual (BAU) scenarios – exercising key scenarios 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.

Collate summary information on  List of existing initiatives List of existing initiatives IT estate and existing initiatives  Use a lightweight survey to gather information on the Summary information on existing existing IT estate IT estate  Intention: use for reference purposes at the facilitated event

Facilitated Event 1. Validate Validate the inputs: Validated inputs An event, strategy map,  Strategy map facilitated by BSA, heat  Business services architecture map external  Heat map consultants, where key 2. Exercise In groups, walk through each scenario, exercising the business and IT the scenarios relevant business services and understanding the represent-atives to determine consequences. Explore how you would change the IT work co- initiatives estate to support different scenarios where additional IT operatively to support is needed, or where IT needs to be changed. produce the When the IT estate is found deficient or wanting, a new outputs. initiative is created to rectify the problem.

3. Classify A first-cut road-map in terms of a list of initiatives (costed Set of initiatives and prioritize at a high level), their precedence relationships, and order the initiatives of implementation is developed out of this exercise. to identify a three-year program

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

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 enterprise, and they are currently implementing the event, was refined along with the costs and benefits. The program. prioritized set of initiatives to move today’s enterprise to THE “EA LIGHT” PROJECT the rationalized state—including a five-year transformation program—was accepted by the 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  A ―just-enough‖ decomposition of a Business review its established program of work. The challenge Services Architecture was developed, with a was to find a method that would build on existing maximum decomposition to Level 3. business-as-usual and top-line initiatives to align with the  A Heat Map, a classification of business services new strategic goals, and build a chain of evidence according to their value, was produced. connecting actions back to business drivers. All this within a very short period of time to provide a tangible STRATEGY MAPS output that could be presented to the business The strategy map was based on the work of Kaplan and executives. Norton (Kaplan & Norton 2004), which we customized The external consultants undertook the assignment, and for IT purposes. Our map components are summarized (with assistance from IT and business stakeholders) in Table 3. delivered the required outcomes within a period of six In our conception of the strategy map for enterprise weeks. Figure 5 shows the main activities undertaken, architecture, the business is the customer of the IT and the relationships between them. The same three- department. The overall business drivers, part of the step pattern of (1) initial work; (2) facilitated event and business strategy, sit at the top of the map. Underneath, review; and (3) acceptance is shown in Figure 5 and the Customer View expresses how the IT department Table 2. The table shows the different activities will demonstrate to the business that they are moving to undertaken, their key features, and their outcomes. achieve these objectives. The Internal View is related to Several strategies and tools were used for this exercise, how the IT department will deliver the Customer View. as inputs to a facilitated event. These are discussed Finally, the Initiatives lists the concrete actions that IT further in the following sections: will undertake to execute the Internal View. Figure 6  Strategy Maps were used to establish direct links shows our strategy map for two of the enterprise between the business drivers and the actions that business drivers. IT should carry out to deliver the goals.

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 Shows the ―Customer View‖ for the two business business that the IT estate are moving toward the drivers company’s strategic business goals

Internal View How the IT department would organize itself to deliver Shows the ―Internal View‖ for the Customer View the Customer View components

Initiatives List the concrete actions that IT will undertake to Shows the initiatives to realize the ―higher‖ components execute on the strategies in the Internal View of the strategy map

Using a strategy map in this way it was possible to Figure 7 shows the decomposition of the funds establish a direct link between the strategic business management business. Following our premise of drivers and the initiatives that will form part of the ―producing just enough‖, Level 3 decomposition was program of work for the transformation. sufficient for the purposes of our exercise. The first indicates the process, while the second shows the THE BUSINESS SERVICES ARCHITECTURE (BSA) hierarchy of the business services. Our Business Services Architecture (BSA) representation follows and extends the work of Jones PRIORITIZING IT INVESTMENTS: HEAT MAP (Jones 2006). The business services represent what the There are several frameworks that can be used to business does and delivers, and what is required to prioritize investment in the IT estate, such as the one in meet business goals. Where an application represents illustrated in Figure 8 (adapted from Jones (op cit)). A large areas of functionality across the business, the BSA four-quadrant classification is used here, stating worked with the business to align our understanding of Business Value and Business Impact. Investments the IT estate with the business activities it is intended to priorities, from highest to lowest, are: (1) market support. As such, it may become a clear language of differentiation; (2) return on investment; (3) cost communication between the business and IT. 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, support the different scenarios, and where additional IT showing in different colours the priority of investments support or changes may be needed. When the IT estate according to the framework. As the first activity, these is found deficient, a new initiative should be created to three input elements, Strategy Map, Business Services rectify the problem. A sample of the scenarios used in Architecture, and Heat Map were validated during the the facilitated event is shown in Figure 10. facilitated event described in Table 2. As shown in Table 2 and Figure 5, the prioritized list of After validation of the three inputs above, the facilitated initiatives developed at the facilitated event was event walked through Business as Usual (BAU) and subsequently refined. This list was accepted by the ―stretch‖ scenarios exercising the relevant business enterprise, and they are currently implementing the services. This explores how the IT estate is able to program.

Figure 8: Business Value Classification (EA Light)

Figure 9: Heat Map (EA Light)

Figure 10: Scenarios (EA Light)

DISCUSSION: LESSONS LEARNED The terms of reference of the EA Heavy were expressed in terms of the gains via rationalization: ―reduce We argued previously for a ―purpose test‖ with two-fold complexity, improve flexibility and interoperability, criteria: improve service levels, and lower the cost to serve.‖ The 1. The raison d’être for enterprise architecture challenge with EA Heavy was to: must stem from, and be kept aligned to, a  Produce evidence in support of the terms of business purpose. reference; i.e., to show the cost to the business 2. The level and detail of the enterprise of the current, very complex IT estate. descriptions must be tailored to be sufficient for  Properly communicate the message to develop its intended purpose. a common understanding of the problem and The two case studies, involving two starkly different generate momentum for solving it. levels of detail, clearly illustrate the purpose test. This was done through the current state assessment, which depicted the problem clearly and unambiguously Lesson 1: Understand the business purpose and then by communicating this to stakeholders both The purpose of the EA Light exercise was alignment, of formally and informally (see below). IT with the strategic goals of the business. The purpose was clear and well understood by the consultants and IT Lesson 2: Understand and deliver what business and IT stakeholders actually want stakeholders. The challenge here was to move IT away from its technical comfort zone and into thinking of In both cases, the ultimate purpose was to identify a set alignment in terms of answers to business objectives of initiatives according to the purpose of each exercise. and problems. The mechanisms used to achieve this In EA Heavy, the initiatives would serve to align the IT included the strategy map, which presented a very clear division more closely with the strategic drivers of the traceability mechanism to the business objectives, and business; in EA Light the initiatives would rationalize and the scenarios that were exercised during the facilitated simplify the IT estate, yielding significant savings in event, which were business scenarios that required an operational expenditure. The approaches and the interim IT response (see also ―Lesson 5‖). 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 pressed the rationalization message home to IT and initiatives. The final form of the target IT estate was of business executives, using the savings dollar figures very little interest to the senior business and IT effectively to solidify support, acceptance, and stakeholders, as opposed to the benefits that the enthusiasm for a critical, significant transformation initiatives would bring: better alignment with business program with an estimated cost well in excess of $100M drivers in EA Light; savings through rationalization in EA over five years. Heavy. In both engagements, the enterprise architecture teams were keenly fixed on this goal, and avoided being Lesson 4: Tailor effort to the intended purpose and seduced by producing artifacts along the way, unless management expectations they directly served a business purpose. To summarize, stakeholders need the following: The two projects show a wide variation of effort:  Where the problem is not clear or commonly  The EA Light exercise was carried out in six understood: present the problem and the do- weeks by a team of two external consultants. nothing consequences articulated in clear,  EA Heavy was a far more substantial affair, business (preferably dollar) terms. involving the entire group of the multi-national;  Establish a set of initiatives to achieve the goal/s performed over a period of approximately six (whether it is better alignment, cost optimization, months by a team of ten staff—internal staff plus etc.), and the benefits, also preferably expressed external consultants—working full time. in dollar terms (see ―Lesson 3‖ below). Our measure of success is that the output was not only This is a lesson that enterprise architecture practitioners accepted, but it has been used to initiate programs of should not miss. There are many examples of enterprise work. Therefore, both in scoping and designing an architecture failures in which producing glossy diagrams engagement, as well as in responding to an established of the target state ends up becoming the goal. This scope definition, it is imperative to understand the typically leaves business stakeholders cold; indeed, we purpose and tailor the effort and the output to argue that the technical artifacts of enterprise stakeholder expectations and no more, to avoid the architecture, in themselves, do no generate enthusiasm enterprise architecture exercise losing momentum and or support for the change initiatives that may be support along the way. recommended. With the engagement in progress, the enterprise architecture team constantly communicated that they Lesson 3: Communicate benefits in business terms were delivering value for money by: (a) constantly reporting progress to stakeholders, including the Management is understandably averse to releasing percentage task completion of project management, and funds where the business benefit cannot be clearly what was being uncovered; (b) establishing credibility by perceived: so always couch the benefits in business ―brown bag‖ sessions on affiliated subjects; (c) most terms. We agree with Lapkin: ―Define a value proposition importantly, by facilitated events engaging stakeholders specific to the enterprise, and articulate it in business as active participants in key decisions. terms‖ (Lapkin 2009a p12), and Strassman: ―Computer investments must show as enhancements to a business Lesson 5: Leverage the richness of the potential plan‖ (Strassman 1997 p3). A benefit originating in IT enterprise architecture space should be couched in business terms, as clearly demonstrated by EA Heavy, where the team’s brief was There was a significant difference in starting confined to rationalization. assumptions for the two approaches. EA Heavy The team worked with the business to streamline operated under terms of reference that channelled the provisioning of the business services via a rationalized project towards delivering a rationalized IT estate. set of application functions and supporting infrastructure. Consequently, it was not possible to explore other However, any significant efficiency gain—as in this case solution spaces, such as how IT can support strategic rationalization of a key set of business services from 14 business intentions. In the event though, we were able to different applications to one, or consolidating the server show very considerable financial gains through infrastructure—having a positive bearing on rationalization that, as described above, fuelled a large CAPEX/OPEX (Capital Expenditure/Operational transformation program. Expenditure) is of interest to the highest echelons of the EA Light, on the other hand, did not start with any such enterprise. By couching these in the right terms, in EA assumptions. This enabled the team to explore a richer Heavy the extent of duplication and the current costs solution space, including BPO (Business Process became clear, as did the very significant rationalization Outsourcing) and SaaS (Software as a Service), to be opportunities and the gains these would bring. The team able to deliver a more complete set of solutions—which

may or may not involve technology installations—to the Work together with, and deliver to, the business: business challenges presented. Two slightly different  Always involve stakeholders in the process points should be highlighted here:  Communicate the benefits in business terms, and  IT staff must be cognizant of non-IT aspects in clearly articulate the consequences of doing enterprise architecture. The natural inclination of nothing, as the business will invest in a new IT IT staff and management is to think of an function only if this clearly provides more benefits enterprise architecture roadmap primarily in than the status quo terms of IT application or infrastructure change. However, changes to the business architecture  Produce a prioritized list of IT initiatives directly will be necessary for the enterprise to change linked to enterprise drivers and business position within the business landscape. We were outcomes cognizant of EA Light’s terms of reference as the  Use the priority list above to produce the IT division’s response to the business strategy. transformation program However, recognizing the natural bias amongst IT staff and management, an explicit attempt was ABOUT THE AUTHORS made to step outside their familiar concerns. Inji Wijegunaratne is an IT consultant with over 25 years  A holistic approach makes it possible to explore a of IT experience, in the past 12 years focusing on wider solution space and possibly develop a enterprise architecture and IT architecture leadership. more appropriate—higher value—solution for the He has occupied IT architecture management positions enterprise. The techniques used in EA Light were in the corporate sector, and consulting positions at tailored to explore this; for example, three Deloitte, IBM, and Capgemini. He is currently with categories were created for initiatives: Infosys Australia. Inji holds Doctoral and Master’s application, infrastructure (the traditional IT degrees in Information Systems from London University ground), plus people and process, and the and a Bachelor’s degree in Electronic Engineering from scenarios shaped to trigger discussion in this the University of Essex, UK. third area as well. Some of the ―softer‖ aspects Peter Evans-Greenwood provides business and were encapsulated in initiatives such as technology consulting to executives across a range of facilitated organizational learning, streamlining of industries. His 20 years of experience working between internal IT processes, capturing internal business and technology have seen him work across the knowledge, and succession planning. full breadth of industry, with leadership roles in global Capturing these softer aspects in current IT frameworks players such as Deutsche Post DHL, and Capgemini is a challenge. The Zachman framework offers slots— through to innovative startups, including the Australian but not techniques—in its taxonomy to include them. Artificial Intelligence Institute and Agentis. However, research is starting to recognize and try to George Fernandez is an Associate Professor at the address these aspects within the strategy. For enterprise School of Computer Science and Information architecture to become more than IT change, these non- Technology at RMIT University (Australia), currently technical aspects of the enterprise should be included teaching Enterprise Architecture and eCommerce and together with the more tangible IT and process aspects. Enterprise Systems. George has more than 30 years of This is an important area for further research. experience in Computing and Information Systems, working in academia, private industry, and government CONCLUSIONS organizations. He is an active researcher, and often These two enterprise architecture exercises deliver very presents technical seminars in academic and industry important lessons, which can be summarized as follows. forums. His research interests include Distributed Follow the principle of parsimony: Computing, Enterprise Systems, and Enterprise Integration.  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

REFERENCES Lapkin A.: Five Questions the CIO should be Asking about Enterprise Architecture, Gartner Research Report, ID Number Bucher T., Fischer R., Kurpjuweit S., Winter R.: Analysis and G00167384, 29 April (2009). Application Scenarios of Enterprise Architecture – An Exploratory Study, Proceedings, EDOC Workshop on Trends Lapkin A.: Key Issues for Enterprise Architecture, Gartner in Enterprise Architecture Research (TEAR 2006), within the Research Report ID Number G00166589, 27 March (2009). Tenth IEEE International EDOC Conference (EDOC 2006), Hong Kong (2006). Mintzberg H.: The Structuring of Organizations, Englewood Cliffs, Prentice-Hall (1979). Doucet G., Gotze J., Saha P., Bernard S.: Coherency Management – Architecting the Enterprise for Alignment, A Real Options Perspective to Enterprise Architecture as an Agility and Assurance, AuthorHouse, Bloomington, Indiana, Investment Activity, Technical Report, National University of ISBN: 978-1-4389-9606-6 (2009). Singapore (2004).

Fischer R., Aier S., Winter R.: A Federated Approach to Schekkerman J.: Trends in Enterprise Architecture 2005: How Enterprise Architecture Model Maintenance, Proceedings of are Organizations Progressing?, Institute for Enterprise the 2nd International Workshop on Enterprise Modeling and Architecture Developments, Amersfoort (2005). Information Systems Architectures (EMISA 2007), St. Goar, Strassman P.: The Squandered Computer, The Information Germany October 8-9, (2007). Economic Press, New Canaan, Connecticut, (1997). Aziz S., Obits T.: Enterprise Architecture is Maturing, Infosys The Open Group: TOGAF Version 9 "Enterprise Edition"; refer Enterprise Architecture Report, October (2007); refer to: to: www.opengroup.org/togaf. www.infosys.com/offerings/IT-services/architecture- services/ea-survey/Documents/ea-maturing.pdf. Zachman Framework (2003); refer to: www.intervista- institute.com/articles/zachman-by-kull.php. 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).

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” The particular project focuses on its own goals (that does not include things like re-use, coherence, When working on architecture and IT in general the consistency, and other enterprise-level interests) and phrase ―the business‖ is used very often. cannot be bothered by taking future generations or other Some examples: projects into account. If you are lucky you get the promise: maybe next time or in the next release.  ―Our architecture principles support the business vision …‖ Also, when designing the user interface the information quality takes second stage compared to ease-of-use for  ―We will align with the business strategy …‖ ―the business‖ users consulted. It seems the scope of  ―IT should be a business enabler …‖ the project and the overall architecture of the IT  ―The business wants a single customer view …‖ landscape has been taken into account in any statement by business representatives. The normal pattern in  ―The business needs this application in projects is a narrowing scope from enterprise via project production in three months time …‖ to end user. Ultimately it is the users performing the  ―The business wants to reduce the number of acceptance test that have to be satisfied. screens in this application …‖ For IT, it is easiest to behave as if there is indeed one  ―For this project the business cannot afford to business entity speaking with a single tongue. take architecture into account, we will focus on All-in-all, the result is the fragmented IT landscape that time and budget, maybe next time we fix the many find normal and take as a fact of life. Even when architecture …‖ the enterprise architecture function has been introduced  … and is fully functional, often its effect on the IT landscape is very limited. It is assumed that all these statements are made by the same entity: ―the business‖. When statements by ―the The explanation is simple: ―the business‖ does not exist. business‖ seem to contradict earlier statements by ―the THE THREE FACES OF “THE BUSINESS” business‖ we think this is a matter of progressive deeper understanding, that the pros and cons have been The diagram below shows a pattern that exists in many weighed and that more recent statements by ―the organizations. Three separate faces of ―the business‖ business‖ overrule earlier statements. can be recognized. 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.

budget through what is perceived as extra work or extra management complexity introduced by 1 Enterprise enterprise architects. Re-use often complicates Top Architecture Management project management as other parties will need to be Project Principals involved. Also developing components positioned for $ „Win‟ re-use requires extra attention to develop and

2 Project Management manage. Coherence often means applying Project Principals information and technology standards that may

System Users again require extra attention. Project managers and $ „Win‟ project principals, therefore, strongly prefer autonomous single solutions. Following enterprise 3 Development Teams System Users 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 Operations agility the enterprise architecture input is often wasted. Top management as well as project Figure 9: The Three Faces of “the Business” principals and project managers do not see 1. Top Management: Top management recognizes the enterprise architects representing top management importance of enterprise architecture as a way to (= enterprise-level) interests. They are seen as ―bad increase coherence and agility, reduce complexity, news‖; notorious worrywarts obstructing progress, and thus reap the associated financial effects. The and spoiling the fun in general. enterprise architecture role is introduced together 3. System Users: Ultimately, it is business system with procedures on how to interact with the users that accept the system. They provide the development process and what artifacts will be detailed input for the system design and perform the produced. Typically, the enterprise architects business acceptance testing before the new system formulate reference architectures describing the can be put in production. Their main worry is their principles to use during development to ensure the colleagues who will protest if their position or comfort strategy of the organization is supported in a is compromised. Their life must be made easier with coherent and agile way. To limit the design space for the new system. Projects making life harder for the individual projects they typically produce Project system users are therefore hard to implement Start Architectures (PSAs). although there may exist a very attractive business

case with strategic goals. On the other hand, Top management discusses business initiatives, projects that make life very much easier for end budget, and timelines with their business users are also difficult, as they form a threat for the subordinates. They receive regular reports on end-user community as a whole – layoffs may be progress in these terms and manage any deviations around the corner. ―The business‖ project principal from the planned activities and spent. also focuses on these aspects: the users must use

the system no matter what. The result is that the As architecture is in place there is no need for top project is within budget, on time, and with happy management to put coherence and agility on the users. What more can you want? Well, quite a lot agenda for discussion with their business actually! This way of working has led us to the subordinates. fragmented IT landscapes that are commonly found. 2. Project Principals: Individual projects are launched This pattern is presented here in black and white to based on specific business cases. Often annual clearly show its nature. Of course, in practice many gray budgets have already been assigned to tones may be recognized. This pattern gives an organizational units based on historic information explanation why so many enterprise architecture and expected developments. Project principals initiatives have little effect on the IT landscape. It provide input for project managers to plan and remains as fragmented, costly, and hard to change as execute the project. Business analysts provide before. It frequently even gets worse. detailed business input where required. They report progress to top management in terms of time and The pattern does provide insight into where essential money. In some cases project analysts review the changes need to be done to make enterprise input from the enterprise architects. They apply the architecture successful. Not as a goal in itself, but to input where it does not endanger the timelines and improve the situation and move in the direction of the

coherent, cost-effective, and agile environment an landscape shows the full history of IT decisions made organization needs to thrive. through the years – the good decisions and the bad In the ideal world ―the business‖ would exist. ―The ones. business‖ really would speak with one tongue. Managers In short, IT is a special case as its history is dragged would make sure that their subordinates do the along, where in other subject areas older mistakes are important things in line with their goals and explicitly easily replaced with new ones. translated into subordinate goals. This is ultimately The phenomenon described here is part of a bigger reflected in the appraisals for the individuals involved picture with ―enterprise governance‖ and ―IT and the associated bonuses. governance‖. It is just that IT as a business area of WHY IS IT DIFFERENT? interest seems to be especially sensitive for the reasons sketched above. Compared to other areas in an organization IT is often perceived as a special case where raising cost and Much has been written on enterprise and IT governance. increasing complexity is unavoidable. Still, there is no Many approaches focus on the structural side of things reason to think IT is generally managed with a lower and describe frameworks, decision rights, processes, quality than other parts of the enterprise. It is safe to and all kinds of boards. They seem to suggest that as assume that generally management quality is the same soon as the decision-making framework has been across the board. But, ultimately, it is top management implemented the desired IT developments will follow that is responsible for any aspect of the organization automatically. This has been noted before (Hoogervorst including its IT department. IT and IT personnel are not 2007). We agree and are convinced that the focus things that are forced upon an organization. The should not be on structure but on content. The content organization is the master of its own destiny. You might part is what it is all about; it must be determined what the say to top management: ―You are caught in a prison of desired IT developments are together with explicit your own devise‖ (Jim Morrison & The Doors 1968) actions that need to be done. when they are complaining about IT. The remainder of this article will focus on this content Simply put, any organization gets the IT it deserves. Just and practical ways of how to go about achieving it. Not in like it gets the personnel it deserves, the logistics it any exhaustive way though; the main goal is to create a deserves, the customers it deserves, the manufacturing new mindset for enterprise architects. capability it deserves, the profit it deserves, and so on. There are some specific things we can do. It all starts In these cases it is self-evident that management must with awareness, first as an enterprise architect, second ensure that the organization does the right things at the as business decision-makers on IT subjects. But first we right time in the right way. Only in IT the department is will describe how to survive as an enterprise architect in blamed instead of top management: a fragmented business world. ―… IT makes things too complicated …‖ ENTERPRISE ARCHITECTURE IN A FRAGMENTED ―… IT does not speak the same language …‖ BUSINESS WORLD ―… IT hinders progress, they are anything but agile …‖ ―… IT architects must sell their ideas better to projects …‖ Given a three-faced business situation, enterprise architecture still can work on improving the situation and But, of course is it up to top management to hire the right making sure that the different business interests are met people and ensure that the right things happen. in a balanced way. When there is a conflict of interests The following quote illustrates the issue very well: this must be discussed in an open and transparent way. ―If we buy a bicycle to improve our personal transport, can we Very often this is not done and the solution is left to blame the bicycle when the situation does not improve if we chance. Many architects working in an organization for a just walk next to it?‖ (Jan Hoogervorst presentation) long time and wanting to survive have found a way to The thing that really makes IT different is the fact that handle this. Often by ducking and reacting on the most earlier IT decisions are not as easily undone as most recent instruction of ―the business‖, no matter which of non-IT decisions. the three flavors of business is providing this instruction. Others get frustrated and leave the organization for For example, changing an organization structure can be better pastures. Of course it is the responsibility of ―the done relatively easily without any traces of the earlier business‖ to speak with one tongue, and when they don’t structure. Bad selling products are replaced by products it is not IT that is to blame. Ducking is a way to survive that do sell. Bad forklifts are replaced by better ones, and avoid getting seen as a Don Quixote fighting etc. In IT, bad decisions are often not erased. Instead windmills that are unseen by business. Others accept the IT landscape is extended with new solutions with the this label and struggle on until they retire. The existing solutions firmly remaining in place. Often the IT professional way is for an architect to recognize the

limited maturity of the organization and find ways to Still this pattern can be broken when business make it slowly move towards the next level. A good introduces discussions on non-functional aspects of IT relation with top management, the level above the solutions, with aspects like agility, information quality, project principals, is crucial to make any progress. and efficiency. Maybe at some point top management will start making The solution is of course for top management to demands on their business subordinates in other terms determine the right goals and indicators and manage the than projects, time, and money. When that happens you organization as an integrated whole accordingly; may see the light at the end of the tunnel. Even then this business-to-business alignment. The power is and may prove to be fragile and depending on local heroes should be in the line organization and changes need to instead of a firm engrained phenomenon. be applied to make enterprise architecture deliver on its TOWARDS A SINGLE BUSINESS promises. Probably this involves more than ―just‖ architecture and is part of improving maturity in a broad Again, we will not try to find the general solution, but find sense. A single business face is seen as a prerequisite a few simple ideas that may improve the situation and for mature IT. may trigger further growth. This big missing thing at the business side of the equation is content. In general We do not suggest in any way for management to micro- business management is well aware of what is wrong manage IT in a top-down fashion. Strategy remains with their IT. But have a simplified view of the world that something for the top; the operational translation in is reinforced by IT vendors and many consultancy successful implementations is typically done bottom-up. organizations as well. This does not mean though that top management can afford to only discuss time and money when ―managing‖ In short, they are sold to the idea that for every problem IT. a specific IT solution exists: It is a matter of also defining what non-functional  Want customer intimacy? Buy a CRM solution. properties the IT landscape should have in order to be a  Want agility? Buy an ESB. business enabler instead of a roadblock – properties like agility, consistency, data quality, coherence, re-usability,  Want integration (finally)? Buy a best-of-breed etc. Not in IT terms but in business terms. These EAI solution (sigh). properties should be present in a measurable way.  Want scalability? Put it in the Cloud. When not measurable they are reduced to hollow  … phrases: ―Do you want agility?‖ ―Yes! (followed by silence)‖. The challenge is to translate these properties It is also very safe for an IT department to let business into specific actions, instead of sound bites. managers suggest a specific vendor. It is safe because in that case business has a high threshold for critique on Most straightforward is applying, what I call, the the new system; they selected it themselves. That Mastenbroek approach (Mastenbroek 1997). threshold would be very low if business suggests Siebel, For example: but IT decides to implement Baan instead. That is how  A top manager who has introduced the the world works. Why take any risks as an IT department architecture team demands that her (business) by suggesting another solution than what business subordinates contribute by asking each of them: proposes? ―What can you do to reduce complexity?‖  One of the answers given might be: ―By removing redundant information stores and preventing the Top introduction of new ones.‖ Management Enterprise Architecture  The top manager then asks: ―And how can we

Project Management measure that?‖ Content (Enterprise Architecture) 1 Project Principals  When satisfied with the answers given she may + Development Teams $ state: ―OK, that is what we will do. Your appraisal depends on reducing complexity with an  Operations improvement of 50% for the coming year (measured in the suggested way).‖ System Users  Each subordinate will do the same to their subordinates. In this case by asking: ―What can Figure 10: A Single Business Face as Prerequisite for you do to make sure 50% of the redundant Mature IT

information stores are removed and no new ones ABOUT THE AUTHOR are introduced?‖ Piet Jan Baarda ([email protected]) is a Senior  and so forth Information Architect at Sogeti Nederland BV. Or another scenario: REFERENCES  Top management wants to be better prepared for Baarda: Your SOA Needs a Business Case (2008); refer to: acquisitions. And asks each of its subordinates: www.via-nova-architectura.org/files/magazine/Baarda.pdf. ―What can you do to make us better prepared for acquisitions?‖ Hoogervorst J.: Enterprise Governance & Architectuur, ICT Bibliotheek, Den Haag (2007).  One of them states: ―By defining and implementing a set of services that allow us to Jim Morrison & The Doors: Unhappy Girl from Strange Days, integrate any acquisition without disrupting our Elektra Records (1968). business processes.‖ Mastenbroek W.: Verandermanagement, Holland Business  ―How can we measure that?‖ Well … these Publications (1997). 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).

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.

can resolve these ambiguities, but often only after lots of WHY ISN’T IT EASIER TO SELECT AND INTEGRATE churn and rework. APPLICATIONS? Involving application providers only intensifies this By now, IT customer organizations should find selecting challenge. Crafting an RFP, answering respondents’ and integrating a major packaged or hosted application a questions, and clarifying their responses all add lot easier than it actually is. Standards for common IT additional perspectives and agendas, as does system components, assemblies, and services are mature or integrator selection and subsequent collaboration. steadily maturing, as are standards frameworks for many Indeed, many vendors task very different people with industries and functions. Tools and APIs for all phases of initial relationship-building, responding to RFIs and application development are generally rich, full-featured, RFPs, and delivering formal customer presentations. and increasingly well-integrated. Custom development of The customer must therefore reconcile a variety of entire applications has become less necessary for IT graphic, written, and spoken material from different groups due to a wide variety of mature software sources. packages and a growing number of hosted applications. Traditional IT challenges such as agile software HOW CAN APPLICATION SELECTION AND development, project management, information security, INTEGRATION BECOME EASIER? and operations management are supported by broadly What could be done to enhance the certainty, efficiency, recognized methods and bodies of knowledge. and velocity of the IT applications marketplace? However, when IT customers select and integrate a Participants could use standard representations of IT major application involving diverse user communities application supply and demand that use graphics as well and legacy applications, the pace of work often as text. Both customers and vendors could use accelerates as the pace of accomplishment slows to a ArchiMate, The Open Group standard visual modeling crawl. Much of this difficulty stems from the complexity language for enterprise architecture, to represent and ambiguity of integrating the contributions of business, data, application, and technology stakeholders with diverse perspectives, responsibilities, architectures, as well as architectures that combine and and intentions. To select applications, customers and relate these layers. As of this writing, the ArchiMate 2.0 their consultants typically use structured methods that extensions for expressing motivations and collect and weigh application and vendor attributes implementation plans are nearing ratification, and some against prioritized or weighted current and expected enterprise architecture practitioners are working with requirements. Some even construct conceptual models them already. of their current and desired states. However, since the If customers modeled their conceptual application same words or pictures can mean different things to architectures and application requirements using different people, ambiguity is unavoidable. As a result, it ArchiMate, application providers could respond in kind. is often difficult to predict the progress or ultimate impact Certainly, free-form customer-supplier interaction would of selection processes due to instability and still be necessary, but a commonly understood model misunderstandings concerning application scope, would organize and focus these exchanges. Customers requirements, and key stakeholders. Selection teams could better orient application providers with models that associate requirements with broader concerns and key

stakeholders, as well as critical business capabilities and representatives should receive basic instruction in processes. Customers requiring implementation plans reading ArchiMate diagrams. could tie requirements and conceptual system If more IT customers, application providers, and system architectures to specific projects within broader integrators embrace ArchiMate, they will increase the programs. effectiveness and efficiency of their own organizations, Application providers could respond by elaborating their trading partners, and ultimately the IT applications customer models with their proposed applications and marketplace. Verifying these improvements could be the integration approaches. Both customers and application subject of future research as ArchiMate gains broader providers would benefit from the precision and re- acceptance. usability of these models. Customers and their system integrators would have a head start on their target ABOUT THE AUTHOR application architectures, and application providers could Iver Band is an enterprise architect at Standard re-use them for subsequent proposals. The selection Insurance Company, where he works on next-generation process would also prepare customers and system customer service solutions as well as enterprise integrators to expedite application integration by building architecture methodology and tools. He also participates on a shared model. in The Open Group ArchiMate Forum. Iver joined ArchiMate can be easily styled or extended to meet the Standard Insurance in 2008 after 16 years at HP, where needs of particular industries, functions, organizations, his roles included software and IT engineering, or methodologies. Modelers can add metadata to the architecture, and management. At HP, he was also the objects represented by its symbols, and can even add or second Visiting Technologist at HP Labs, where he led replace symbols. In these cases, the extending party just the development of a patented method for managing needs to provide a reference that explains its styles or network access control. 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

Book Reviews

The answer to that question is suggested by the authors’ 121 Things I Learned in Business notes that introduce each book. Architecture School? From ―… Architecture …‖: ―This book aims to firm up the foundation of the architecture 101 Things I Learned in studio by providing rallying points upon which the design Architecture School process may thrive. The following lessons in design, drawing, Matthew Frederick, The MIT creative process, and presentation first came to me as barely Press, 2007. discernible glimmers through the fog of my own education.‖ ISBN: 978-0-262-06266-4 From ―… Business …‖:

101 Things I Learned in ―While business schools provide specific information, skills, Business School and tools for tomorrow’s business people, they more Michael W. Preis with Matthew importantly should instill a desire and proficiency for learning Frederick, Grand Central beyond the classroom. Furthermore, there is no single Publishing, 2010. discipline called business; it is, rather, a broad field of ISBN: 978-0-446-55028-4 endeavor encompassing such diverse disciplines as accounting, communications, economics, finance, leadership, REVIEW BY LEN FEHSKENS management, marketing, operations, psychology, sociology, and strategy.‖ One of the things I’ve learned in the school of hard Except maybe for drawing (and I could make a case for knocks is that it often helps to remind oneself of the its inclusion if pressed), these enumerated concerns are obvious, as the obvious is too often overlooked as not all also concerns for enterprise architects. How many of worthy of consideration. These little books, though not the 101 sometimes very brief essays on these concerns explicitly intended to, remind us of the obvious. in each of these books say something of potential use to Nor are they intended to be comprehensive treatments a practicing enterprise architect? I did a simple count to of their subjects, and as such, I found the few bad find out, and it turns out it’s a little more than half of reviews they received on Amazon.com hilarious in their them. My categorization was necessarily subjective, but cluelessness. Only the clueless could imagine that a certainly no more arbitrary than the choice of 101 as a small book titled ―101 Things I Learned …‖ would bound. It was 53 (or so) for ―… Architecture …‖, and 68 effectively summarize, never mind obviate, an entire (or so) for ―… Business …‖. Hence, the 121 in the title of undergraduate and graduate education. But set your this review. Your mileage may (almost certainly will) expectations appropriately, and I think you’ll find them vary, of course. worth a periodic revisit. Some examples. The ―… Business …‖ book starts out These two books are part of a series that now comprises with a definition of business that ought to be required five books, the first of which was ―… Architecture …‖. reading for anyone who wants to talk about business Matthew Frederick, that book’s author, is the common architecture: thread; he illustrates the other volumes, using the same ―Business is the exchange of entities to which value has been architectural drafting style. The books are all in the same assigned.‖ format, with a 5.2‖ high by 7.4‖ wide format, a little less than an inch thick. The other three volumes cover Business is not about value creation. Business is not an culinary, fashion, and film school. enterprise’s processes. Architectures that address these concerns are not ―business architectures‖. They are Enterprise architecture is increasingly viewed as some value creation architectures or process architectures. sort of intersection or integration of business and While they are certainly supportive of business, they are architecture, so the real question for a review in this not what a ―business person‖ would likely expect journal is what, if any, relevance do these two books, business architecture to be, if said ―business person‖ did especially together, have for an enterprise architect? not vanish at the mention of the ―a-word‖. They are, after all, not intended for an audience of enterprise architects, but for students respectively of civil Then there are items like The Rule of 72, which, though (building) architecture and business. 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 ITSA), and the concepts underlying it. While originally can survive without. intended as a method for developing solution Similarly, from the ―… Architecture …‖ book, a statement architectures (as should be apparent from the title), the like: thoughtful reader may realize that it is much more generally applicable. At HP Services, we often used ―If you can’t explain your ideas to your grandmother in terms ITSA as a general problem-solving method. that she understands, you don’t know your subject well enough.‖ What distinguishes ITSA from most other solution is something that every enterprise architect ought to architecture methods, and thus distinguishes this book embrace as a first principle. On the other hand, while the from most other books about IT architecture, is best fact that ―Windows look dark in the daytime‖ may be a summarized by quoting myself from the book’s foreword: fascinating cocktail party conversational gambit, it’s ―Most of these methods are project management lifecycle again not something an enterprise architect needs models for architecture projects; they say what things you desperately to know. should do or produce in what order, but they say little about how to do or produce these things. Only a few of these I have long argued that the successful enterprise methods are heuristics for producing architectural work architect’s competencies are a synthesis of products; ITSA is one of these few.‖ competencies from many other disciplines, integrated Structurally, the book comprises a foreword, a preface, with and by an architectural perspective. I also noted in 16 chapters, 6 appendices, an ―About the Authors‖ an earlier JEA book review that I am always looking for section, and an index. It includes 49 figures and 15 ways to extend the way I think about enterprise tables. architecture, and that these often come from outside the discipline. These books are a case in point – I think their Each chapter starts with an aptly chosen epigraph or real value to an enterprise architect comes from the two, and a concise summary of the chapter’s content. exercise of asking which of the 101 things in each of The content of the book is heavily derived from the these books is relevant to enterprise architecture, and training materials used to teach ITSA to HP Services more importantly, how. solution architects. The ―Architecture Concept‖ was Len Fehskens is the Vice President, Skills and Capabilities for taught in a week-long intensive workshop combining The Open Group. He is responsible for The Open Group's lectures and a role-playing exercise in which the class activities relating to the professionalization of the discipline of participated over the entire week. The ―Architecture enterprise architecture. Blueprint‖ was taught in a virtual classroom spanning four days of four hours each. Both the Architecture IT Architecture: Essential Practice for Concept and Architecture Blueprint are covered in the IT Business Solutions book. As I am already intimately familiar with the details of Beijer, Peter & Theo de Klerk, Lulu.com, 2010 (xviii + 217 ITSA, and specifically with these training materials, it is pages). ISBN 978-1-4457-0603-0 hard for me to judge how well the book does in explaining the method to the uninitiated. The only thing REVIEW BY LEN FEHSKENS missing from the book that I think played an important factor in the success of the week-long workshop is the First, I have to address my objectivity role-playing exercise. Still, I am confident that the book in reviewing this book. I know the can provide a thoughtful reader with a usable authors; they were colleagues of understanding of the ideas of the method. mine at HP Services and remain personal friends. I wrote the foreword What are those ideas? From the book: to this book, and am mentioned in it  Business Drivers are business conditions or in several places. While I have no pressures that motivate to seek a solution. financial interest in this book’s success, its content was an integral  Business Goals are objectives of the solution; i.e., part of the last seven years of my what the solution must accomplish in business career at Compaq Professional terms. Services and HP Services, and I have an obvious  Business Metrics define the goals in measurable interest in the promotion of its ideas. You have been terms so they indicate the degree to which goals warned – take what I say with an appropriately sized are achieved. grain of salt.  Principles are a fundamental approach or means This book is about HP Services’ IT architecture method for achieving a goal; they are timeless, show how (HP Global Method for IT Strategy and Architecture, or

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 Figure 20: ITSA Goal-Means Hierarchy of Principles architectural elements of principles, models, and standards into four views: business (why?), functional Note that this is not a process or workflow diagram; it is (what?), technical (how?), and implementation (with an information structure diagram. ITSA as a method what?), as depicted in Figure 6 from the book: 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 Figure 6: The Four Views with Architectural Elements purely architectural domain to the domain of project Please note that these ―views‖ are not exactly the views planning, management, and execution. Figure 35 from of IEEE 1471/ISO 42010; the ITSA terminology predates the book illustrates this connection. these standards for the ―architectural description of My experience using ITSA in real-world situations is that software-intensive systems‖. This structure of it dramatically improves the likelihood of a project being architectural elements is motivated by and evaluated successful, not only from the project management against drivers, goals, and metrics. It’s also important to perspective (―on time, on budget, on spec‖), but more understand that the ―implementation‖ view includes importantly from the stakeholder satisfaction perspective deployment, operation, maintenance, evolution, and – it’s not success to do an excellent job of delivering the retirement of the architected entity; ITSA treats a wrong solution. If you want to learn how to do this, and solution as considerably more than a software incidentally why principles deserve to play at least as application and its execution platform. large a role in architecture as models currently do, I ITSA emphasizes the role of principles much more cannot imagine a better place to go than this book. heavily than most architectural methods; it devotes three Why should a book about solution architecture be of chapters totaling 35 pages to principles, compared to a interest to enterprise architects? single chapter of 8 pages devoted to models. Architectural principles are used to tie the four views of As a solution architecture method, ITSA complements the ITSA architecture concept together, as depicted by rather than competes with the methods and frameworks Figure 20 from the book: familiar to enterprise architects.

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‖. Figure 35: The Big Picture from Initial Architecture to Len Fehskens is the Vice President, Skills and Capabilities for Solution Project The Open Group. He is responsible for The Open Group's Enterprise architectures are rarely implemented in their activities relating to the professionalization of the discipline of enterprise architecture. 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.