Enterprise Architecture Jeanne W

Journal of

E nterprise Architecture

February 2012, Volume 8, Number 1 FEATURES Editor’s Corner: John Gøtze Architect in the Spotlight: Mark Perry ARTICLES SEA Change: How Sustainable EA Enables Business Success in Times of Disruptive Change Leo Laverdure and Alex Conn PhD Maturity Matters: Generate Value from Enterprise Architecture Jeanne W. Ross and Cynthia M. Beath Improving Government Enterprise Architecture Practice – Maturity Factor Analysis Adegboyega Ojo, Tomasz Janowski, and Elsa Estevez Architecture Styles Indranil Bhattacharya, Enterprise Architect, Deutsche Telekom The Impact of Enterprise Architecture Principles on the Management of IT Investments Mats-Åke Hugoson, Thanos Magoulas, and Kalevi Pessi Can a Re-Discovery of Open Socio-Technical Systems Strengthen EA? James Lapalme and Donald W. de Guerre CASE STUDY The Enterprise Architecture Approach to Support Concept Development in a Military Context: A Case Study Evaluation of EA’s Benefits Jukka Anteroinen and Juha-Matti Lehtonen BOOK REVIEW Thinking in Systems: A Primer Review by Leonard Fehskens

https://www.globalaea.org/journal

Journal of Enterprise Architecture

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

Associate Editors

Andy Blumenthal James Lapalme, PhD Division Chief, US Department of State Enterprise Architecture Consultant and Researcher 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 PhD 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 Human Resources and Skills Development Canada Professor of Information Systems, National University of Singapore Robert Ellinger, PhD Cathy Sowell Enterprise Architect President, Custom Enterprise Solutions, LLC Len Fehskens Torben Tambo VP, Skills and Capabilities, The Open Group Associate Professor, Aarhus University Institute of Business & Technology Kristian Hjort-Madsen, PhD Michael Tiemann Manager, Accenture Program Director, FEAC Institute Michelle Kaarst-Brown, PhD Pat Turner Associate Professor, Information Studies, Syracuse University Director, Centre for EA & Research Management, Griffith University Leon Kappelman, PhD Tim Westbrock College of Business, University of North Texas Managing Director, EADirections William W. Krauter, PhD John A. Zachman Senior Architect, Lockheed Martin Corporation Zachman 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 Enterprise Architects (AEA). Sponsors: JEA is sponsored by AEA (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 https://www.globalaea.org/journal. 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 AEA associate membership is $70.00/£40.00/€60.00 and includes access to the Journal of Enterprise Architecture. To join, please refer to https://www.globalaea.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 AEA.

2 © Journal of Enterprise Architecture – February 2012

Contents Editor’s Corner ...... 4 Architect in the Spotlight ...... 5 SEA Change: How Sustainable EA Enables Business Success in Times of Disruptive Change ...... 9 Maturity Matters: Generate Value from Enterprise Architecture ...... 22 Improving Government Enterprise Architecture Practice – Maturity Factor Analysis ...... 27 Architecture Styles ...... 38 The Impact of Enterprise Architecture Principles on the Management of IT Investments ...... 46 Can a Re-Discovery of Open Socio-Technical Systems Strengthen EA? ...... 55 The Enterprise Architecture Approach to Support Concept Development in a Military Context: A Case Study Evaluation of EA’s Benefits ...... 63 Book Review ...... 75

Editor’s Corner

By John Gøtze

JEA’s first number in 2012 is packed full with new and JEA ARCHIVES valuable insights into Enterprise Architecture in theory and practice. We have extended our digital archives, and have all published numbers available for (members) download at The Architect in the Spotlight is Mark Perry from HP. https://www.globalaea.org/journal. Leo Laverdure and Alex Conn discuss how sustainable EA enables business success in times of disruptive CALL FOR REVIEWERS change. Please consider becoming a reviewer for JEA. As a Jeanne Ross presents MIT CISRs findings in their reviewer, you are given decisive influence on what is research on EA maturity in over 100 companies in a two- published in the journal, and as all reviews are blind part series. The first part introduces the background. (anonymous), you can provide your honest opinion. Contact me if you are interested. Adegboyega Ojo, Tomasz Janowski, and Elsa Estevez discuss how to improve government EA practice through CALL FOR PAPERS Maturity Factor Analysis. Please consider sharing your story with the EA Indranil Bhattacharya discusses architecture styles in community, and submit a paper for JEA. Read more on another two-part series. The first part discusses the https://www.globalaea.org/journal. concept of architecture styles. ABOUT THE EDITOR Mats-Åke Hugoson, Thanos Magoulas, and Kalevi Pessi discuss how EA principles can be used in the Dr. John Gøtze is program manager at the IT University management of IT investments. of Copenhagen and lecturer at Copenhagen Business School. He is also a partner in EA Fellows, and runs James Lapalme and Don de Guerre discuss socio- Carnegie Mellon University’s EA Certification program in technical awareness in the architecture practice. Europe. He can be reached on [email protected]. Jukka Anteroinen and Juha-Matti Lehtonen present a case study from an EA effort in the Finnish Defense, and discuss benefits for concept development. Last, but not least, Len Fehskens does a book review of a classic, Thinking in Systems. As always, the full articles have been carefully reviewed in a double-blind peer-review process, and all published articles been accepted by at least two reviewers. A total of 44 peer-reviews by more than 20 reviewers were conducted in the making of this issue. Some articles had to go through three revisions before final acceptance, and other submissions were rejected. JEA’s current acceptance rate is 58%.

4 © Journal of Enterprise Architecture – February 2012

Architect in the Spotlight

Mark Perry

and programs and have been doing that now for about PLEASE INTRODUCE YOURSELF! 15 years. I am an Enterprise Architect and the CTO for HP Enterprise Services’ UK Defence Business Group with WHAT IS THE GREATEST CHALLENGE FACING 32 years’ experience in IT systems, services, and ENTERPRISE ARCHITECTURE TODAY? consultancy. In my current role I lead a team of It has always been, and continues to be, the case that business, portfolio, and technical architects whose prime we have to continually explain to people about the need responsibility is the formulation of IS/IT strategy and the to link business needs and aspirations to what can be design of service solutions for the UK Defence & achieved and facilitated with the right mix of technology, Security client base and internal business/operational people, and process. I am still amazed by the number of initiatives. My CTO function also drives and co-ordinates people who will jump into choosing a technology product solution innovation across the business. My career has without being clear on the business context or the covered engineering, product design, systems integrator, required benefit to the “bottom line”. On an almost daily systems engineering, and consultancy providers, and basis I still have to reinforce how EA sits above various end-user organizations including central individual problems and systems and is not there to only government and defence and a range of commercial focus on the technical details. Everyone in the EA companies. In earlier roles I have performed community needs to continue to promote EA and its engineering, technical management, architecture, enterprise-wide benefits otherwise there is the danger strategy, and trusted-advisor roles – typically operating that EA as a specific approach and discipline, which I as the “thought-leader” and the individual responsible for really believe it is, will slip back into the general “techie” leading and implementing the solutioning change space. required and achieving the future state across technology, process, and org/role design. WHAT IS THE NEXT BIG THING IN ENTERPRISE ARCHITECTURE? HOW DID YOU BECOME INVOLVED WITH I think it’s embedding serious modeling rigor into our ENTERPRISE ARCHITECTURE? core analysis and design activities and probably After graduating I started as a development engineer automating more of the governance tracking processes! specializing in electronic circuit design and development, Things are simply becoming too complex in the EA but quickly became interested in the wider human space to not consider this and no one person can keep factors aspects of my work (mobile military in the mind all the details of today’s organizational model communications) and so got involved in firmware with their extending ecosystems, customer channels, development in order to better address end-user needs and rapidly changing IT systems landscape (e.g., cloud- in a more holistic manner. based) – we have to start more seriously adopting It was a fairly natural development to then move onto modeling and automation approaches for EA to really equipment design (this time a medical systems supplier) provide the benefits it is capable of. and technical team leadership which covered electrical, WHAT IS IT LIKE BEING A HEAD OF ENTERPRISE electronic, software, mechanical, and hydraulic ARCHITECTURE? disciplines – this started to give me a really good insight into the importance “of the whole” and how you often It is never boring. One of the reasons I started to major have to make compromises to best address the user on EA roles and assignments in the mid-1990s was that requirement. I like the breadth and, when needed, the deeper dives into solutioning in its widest sense; i.e., the classic From those earlier experiences I moved onto technical people, process, technology aspects. So, my EA roles and systems architecture, and all the time the solutions I continue to throw up new challenges in that wider space was producing were becoming bigger and more complex and I find that even the more obscure experiences (e.g., and starting to involve elements of organizational the psychology of team behavior, new working practices, transformation which are typically involved when you are outlandish use of technologies, etc.) all become part of deploying big IT solutions. This was when I started to my evolving EA toolkit which I can apply to build better adopt EA approaches and actively seek out EA roles

business understanding, obtain executive-level support, reality – that is what makes work as an EA attractive to and push solutioning to the next stage. Building and me. coaching a good EA team around you is also a major part of my role and seeing people talk and act and WHAT WAS A LEAST FAVORITE ENTERPRISE influence decisions as Enterprise Architects is something ARCHITECTURE EXPERIENCE? which also makes the whole effort worthwhile. It was probably those engagements where an EA approach was not wanted or understood by the senior WHAT WOULD YOU SAY TO SOMEONE decision-makers, even though the underlying need was CONSIDERING MAKING ENTERPRISE there, and I would find myself operating in a role which ARCHITECTURE THEIR CAREER AREA? (AND TO was constraining what could potentially be achieved. In SOMEONE HAVING AN ENTERPRISE those early days, when I was not best equipped to ARCHITECTURE CAREER?) challenge or change the status quo, I found those Be very clear on what you are looking for in your career experiences frustrating more than anything else, and how much personal commitment you are prepared although it did give me the push to get more of the EA to invest. EA is still a relatively new discipline, even by skills and experience needed. general IT industry timescales, and is still establishing itself in organizations and the wider IT industry and community. This sometimes means you could be the lone voice promoting its approaches, you might get seen or pushed into a more recognizable technical SME role, or you might be considered simply as the manager of a technical team – all these cases will require you to provide that extra bit of effort to stay focused on EA as a This section aims to bring recognition to a variety of discipline in its own right, and as a specific role which contributors to the Enterprise Architecture field – from needs recognizing at the more senior levels of the early pioneers, to current practitioners beginning their organization. Ultimately, you have to decide whether or careers, to experts from other fields that influence not you want to be the guy who will walk to the front of Enterprise Architecture – and is intended to show the the room, when the rest of the group have either gone rich diversity of backgrounds and views that the quiet or are shouting over each other, and be the one Enterprise Architecture community enjoys. who takes the lead and starts to bring some structure to shaping the solutioning ideas on the whiteboard – that’s the EA role challenge, but it’s also the source of a huge amount of personal satisfaction. WHAT WAS YOUR FAVORITE ENTERPRISE ARCHITECTURE EXPERIENCE? To be honest, there have been a number with each addressing different needs. One was leading the implementation of a global enterprise-wide automated software distribution capability from a standing start of no team, no processes, and an empty room with no infrastructure. Another was working client-side helping to shape their business change program and embedding EA thinking in their future operating model. Yet another was building out an architecture function and implementing effective joint working practices with the end-user organization. Most recently, it’s been shaping a number of solutioning campaigns in a number of solutioning areas which is really helping to shape what future offerings and portfolio a business needs. I suppose the common thread which runs through all these different favorites is that they needed significant amounts of thought leadership and visioning followed up with some real drive and rigor to make that vision a

6 © Journal of Enterprise Architecture – February 2012

Visit the JEA website at https://www.globalaea.org/journal

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 https://www.globalaea.org/journal.

ACM/IEEE 15th International Conference on Model Driven Engineering Languages & Systems Sept 30 –Oct05 2012, Innsbruck, AUSTRIA http://modelsconference.org Jury (to be confirmed): Model Gamification Challenge @ MODELS 2012 – Call for Submission Thomas Allweyer Scope (University of Applied Sciences Models are used in many different software engineering and management disciplines as tools to communicate Kaiserslautern, Germany) information, to express and analyze system properties at an abstract level, to plan future changes, and to Colin Atkinson analyze complex interdependencies. In order to use models effectively system stakeholders have to understand (University of Mannheim, the rules and languagesused to createthem and to become familiar with the way models convey information. Germany) Gamification is an increasingly popular strategy for helping stakeholders in a system gain an intuitive Ruth Breu understanding of the way that it works and the goals that it is intended to fulfill. It involves the translation of a (University of Innsbruck, Austria) system, or parts of a system, into a game whose rules of play are designed to teach and communicate central aspects of the system’s behavior and functionality. Model Gamification applies this notion to the use of models Bernd Brügge, Ph.D. in IT systems modeling – it aims to use game playing techniques to teach users how to create, interpret and (Technische Universität München, Germany) work with models. As an example, http://www.eagame.net/ and [1] demonstrate the idea of model gamification in the area of Enterprise Architecture Modeling. Bernd Dreier (University of Applied Sciences Other domains where gamification may be beneficial include: Kempten, Germany) • Software Architecture Modeling John Gøtze • Business Process Modeling (IT‐University of Copenhagen, • Requirements Modeling Denmark) • Model‐Based Testing Giancarlo Guizzardi (Federal University of Espirito Submission and Evaluation Procedure Santo, Brazil) The goal of the MODELS 2012 Gamification Challenge is to promote the use of gamification techniques in Stijn Hoppenbrouwers model‐driven development by identifying innovative and effective modeling gamification strategies. The (Radboud University Nijmegen, challenge solicits descriptions of innovative gamification strategies in the form of concept papers conforming to Netherlands) the ACM format (up to 4 pages). These should explain the rules of game play and describe how the game helps Dimitris Karagiannis users learn how to communicate/gather/analyze information based on models. The submissions will be (University of Vienna, Austria) evaluated through a two‐phase process. Florian Matthes (Technische Universität 1. In round one, the papers will be evaluated by the program committee and the three best submissions München, Germany) will be selected.

Erik Proper 2. In round two, each of these three papers will be presented ina short slot during the main conference (Public Research Centre –Henri Tudor, Luxembourg) and the winning submission will be selected by the audience. This paper will be published in the electronic MODELS 2012 workshop proceedings. Christian M. Schweda (iteratec GmbH, Germany) In round one, submissions will be assessed according to their innovativeness and appropriateness for Elena Simperl communicating/gathering/analyzing information based on models as well as their suitability for the context of (Karlsruhe Institute of software engineering and IT management. In the second round, submitters are encouraged to implement a Technology, Germany) prototype realizing the game, although this is not mandatory. We particularly encourage student teams to Marten van Sinderen submit concepts. (University of Twente, Netherlands) Each of the three invited author teams will receive one free registration for the main conference. The winning team will receive a prize of €500 awarded by the German Chapter of the ACM. Additional funding for travel support is available upon request.

[1] J. Groenewegen, S.J.B.A. Hoppenbrouwers, and H.A. Proper. Playing ArchiMate Models. In I. Bider et al. (eds): Enterprise, Important Dates: Business‐Process and Information Systems Modeling ‐ 11th International Workshop, BPMDS 2010 and 15th International Conference, July 26, 2012 Submission Deadline EMMSAD 2010, held at CAiSE 2010, Tunis, Tunesia, June 2010, volume 50 of Lecture Notes in Business Information Processing, pages Sept 03, 2012 Notification of 182‐194. Springer, Berlin, Germany, 2010. Acceptance Oct04, 2012 Date of Presentation

All deadlines are hard. No extensions will be allowed. (All dates are according to time zoneUTC).

8 © Journal of Enterprise Architecture – February 2012

Article

SEA Change: How Sustainable EA Enables Business Success in Times of Disruptive Change

By Leo Laverdure and Alex Conn PhD

Abstract Enterprise Architecture (EA) is a key tool to help businesses transform themselves to meet changing business challenges. To do so, however, architectural methods must themselves be adapted to focus less on technology per se and more on how these technologies enable the business to survive and thrive over the long term—to be sustainable—in the shifting, uncertain business context. We call this shift to Sustainable Enterprise Architecture (SEA) a “SEA change”. The practice of SEA differs from the usual practice of EA in a number of ways. Sustainable architecting emphasizes the long-term perspective, focusing on how the enterprise can identify and respond effectively to a range of strategic disruptions. It is based on systems thinking; is continuous, iterative, and adaptive; and calls for integrated strategic planning, architecting, governance, and learning. It considers sustainability the primary system quality and organizes other system qualities in support of sustainability. The enterprise’s approach to sustainability is recorded in a formal sustainability architecture, which describes the threats to sustainability in the business context and defines sustainability goals, models, principles, policies, and standards to address them. It pays close attention to strategic resources and the pragmatic integration of societal, economic, and environmental considerations. It recognizes that sustainable architecting is a cultural change, and provides a set of essential checklists to guide that change. Keywords Business sustainability, business context, risk management, disruptive change, systems thinking, system qualities, sustainable enterprise architecture, architecture methods, strategy, governance, lifecycle

This is starting to change. The SABSA (Sherwood INTRODUCTION: PERVASIVE, UNRELENTING, Applied Business Security Architecture) Institute and DISRUPTIVE CHANGE The Open Group recently announced the publication of a In today's rapidly shifting business context, organizations joint White Paper recommending the integration of face major challenges, including economic instability, TOGAF® and SABSA as a best practice to secure energy and resource uncertainty, growing populations Enterprise Architectures (The Open Group and SABSA and new entrants to the global middle class, social and Institute 2011). The paper stresses the primacy of political unrest, climate change, and disruptive addressing business risks. Also, the SABSA Institute’s technologies. A seemingly isolated event half the world Enterprise Security Architecture (Sherwood et al. 2009) away can send shockwaves across the global economy provides a useful set of Business Profile Attributes for and supply chains, severely testing a business’s defining business risk elements that must be managed. resilience. Worse, some disruptions signal long-term It correctly points out that risk management includes an shifts rather than temporary fluctuations and require opportunity side as well as threats. strategic changes of direction. Whole industries may be Nearly all enterprises have a business continuity solution impacted. in place to assure continued operations in the face of a Enterprise Architects have a long history of dealing with range of disruptive events. A basic need is to keep disruptive technologies. Indeed, one of the key skills of communications and information systems operational, the architect is to recognize which emerging while recognizing that business resilience ultimately technologies are likely to yield business benefits and depends upon management discipline rather than simply when it is time to embrace them. Architects also technology (Owens 2004). understand how business events, such as mergers, What is common to security and business continuity/ acquisitions, and divestitures, can drive new architecture resilience arrangements is the assumption of a relatively development. What is less familiar, however, is the short-term disruption, after which the business returns to importance of using Enterprise Erchitecture as a tool to more-or-less normal operations, often referred to as address general business context risks. “Business As Usual” (BAU). But what if the business context shifts to a significantly different landscape—a

“new normal” from which return to the previous without adequate understanding of fault lines, soils, and conditions is infeasible? Enterprises must adapt. And the the full historical record of local seismic events. imperative for Enterprise Architects is to help them adapt We also generally assume that the system environment effectively, efficiently, and often very rapidly. is, by definition, beyond our control. Most of it is, but a How can architects do this? There is no silver bullet, but large part of the environment with which we interact, successful architects will work with business leaders to: while uncontrollable, is influenceable (Gharajedaghi • Redefine goals and directions to make clear that 2006). We call this interaction environment the Business the fundamental goal is sustaining the business in Ecosystem, depicted in Figure 1. Also depicted are Your uncertain, disruptive times Business, its inputs and outputs (coming from and going to other parties, not shown, in your business • Shift thinking to a new level, with a greater focus on ecosystem), and two key internal aspects: your core understanding long-term contextual shifts and Business Idea (the overall differentiating quality of the systems interactions enterprise, similar to mission/vision; van der Heijden • Craft Sustainable Enterprise Architectures (SEAs) 2005) and Capabilities (abstractions of a business’s with capabilities, platforms, and system qualities offerings and competencies). that help to define and enable strategic agility • Improve adaptive capacity, turning it into a core competency The remainder of this article outlines how to accomplish these. THE FUNDAMENTAL GOAL: BUSINESS SUSTAINABIILTY All organizations understand that they exist to provide products and services valued by their customers; for many organizations, making a profit for shareholders and/or providing jobs are also basic goals. And, there is wide and growing realization that addressing a broader set of stakeholders’ concerns is good for business. This often finds expression as corporate social contribution and/or stewardship of the natural environment (“doing Figure 1: Your Business and Its Environment well by doing good”). The environment—both the multiple Surrounding But businesses, like most people, are also pragmatic— Contexts and the Business Ecosystem—is the source of what matters most to them is their own prosperity. most disruptions, which change the competitive Accordingly, we define a sustainable business (or landscape and business models, forcing the enterprise enterprise) as one that survives and thrives over the long to adapt its business idea and capabilities. (We find that term by balancing economic, social, and environmental viewing the environment as multiple contexts makes it considerations and by managing risks and seizing easier to think about the different kinds of disruptive opportunities associated with disruptions. forces that might impact the enterprise.) SEA is about the architecture of a sustainable Figure 2 shows one way to categorize these disruptive enterprise. forces, and suggests that most, but not all, of the UNDERSTANDING SYSTEMS, CONTEXTS, AND influence is directed from the environment to the RISKS business. In some cases, however, a business can influence one or more of these forces; e.g., with a major A useful heuristic in systems architecting is that the three technical or business innovation that becomes a new de most important things are scope, scope, and scope facto standard. (Rechtin & Maier 1997). In other words, it is critical to understand the boundaries between systems and their A number of organizations provide valuable information environments. about the risks of potential business disruptions, ranging from government organizations to trade groups and We tend to jump quickly to system solutions because we individual companies. Each looks at the risks from a assume that we understand the system environment. different perspective. Government organizations include But, in a time of disruptive change, that is a dangerous the US National Academy of Sciences, the assumption, akin to building in an earthquake zone

10 © Journal of Enterprise Architecture – February 2012

Intergovernmental Panel on Climate Change (IPCC), Kureha had 70% of the global market for a resin that is a and the International Energy Agency (IEA). Additional critical binder for lithium ion batteries. The only Kureha sources include the UN Millennium Project, which tracks factory to make the resin is in Fukushima Prefecture and and forecasts key global indicators, and insurance stopped production because it suffered damage and companies, such as Swiss Re, who are starting to could not get raw materials. In the words of Kevin Tynan, increase premiums for unsustainable corporate policies. an automotive analyst for Bloomberg Industries in New Two especially relevant reports are Strategy under York: “in many cases companies weren't even aware of Uncertainty (McKinsey 2000) and the Shell Energy their exposure; they know their suppliers, but not their Scenarios to 2050 (Royal Dutch Shell 2008). suppliers' suppliers, or the suppliers of those suppliers” (Coy 2011).

Figure 2: Kinds of Disruptive Change

The World Economic Forum, which publishes an annual Figure 3: World Economic Forum Top Risks Global Risks report (WEF 2011), is a particularly useful (Adapted from WEF 2011) source that outlines some three dozen risks by perceived impact and likelihood. Figure 3 shows those Another example from the fall of 2011: according to risks deemed most impactful and most likely. research firm IHS iSuppli: “the devastating floods in (Technology risks were also covered in the report, but Thailand will cause a 28% quarter-on-quarter drop in none made the top six.) hard disk drive (HDD) production, potentially affecting A prudent business must take reasonable steps to notebook production in early 2012” (Ribeiro 2011). This, manage these and other macro risks, especially those in turn, has dramatically affected drive delivery dates that are directly relevant to its operation. But because and prices, and impacted sales and/or delayed product risks are interconnected, the business must also launches of other devices, including computers, solid consider indirect risks. state disks, and cameras. In addition to lost revenue, other negative impacts of this kind of disruption include For example, according to the Texas state climatologist increased production costs and customer base attrition. (Nielsen-Gammon 2011), increasing global warming combined with natural weather variation in Texas during As disruptions increase, a deep knowledge of the the summer of 2011 caused record droughts (over 100 business environment, risks, and their interconnections days of 100+ degrees Fahrenheit). This, in turn, caused is becoming fundamental to strategy formation and the not only widespread wildfires and multi-billion-dollar development and operation of business capabilities. agricultural losses, but also a six-fold increase in the Architects must understand this context and its risks as a cost of electricity in spot markets as air conditioners necessary precondition to crafting systems that address struggled to keep indoor temperatures out of the danger them effectively. zone. Even local businesses not directly impacted by the A CRITICAL TOOL FOR ARCHITECTS: SYSTEMS heat, drought, and fires nonetheless found themselves THINKING indirectly impacted by power brownouts and high utility bills. The business context today is complex and richly interconnected. Seemingly unrelated events can be Recent events have had clear impacts on the IT linked through chains of interactions, often difficult to industry. As a result of the Fukushima earthquake, see. The result can be unintuitive—sometimes even tsunami, and nuclear meltdown, there was a major counter-intuitive—behavior of the systems we encounter. disruption in Apple’s supply of batteries for portable This leads to policy resistance (our solutions don’t work) devices. At that time, a Japanese company called and unintended consequences (even if they do solve the

targeted problem). Systems thinking is a discipline to help us deal with this complexity to arrive at better understanding, decisions, and systems architectures. Mental models are “deeply ingrained assumptions, generalizations, or even pictures or images that influence how we understand the world and how we take action” (Senge 1990). Systems thinking explains why we are surprised whenever the mental models we use to make decisions do not match the actual circumstances that we encounter. The problem is that our models are too simple. For example, we often assume that systems have a single, well-defined boundary, when in fact, Figure 4: Systems Thinking “Iceberg” Model of Layers of because everything is connected, each stakeholder Understanding (Adapted from Ambler 2006 and others) concern can require a different system boundary for The structures level of the iceberg describes the effective analysis (Meadows 2008). For example, we conditions that generate the patterns. It is modeled as a think of a car as a system, but closely related systems set of inter-related causal factors. This causal structure include: (car + driver), (car + driver + road), (car + driver emphasizes feedback loops (direct or indirect + road + signage + on-board-navigation + GPS), (car + connections back to the same component) and fuel), (car + fuel + atmosphere), etc. associated delays, which together help us understand Other sources of systems complexity arise because why a system behaves in a particular—often systems are: constantly adapting and evolving; governed unintuitive—way. System traps are common ways in by feedback, with delays; exhibit non-linear/exponential which systems get stuck in a problematic structure responses to changing input conditions; self-organize, (producing unintended consequences), while leverage with emergent behavior; and are characterized by trade- points are general strategies for exiting the traps offs (Sterman 2006). (Meadows 2008). An example of a common oversimplification is to imagine The mental models level represents the beliefs and ways that something as complex as a market can be governed of thinking that cause the structure to be the way it is. by a single variable—price. A more accurate model is These models exist in the minds of the structure’s one that treats the market as an interacting set of stakeholders—the people who set up the structure variables that describe key stocks (how much there is of and/or play a role in the way it operates. Shared mental something) and flows (how rapidly it can move between models allow stakeholders to act quickly and in concert. parties or states), including: supply, demand, It is difficult to examine mental models because we are replenishment rates (for renewable resources), usually unaware of them and often uncomfortable regulations, and even such intangibles as trust and exploring them. But, in times of disruptive change, confidence about the future. unexamined mental models (and especially worldviews) A key prescription of systems thinking is to be may lock us into outmoded, ineffective ways of continuously aware of how we are making sense of our understanding our situation. Developing more effective world. The iceberg model (see Figure 4) differentiates mental models, and corresponding language, that five levels of understanding. The top level is concrete facilitate reasoning about long-term, disruptive change is and directly visible, with each lower level becoming more a pre-requisite for architecting more sustainable abstract and harder to see. Lower levels are increasingly businesses. broader in scope. Solutions generated at lower levels The worldview level is the deepest set of mental models; tend to be more innovative and have a more substantial the framework of thoughts and beliefs (and related impact—and be more difficult to implement (Ambler emotions) that shapes and constrains all our mental 2006). models. This layer is particularly relevant for Starting from the top, the events level deals with what is sustainability considerations because these often happening. Because it is the most concrete and directly challenge our worldviews. For example, people who visible, it is shown as being above the “waterline”. believe deeply that growth is the answer to macro- economic problems are likely to strongly resist “limits to Next comes the patterns level, which deals with how the growth” mental models. events are changing, or not, over time (i.e., trends). It is only partly visible because it takes time and close attention to spot some trends.

12 © Journal of Enterprise Architecture – February 2012

CRAFTING SUSTAINABLE ENTERPRISE ARCHITECTURES The enterprise’s approach to sustainability is best recorded in a formal Sustainability Architecture, which describes the threats to sustainability in the business environment and how to address them. In turn, the Sustainability Architecture guides the transformation of the overall EA into a Sustainable EA (SEA). Because sustainability is such a fundamental concept, architects must address not only the sustainability of the enterprise they are architecting, but also the process and methods used to do the architecting. Indeed, even the way we think about the enterprise and architecting needs to change. Figure 5: The Sustainable Business Cycle Architecting must be Continuous, Iterative, and Adaptive To be effective, architects must participate actively in all One of the central insights of systems thinking is that the of these phases. This interaction ensures that the complexity of our systems and their environment is architecture will continuously track and inform the dynamic; that is, it arises due to changes over time. evolving strategy and plans. In practice, there will be Worse, many changes are unforeseeable. Yet the architectural activities for different enterprise systems building-architecture metaphor often used for information and subsystems simultaneously in progress in all of the systems architecture suggests that nearly all of the phases. architecting is done once at the front end of projects. Before examining the activities of each phase in more A better metaphor for SEA is the architecting of urban detail, we next consider the structural model of a planning and renewal, which implies that enterprise sustainable enterprise. architecting needs to be continuous. Most of the detailed architecting is done as a series of The Sustainable, Adaptive Business Model: The Enterprise in Context projects, including renewal initiatives, so it is iterative. (Many projects, of course, will be under way in parallel.) The Sustainable Business Cycle is a process model. And conditions change after some original overall vision Adaptive architecting also requires that structural models is established, so the architecting must be adaptive in of the enterprise make it clear how the enterprise can the presence of disruptive change and resource limits. adapt to changes in the business environment. We have found that the overall enterprise—and its context—are The Sustainable Business Cycle effectively modeled as a sustainable, adaptive business, at multiple levels of detail. Figure 6 shows the highest- An important implication of the need for continuous, level model. iterative, and adaptive architecting is that the Plan- For more-detailed levels of this model, see our White Design-Implement-Manage (PDIM) lifecycle commonly Paper (SBSA Partners 2010). used for systems development needs some revision. Specifically, it needs to be: We developed this model by adding sustainability considerations to a commonly used model of the 1. Front-ended with a phase to sense and interpret organization as an adaptive system (Rummler & Brache what is happening in the business environment, 1995). paying particular attention to potential disruptions Even in this high-level model, you can see small but important changes: 2. Back-ended with a phase to monitor and adapt to significant changes in the context • The addition of Waste with a recycle loop In addition, there must be an initial decision to commit • The usual “shareholders” is generalized to the enterprise to a sustainable way of thinking and Stakeholders operating, and a continuous effort to improve • The usual “competition” adds Collaboration sustainability-related mental models and use them across the entire extended enterprise. The resulting Sustainable Business Cycle is shown in Figure 5.

In addition, the Strategic Business Factors include the shown in Figure 7. The entries in the cells are disruptive full range of potential disruptions over all meaningful risk factors and impacts (color-coded for severity). timescales (not shown). Arrows show how some of the disruptions can flow from cell to cell.

Figure 6: Sustainable, Adaptive Business Model (Generic, High-Level) The architecture team creates the Sustainable Adaptive Figure 7: SEER Chart for Analyzing Cascading Resource Business Model, at multiple levels of detail, as part of the Risks (Example) initial Sustainability Architecture. The team then (Yellow and red circles indicate moderate and large continuously refines and adjusts it with each iteration of impacts, respectively.) the Sustainable Business Cycle. For example, as Sense & Interpret activities uncover relevant changes in the In this simplified example, the ongoing depletion of Oil Strategic Business Factors, including Resource shifts, Reserves, along with a rapidly increasing demand from the team updates the model to reflect these new developing countries, is triggering the economic risk of conditions. higher, volatile Oil Prices. These prices impact, and are impacted by, Global Car Use. Governmental Energy Sense & Interpret: Tracking Strategic Business Factors, Policy, including taxes, subsidies, leases, drilling Including Resources oversight, strategic reserves, etc., is a key co-factor in the disruptive threat. The cells with red circles are the Understanding strategic business factors is a crucial most impacted by the threat; for example, the overall precursor to strategy formation. In the Sustainable output of Goods & Services (GDP) of our Economy is Business Cycle, this is formally part of the Sense & directly tied to Oil Prices. In turn, the rate of depletion of Interpret phase, but, like architecting, is really a the Oil Reserves is directly impacted by the GDP, continuous activity. completing a causal loop. One of the biggest risks to any enterprise is a disruption Each cell has a broad set of information about the risks in its resources supply chain. This can be sudden as in associated with the cell, including description, the case of a storm, earthquake, or other natural disaster magnitude, likelihood, scope, and relevance of impacts; or infrastructure failure. Or it may be gradual, as in the upstream and downstream linkages; timeframes; case of resource depletion. It may range from relatively information sources and uncertainties; and opportunities, short-lived to permanent, partial to complete. In our strategies, and actions. global economy with lean supply chains and volatile but We have found that by adopting a broad understanding generally rising energy and commodity prices, the risk of of resources, we can model all disruptions as resource- resource disruption is a primary strategic factor. related risks (see Figure 8). Thus, the SEER chart As previously discussed, a sustainable enterprise needs becomes a broadly useful risk management tool. to pay attention to societal and natural environment An important reason for architects to participate in the considerations as well as economic ones. We have Sense & Interpret phase is to better understand which found it helpful to cross these three domains (Society, potential disruptions require architectural flex points Economy, Environment) with a full range of Resource (aspects that can be readily changed to accommodate risks to create a general model for analyzing potential likely needs; for example, re-usable services and risks and how they might cascade to other resources, configuration parameters). producing impacts in any or all of the three domains. We call this matrix a SEER chart, an example of which is

14 © Journal of Enterprise Architecture – February 2012

enterprise‘s future capabilities must also be viable under each of the plausible futures.

Figure 8: SEER Resources Taxonomy

Strategize & Plan: Sustainable Strategic Planning

Given the large degree of uncertainty across a wide range of interconnected risks, how does the architect Figure 9: Process for Developing Sustainable Business make choices that enhance the enterprise’s adaptive Idea and Capabilities capacity? The simple answer: by participating in the Enterprise Architects use this information about future strategic conversation (a continuous senior-management conditions, Sustainable Business Idea, and Sustainable dialog about directions and key decisions) that is an Capabilities to build the needed capabilities and flexibility integral part of the Strategize & Plan phase. into the enterprise’s future-state architecture. Many practitioners of EA take the view that strategy formulation is not part of the architect’s job description. Architect & Build: Sustainable Architecting Strategy, however, is concerned with the fit of the business with the emerging business context. The As previously mentioned, the first stage of creating a organization must evolve its unique competencies and Sustainable Enterprise Architecture is to define a capabilities to remain competitive. Architects define Sustainability Architecture for the business, which is then capabilities, and hence their participation in the strategic used to guide the transition to a full SEA over time. conversation is imperative. Figure 10 shows the high-level process that is used We believe that the scenario-based planning approach, during each iteration of the cycle to improve the championed by Royal Dutch Shell (van der Heijden sustainability of the EA, starting with the outputs from the 2005), amongst others, provides especially powerful Sense & Interpret and Strategize & Plan phases. insights to guide the strategic planning process. In this approach, senior management adopts a small number of potential scenarios that cover the full landscape of possible future conditions. The scenarios, however, are strictly limited to plausible futures only; that is, future states—including the status quo—that can’t be ruled out because reaching them, or staying in them, would take “too many miracles”. The process also divides future conditions into those that are “locked-in” and those that are truly uncertain. Locked-in change refers to conditions that are already inferable from present conditions; e.g., future school populations are predetermined by current birth rates; downstream flooding is predictable from upstream water Figure 10: Process for Developing Sustainable Enterprise levels. Strategic planners must incorporate locked-in Architecture changes into any future directions. The Landscape component of the Sustainable Figure 9 shows the high-level process strategic planners Enterprise Architecture (lower right in Figure 10) can use to adapt the enterprise’s fundamental Business describes how the architecture is guided and Idea to be sustainable; that is, to accommodate locked- constrained by the SEER information and the in future change as well as each scenario. Of course, the Sustainable Strategy.

The next section provides an overview of the subsystems and components, and reducing the Capabilities and Platforms components of the SEA; it is costs of technology refresh. followed by a discussion of the sustainability-related • Virtual and local: Increase virtual and local qualities of the architecture. operations to reduce the need for travel and transportation. Sustainable Capabilities and Platforms Effective platforms follow these same principles. In Business capabilities and platforms are central to addition, they provide leverage by propagating the Enterprise Architecture. benefits to all capabilities built on the platforms, at low or Businesses sustain themselves by providing a range of no additional cost to each capability. attractive capabilities to their customers. Business Of note in all of these strategies is that they not only capabilities constitute the top-level services of the improve enterprise sustainability, but also save costs. business architecture. They are provided by the An important aspect of the platform is its ability to business’s systems, and include or make use of people, disseminate information in real time to all people and processes, technology (including automated systems), enterprise systems that need to know, including information, and other resources (physical plant, management and operation center dashboards. Delta materials, energy, working capital, business agreements, Airlines developed such a “digital nervous system” using etc.). a service and event-based architecture (Weil 2003). A business capability can be as simple as a physical A number of sustainability dashboards have appeared, product or service. However, even simple offerings providing quick access to sustainability-related metrics. require delivery channels and support. Many of today’s These range from global and national sustainable products involve whole ecosystems of related products development indicators (CGSDI 2011) to a and services that must function together as a cohesive “comprehensive view of economic, ecological, and social capability. aspects” of data center and cloud computing (Bash et al. A business platform is a set of lower-level capabilities 2011). upon which the top-level business capabilities are built There are also a number of recent commercial products and operated. The platform may be offered to clients and in the business sustainability dashboard space, many other parties (e.g., as “cloud” services), or it may be with a focus on energy and water use and carbon restricted to use by the enterprise itself and perhaps its emissions. business partners. By providing a common, stable base, the platform facilitates the creation, operation, and As dashboards evolve, we anticipate that they will begin evolution of an integrated set of business capabilities. An to provide insight on strategic, long-term disruptive risks, effective platform enables strategic agility (Ross et al. including risks originating outside the enterprise. As 2006). such, they will likely become integral to the practice of SEA. Important principles that architects can adopt to improve the sustainability of the enterprise’s business capabilities Sustainability as the Prime System Quality include: • Radical efficiency: Revise mental models and re- The most fundamental need for a business is to stay in architect to deliver products and services with business, surviving and ideally thriving in the face of radically more efficient use of resources. See, for even significant disruptions. Accordingly, business example, the work of the Rocky Mountain Institute sustainability is the prime system quality that the (RMI 2010; Lovins 2010). architecture for the business capabilities and the platform must ensure. • Zero waste: Eliminate product and service waste and emissions using Life-Cycle Assessment (EPA To be sustainable, a business needs not only to address 2011) and Zero Waste strategies (Langenwalter supply chain security and disruptions to business 2006; ZWA 2011). operations, but also to look beyond them. The entire landscape within which the business provides value • JIT-JIC balance: Balance Just-In-Time lean supply could be greatly altered. Sustainability thus requires that chains with Just-In-Case alternatives that reduce the enterprise continuously adapt to provide goods and the impact of disruptions. services that: • Build for change: This preserves overall system • Fit the customers’ purposes (address their evolving value by effective modularity and configurability, needs and concerns) accommodating different lifetimes for different

16 © Journal of Enterprise Architecture – February 2012

• Maintain a high degree of Usability with minimal overall EA. Over time, you can use the Sustainability requirements for customer adaptation Architecture to guide broader integration of sustainability concepts throughout the entire EA, transforming it into • Remain Safe within the evolving operational an SEA. This is similar to the way most EAs use a context security architecture to ensure that the entire EA • Continue to be Economical as the landscape addresses security appropriately. changes Figure 11 illustrates these four essential supporting Architect & Build: Sustainable Building qualities with the FUSE acronym. These four, in turn, must be supported at the next layer by a variety of The Architect & Build phase addresses how additional system qualities. sustainability is realized in the capabilities and platform. In the Build sub-phase, the architect actively engages in helping to interpret the sustainability architecture. The architect and developers, working together, respond to unforeseen problems and thus learn by doing. As new sustainability approaches to architecting and building become better understood, they are incorporated into a growing body of knowledge of sustainable practices, which over time become standard practices.

Deploy & Operate: Getting Sustainability into your Business Operations

The benefits of sustainable architecting are, of course, only realized once the sustainability-based improvements to systems are placed into operation. These improvements include retrofits, reconfiguration, and upgrades of existing systems to achieve efficiency and long-term viability. It is critical for architects to be actively involved in this phase to ensure that the Figure 11: Hierarchy of System Qualities sustainability benefits are actually being achieved in practice. For example: Change management is a critical success factor when • Fitness-for-purpose/utility requires situational modifying people-related systems, and this means awareness to meet the rapidly evolving needs and minimizing user disruptions. We introduce the principle concerns of the business and other stakeholders, of “progressive transition” to emphasize designs that including scaling (up or down) as well as facilitate user acceptance of changes. responding to disruptions. • Usability requires not only manageability and Monitor & Adapt: Recognizing Key Signals and customizability, but also graceful evolvability Responding Effectively (adaptability over the long term) and business continuity/resilience for shorter-term disruptions. While all enterprises monitor operations on a day-to-day basis, many are not equipped to recognize trends that • Safety broadly includes not only potential physical are potentially disruptive over a longer term. In addition, damage but also the security, privacy, reliability, while they may be focusing on certain performance etc. of information communication and storage. measures, they may be overlooking other critical • Continuing to be economical within a landscape of indicators, especially those external to the enterprise. increasing resource costs may require the The analyses carried out in the Sense & Interpret and enterprise to adopt a strategy of radical efficiency in Strategize & Plan phases depend upon assumptions its operations while remaining socially responsible about uncertain conditions. These analyses may also and environmentally sound by internalizing true identify events that would signal the timing of locked-in lifecycle costs. changes or the likelihood of one scenario over others. A good way to ensure that your Enterprise Architecture Sustainability monitoring looks for these signal events addresses sustainability considerations effectively is to and triggers re-examination of relevant strategic include a Sustainability Architecture as part of your

business factors, allowing the organization to react, and Sustainable Business Checklists potentially change direction, in a timely fashion. An effective means for introducing sustainable business With a clear understanding of the flexibility incorporated practices and methods is the adoption of Sustainable into the deployed systems, the architect helps the Business Checklists, which help you get the important organization respond rapidly and effectively. things right. Rather than providing an exhaustive list of GROWING ADAPTIVE CAPACITY INTO A CORE things to do, these checklists focus on the essentials that COMPETENCY together “solve the problem”, change the culture to focus on the right problem, and include only what are While it is possible to anticipate some disruptions and necessary and sufficient additions to common practice. make relevant preparations, there will always remain They incorporate many of the insights used in the considerable, irreducible uncertainty about what will medical field to address significant problems that have happen, when, and with what impacts. Accordingly, resisted technology-based solutions (Gawande 2010). successful organizations must not only prepare for what is foreseeable, but also grow their ability to deal We have developed prototypical checklists for each effectively with uncertain and unforeseen disruptions. phase of the Sustainable Business Cycle (Figure 5). Before any checklist can be put into operation, it must be Recent research has identified three traits common to tailored to each organization by those who will be using companies that significantly outperformed comparison it. companies, over a period of at least 15 years, in a highly disruptive business environment: fanatic discipline, Example checklist items for the Strategize & Plan phase empirical creativity, and productive paranoia (Collins & include: Hansen 2011). These are characteristics of the entire • Are all key stakeholders involved in the strategic business, to which the practice of SEA could make a conversation, including Enterprise Architects? large contribution by focusing on: planning for the long • Is there a mechanism to ensure that participants term, support for limited deployments of new capabilities challenge BAU assumptions? Is there a catalog of before scaling up, and tracking a broad range of strategic resource risks to be considered? disruptive risks and building in alternatives for addressing them. • Is there a robust process for scenario selection, including recording of what was rejected and why? Sustainable Business Methods • Are your Sustainable Business Idea and Capabilities regularly analyzed for viability under Successful businesses would do well to formalize these identified locked-in-change conditions and all SEA contributions as part of a set of Sustainable plausible future scenarios? Business Methods, which would also cover sustainable business strategy (already discussed in Strategize & Example checklist items for the Architect & Build phase Plan: Sustainable Strategic Planning) and sustainable include: governance (discussed in Sustainable Governance and • Do you have a Sustainability Architecture as part of Learning). Together, the methods help you define your EA? Is it used in architectures at all levels disruption-resistant directions and initiatives, evolve (enterprise through solution)? Does it address long business capabilities, and manage change. and short-term trade-offs, helping you find You will also need methods to manage disruptive risks, immediate benefits for working toward long-term including procedures for maintaining and using your goals? SEER information and for handling signals associated • Does your architecture identify and describe flex with disruptive events. points and how they are intended to help you adapt For TOGAF® practitioners, the Preliminary phase would to a range of disruptions? Are the flex points be extended to include a more complete examination of designed to be stable over the long term? the business environment and its disruptive factors. • Are you using sustainable, adaptive systems These would be retained in the repository and updated thinking for dealing with complexity and as the situation changes, possibly triggering changes to uncertainty? Have you identified a comprehensive the requirements and/or rework in any of the phases. range of stakeholder issues and appropriate The sustainable business methods can be introduced systems boundaries for addressing each? and improved over time using a sustainable business • Have you architected in the flexibility to make real- capability maturity model (a formal way to assess the time adjustments between just-in-time and just-in- development level of an organization’s sustainability practices).

18 © Journal of Enterprise Architecture – February 2012

case operations based upon resource supply-chain • Productive paranoia: They will pay obsessive threats and disruptions? attention to the myriad things that can go wrong and find effective trade-offs between efficiency and Sustainable Governance and Learning safety, innovation and continuity, the short and the long term, and across societal, economic, Improving sustainability requires that businesses environmental, and resource challenges. measure sustainability and integrate sustainability considerations into everyday practices. This includes the To succeed, architects must work with business leaders continuous monitoring and evaluation of both internal and sustainability experts to: and external events, making decisions, and taking timely • Redefine goals and directions to make clear that action to adapt and revise strategies and operations. the fundamental goal is sustaining the business in Because a disruptive environment necessitates much uncertain, disruptive times on-the-job learning, it is best to integrate learning, doing, • Shift thinking to a deeper level, with a greater focus and governance (Gharajedaghi 2006). In particular, it is on understanding long-term contextual shifts and important to record the reasoning behind each significant systems interactions decision so that a future review of the decision can • Craft Sustainable Enterprise Architectures (SEAs) maximize learning. More fundamentally, future parties with capabilities, platforms, and system qualities can use this information to understand why a decision that help define and enable strategic agility was made and “unmake” it or know how to revise it if the circumstances have changed. • Improve adaptive capacity, turning it into a core competency Making decisions about funding proposed initiatives is a basic part of governance. Accordingly, a critical skill for Immediate steps that architects can take are to: sustainable Enterprise Architects is the ability to create • Learn more about business sustainability and the strong business cases for projects that have relatively management of disruptive risks across all SEER long timeframes for return on investment. Two general (Society, Economy, Environment, and Resources) strategies are possible: dimensions. • Develop financial models for the cost of avoided • Participate actively in your company’s strategic disruptions conversation. Seek first to understand the dynamic • Rethink the project to include more short-term business context and its implications for the returns along with the longer-term benefits practice of SEA, and then to convince others of the beneficial role SEA can play in helping the While this article does not attempt to quantify the company to meet its challenges. benefits of making a SEA Change, many authors do discuss costs and savings associated with • Start crafting your Sustainability Architecture. efficient/sustainable design and operations. The • Share SEA ideas with other SEA practitioners to referenced works offer rather different but helpful increase our common body of knowledge. Use perspectives (Bash et al. 2011; Esty & Simmons 2011; these ideas in your practice, and grow your Lamb 2009; Lovins 2010; McKinsey 2012). competency. SUMMARY AND PRACTICE RECOMMENDATIONS ABOUT THE AUTHORS Today’s business landscape is characterized by Leo Laverdure ([email protected]) is a pervasive, unrelenting, and disruptive change. managing partner of SBSA Partners, LLC. He has led a Businesses that thrive in this business climate will number of Enterprise and Solution Architecture exhibit: programs at HP and other companies, serving as lead • Fanatic discipline: They will pursue with intensity architect for HP’s Adaptive Enterprise and heading up clear, long-term goals with steady, measured their Architect profession. Leo holds a BA from Harvard progress, maintaining deep reservoirs of resources University. He is a member of the Sustainability and agile capabilities and platforms to take Commission for the town of Groton, Massachusetts. advantage quickly of favorable conditions Dr. Alex Paul Conn ([email protected]) is a presented by disruptive change. managing partner of SBSA Partners, LLC. He has • Empirical creativity: They will sense the business extensive experience as both a practitioner and environment, test innovative and efficient offerings professor in computer systems architecture and until they are certain of their merits, scale them engineering, concentrating on the early business-critical rapidly but judiciously, and then repeat. development phases. His focus on system qualities

stresses the importance of minimizing the disruptions https://www.mckinseyquarterly.com/Strategy_under_uncertaint introduced by changes in systems architectures and y_1064. associated policies and governance. Alex received his McKinsey & Company: Resource Revolution: Meeting the PhD from University of California, Berkeley. world’s energy, materials, food, and water needs (2012); available at: REFERENCES www.mckinsey.com/Features/Resource_revolution.aspx. Ambler, G.: Systems Thinking as a Leadership Practice (2006); Meadows, Donella: Thinking in Systems: A Primer, Chelsea available at: www.thepracticeofleadership.net/systems- Green, White River Junction, VT (2008). thinking-as-a-leadership-practice. Nielsen-Gammon, J.: Texas Drought and Global Warming Bash, C., Cader, T., Chen, Y., Gmach, D., Kaufman, R., (2011); available at: Milojicic, D., Shah, A., Sharma, P.: Cloud Sustainability http://blog.chron.com/climateabyss/2011/08/texas-drought- Dashboard, Dynamically Assessing Sustainability of Data spot-the-outlier/. Centers and Clouds, HP Laboratories, HPL-2011-148 (2011); available at: www.hpl.hp.com/techreports/2011/HPL-2011- Owen, C.: Fostering Business Resilience (2004), available at: 148.html. www.interisle.net/sub/Business_Resilience.pdf.

CGSDI, Consultative Group on Sustainable Development Rechtin, E., Maier, M.: The Art of Systems Architecting, Indicators: Dashboard of Sustainability (2011); available at: Second Edition, CRC Press, p. 234 (1997). www.iisd.org/cgsdi/dashboard.asp. Ribeiro, J.: Thailand Floods Hit Hard Drive Production, Collins, J., Hansen, M.: Great By Choice: Uncertainty Chaos, Macworld website (2011); available at: and Luck—Why Some Thrive Despite Them All, HarperCollins www.macworld.com.au/news/thailand-floods-hit-hard-drive- Publishers, New York (2011). production-39511.

Coy, P.: Japan: Economic Aftershocks, Bloomberg RMI, Rocky Mountain Institute: Factor Ten Engineering Design Businessweek (March 30, 2011); available at: Principles (2010); available at: www.rmi.org/10xE+Principles. www.businessweek.com/magazine/content/11_15/b422301261 4574.htm. Ross, J.W., Weill, P., Robertson, D.C.: Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, EPA, Environmental Protection Agency: Life Cycle Assessment Harvard Business School Press, Boston (2006). Research website (2011); available at: www.epa.gov/nrmrl/lcaccess. Royal Dutch Shell: Shell Energy Scenarios to 2050 (2008); available at: www-static.shell.com/static/public/downloads/ Esty, D., Simmons, P.J.: The Green to Gold Business brochures/corporate_pkg/scenarios/shell_energy_scenarios_2 Playbook: How to Implement Sustainability Practices for 050.pdf. Bottom-Line Results in Every Business Function, Wiley, Hoboken, NJ (2011). Rummler, G., Brache, A.: Improving Performance: How to Manage the White Space on the Organization Chart, Second Gawande, A.: The Checklist Manifesto: How to Get Things Edition, John Wiley & Sons, Inc., Hoboken, NJ, pp.10, 82 Right, Metropolitan Books, New York (2010). (1995).

Gharajedaghi, J.: Systems Thinking: Managing Chaos and SBSA Partners: Improving Business Sustainability, pp.15-16 Complexity: A Platform for Designing Business Architecture, (2010); available at: http://sbsapartners.com/Limited/Improving- Second Edition, Elsevier, Butterworth-Heinemann (2006). Business-Sustainability-4dnld.pdf.

Lamb, J.: The Greening of IT: How Companies Can Make a Senge, P.: The Fifth Discipline: The Art and Practice of the Difference for the Environment, IBM Press/Pearson plc, Upper Learning Organization, Doubleday/Currency, New York (1990). Saddle River, NJ (2009). Sherwood, J., Clark, A., Lynas, D.: Enterprise Security Langenwalter, G.: ”Life” is Our Ultimate Customer: From Lean Architecture White Paper (2009); available at: to Sustainability, Target Magazine, Volume 22 No. 1, www.sabsa.org/whitepaperrequest.aspx?pub=Enterprise+Secu Association for Manufacturing Excellence (2006); available at: rity+Architecture. www.zerowaste.org/publications/Lean_to_Sustainability.pdf. Sterman, J.: Sustaining Sustainability: Creating a Systems Lovins, A.: Profitable Solutions to Climate, Oil, and Science in a Fragmented Academy and Polarized World; Proliferation, Royal Swedish Academy of Sciences, Springer available at: http://jsterman.scripts.mit.edu/On- (2010); available at: www.rmi.org/Knowledge- Line_Publications.html#2011sustaining. Center/Library/2010-18_ProfitableSolutionsClimateOil. The Open Group and SABSA Institute: TOGAF® and SABSA McKinsey & Company: Strategy Under Uncertainty, McKinsey Integration: How SABSA and TOGAF complement each other Quarterly (2000); available at: to create better architectures (2011); available at: www.opengroup.org/bookstore/catalog/w117.htm.

20 © Journal of Enterprise Architecture – February 2012

van der Heijden, K.: Scenarios: The Art of Strategic Weil, P.: MIT's Weill on Leveraging Infrastructure, CIO Insight Conversation, John Wiley & Sons, Ltd., Chichester, England interview; available at: www.cioinsight.com/c/a/Past- (2005). News/MITs-Weill-on-Leveraging-Infrastructure.

WEF, World Economic Forum: Global Risks, Sixth Edition ZWA, Zero Waste Alliance: Publications and Case Studies (2011); available at: www.weforum.org/reports, (2011); available at: www.zerowaste.org/publications.htm. http://riskreport.weforum.org/global-risks-2011.pdf.

Article

Maturity Matters: Generate Value from Enterprise Architecture

By Jeanne W. Ross and Cynthia M. Beath

Abstract This two-part article is an introduction to MIT’s EA maturity research. This first article*, introduces a series of research studies at MIT’s Center for Information Systems Research, including survey results from 2004, 2007, and 2010. In the second article, in the next number of JEA, the findings from the 2011-2012 update of the research will be presented. * This article is based on J. Ross: Maturity Matters: How Firms Generate Value from Enterprise Architecture (Rev. February 2006), MIT Sloan CISR Research Briefing, Vol. IV, No. 2B, July 2004, and J. Ross and C. Beath: Maturity Stilll Matters: Why a Digitized Platform is Essential to Business Success, MIT Sloan CISR Research Briefing Vol. XI, No 2, February 2011.

In order to better serve their customers and to cut by virtue of historical investment patterns that focused operating costs, firms have increasingly been instituting on business cases addressing local business needs. enterprise-wide efforts to leverage synergies and reap economies of scale. Initiatives such as One State Street, One DuPont, and JPMorgan Chase’s “one firm—one team” place IT in the role of strategic enabler. CISR research indicates, however, that firms can’t just decide to use IT strategically, write a slogan, and then reap the rewards. Rather they must learn how to make IT a strategic competency. A firm’s learning about the strategic role of IT can be represented in four stages of Enterprise Architecture (EA) maturity. A firm’s EA is the organizing logic for business processes and IT infrastructure, reflecting the integration and standardization requirements of the firm’s operating model. In our 2004 survey of 103 firms, we acquired specific data on investment patterns and management practices associated with the four stages of architecture maturity. Figure 1: Architecture Maturity Stages In this study, firms achieving greater architectural maturity reported lower IT costs, shorter IT development As shown in Figure 1, firms shift their investments away times, greater discipline in their business processes, and from local applications and into shared resources as more strategic benefits (e.g., customer intimacy, product they move through the second and third stages. In the leadership, and strategic agility) from IT. In the following, second stage, firms are developing shared infrastructure we describe how firms capture and formalize the services. Firms like State Street and Carlson migrated to learning from each architectural stage so that they can this stage in an attempt to generate cost savings through benefit from the current stage and, if appropriate, technology standardization and consolidation. migrate toward later stages. By the third stage—Optimized Core—firms are sharing data and standardizing business processes. Firms like IT INVESTMENT PATTERNS Air Products and MeadWestvaco moved into this stage As firms learn to apply IT more strategically, they evolve through an investment in an ERP, while Delta Air Lines their IT investment patterns. For example, firms in the focused on developing shared data to enhance customer first stage—Business Silos—invest heavily in local service and airline operations. applications. In some cases this investment pattern Finally, in the fourth stage, firms’ investment patterns are represents a strategic choice. Holding companies, for focused on smaller, re-usable application and process example, may choose to be stage 1 firms. Most components to support a more modular operating model. companies, however, have been (or still are) in stage 1

22 © Journal of Enterprise Architecture – February 2012

Firms like ING Direct and Marriott create standard business application modules that can be used by any of their business units. Firms apply re-usable application modules in new business units or purchase modules from vendors. In addition to the variation in investment patterns, we found that IT spending levels varied from stage to stage (see Figure 1). IT budgets in the first stage are high because firms have limited opportunities for enterprise- wide purchase agreements, sharing of technical expertise, and consolidation of data centers. Not surprisingly, IT spending decreases as firms introduce first hardware and then software, process, and data standards. Late in the third stage the IT spending pattern appears to reverse itself. By stage 4, firms in our study were spending more on IT than stage 1 firms. While this finding may discourage firms from moving into later Figure 2: Evolving Management Practices for Designing stages of architecture maturity, it is important to and Protecting Architecture recognize that firms are gaining greater strategic benefits from IT and thus will find it easier to justify IT Management Practices Key to Stage 2 expenditures. In addition, we don’t know if the experiences of early adopters will prove representative Practices that were associated with greater IT value in of the experiences of all firms. stage 2 included three mechanisms facilitating more centralized IT funding: IT GOVERNANCE AND MANAGEMENT PATTERNS As firms’ investment patterns change, they also start to • An IT steering committee generate different kinds of value (see Figure 1). But • An infrastructure renewal process getting value from IT demands far more than investment • Centralized funding of enterprise applications in building out the technical requirements of the architecture. We have learned that when IT units build These funding initiatives help firms support enterprise- enabling IT capabilities, firms may—or may not—derive wide initiatives and are important to the migration from value from them. Managers must introduce new stage 1—where firms think about optimizing local management practices to formalize organizational business needs—to stage 2, where firms focus on learning about how to manage IT investments and maximizing the benefits of standardized technologies generate IT value. They will not achieve increased value across the firm. The other mechanisms of particular from simply changing investment patterns. value in stage 2 are all related to managing a standardized technology environment: Management Practices Key to Stage 1 • Architects on project teams In our study respondents rated the value they received • An architecture exception process from a set of IT management practices, and we • Formal architecture compliance process determined statistically which practices generated greater value as architecture matured (see Figure 2). • A centralized standards team For example, in stage 1, key practices supporting firms’ Together, the seven practices important to stage 2 efforts to generate value from application silos were: reflect the growing need for IT governance to address the challenges of using IT as an enterprise-wide, rather • Well-designed business cases than business unit or functional, asset. • A standardized project methodology Management Practices Key to Stage 3 These two practices encapsulate the requirements for generating value from local applications. They can help Following on technology standardization in stage 2, key firms generate value at any stage, but firms that acquire management practices in the third stage help firms the learning associated with these practices at an early adjust to process integration and standardization. While stage are better positioned to generate value from technology standardization has its challenges, process subsequent IT investments. standardization will surely confound and irritate business

unit leaders. Practices emerging as important in stage 3 IT management. We have found no shortcuts to emphasize the increased role of senior management in business value from IT. setting direction and defining enterprise-wide processes. These include: THE TANGIBLE OUTCOME OF ENTERPRISE ARCHITECTURE IS A DIGITIZED PLATFORM • Enterprise-wide process owners Ongoing MIT CISR research has found that the tangible • A statement of EA guiding principles outcome of EA efforts is a digitized platform. This • Business leadership of project teams platform, which we define as a coherent set of standardized business processes along with supporting • Senior executive oversight of architecture initiatives infrastructure, applications, and data, intended to ensure • IT program managers the quality and predictability of core transactions, These five practices highlight the need for senior provides the foundation for doing business in a digital management to articulate business direction, and to economy. implement IT-enabled processes to fulfill the business EA provides the blueprint for the digitized platform. It vision. captures both business and IT requirements and depends on a set of evolving management practices. IT Management Practices Key to Stage 4 leaders have long recognized the importance of EA. But the importance of digitized platforms makes architecture Finally, in the fourth stage, firms were implementing a critical business capability. In this briefing we provide practices for communicating and assessing IT. These new evidence that helps explain how architecture included: maturity—and the digitized platforms it generates—has • A one-page graphic for communicating an become essential to business success. enterprise vision ENTERPRISE ARCHITECTURE REVISITED • Post-implementation assessment EA articulates a firm’s core transaction processes and • A formal research and adoption process defines how data from those transactions is shared with • A full-time EA team employees, customers, and partners. Unlike the architecture of a building, EA evolves, reflecting These four practices could seemingly add value at any organizational learning about optimal business process stage, but their delayed importance to firms in this study design, organizational structure, and governance of and our prior experiences studying IT management decision rights. practices suggest that firms are failing to take advantage of these tools at an earlier stage. They are valued by While the four stages described earlier have been in firms in stage 4 because these firms have generally evidence for some time, the distinctions among these benefited from good IT management practices. The stages and the need for firms to progress through them survey instrument did not collect behaviors such as in sequence has been confirmed repeatedly in our developing directories of re-usable process components, research since 2004. Recent data show a large increase but we anticipate that the ability to create and re-use from 2007 to 2010 in firms that are building and application components is critical to the fourth stage. leveraging digitized platforms (stages 3 and 4; see Figure 3).1 ALL MANAGEMENT PRACTICES SUPPORT The journey across the four stages is transformational. BUSINESS VALUE One indicator of that transformation is the shift in IT What is important to note about the management spending patterns. As reflected in Figure 3, firms in practices listed in Figure 2 is that they are cumulative. stage 2 make cutting IT costs a priority. In contrast, firms Practices key to value in stage 1 are still important in in stage 4 spend heavily on IT. But the scope of the IT stage 2—in fact, they are more important. Thus, if firms unit’s responsibility in stage 4 more often encompasses do not acquire good practices in early stages, they business operations, manufacturing floor control reduce the odds that they will be able to generate systems, digital product development, or shared significant value from their IT initiatives in later stages. services. Long lists of failed ERP and CRM implementations, lightly used data warehouses, and abandoned workflow management systems highlight the potential for wasting money on IT. We interpret these findings to mean that firms embarking on an EA journey should plan for steady 1 2007 data in this briefing is from a joint MIT CISR/Gartner survey of increases in IT value through gradual enhancements in 1508 CIOs; 2010 data is from a joint MIT CISR/CIO Magazine survey of 206 CIOs.

24 © Journal of Enterprise Architecture – February 2012

reduced out of stocks in customer stores from 14% to 3.7%, was possible only because PepsiAmericas had built a foundation of standardized processes and systems and enriched it with a powerful information backbone (Beath and Ross, 2010).

Figure 3: The Stages of Architecture Maturity Changing organizational mindsets are also visible in the allocation of IT spending between run and build. In stage 2, IT leaders work to shift funds from run to build to gauge success in eliminating inefficiencies. By stage 4, IT leaders are attempting to minimize capital expenses, Figure 5: Firms’ Digital Capabilities Relative to taking advantage of the opportunities of business Architecture Stage process outsourcing and Software as a Service (SaaS). Our data also indicates that mature firms are better As one CIO described it, once the IT unit had learned to positioned for generating benefits from digital manage services and unit costs: “we stopped thinking of capabilities, such as business process optimization, IT run as bad, and started thinking of it as what keeps business analytics, master data management, strategic the business running”. In short, firms in later stages tend experiments, and digital product design (see Figure 5). to be much more focused on the value realized than the While some of these capabilities can develop within cost incurred from IT. pockets of expertise in siloed firms (e.g., business WHY A DIGITIZED PLATFORM MATTERS intelligence and design of digital products), a mature firm’s enterprise mindset and discipline compounds the Earlier MIT CISR research found that architecture impact of these capabilities enterprise-wide. Mature maturity was associated with firm profitability (Ross, firms’ sophistication of these digital capabilities is 2004). In the 2010 survey, CIO assessments of firm significantly correlated with architecture maturity. performance relative to competitors on dimensions like process efficiency, process innovativeness, and driving Again, case study data supports the statistics. For value from IT are highly correlated with architecture example, we have observed that master data maturity (see Figure 4). management efforts are often frustrated by an inability to preserve the integrity of the data. In contrast, PepsiAmericas approached data integrity issues by focusing on improvement of data collection processes when it built its platform. Process changes alone led to data that provided better decision-making support, but decision-makers still found problems. These problems motivated participation in governance practices that further enhanced the data—and further improved decision-making. What we have observed about mature firms is continuous improvement in their digital capabilities at an increasingly fast pace. For example, USAA, the financial services company serving the US military, needed a few Figure 4: Competitive Comparisons of Business years to build an integrated platform across its three Capabilities Relative to Architecture Stage businesses (property and casualty, banking, and Case studies of mature firms reinforce these findings. financial services like investments and life insurance) For example, PepsiAmericas, a stage 4 company, used (Ross and Beath, 2010). With the platform, USAA’s time customer transaction data as input into predictive to market for new systems in 2009 was 178 days, as models to suggest customer orders. This effort, which compared to an industry benchmark of 235 days. Those

systems leverage USAA’s platform by enabling rapid ABOUT THE AUTHORS innovation of new customer services on new technologies. Jeanne W. Ross is Director & Principal Research Scientist at MIT Center for Information Systems ARCHITECTURE MATURITY CHANGES Research. EVERYTHING Cynthia M. Beath is Professor Emeritus at University of John Kreul, who was Vice President of Applications and Texas, Austin. Customer Service at PepsiAmericas from its stage 1 days in the late 1990s through its journey to a stage 4 REFERENCES firm prior to its acquisition in 2010, noted that life in an C. Beath and J. Ross: PepsiAmericas: Building an Information architecturally mature firm is totally different from life in Savvy Company, MIT Sloan CISR Working Paper No. 378, earlier stage firms. For example, he said his work-life February 2010. balance improved because he—and all of IT—got more done in fewer hours. From a company perspective, he J. Ross: Generating Strategic Benefits From Enterprise noted that PepsiAmericas transformed from a company Architecture, MIT Sloan CISR Research Briefing, Vol. IV, No. with high IT costs and regular IT failures to one in which 3A, October 2004. IT issues were rare and readily resolved, project failures J. Ross and C. Beath: USAA: Organizing for Innovation and were nearly non-existent, and deployments consistently Superior Customer Service, MIT Sloan CISR Working Paper added measurable business value. Kreul’s comments No. 382, December 2010. suggest that life in an architecturally mature firm is as idyllic as architects advertise. To get there, firms must learn to do business on a digitized platform.

26 © Journal of Enterprise Architecture – February 2012

Article

Improving Government Enterprise Architecture Practice – Maturity Factor Analysis

By Adegboyega Ojo, Tomasz Janowski, and Elsa Estevez

This article is republished with permission from Proceedings of the 45th Annual Hawaii International Conference on System Sciences (HICSS’12), January 4-7 2012, Grand Wailea, Maui, Hawaii, IEEE Computer Society Press. Abstract Recognized as a critical factor for the whole-of-government capability, many governments have initiated Enterprise Architectures (EA) programs. However, while there is no shortage of EA frameworks, the understanding of what makes EA practice effective in a government enterprise is limited. This article presents the results of empirical research aimed at determining the key factors for raising the maturity of the Government Enterprise Architecture (GEA) practice, part of an effort to guide policy-makers of a particular government on how to develop GEA capabilities in its agencies. By analyzing the data from a survey involving 33 agencies, the relative importance of the factors like top management commitment, participation of business units, and effectiveness of project governance structures on the maturity of the GEA practice was determined. The results confirm that management commitment and participation of business units are critical factors, which in turn are influenced by the perceived usefulness of the GEA efforts.

resistance, organizational parochialism, lack of INTRODUCTION understanding by top management, and lack of human Increasingly, Government Enterprise Architecture (GEA) capital and funds (GAO 2006). While the challenges efforts are part of Electronic Government (EGOV) have not reduced the investment in the GEA programs; programs conducted by national and other levels of they have caused the repositioning of the GEA practice governments. One reason for the increasing prominence as a management concern; improvements in the of GEA as a management and technology practice in efficiency of the GEA process, methods, and frameworks government is its association with the transformational used by architects; and the emergence of performance government goals by influential global EGOV policy measures for the GEA practice maturity (van der Raadt reports such as the United Nations E-Government 2010). Presently, many GEA maturity assessment Survey (UN 2010) and the Waseda University World E- models are available, in line with the empirical Government Ranking (Waseda University 2011). observation that only those organizations that are According to the studies presented in Ojo et al. (2010) engaged in a mature GEA practice benefit from good IT and Ministry of Finance (2007), many leading countries management (Ross et al. 2006). in EGOV development have GEA programs towards Lately, various studies have been carried out on how to transformational government (Janssen and Kuk 2006). improve the effectiveness of the GEA practice. These GEA can be viewed as a practice or an artifact. As a studies examined the impact of the factors such as the practice, it enables rigorous description, design, and organizational culture and design (Raadt and Vliet 2008; analysis of organizational structures that span the Makiya 2009), stakeholder satisfaction (Raadt et al. boundaries of different organizations. As an artifact, it 2010) and operating models (de Vries 2009). In these comprises principles, methods, and models used to studies, GEA effectiveness is expressed in terms of design and implement organizational structures, explicit maturity models and includes satisfying business processes, and information systems and organizational and stakeholder-specific goals. Other infrastructure of an enterprise (Lankhorst 2009). factors like management commitment and leadership, Unlike in the private sector, the GEA practice is relatively participation of business unit, existence of strong recent and existing GEA initiatives show mixed results governance structures, and availability of skilled (Lagerström et al. 2001; Makiya 2009; GAO 2006). personnel were also highlighted (GAO 2006; According to Makiya (2009), over 40% of the GEA EADirections 2007; van der Raadt et al. 2010). programs will be stopped through 2012 due to poor However, an empirical investigation of the effects of execution. Typical barriers, based on the study of the 27 such factors on the maturity of the GEA practice is yet to GEA programs in the US federal agencies are: cultural

be reported. Despite the existence of 148 conference • The results are validated in Section 6, including papers, 66 journals, 29 books, and 15 book chapters on convergence with existing results. EA, EA management is yet to be accepted among the • Section 7 contains a discussion. core Information Systems research topics, considering that EA is often treated in an enterprise-specific way • Section 8 provides some conclusions. (Buckl et al. 2009). BACKGROUND This article addresses this knowledge gap through an empirical study of key maturity factors affecting the GEA This section provides a background to GEA. The section practice. The study examines seven factors identified in describes the GEA practice, the concept of GEA maturity the literature: and its influencing factors, and how the GEA practice supports EGOV initiatives. 1. Availability of external support 2. Availability of technical skills GEA Practice 3. Existence of project governance structures Formally, Enterprise Architecture (EA) is a holistic set of 4. Learning culture principles, methods, and models used in designing and 5. Management policies and processes realizing organizational structures, business processes, information systems, and infrastructure of an enterprise 6. Participation of strategic business units (Lankhorst 2009). A government enterprise, in turn, is a 7. Top management commitment co-ordinated set of activities involving one or more public By analyzing the data gathered through a survey and possibly private or third-party organizations (Ojo et involving 33 government agencies, the relative al. 2010b). importance of these factors on the level of GEA maturity Among the leading EGOV countries, many have ongoing is determined. In addition, we investigate how the GEA programs: Australia, Belgium, Canada, Denmark, perceptions on the usefulness of the GEA practice may Estonia, Finland, Germany, Korea, Netherlands, New affect the participation of strategic business units and Zealand, Norway, Singapore, South-Africa, Sweden, commitment of top management to EA programs. The Switzerland, United Kingdom, and United States results show that management commitment and (Ministry of Finance 2007; Ojo et al. 2010; Janssen and participation of business units strongly influence the Hjort-Madsen 2007). While specific reasons for EA maturity of the GEA practice, both depending on the adoption may vary, common reasons include (Ojo et al. perceived usefulness of GEA. However, we were unable 2010a): to conclude the criticality of the remaining factors based • Enabling interoperability and providing technical on available data. and managerial standards for agencies Given the lack of theories in the GEA domain, this work • Enabling resource sharing across agencies and contributes to building such a theory and provides a reducing the cost of IT and business operations by concrete basis for a deeper qualitative investigation of identifying duplications and opportunities for re- the seven factors. It also suggests plausible using business and IT services relationships between the factors. In particular, it confirms that the availability of skills, management • Enabling the development of shared processes and processes, external support, and learning culture are delivery of seamless services mediating factors with respect to the independent factors These reasons are consistent with the observation that for the GEA maturity – management commitment, the public sector EA deployment is often aimed at participation of business units, and availability of project addressing the decentralization of relationships between governance structures. central and local governments to better manage local IT- The rest of the article is organized as follows. related projects and activities (Janssen and Kuk 2006). • Section 2 presents a background to the GEA GEA is usually developed based on an existing EA practice. framework. Such frameworks provide methodologies to describe the process of developing and managing EA; • Section 3 documents related research on improving languages for modeling human, organizational, and this practice. technology aspects across various EA perspectives • Section 4 describes the adopted research (business, data, application, and technology); and methodology. enterprise models including re-usable reference models and designs (Ojo et al. 2010a). The GEA program • Section 5 describes the survey of the GEA practice analysis reveals typical elements of a GEA framework: including data gathering, analysis, and results.

28 © Journal of Enterprise Architecture – February 2012

EA goals, principles, and reference models, and EA creating EA awareness, managing GEA maturity, methods and interoperability frameworks (Ojo et al. completing GEA products, and leveraging GEA to 2010b). manage change. Lastly, we also consider the maturity Internally, GEA stakeholders include Government Chief assessment model for the State of Oregon, based on Information Officers (GCIO), Government Chief Gartner’s EA Program Maturity Self Assessment Model Technology Officers (GCTO), agency heads and heads (Amo et al. 2007). The model identifies several of business units, business and information analysts, assessment areas: architecture context, scope, impact, and project managers and IT officers (van der Raadt et authority, and development; stakeholder involvement al. 2010). Externally, GEA stakeholders include and support; business context; future state realization; government customers (business and citizens) as well and architecture team response. as civil society and private sector organizations (Solander and Paivarinta 2002). GEA Practice Maturity Factors To develop an efficient and effective GEA capability, GEA Practice Maturity government agencies must address several Several models exist for measuring the EA efforts. environmental and organizational factors. A number of These models either measure the maturity of the EA such factors have been suggested in the literature. practice or the effectiveness of the EA practice on IT For example, based on stakeholder responses, GAO management or on the organization as a whole. (2003) identifies 14 attributes that a GEA function must Based on Balanced Scorecards, an outcome-based possess to achieve effectiveness. These attributes approach for measuring enterprise system benefits is include: availability of governance structures, ability of described in Sedera et al. (2000) using four architects to communicate with stakeholders, clear roles, perspectives: vision, possession of functional knowledge, availability of technology, availability of governance processes and 1. Resource management accountability. Employed in Amo et al. (2007), the 2. Internal business processes Gartner’s EA self-assessment tool suggests that the 3. People, learning, and innovation enabling organizational factors for EA maturity include corporate management support, participation of 4. Client and community relationships business units, communication with stakeholders on A foundational framework for measuring the expected benefits and roles in the EA programs, effectiveness of EA (using a set of indicators) on architecture governance, and availability of resources. business-technology alignment and agility is described in According to Spewak and Hill (1995), the factors Bonnet (2009). Another set of indicators is provided in influencing EA program success include: effective van der Raadt et al. (2010). project leadership, end user and management By far, available EA measurements models are based participation, management support and commitment, on either maturity or efficiency. This can be explained as availability of resources, acceptable balance of scope, a certain level of EA maturity is required for any and trained team of consultants. For Enterprise meaningful outcome of the EA practice on organizational Resource Planning, 40 critical success factors include: goals (Makiya 2009). One of few theoretical results in EA top management support, inter-departmental maturity models, Steenbergen et al. (2010) proposes a communication, change and project management conceptual framework for analyzing EA maturity models abilities, motivation to collaborate, teamwork culture, and through core focal areas and the corresponding maturity clear goals and objectives (Shafaei and Dabiri 2008). In addition, 11 critical success factors for EA include: levels. business linkage, business unit participation, senior Considering government-focused EA maturity models, management involvement, and EA resources three GEA examples are examined here. The first by the (EADirections 2007). Finally, GAO (2006) identifies National Association of State Chief Information Officers leadership as the key factor to drive GEA-enabled defines the following levels of the GEA practice: operational and technology changes in US federal architecture planning, architecture framework, government. Organized into 11 categories, all these architecture blueprint, communication, compliance, factors are shown in Table 1. integration, and involvement (NASCIO 2003). The second by the General Accountability Office is a GEA management maturity framework consisting of maturity stages, GEA management, and critical success attributes (GAO 2003). GEA management includes:

Table 1: GEA Maturity Factors flexibility in service delivery. The GEA practice is expected to enable the realization of these features; for No. Factors Sources instance, as a dynamic capability required for inter- F1 Management commitment Gao 2006; organizational integration, service delivery coordination, Top management support EADirections 2007; technology integration, and the overall transformation to Senior management Amo et al. 2007; a virtual government enterprise (Klievink and Janssen involvement Spewak & Hill 1995; 2009). Leadership Shafaei & Dabiri 2008 Corporate support The dependency between EGOV development and the F2 Participation of business EADirections 2007; required EA support is presented in Table 2 (Saha 2009) units Amo et al. 2007; as a mapping between EGOV and GEA maturity stages. End-user and management Spewak & Hill 1995 The mapping utilizes the four-level GEA maturity model participation (Ross et al. 2006): F3 Project governance EADirections 2007; 1. Business Silos – optimizing the needs of structures GAO 2003; business units Effective project leadership Amo et al. 2007; 2. Standardized Technology – providing IT Compliance Spewak & Hill 1995 Architecture governance efficiencies through technology standardization and centralization of technology management F4 Technical skills GAO 2003; Technological knowledge Amo et al. 2007; 3. Optimized Core Architecture – providing Training and education Shafaei & Dabiri 2008 organization-wide data and process F5 Management policies/ EADirections 2007 standardization processes 4. Business Modularity Architecture – loosely- EA-related processes coupled, IT-enabled business process F6 External support Spewak & Hill 1995 components preserving global standards and Availability of consultants enabling local differences F7 Learning and change culture Shafaei & Dabiri 2008 Progression from Business Silos to Business Modularity Commitment to change requires addressing the EA maturity factors identified in F8 Functional knowledge GAO 2003 Table 1. F9 Communication EADirections 2007; Inter-departmental GAO 2003; Table 2: Mapping EGOV and GEA Maturity Levels communication Amo et al. 2007; GEA Communication with Shafaei & Dabiri 2008 stakeholders EA program communication F10 Availability of resources Spewak & Hill 1995; EA resources EADirections 2007 F11 Clear vision and goals EADirections 2007;

Realistic EA scope and GAO 2003; rchitecture objectives SiloBusiness Standardized Technology Optimized Core A Business Modularity Shafaei & Dabiri 2008 Web Presence X Interaction X X Supporting EGOV with GEA Transaction X X EGOV A major application area for the GEA practice, Electronic Transformation X X Government (EGOV) is defined as strategic use of For EGOV development, various staged models are Information and Communication Technology (ICT) by available in the literature. The model applied in Saha governments to enable transformation in service (2009) consists of four-stages: delivery, relationships with key stakeholders, and 1. Web Presence – provision of (non-interactive) internal working and management in government. The websites by agencies next wave of EGOV is associated with connected government (Saha 2009), transformational government 2. Interaction – enabling two-way communication (Parisopoulos et al. 2009), holistic government (Peng with citizens and businesses through websites Peng 2005), and whole of government (Martin 2004) and other channels paradigms. Common features across these paradigms 3. Transaction – electronic initiation and completion include: the integration of all levels of government, of requests by citizens delivery of seamless and joined-up services, and

30 © Journal of Enterprise Architecture – February 2012

4. Transformation – provision of seamless services In addition, the work studies whether technology and and integrated policies across sectors and levels organizational environment are moderating variables in of government, and integration with the entities this context. Unfortunately, the status and results of this from the private sector and civil society work are not available. Table 2 shows the required maturity of the GEA practice While two of the publications above investigate EA for each of the four EGOV maturity levels based on maturity issues in the government context, none of them Saha (2009). investigates the impact of organizational factors in Table 2 on the EA practice maturity. The goal of this article is RELATED WORK to address this gap by developing additional This section reviews related empirical or theoretical understanding of how these factors directly impact the research aimed at providing a better understanding of development of the agency EA capabilities. how the GEA practice can be improved. Unfortunately from our literature review, few scholarly publications RESEARCH APPROACH exist that provide quantitative or qualitative analysis of Following the background and related work presented in the GEA success factors. Among them, four such Sections 2 and 3, we now articulate the theoretical publications are summarized below. framework for our work, and present research questions The first investigates the relationship between GEA and hypotheses to be investigated, and the design of our effectiveness and stakeholder satisfaction (van der study. Raadt et al. 2010). By adopting a theoretical framework based on customer satisfaction and cognitive structures Theoretical Framework and means-ends chain analysis, van der Raadt et al. A number of important constructs can be identified from (2010) conducts a qualitative analysis of the agreement the body of the EA literature related to this work. These between the overall organizational goals for GEA and include EA Effectiveness, EA Maturity, EA Stakeholder the goals of individual stakeholders. Satisfaction, EA Function Design, and EA Environment. The second publication (Jensen 2010) applies an In this section, we develop a theoretical model to relate empirical approach to demonstrate the insufficiency of these constructs based on related work. The model is the meta-modeling approach traditionally employed by shown in Figure 1 and explained below. the EA practice when applied to the government context, due to its complex social and bureaucratic nature. Based on the case of two agencies of Australian Government, the results show a gap between methodology and reality. To improve the effectiveness of the EA practice in the government domain, Jensen (2010) proposes to rethink the EA meta-modeling framework for government use. The third publication (Lagerström et al. 2011) examines the impact of the EA management on organizational success with IT. EA management is operationalized as the existence of the EA management staff, the maturity of the EA management practice, and the amount of time devoted to it. IT success involves successful execution Figure 1: EA Practice Maturity Theory of IT projects, satisfaction of operational departments with IT, and the duration of procurement projects. The Rarely defined explicitly, EA Maturity is a measure of results show that the EA management maturity development of an EA practice – its capabilities and correlates with the duration of the procurement projects management in an organization. EA Effectiveness is a and satisfaction of operational departments. measure of the EA impact on organizational goals, or a degree to which the EA objectives are met (van der The fourth publication (Makiya 2009) is most related to Raadt et al. 2010; Bonnet 2009). According to Ross et our work. It describes a qualitative approach to al. (2006) and Makiya (2009), EA Effectiveness requires understand the relationship between the EA program a certain level of EA Maturity. Therefore, the first maturity and performance, searching for factors that proposition is that EA Maturity determines EA influence the maturity of the EA programs in government Effectiveness. This relation is labeled A in Figure 1. agencies. Relying on organizational theory, Makiya (2009) considers how organizational culture, structure, EA Stakeholder Satisfaction is similar to customer and design enhance or inhibit EA program performance. satisfaction. Goal attainment or EA Effectiveness

influences or is even a precondition to EA Stakeholder maturity of the government EA practice. This Satisfaction. This proposition is labeled B in Figure 1. question aims to verify the relation G in Figure 1. An organizational capability responsible for the EA • R2: Determine the extent to which the usefulness program (van der Raadt et al. 2010), the EA Function of the EA efforts perceived by the stakeholders consists of EA decision-making, EA delivery, and EA impacts on the factors in R1. This question aims to conformance (Raadt and Vliet 2008). According to verify the relation H in Figure 1. Makiya (2009), organizational culture, organizational Based on the factors F1 to F7, the questions R1 and R2 structure, and organizational design may influence EA are refined into 10 specific research hypotheses in Table Effectiveness and EA Maturity. This implies that EA 3: hypotheses G to G and G seek to answer R1 by Function Design could influence EA Maturity and EA F1 F7 All verifying the relation G, and hypotheses HF1 and HF2 Effectiveness. These propositions are labeled C and D. seek to answer the question R2 by verifying H. In A space outside the EA Function, EA Environment addition, Figure 2 presents a visual representation of the comprises organizational and technology environments hypotheses. Combining the answers to R1 and R2 (Bonnet 2009). As the fit between structure and provides information on the duality of EA Maturity with technology determines organizational performance respect to the organizational environment. (Makiya 2009), we deduce that the EA technology Table 3: Research Hypotheses – Factor Significance environment is related to EA practice effectiveness via the EA Function Design. In other words, EA Environment No. Description mediates the effect of the design of the EA Function on GF1 Agencies with senior management commitment (F1) EA Effectiveness (Makiya 2009). This is shown as the tend to have a higher EA Maturity. relation E. Since EA Environment is characterized by the GF2 Increased participation of business units in EA maturity factors in Table 1, we add a determinant initiatives (F2) positively affects EA Maturity in relation G between EA Environment and EA Maturity. government agencies.

Note that the label F has not been used in Figure 1 as it GF3 Strong project governance (F3) positively affects EA is already applied in Table 1. Maturity in government agencies. Logically, EA Stakeholder Satisfaction with the EA GF4 The availability of technical skills (F4) positively practice could impact on the EA Environment; for affects EA Maturity in agencies. instance, by releasing resources or active participation of GF5 The availability of management policies and user departments. Concerning the latter, Technology processes (F5) positively affects EA Maturity in Acceptance Model and related theories suggest that the government agencies. perceived usefulness of the EA practice influences GF6 Access to external support (F6) positively affects EA participation. Since it is plausible to assume that the Maturity in government agencies. stakeholders’ satisfaction implies perceived usefulness, GF7 Learning culture in government agencies (F7) we expect EA Stakeholder Satisfaction to influence or positively affects their EA Maturity levels. impact EA Environment factors, such as participation of GAll The factors F1 to F7 jointly determine EA Maturity user departments in EA or commitment of top levels in government agencies. management. Thus, we introduce the H relation, from HF1 The perception of the usefulness of EA efforts EA Stakeholder Satisfaction to EA Environment. influences management commitment (F1) in government agencies.

Since our interest lies in EA Maturity, this article HF2 The perception of the usefulness of EA efforts affects validates the logically deduced relations F and G. To this Business Unit Participation (F2) in government end and given available data, we operationalize EA agencies. Environment using a subset of the factors in Table 1 (F1–F7) and EA Stakeholder Satisfaction using the Research Design perceived usefulness of the EA efforts by stakeholders. This research applies a post-positive view to empirically Research Questions and Hypotheses verify the relations between the first seven factors in Table 1 and the maturity of EA practice. The aim of this research is to determine the major The verification is based on the survey of existing EA factors affecting EA Maturity in government agencies, capabilities, enabling factors and barriers to EA driven by two concrete research objectives: development in a major city government. All 73 agencies • R1: Determine the significance of the factors F1 to of this government were invited to participate. Most of F7 in Table 1, selected among F1 to F11 based on the questions in the survey were close-ended and data availability, with respect to their impact on the required Likert-type scale responses.

32 © Journal of Enterprise Architecture – February 2012

Perceived EA Stakeholder 1. Identifying the required EA capabilities in Usefulness of EA Satisfaction agencies 2. Determining co-ordination requirements for the HF1 HF2 whole-of-government EA 3. Examining organizational factors for successful F1 F2 F3 F4 F5 F6 F7 EA deployment within individual agencies and across the government Through the EA program, the government hopes to build the capabilities required for delivering integrated, cross- agency services and enabling sector-wide and cross- sector policy development.

EA Environment Environment EA Objectives and Process Technical skills External support Governance structure

Management commitment To fulfill project objectives, the survey aimed to: Learning and change culture culture change and Learning Participation of business units units business of Participation

Management policies/processes establish the level of awareness about EA in agencies, determine EA adoption drivers by agencies, establish EA

GF1 GF2 GF3 GF4 GF5 GF6 GF7 capabilities in agencies, determine success factors and inhibitors for government-wide EA adoption and practice, EA Maturity and determine the skill and knowledge needs of the agencies to improve EA adoption and practice. Figure 2: EA Maturity Factors Model All agencies were invited to participate in the survey,

Given that the independent variables HF1 and HF2 are of which lasted for six weeks including one week devoted the ordinal type and the dependent variables GF1 to GF7 to pilot agencies. Throughout the exercise, a help-desk are ratio type, we analyze relationships between was set up to support agencies in answering the independent and dependent variables using the Pearson questions and completing the survey. At the end, 33 product moment correlation and simple regression agencies (45% response rate) completed the survey. analysis. The joint effect of all factors on dependent variables is analyzed using multiple regression analysis Survey Instrument (i.e., GAll). The relations between independent variables are analyzed using the Pearson product moment The survey instrument comprised five sections: correlation and simple regression analysis. 1. Strategic Context – major transformational and The reliability of our instrument was determined by strategic activities carried out by the agencies. computing the Cronbach's Alpha coefficient on the set of 2. Drivers for EA Adoption – important internal and seven independent variables representing the external drivers for developing the EA practice. “organizational enablers” for EA Maturity. In addition, the 3. EA Practice Maturity – available capability in four Cronbach's coefficient was also computed for the four EA domains – processes, data, applications, and EA Maturity dimensions to determine their internal technology – and coherency between domains. consistency. To validate our results, we argued for content validity of our instrument and convergent validity 4. EA Maturity Factors – to what extent the of our EA Maturity construct. agencies maintain the required organizational environment for developing their EA capability. SURVEY 5. EA Inhibitors – what inhibiting factors, with This section presents research context, objectives and respect to the EA capability, exist in agencies. elements of the survey, provides details of the survey This article focuses on the information gathered through instruments, and describes data analysis and results. the Sections 3 and 4: the EA Maturity construct is operationalized in Section 3, while EA Maturity Factors Research Context are operationalized in Section 4. The former, defined The research was carried out as part of a project to using business process, data, applications, and develop a government-wide EA program for a city technology dimensions, was measured using the government. Part of an ongoing EGOV program, the variables in Table 4, guided by Spewak and Hill (1995). project aimed at: The variables also implicitly measure the levels of maturity within each domain. For the latter, the agencies

indicated their perception of the organizational To determine the significance of the correlation between environment using seven variables, ranging from very the variables, we determined the significance level of low to very high, that correspond to the first seven each computed correlation through a two-tailed test factors in Table 1. (Sig2). Shown in Table 6, the results demonstrate that To ensure internal consistency in the measurement of only the correlations corresponding to GF1, GF2, GF3, HF1, both constructs (Golafshani 2003), we computed the and HF2 are significant at 0.05. Cronbach’s Alpha (Weiner 2007; Lagerström et al. 2011) Table 6: Pearson Correlation for Hypotheses for EA Maturity over its four domains and over the seven EA Maturity factors. Presented in Table 5, the results No. Pearson Correlation Sig2 N show a good degree of internal coherence between the GF1 0.575787 0.000455* 33 variables for both constructs. GF2 0.547531 0.000974* 33 Table 4: Measuring the GEA Maturity Construct GF3 0.345621 0.048830* 33 GF4 0.185736 0.300728 33

No. Dimensions Variables GF5 0.114384 0.526188 33

1 Business Service catalog GF6 0.131104 0.467076 33 Process Process documentation GF7 0.222552 0.213187 33 Process description standards HF1 0.455645 0.007705* 33 Shared cross-agency standards H 0.448769 0.008804* 33 One-stop service support F2 2 Data Data dictionary Thus, there is strong evidence that Management Standards for data definition Commitment (F1), Participation of Business Units (F2), Shared data standards and availability of Project Governance Structures (F3) Defined data ownership positively influence EA Maturity. By computing the 2 Metadata repository coefficient of determination for these three factors (r ), Data security policies we also know that they account for 12% to 33% of the Cross-reference with processes changes in EA Maturity practice of the agencies.

3 Applications Application catalog The tests for hypotheses HF1, and HF2 also show that the Reference to data/processes Perceived Usefulness of EA Efforts by stakeholders is Documentation standards positively related to Management Commitment (F1) and Shared cross-agency standards Participation of Business Unit (F2). Up to 20% of the Government-wide application repository variation in F1 and F2 could be explained by the 4 Technology Technology catalog Perceived Usefulness of EA Efforts. Hardware standardization Since only F1, F2, and F3 are significantly related to EA Standardized documentation Maturity, we modified hypothesis G to only test the joint Shared cross-agency standards All influence of these factors on EA Maturity. The new Cross-reference to data, processes, and applications hypothesis GF1-3 is tested through a multiple regression Shared agency-wide database analysis with F1, F2, and F3 as independent variables and EA Maturity as the dependent variable. Table 5: Reliability of Constructs’ Measures The results, depicted in Table 7, show that none of the No. Construct Cronbach’s Alpha coefficients for the three factors is significant at a 0.05 1 EA Maturity 0.768662215 (2-tailed) level, although the coefficient of multiple determination (r2) for all factors is 0.341166. This implies 2 Maturity Factors 0.883572568 that we cannot conclude on the joint influence of these three variables on EA Maturity. Possible reasons for this Results are presented in Section 7. The relationships between the seven independent Table 7: Regression Results for Maturity Factors variables (Maturity Factors) and the dependent variable (EA Maturity) were analyzed by computing the Pearson Factor Coefficient Sig2 correlation (r) given respectively the ordinal and ratio F1 0.098954 0.192159 variable types (Cresswell 2009). In order to analyze the F2 0.047903 0.524517 relationship between one or more Maturity Factors and F3 -0.01715 0.760807 the EA Maturity, we carried out a regression analysis. All statistical computations were carried out using Microsoft® Excel and third-party add-ins.

34 © Journal of Enterprise Architecture – February 2012

VALIDATION as possible intervening factors is required for a more Having established in Section 5 the reliability of our accurate account of EA maturity. instruments and measurements for the EA Maturity and CONCLUSIONS EA Maturity Factors constructs, in this section we put forward the arguments for the content and construct The aim of this work is to contribute to establishing validity (Edwards 2003) of our results. empirically-verifiable theories about the EA practice in government and in general. The results reported in this For content validity, our claim rests on the adopted article provide empirical evidence to support the claims approach to developing the measures and instruments by practitioners on the importance of top-management for the EA Maturity construct. The measures rely upon commitment, participation of business units, and strong the well-known checklist (Spewak and Hill 1995) for EA project governance in raising the maturity of the EA planning, covering process, data, applications, and practice. The article also shows that maturity factors can technology dimensions. In addition, the instrument was be further stimulated by demonstrating the usefulness of peer reviewed by an experienced practitioner for EA to the stakeholders, particularly to the senior coverage. management and user or business departments. For construct validity, we claim convergent validity of the However, we are yet to fully account for most of the EA results since our results confirm the relations with maturity factors. In general, this work provided a basis already identified maturity factors (GAO 2006; Shafaei for developing “EA Practice Maturity Theory” which and Dabiri 2008). In addition, the results for the relates core EA constructs such as EA Maturity, EA hypotheses HF1, and HF2 are consistent with Technology Effectiveness, EA Stakeholder Satisfaction, and EA Acceptance theory (Venkatesh et al. 2003). Next, we Environment. However, as our theory-building relies checked for descriminant validity by testing possible upon empirical evidence from a single case, further effect of the organizational barriers – e.g., lack of validation through additional cases is required. experience in IT management – against EA Maturity, and found the relationship significantly negative. ABOUT THE AUTHORS Adegboyega Ojo, Tomasz Janowski, and Elsa Estevez DISCUSSION are researchers in the Center for Electronic Governance The results presented in Section 5 and validated in at United Nations University in Macao SAR, China. They Section 6 strengthen, through empirical evidence, the can be reached at {ao,tj,elsa}@iist.unu.edu. Program Maturity Theory in Figure 1. Specifically, we accounted for three EA Maturity Factors: Management REFERENCES Commitment (F1), Participation of Business Units (F2), and availability of Project Governance Structures (F3). In Amo C., Avilla T., Doyle J., Marecic J., Riordan S., and addition, consistent with technology acceptance and Wells D.: State of Oregon – Enterprise Architecture Iteration 1 – Building the Foundation: Maturity Assessment, Version 0.5 innovation diffusion theories, we showed that Perceived (2007). Usefulness of EA – a precondition for EA Stakeholder Satisfaction potentially drives F1 and F2. Bernard H.R.: Social Research Methods – Qualitative and Quantitative Approaches, SAGE Publications, Inc. (2000). However, we are yet to gain a full understanding of these maturity factors; for example, if the availability of Bonnet M.J.A.: Measuring the Effectiveness of Enterprise Technical Skills (F4), Management Policies and Architecture Implementation, Delft University of Technology Processes (F5), External Support (F6), and Learning (2009). and Change Culture (F7) are intervening factors with Buckl S., Matthes F., and Schweda C.M.: Future Research respect to the EA Maturity; since it is clear that lacking Topics in Enterprise Architecture Management – A Knowledge requisite skills, Management Commitment and user Management Perspective, ICSOC/ServiceWave'09 participation would not lead to improved practice. In fact, Proceedings of the 2009 International Conference on Service- reasons like this could explain modest values of the oriented Computing, Stockholm, Sweden: Springer (2009), coefficient of determination for even the significant pp.1-11. variables. Therefore, there is a need for factor, path dependency, and other kinds of multivariate analysis Cresswell J.W.: Research Design – Qualitative, Quantitative, and Mixed Methods Approaches, SAGE Publications Ltd. (Bernard 2000) to determine how these factors (2009). interrelate. This work did not consider the negative factors that de Vries M. and van Rensburg A.C.J: Evaluating and Refining the Enterprise Architecture as Strategy Approach and Artifacts, could affect EA maturity, except in demonstrating the South African Journal of Industrial Engineering, Vol. 20 (2009), descriminant validity. The consideration of such factors pp.31-43.

EADirections, Critical Success Factors for EA Effectiveness Ojo A, Basanya R., Soupkodjou J., and Janowski T.: (2007). Government Enterprise Architecture – Policy Recommendations for Macao SAR, Macao (2010). Edwards J.R.: Construct Validation in Organizational Behavior Research, Organizational Behavior: The State of the Science Ojo A, Basanya R., Soupkodjou J., and Janowski T.: (2003), pp.327-371. Government Enterprise Architecture – State-of-the-Art Survey (2010), p.56. GAO – General Accounting Office, Executive Guide (2003). Parisopoulos K., Tambouris E., and Tarabanis K.: GAO, Enterprise Architecture: Leadership Remains Key to Transformational Government in Europe: A Survey, Business Establishing and Leveraging Architectures for Organizational (2009), pp.462-471. Transformation (2006). Peng Peng T.C.: Strategies to Build Up Holistic Governance, Golafshani N.: Understanding Reliability and Validity in Public Administration and Governance (NAPSIPAG) Annual Qualitative Research, The Qualitative Report, Vol. 8 (2003), Conference, Beijing (2005), pp.1-14. pp.597-606. Raadt B.V.D. and Vliet H.V.: Designing the Enterprise Janssen M. and Kuk G.: A Complex Adaptive System Architecture Function, QoSA, Ed. Becker S., Plasil F., and Perspective of Enterprise Architecture in Electronic Reussner R., Springer-Verlag Berlin Heidelberg (2008), Government, Proceedings of the 39th Annual Hawaii pp.103-118. International Conference on System Sciences (HICSS'06), IEEE (2006). Ross J.W., Weill P., and Robertson D.C.: Enterprise Architecture as Strategy, Harvard Business School Press Janssen M. and Hjort-madsen K.: Analyzing Enterprise (2006). Architecture in National Governments: The Cases of Denmark and The Netherlands, Proceedings of the 40th Hawaii Saha P.: Architecting the Connected Government: Practices International Conference on System Sciences (2007), pp.1-10. and Innovations in Singapore, International Conference on Theory and Practice of Electronic Governance, Ed. Jensen A.Ø.: Government Enterprise Architecture Adoption: A Janowski T. and Davis J., Bogota, Colombia (2009), pp.11-18. Systemic-Discursive Critique and Reconceptualization, Copenhagen Business School (2010). Sedera D., Gable G., and Rosemann M.: A Balanced Scorecard Approach to Enterprise Systems Performance Klievink B. and Janssen M.: Realizing Joined-up Government Measurement, 12th Australasian Conference on Information — Dynamic Capabilities and Stage Models for Transformation, Systems (2000). Government Information Quarterly, Vol. 26 (April 2009), pp.275-284. Shafaei R. and Dabiri N.: An EFQM-based Model to Assess an Enterprise Readiness for ERP Implementation, Journal of Lagerström R., Sommestad T., Buschle M., and Ekstedt M.: Industrial and Systems Engineering, Vol. 2 (2008), pp.51-74. Enterprise Architecture Management’s Impact on Information Technology Success, Proceedings of the 44th Annual Hawaii Solander K. and Paivarinta T.: Describing and Communicating International Conference on System Sciences (HICSS'11), Software Architecuture in Practice: Observation on IEEE (2011). Stakeholders and Rationale, 14th International Conference on Advanced Information Systems Engineering, Toronto, Canada, Lankhorst M.: Enterprise Architecture at Work – Modelling, Springer-Verlag (2002), pp.117-133. Communication and Analysis, Springer Berlin Heidelberg (2009). Spewak S.H. and Hill S.C.: Enterprise Architecture Planning – Developing a Blueprint for Data, Applications, and Technology, Makiya G.: Impact of Organizational Culture, Structure, and John Wiley & Sons (1995). Design on Enterprise Architecture Program Performance: A Qualitative Study, Case Western Reserve University (2009). Steenbergen M.V., Bos R., Brinkkemper S., and Weerd I.V.D: The Design of Focus Area Maturity Models, Global Martin N.: Using a Common Architecture in Australian e- Perspectives on Design Science Research, Springer (2010), Government – The Case of Smart Service Queensland, pp.317-332. ICEC'04 6th International Conference on Electronic Commerce, Ed. Janssen M., Sol H.G., and Wagenaar R.W. United Nations, E-Government Survey (2010). (2004), pp.516-525. van der Raadt B., Bonnet M., Schouten S., and van Vliet H.: Ministry of Finance, Overview of Enterprise Architecture Work The Relation Between EA Effectiveness and Stakeholder in 15 Countries, Finland (2007). Satisfaction, Journal of Systems and Software, Vol. 83, (October 2010), pp.1954-1969. Mykhashchuk M. and Schweda C.M.: Charting the Landscape of Enterprise Architecture Management, an Extensive Venkatesh V., Morris M.G., Davis G.B., and Davis F.D.: User Literature Analysis, Information Systems. Acceptance of Information Technology: Toward a Unified View, MIS Quarterly, Vol. 27 (2003), pp.425-478. NASCIO, Enterprise Architecture Maturity Model (2003).

36 © Journal of Enterprise Architecture – February 2012

Waseda University: The 2011 Waseda University World e-Government Ranking, Group (2011), pp.1-10.

Weiner J.: Measurement: Reliability and Validity Measures (2007).

Article

Architecture Styles

By Indranil Bhattacharya

Abstract Architecture styles are derived from the design and management criteria used to realize, operate, and evolve enterprise systems. By applying different architecture styles, Enterprise Architects can decide on relevant functional features, extent of process automation, the appropriate management style, and optimal technical infrastructure for an application landscape. As the first part of two, this article provides a theoretical foundation for developing architecture styles by considering the characteristics of an architectural style, some analogies that are useful in explaining architecture styles, and considerations for implementing style diversity in enterprises. Keywords Architecture Styles, Enterprise Architecture, Design Strategy, Architecture

elements, desired cultural changes, prevalent attitudes INTRODUCTION within the enterprise, and other intangibles within the The design of enterprise systems is becoming enterprise. increasingly complex due to rising demands on By developing pattern languages that use networks of functional coverage, automation, usability, patterns to resolve the prevalent tangible and intangible interoperability, performance, maintainability, portability, forces within a system's operating environment, and by reliability, and cost-consciousness. Businesses feel the applying trade-off methodologies assessing different pressure of being able to match their competitors’ architecture criteria (Hyatt 1996), architects are able to portfolios and capabilities, and often respond by assess alternatives that provide best fit. Through increasing their own product portfolio, leading to greater abstractions, layered architectures, and frameworks, functional coverage at the cost of poorer usability, architects are able to break down complex problems into maintainability, performance, and a higher spend. smaller problems, and then re-assemble the smaller Leadership in enterprises also varies in what they solutions into a whole. Given these existing methods, it consider effective practice, ranging from focusing would be reasonable to expect that if different architects primarily on repeatable processes to emphasizing “out- were provided with a well-specified problem, they would of-the-box” and innovative thinking. all be able to produce similar results. In practice, Data models can vary, using abstractions in some cases architects tend to blend their experience, personal to permit re-use, which conflicts with the need to have values, comfort level, expertise, and ambitions with their specific attributes in order to satisfy domain-specific understanding of different empirical and theoretical rules and constraints. On the other hand, data built methods to produce unique and varied results. around specific facts rather than abstractions restricts Furthermore, architects do not usually have to work with their re-use, requiring parallel data structures to solve the systems they have designed, and like their similar problems. Similarly. service models can vary, contemporaries in building design (Jacobs 1961), are exposing abstract interfaces in some cases that permit often unable to directly experience the consequences of re-use but suffer from poor usability as service invokers their design choices. Abstractions, despite their power of need to translate their specific facts into abstract being able to simplify complexity, have the effect of concepts. On the other hand, providing highly detaching architects from the daily practices in specialized services makes it difficult to discover and operational situations. Several of the methodologies and invoke services. Providing services that are highly frameworks utilized by architects are difficult to explain available and consistent comes at the expense of to non-architects, and are often reduced to simpler terms compromising on performance, and alternately, at the cost of removing complex but valuable concepts. providing services that are highly available and Finally, there is a tendency for architects to produce responsive comes at the expense of compromising on design artifacts within certain boundaries, with a certain consistency. Beyond these examples of complexity, amount of ambivalence on the consequences of their architects should be able to incorporate strategic designs outside those boundaries. For instance, a

38 © Journal of Enterprise Architecture – February 2012

functionally-oriented architect may define their examples, and anecdotal evidence. The use of responsibility to the extent of defining the required analogies is especially compelling as they can help functional coverage of a system, but not the underlying architects obtain a deep context on how users would like technology used to fulfill the range of functionality. to experience a completed system. The analogies can Technology specialists with expertise in specific tooling also be applied with business stakeholders and other can then choose to fulfill all functional requirements members of the enterprise without architectural skills. through a technology stack with which they are familiar, Business stakeholders can be encouraged to express even if other technological solutions could have been how the realized system should make them feel, utilizing more appropriate. Similarly, each area of the enterprise analogies, similes, and metaphors from parallel could then choose standard components and disciplines. For instance, there are different styles approaches regardless of the problems they should (Spinosa et al. 1997) of writing (concisely or solve, the sum of which would result in a dissonant descriptively), driving (hectic or steady), making whole. presentations (marketing a product launch or giving a lecture), and cooking (gourmet cooking or a rapid stir- WHAT ARE ARCHITECTURE STYLES? fry), and the differences in each of these styles is easy to Architecture styles represent the set of values, patterns, explain to almost everyone in the enterprise. Analogies and principles used to select the most appropriate and metaphors are powerful communication methods architectural criteria for a problem domain. Their (Lakoff et al. 1980), and they are particularly effective in principal purpose is to provide a unifying quality to create providing different design participants with a shared resonance across every aspect of a system's understanding of how a system would make them feel. architecture. An architecture style can provide guidance This empowers design to become an open and on the appropriate extent of functional coverage participatory process, enabling stakeholders to have a (extensive or just critical functions), user experience deeper influence in the choices leading to the realization (highly usable with limited functions or poor usability with of a system. In order to ensure that the analogies have a several functions), appropriate knowledge model unifying quality, it is important to select them from a (whether knowledge should reside within people or the single discipline and to apply a principal analogy in the application), attitude requirements of users (focus on a design of a system. Additionally, aphorisms derived from single task at a time, flexibility to handle several tasks, the principal analogy can become powerful agents of etc.), scale of automation, appropriate management change as they are translated into practice by everyone style (e.g., controlling, team-oriented, market-oriented, or in the enterprise from leaders to operational staff. The innovation-oriented), data typing (weakly-typed or ability of aphorisms to reflect the finest thoughts in the strongly-typed), different programming paradigms fewest words (Davis 1999) gives a succint means of (object-oriented, logic-oriented, functional programming, communicating the essence of an architecture style etc.), appropriate programming language (Java, Scala, across the enterprise. Erlang, Prolog, etc.), appropriate persistence paradigm The field of urban design and the forms of regions, cities, (relational, key-value, graph, object store, hierarchical neighborhoods, buildings, and rooms provide a rich base store, etc.), appropriate operating environment (desktop- of analogies that we can utilize to design information based, client-server, peer-to-peer, etc.), and applicable systems. Urban designers that have applied purely hardware (highly reliable but expensive servers or empirical methods without incorporating the intangibles somewhat reliable but cheap servers). Styles combine in the lives of the inhabitants will have created poor both tangibles, such as persistence paradigms and urban architectures (Jacobs 1961). Furthermore, given applicable hardware, and intangibles, such as the virtual nature of software systems, the usage of management styles and required attitude. An analogies with urban typologies provides tangible architecture style provides the means to unify inter- comparisons that can transcend inter-disciplinary disciplinary practices and patterns, penetrating and practices. For instance, by applying the metaphor of permeating across layers, concerns, aspects, urban design thoroughly to each type of application in an perspectives, and disciplines to produce a cohesive and enterprise, it is possible to create an application layout consistent quality (Alexander 1979). It is this quality that inspired by the map of a city. If we consider three needs to be created and sustained across every aspect prominent features of most European cities, the of a system's architecture, and architecture styles Cathedral, Town Hall, and the Bazaar, we can see that provide the means of understanding, translating, and each one is designed with a different style. Tall, stately, incorporating this quality across disciplines with some and robust, Cathedrals like the Notre Dame in Paris or measure of consistency. the Dom in Cologne are dominant features in their cities. Architecture styles can be represented through a Cathedrals, and their extensions, are usually built to last combination of analogies, formal specifications, centuries as the definitive landmark around which the

rest of the city can grow and prosper. Town Halls are Neither appointments nor ceremonies are important in designed to govern cities and to provide services for the the Bazaar. Consumers show up when they want, residents of the city. They are built to last several purchase things that catch their fancy, and leave at their decades, and they should be able to adapt with changes will. Nevertheless, when interacting in these common in the environment (e.g., prevent flooding due to spaces, parties adjust their styles. Hawkers and stall- changing weather patterns), commercial concerns (e.g., operators who sell goods to consumers should adapt to provide the new financial district of the town with the rules and regulations of the Town Hall when applying adequate security), residents (e.g., provide an increasing for a permit to operate in the Bazaar. The Town Hall population of senior citizens with better health care should understand the needs of consumers and hawkers services), and visitors (e.g., offer travelers good hotel when designing regulations for the Bazaar. Priests advice). The records stored in Town Halls, such as birth should understand the nature of sales and commerce if certificates, marriage licenses, and other information they operate a market stall in the bazaar during a about residents, should be secure from those who might Christmas Fair, but the consumers also give the market- abuse such information. Bazaars or open marketplaces, stall operated by a priest a different degree of respect such as a farmer's market or a flea market, usually than a regular stall. Hawkers and stall-operators should inhabit open squares, are assembled each morning, and respect the transactional nature of payments. In all of taken down by the end of the day. Their vibrant these cases, the intersection points between different character changes with every new day, drawing styles require adaptation between parties accustomed to residents and visitors who are attracted by its energy. different styles. THE CATHEDRAL STYLE The structures necessary for supporting the area of Finance are analogous to the architecture style of Cathedrals. While it can be argued whether Finance truly is the religion of enterprises, its seminal role in almost any business is difficult to deny. Regardless of the nature of the business, book-keeping is performed to exact standards governed by regulatory authorities. The prevalent structures of Finance, such as general ledgers, have evolved over several centuries and implementations of these stable concepts can be used over several years without significant changes. When changes do occur, they are often driven by external forces that apply to other businesses such as taxation laws and financial regulations (e.g., Sarbanes-Oxley). Systems that manage financial information usually require high stability and reliability. Financial data should Figure 1: Activities Develop between the Spaces Provided be highly consistent and centralized, and operations on by Cathedrals, Town Halls, and the Bazaar, requiring the them must be transactional, guaranteeing atomicity, adaptation of styles consistency, isolation, and durability (Gray 1981). The ceremonies and rituals around taxation are usually Although each archetype seems to exist independently carefully orchestrated for a high-degree of compliance of each other, they also occupy common spaces. and, if they are violated, offenders must be ready to face Couples who want to get married in the Cathedral should grave peril. register themselves in the Town Hall. Priests in the Cathedral can organize marketplaces, such as An effective architecture style for Finance would lay the Christmas Fairs. Hawkers and stall-owners in the Bazaar emphasis on creating systems that enable repeatable should register with the Town Hall in order to obtain a and stable processes, rely upon stable data structures, trading license. Although priorities vary in each of the and ensure that data is highly consistent. The leadership spaces, people adapt when they are in the space of should practice a controlled and structured style of others. Appointments and schedules are very important management, emphasizing that establishing repeatable in the Town Hall, and ceremonies are more important processes that produce consistent results is the best than schedules in the Cathedral. If we are to believe measure of effectiveness, roughly corresponding to the contemporary movies, schedules are not important at all hierarchy style of leadership of the competing values in places of ceremony given that the bride or groom is framework (Cameron et al. 2006). Captured as an forever turning up at the last moment for the wedding. aphorism, the leadership style can be expressed as

40 © Journal of Enterprise Architecture – February 2012

“constant mediocrity is preferable over patchy brilliance”. rather than how quickly it is served, availability can be Stable processes should be automated wherever sacrificed in order to improve consistency when faced possible, in order to ensure that manual tasks do not with a limited budget to realize the system. create the possibility of errors or fraud. Systems should also be adaptable to strong external forces, such as THE TOWN HALL STYLE commercial and taxation regulations. Architects Like Town Halls which manage one of the principal designing financial systems would need to ensure reasons a city exists (its residents), Customer regulatory compliance to financial and taxation Relationship Management (CRM) systems manage one requirements. Predictable exceptions should be thought of the principal reasons a business exists (its about, and handled by the system, rather than treating customers), and we can draw several analogies between exceptions generically and asking users to determine the Town Hall and CRM systems. CRM systems how to resolve them. Designs should be precise and represent information about customers and their leave no room for interpretation, and user documentation purchased products or services, interactions between should be extremely thorough. Implementation of new prospects and customers with the business, campaigns systems should be accompanied by comprehensive test and products offered by the company, and records of coverage, and any changes to the system should go purchases by customers. Like Town Halls, the CRM through a controlled change management process. system should be able to adapt to changes in the nature of the products offered by the business or changes in the nature of the customers. Just as residents want to feel valued when they visit the Town Hall, customers should feel valued when they interact with the business, and be

orm ance able to return for their changing needs. Occasionally, the

Perf business should be able to pleasantly surprise customers, just as Town Halls manage to pleasantly surprise residents by putting on a fireworks display on special occasions. Information about customers should be safe-guarded from abuse, particularly from competitors, just as Town Halls should protect personal data about its residents. At a minimum, the CRM system should apply legal and security regulations to ensure that the integrity of their relationship with the customer is safe-guarded. CRM systems, above all, should be able to accommodate the complex relationship between Figure 2: Elements of a Architecture Style for Finance customer and the business. The bond between a User interfaces for Finance systems should emphasize customer and a business is formed through a functional coverage over usability, especially in the combination of the ability to provide products that meet areas where regulatory compliance is required. Services needs, trust built through reliability and consistency, should expose data objects that are strongly-typed loyalty built through genuine gestures that the business (Bhattacharya 2010) to ensure that behavioral cares about its customers, and price competitiveness. In constraints are applied to specific entities rather than meeting needs, building trust and growing loyalty, weakly-typed objects that apply the generic behavioral businesses should understand both the tangibles constraints. For instance, rather than exposing a single (products, offers, invoices, etc.) and intangibles abstract service for making a payment containing (interactions, expectations, pleasant surprises, etc.) that generic parameters for amount and the payment type, a constitute the relationship with the customer. set of services should be exposed where each service Given that each set of interactions with customers is exposes parameters specific to a type of payment (cash, unique, it is important that functionality that facilitates debit-card, credit-card, etc.) such as account number, customer interactions be flexible and adaptable to credit-card number, and verification code. The most change, and empower both customer service agents and appropriate storage technology for financial data can be customers. Interactions with customers can occur with relational databases that are operated on highly reliable mediums like voice (customers calling a service hardware to ensure consistent transactional integrity. number), through social media (chat, social networking Emerging paradigms like event sourcing are very sites, etc.), self-service channels like mobile powerful at establishing detailed audit-trails, provided applications, and through the company’s website. In that events are generated, persisted, and consumed order to build strong empathy with customers, leadership reliably. As it is more important that the data be accurate in this space of the enterprise should have a strong

personal touch, create a mentoring culture where THE BAZAAR STYLE customer and product knowledge is fostered, and create Marketplaces, specialist shops, and large stores offer environments where teamwork is emphasized through relatively obvious analogies with Web-Shops and participation and consensus. The underlying E-commerce solutions. Consumers first come to shops organizational glue for members in the customer service out of curiosity (perhaps by a campaign that has caught department should be built on loyalty and mutual trust, their fancy), necessity (a need to purchase a product or and the scale of success of the department can be service), perceptions of value, and hearsay (someone measured by the development of human resources, has told them something nice about the shop). scale of empowerment, and concern for people. These Consumers have the freedom to browse around the characteristics are similar to the clan style of shop, select things they might want to purchase later, management in the competing values framework. ask for assistance should they choose to have it, receive Aphorisms like “always give the customer more than consultancy about products from staff, and make they expect” or “first seek to understand” capture the purchases. The most interesting shops are those where essence of the architecture style necessary to facilitate the shopkeepers have good knowledge about the excellent customer service. Automation in this area products and services they are selling and are able to should be cautiously applied, if at all, relying instead on provide informed advice. Shopkeepers on any given day building knowledge and best practices around people. can set up their merchandise in unique configurations Customer Service Interaction Style and combinations based on factors such as seasons, Architectural Emphasis Management Style trends, or demand perceptions. Shopkeepers also need Functional Dominant Organizational Style Strong personal touch, build empathy with Coverage customers the flexibility to offer their products with different pricing Reliability Leadership Style Mentoring, Knowledge Culture, structures, incorporating promotions and discounts. Employee management orm ance Similarly, effective Web-Shops balance the limitations of Usability Teamwork, consensus, participation Organizational Glue a virtual experience with a wealth of information about Portability Perf Loyalty and Mutual Trust products. Web-Shop administrators usually want to be Maintability Strategic Emphasis Human development, high trust, openness able to attract a high number of relevant visitors and Criteria for Success Development of Human Resources, Scale of offer them products that ensure purchases and repeated Functional Emphasis Empowerment, Concern for People Material adapted from © Competing Values Framework Processes visits. Consumers must be able to find their way easily Focus on flexibility to change processes Technical Considerations Automation Programming paradigm(s) around the Web-Shop, get information about products Automate very cautiously, if at all Functional Programming and Object-Oriented (as little or as detailed as they want), speak to experts Knowledge Model Storage paradigm(s) Build minimum knowledge in systems, Graph Databases capable of capturing relationships about advice if required, and make selections for empower people Highly scalable NoSQL databases (e.g. Cassandra) Data model purchases. Web-Shop administrators must be able to Weakly-typed objects around Interaction easily add different types of products, easily change product information, incorporate different pricing models Figure 3: Elements of an Architecture Style for Customer Service Interaction with promotions and discounts, and adapt to changing demands. Aphorisms such as “nothing endures but Customers calling a customer service line should expect change” or “less is more” reflect the architecture style in high availability and responsiveness. Traditional this area. Interactive Voice Response (IVR) systems tend to utilize The strategic emphasis for Web-Shops is usually relational databases at great cost, primarily because focused around competitive actions and winning in the there were very few mature database options during the marketplace, roughly corresponding to the market style early years of their emergence. Ideally, recording in the competing values framework. Given the self- customer interactions needs to prioritize scalability, service nature of Web-Shops, usability and performance availability, and performance over consistency. should be emphasized over functional coverage. The Emergent NoSQL database technologies like Cassandra functionality consumers need to make purchases should are able to meet these requirements at far lower cost be emphasized over others, and design principles like than a traditional RDBMS by providing eventual progressive disclosure and forgiving user interfaces consistency. Functional programming languages, such should be applied (Nielsen 2006). Process automation as Clojure or Scala, are better at representing the fluid should be applied very cautiously, if at all. Information nature of interactions than object-oriented languages like about products can be served from a document-oriented Java, creating the possibility of developing a model for or content-oriented database, such as the content the different types of interactions customers have with repository component of a Content Management System the enterprise. Services should expose weakly-typed (CMS). If a wide variety of products is to be advertised data objects with re-usable behavioral models capturing on the Web-Shop, a weakly-typed data model would customer interactions. enable generic coverage of the universal characteristics of physical products, such as the product’s name, text

42 © Journal of Enterprise Architecture – February 2012

description, and images. If the Web-Shop features order, and obtaining a commitment to the purchase specialized products, strongly-typed models can be used process, must be experienced consistently and to capture their specifications and capabilities. While a cohesively. Distinct from other areas of the Web-Shop, customer is still choosing their products for purchase, the checkout process needs to create a user experience adding or removing products from their shopping cart that clearly distinguishes itself from the Web-Shop’s non- should remain at the consumer's complete discretion. By committal areas. Persistence of the payment information emphasizing the availability of the shopping cart over its should be made on a repository that ensures consistency, it is possible to significantly reduce the consistency and transactional behavior, such as a costs of operating Web-Shops as demonstrated by relational database. Consumers must be able to return Amazon's Dynamo (DeCandia et al. 2007). By utilizing to obtain information about their purchases, creating a the recent improvements in browser technology, more distinct space and experience from the area of the Web- costs can be reduced by moving server-side model view Shop where they can make new purchases. Other controller frameworks to browser-based JavaScript and examples of enterprise applications that are analogous REST frameworks. to Christmas Fairs are integration middle-ware, order management, and product lifecycle management where it is necessary to co-ordinate activities with several applications, each with their own styles. The ability to accommodate the confluence of styles requires the ability to deal with multiple paradigms. Emergent polyglot paradigms, such as polyglot programming which sees the usage of different programming paradigms in a single application, or polyglot persistence, which sees the usage of different storage techniques in a single application, are a reflection of the ability to accommodate multiple styles in a single space. STYLE ANTI-PATTERNS The inability to understand the necessity for multiplicity Figure 4: Elements of an Architecture Style for Web-Shops in architecture styles usually manifests itself through anti-patterns. While patterns are able to balance the CHRISTMAS FAIRS prevalent forces in an environment in a positive, Just as Christmas Fairs witness the influence of the effective, and productive manner, anti-patterns reflect an bazaar, Cathedral, and the Town Hall in a single space, ineffective or counter-productive resolution of forces in several areas of the enterprise see the confluence of an environment. A common anti-pattern is the adoption multiple styles. In the example of the Web-Shop, of a single architecture style across the entire enterprise, consumers arriving at the checkout page after having which can often occur in enterprises that have rigid IT selected a few products must be able to commit to a standards. The different eras of computing, ranging from purchase. The process of obtaining payments from the early days of mainframes to the present day of cloud consumers for their purchases is an intersection of the computing, are conducive to supporting specific types of Web-Shop and the Finance styles. If products require architectures. Investment in a single technological after-sales service or the physical delivery of goods, the infrastructure can directly influence application design registration of the customer is required, which is an choices in a single direction. This can result is a single- intersection of the Web-Shop style and the customer minded approach for developing application interaction style within the CRM. The confluence of architectures, or a monothetic architecture style. For these styles sees the emergence of a new style. Given instance, traditional ERP systems tend to apply a the self-service nature of shops, usability remains very Cathedral style throughout the enterprise, measuring all important in this new style. Consumers need to aspects of the business through the lens of Finance. In understand the required commitment when they make a order to convince stakeholders in the enterprise of the purchase, requiring a different user experience from their danger of this single-mindedness, the usage of earlier experience of the site where they could easily add analogies such as the following are particularly helpful: or remove products from the shopping cart without any “If I am praying all the time, it is likely that I am a priest. If commitment. The entire checkout process, which can we are talking about money all the time, it is likely we are consist of confirming the consumer's purchases, bankers. Otherwise, just as an occasional sermon or a obtaining payment, capturing information to fulfill the daily prayer is enough for most of us, an occasional

reminder about money is sufficient.” Another course that to build, operate, and grow effective systems. Enterprise enterprises can follow in their inability to develop style Architects can utilize models of functional coverage, multiplicity is to resort to different developing such as eTOM or SCOR, and establish architecture architectural practices in silos or stovepipes. Each area styles for each functional area. Through the judicious of the enterprise operates completely independently of application of an architecture style, businesses can each other, and utilizes an implicit and monothetic style drastically reduce waste and differentiate themselves for their system design. This style is usually not explicitly from their competition. The use of strong metaphors and voiced, and is perceived as the most effective way of aphorisms help inter-disciplinary experts understand the getting things done. Rather than developing appreciation essence of an architecture style, which in turn empower for style multiplicity, an attitude develops of “my way or individuals across the enterprise to participate in the highway”. Intersections between these stove-piped engaged design and implementation. Finally, it is styles are often painful, and are hardly analogous of through the appreciation of different styles that mature Christmas Fairs. This leads to the final anti-pattern often intersection points can prosper, empowering enterprises evident within enterprises unable to develop well- to conduct their own Christmas Fairs. communicated style multiplicity, which is that of style buffering through layers. Traditional n-Tier architectures ABOUT THE AUTHOR (Alur et al. 2001) espouse the need for different layers Indranil Bhattacharya is an Enterprise Architect with where each discipline can do their own thing in relative around 15 years’ experience in developing and detachment from other disciplines. As a consequence, designing systems in large enterprises. He works in the expensive buffers are required for paradigm translations, Enterprise Architecture practice within Deutsche which increases the overall system complexity without Telekom, specializing in the Product Lifecycle contributing to business value. Management domain. In his spare time, he works on social ventures that assist small businesses in becoming FURTHER APPLICATIONS OF STYLES more competitive by working together in collaborative Architecture styles can be further enhanced as a tool for supply-chain networks. Enterprise Architecture by correlating them with existing EA models. Models of functional coverage, such as the REFERENCES Enhanced Telecom Operations Map (eTOM) for the Alexander C.: The Timeless Way of Building, Oxford University telecommunications industry and Supply-chain Press (1979), pp.25-40. Operations Reference (SCOR) for supply chain management, can benefit from correlation with Alur D., Crupi J., Malks D.: Core J2EE Patterns, Sun architectures styles in each functional area. For Microsystems Press (2001). instance, eTOM defines separate areas for Customer Bhattacharya I.: Weak versus Strong Typing (2010); Relationship Management (CRM) and Supplier www.visualspec.org. Relationship Management (SRM), which are then broken down into smaller functional sub-components. Cameron K.S., Quinn R.E., DeGraff J., and Thakor A.V.: Archetypes based on a common metaphor can be Competing Valued Leadership: Creating Value in assigned to each functional component within an area. Organizations, Edward Elgar (2006). By correlating architecture styles with business models Davis M.S.: Aphorisms and Clichés: The Generation and of value, such as value networks and strategy maps, it Dissipation of Conceptual Charisma, Annual Review of becomes possible to demonstrate where architecture Sociology, 25(1), 245-269, Annual Reviews, changes can produce value. Finally, architecture styles doi:10.1146/annurev.soc.25.1.245 (1999). can be used to develop and structure a unified pattern DeCandia G., Hastorun D., Jampani M., Kakulapati G., language for EA. The communication-intensive nature of Lakshman A., Pilchin A., Sivasubramanian S., Vosshall P., and an Enterprise Architect’s role is not necessarily Vogels W.: Dynamo: Amazon’s Highly Available Key-value diminished by the usage of architecture styles, but their Store (2007); www.allthingsdistributed.com/files/amazon- utilization does aid the difficult processes of inter- dynamo-sosp2007.pdf. disciplinary design and enterprise transformation. Gray J.: The Transaction Concept: Virtues and Limitations, CONCLUSIONS Proceedings of the 7th International Conference on Very Large Databases (1981), pp.144–154. Style multiplicity in architecture is important for enterprises that desire a cost-effective application Hyatt L., Rosenberg L.: A Software Quality Model and Metrics landscape. By correlating leadership and architecture for Identifying Project Risks and Assessing Software Quality, styles with the prevalent forces in an enterprise, Product Assurance Symposium and Software Product businesses can realize an optimal balance in being able Assurance Workshop, EAS SP-377, European Space Agency (1996), p.209.

44 © Journal of Enterprise Architecture – February 2012

Jacobs J.: The Death and Life of Great American Cities, Pritchett D.: BASE: An ACID Alternative, ACM Queue (May Random House (1961). 2008).

Lakoff G. and Johnson M.: Metaphors We Live By, Language Spinosa C., Flores F., and Dreyfus H.L.: Disclosing New (Vol. 59, p.242), University of Chicago Press, Worlds: Entrepreneurship, Democratic Action, and the doi:10.2307/414069 (1980). Cultivation of Solidarity, MIT Press (1997), pp.19-22.

Nielsen J.: Progressive Disclosure (2006); www.useit.com/alertbox/progressive-disclosure.html.

Article

The Impact of Enterprise Architecture Principles on the Management of IT Investments

By Mats-Åke Hugoson, Thanos Magoulas, and Kalevi Pessi

This article is reproduced with permission from the publishers of the Electronic Journal of Information Systems Evaluation (www.ejise.com). Abstract The strategic role of IT and its significance throughout the organization increases complexity, variety, and the need for change. Hence, IT management must deal with uncertainties derived from different, conflicting, and ever-changing demands. In this sense, Enterprise Architecture (EA) is playing an increasingly important role in improving IT management practice. If contemporary organizations do not succeed in managing architectural issues, there is a clear risk that considerable resources will be invested without achieving desirable effects. This article investigates how Enterprise Architecture Principles impact the management of IT investments in the context of large organizations. The purpose of the article is to provide a deeper insight into the relationship between EA and management of IT investments through the elucidation of two significant types of principles: Delineation (differentiation) principles and Interoperability (integration) principles. Our conclusion is that the choice of architectural principles has a major impact both on alignment between information systems and business demands, and on the management of IT investments. This impact concerns at least four aspects: the responsibility for IT investments; time to value; long-term alignment; and coordination of investments in information systems with changes in business processes. Keywords Enterprise Architecture, Information Systems Architecture, Business Architecture, Architectural Principles, Alignment, Management of IT Investments

investments are considered as standalone investments INTRODUCTION rather than co-ordinated investments; i.e., investments During the last decades IT has received a more central related to each other (Edwards and Lambert 2003; role in transforming organizations in order to meet the Marchand and Peppard 2008). challenges of the 21st century. IT strategic planning and This article investigates how Enterprise Architecture management has gone from an emphasis on mastering Principles impact the management of IT investments in the technology, developing information systems, and the context of large organizations. The purpose of this controlling the costs of the IT department to seeing IT as article is to provide a deeper insight into the relationship an essential means to achieve business value, as well between EA and management of IT investments as to create new organizational forms with an increased throughout the elucidation of two significant types of ability to innovate, compete, and co-operate. We can principles: delineation principles and interoperability recognize three significant trends. Firstly, the use of IT is principles. Cases from Swedish industry are used to continuously influencing every area of social and illustrate how these architectural principles impact business life. Secondly, IT investment issues that management of IT investments. The article contributes previously were a matter for the IT department have now to a better understanding of how the choice of become issues of interest for the entire organization, not architectural principles may impact the management of least the top management. Lastly, the management of IT IT investments. investments from a strategic point of view has become more complex and more difficult. Although there are RESEARCH METHOD quite a few models and methods for evaluating IT The research has been inspired by collaborative practice investments, it is still difficult to achieve impact in the research (Mathiassen 2002) and its inside/outside business. One of the most common reasons is that the perspectives. One author of this article has been working larger the project, the more complicated IT management for several years with the case companies and provides – and especially evaluation of the business value – “inside perspective”. The other two authors are full-time becomes. Another reason is that very often IT

46 © Journal of Enterprise Architecture – February 2012

academic researchers and provide “outside perspective”, • How to delineate (differentiate) information systems which allows for deeper assessment and reflection. • How the different information systems should The research methodology is essentially interpretive interoperate (integrate) case study (Walsham 1995; Klein and Myers 1999). We Differentiation and integration in complex organizations carried out data collection primarily through has been discussed in management research for many observations, semi-structured interviews, and workshops decades. For example, Lawrence and Lorsch (1967) with CEOs, CIOs, Process Managers, Enterprise state that large organizations are being expected to cope Architects, Project Managers, and Users. Observations with heterogeneous environments that have both highly and activities were recorded in a research diary. dynamic and quite stable sectors. This continually Research rigor is a question in any case study; typical increases the need for differentiation in organizations, critiques target the validity of generalization or the lack of yet the requirements for integration to achieve a unified self-criticism. However, the main objective in these case effort are at least as great as ever. In this article we studies is to increase the understanding of the discuss differentiation and integration issues in terms of relationship between EA and management of IT principles for how information systems can be delineated investments. and how the information systems can interoperate ENTERPRISE ARCHITECTURE (Magoulas and Pessi 1998). These two kinds of principles will be discussed further in the following Contemporary organizations invest more and more sections. money in new information systems and in managing legacy systems. At the same time organizations are Delineation of Information Systems finding it more and more difficult to keep these information systems in alignment with business In order to handle heterogeneity and complexity in IT- demands. Furthermore, the role of information systems based information processing, delineation or has changed during the last two decades, from differentiation of systems is crucial (Magoulas and Pessi automation of routine administrative tasks to a strategic 1998). Two basic delineation principles are discussed in and competitive weapon. In light of this development, a this article; one principle is based on different types of new field of research and practice has emerged and information models (i.e., Information-driven principle); came to be known as Enterprise Architecture (EA). One the other principle is based on responsibilities in the of the pioneers introducing the concept of architecture enterprise (i.e., responsibility-driven principle). was John Zachman (Zachman 1987). His Enterprise Architecture Framework (Sowa and Zachman 1992) is The information-driven principle is applied in several probably one of the most referenced, both by different architectural frameworks and is widely used practitioners and researchers. A number of EA (Magoulas and Pessi 1998; Alter 1996). Allen and frameworks have evolved since Zachman first Boynton (1991) called it “the high road alternative”. The introduced his framework. For example, the Federal information-driven principle focuses on information as Enterprise Architecture Framework (CIO Council 2001) the basis for delineation of systems; for example, all and TOGAF® (TOGAF 2007) to mention two well-known product data should be gathered in one system, the frameworks. EA is usually divided into different “Product Data System”. The core IS activities of the categories or domains or architecture types. For business are centralized and core information systems example, Aerts et al. (2004) identify three domains in are designed to be organizationally independent; that is, which architecture matters: immune to restructuring in business. The information- driven principle has as its starting point the premise that 1. The business architecture information is a central resource that must be controlled 2. The information systems architecture (IS centrally. architecture) The responsibility-driven principle (Magoulas and Pessi 3. ICT platform architecture (or IT architecture) 1998), also referred to as “the low road alternative” (Allen and Boynton 1991), is based on the principle that EA frameworks should give guidelines for the choice of the responsibility for an area of operations in the architectural principles for information systems (CIO enterprise should comprise all resources (including Council 2001). Architectural principles are statements information systems) used to fulfil objectives and tasks that express how your enterprise needs to design and specified for this area. Each information system should deploy information systems across the enterprise to therefore support only one area of responsibility, and connect, share, and structure information. Such can then be developed for efficient support to users in guidelines and principles should take into account at that area. Necessary interaction and information least two crucial aspects: exchange between different areas of responsibility in the

organization and with external partners must, however, The objective of the intersection principle is to improve be considered. Every system should respond to two the availability and quality of information and the efforts tasks: to support local users and to support information of information management through the elimination of exchange with other information systems in the redundancies. Accordingly, the intersection principle (or enterprise. Similar areas of responsibility can use the overlapping) takes place when the structure of each of same type of solution, but still each instance of the participating systems has one or more elements information system can operate (and be changed whose properties are identical (or sufficiently similar) or internally) independent of other systems. Independence one of the participating systems has elements which can in development, operations, and change is an important be used in some of the other systems. Intersection issue when delineation of information systems is based strives to eliminate duplicates. on responsibilities in the enterprise. The responsibility The intersection principle creates a shared information principle stresses a rather high degree of autonomy, but space, which can be exemplified by a situation where also co-operation between information systems, where the participating information systems share some of their each information system is administered by the part of constituent parts; i.e., the conceptual base, the the enterprise that owns and uses that system. information base, or the rule base. In this sense, the participating information systems can be coordinated Interoperability between Information Systems either by: One of the major issues in designing and developing EA • Keeping the previously redundant part in one is which degree of interoperability should there be system and allowing the other systems to access to between the various business units of the enterprise and that part how should this be reflected in the integration of their • Unifying the redundant local parts into one shared information systems (Clark and Jones 1999). and common part (like a common database) Interoperability is usually defined as “the ability of two or more systems or components to exchange and use Thus, a shared information environment might be seen information” (IEEE 1990). Solotruk and Kristofic (1980) as the result of a co-ordinating process aiming either to discuss three alternative principles for interoperability: eliminate the overlapping parts of the participating Unification, Intersection, and Interlinking. systems or the globalization of some of their parts. Unification is defined as the process of producing a The shared parts become common property because common structure for two or more information systems. any kind of change in those parts may have effects on all A unification strategy creates a unified information of the participating systems. Locally, the right to alter the space. One kind of unification means that two or more system is limited to unshared parts only. In this sense entities are merged into one entity (one common system the effects of integration might be described in terms of principle). Another kind of unification is standardization expectations for better quality and availability of of two or more systems with regard to their inner information services, as well as in terms of an structure, functions, and content. In this case, the acceptance of a limited freedom of alteration. systems don’t merge into one physical system; rather The interlinking principle represents a different concept there are many systems which are replicas of each other for systems interoperability. Interaction between different (replication principle). The latter situation covers systems is carried out through the exchange of physically distinct systems that conceptually are treated messages which are based on business demands. A as one system. Unification is about the full integration significant feature of interlinking is that interoperability into one common system or the standardization of takes place without substantial interference with the information systems with respect to their inner structure, inner structure of the participating systems and without function, and content. substantial limitation of their independence. Only Unification as strategy leads to a very high intensity of information exchange is federated in the interaction interoperability or integration. Accordingly, a change in agreement, which means that the inner structure in each one system must necessarily lead to changes in all other system can be specified and developed quite systems. Very often economic and efficiency reasons independently of the inner structure in all other systems are the driving force behind unification as strategy. One in the enterprise. Each system has to produce specified purpose of the unification strategy may be to improve the messages according to interaction agreements, either as simplicity, rationality, and costs of information a planned task or on request, and has to handle management. Another purpose may be to equally treat incoming specified messages. social events (e.g., pensions, insurances, membership, Interlinking implies a change from access or sharing etc.). thinking to messaging. Interaction is bridged through the defined messages based on business relations. It is not

48 © Journal of Enterprise Architecture – February 2012

a question of understanding data in other systems; it is a The impact of EA on the management of IT investments question of understanding what information is to be can also be demonstrated and judged in terms its transferred between the systems. The different data intrinsic values; i.e., the architectural goodness provided structures are local and connected to the messages by the principles of a certain school of thought or certain through mapping mechanisms, which must be architectural framework. For instance, the larger, more developed and maintained for each system. If the inner heterogeneous, and dynamic the business and its structure in one system is changed, then the mapping environment are, the more crucial are the issues of mechanism may need to be changed in that very system information systems delineation and interoperability. in order to maintain proper interaction, but there will be Hence, business agility, manageable complexity, and no change in any other system as long as the interaction comprehendability may be seen as arguments for the agreement stands. choice of relevant architectural principles (Simon 1962; In the long term, interlinking creates the possibility to Ackoff 1967, 1980; Emery 1969, 1975; Galbraith 1973, replace a system without any changes in interoperability, 1977; Hewitt 1986; Sanchez 2000, 2003; Ulrich 1980). as long as the new system fulfills the interaction Unfortunately, very few existing EA frameworks give agreement. This has a major impact in that it reduces clear guidance about how to architect and manage these migration problems and facilitates the sustainability of critical issues. In the two cases below, the intrinsic value complex structures of systems. of EA will be demonstrated with reference to four areas of architectural interest. These are: The Impact of Enterprise Architecture on the Management • Responsibility for investments in Information of IT Investments Systems (Ross et.al. 2006) The impact of EA on the management of IT investments • Time to value (Sessions 2006; Hamilton 2003) can be discussed in terms of two significant dimensions • Managing the co-ordination of IT investments that together express the essence of management in (Ross et.al. 2006; USAID 2008; Ross 2004) general and IT management in particular. The first dimension deals with the principle of stakeholders • Managing the effects of long-term alignment expectations; i.e., “doing the right thing”, and can be (Hugoson et al, 2008; Aert et al. 2004; USAID understood in terms of the extrinsic value of the EA. The 2008) second dimension concerns the principle of knowhow of EA is an expression of an operational alignment architecting; i.e., “doing things right”, and can be between short-term business requirements and understood in terms of the intrinsic value of the EA. In information systems assets that have been organized in this article we focus mainly on the intrinsic value, a particular way as a response to the nature of business although below both dimensions are presented. Thus, environment (Ross et.al. 2006). In the same sense, EA architectural excellence is the situation that both expresses a strategic alignment (or misalignment) dimensions are continuously aligned in a harmonious between the business architecture, information systems way (Hoffman 1988). All these areas denote one and the architecture, and IT architecture (Henderson and same thing; namely, that EA makes sense, also in the Venkatraman 1999). Therefore the EA frameworks context of management of IT investments. should give guidelines for how to manage short-term The impact of EA on the management of IT investments operational alignment and long-term strategic alignment. can be demonstrated and judged in terms its extrinsic values; i.e. various forms of performance improvements. MANAGEMENT OF IT INVESTMENTS – TWO CASES Accordingly, the management of investments in existing In order to demonstrate how EA principles may have or future IT assets can be understood in three areas of impact on the management of IT investments, we use performance (CIO Council 2001): two cases from Swedish industry. The first case is a Chemical Company and the second case is a Company • Resource-related performance; i.e., savings, in the Pump industry. These two cases illustrate how quality, reliability, availability, etc. of IT assets in different architectural principles have been applied in general and infrastructural assets in particular these companies. At the end of this section we discuss (Inputs) how the applied architectural principles impact • Process and activity performance (Outputs), such management of IT investments. as in business efficiency, business effectiveness, business attractiveness, etc. (FEAPMO 2003) Case 1: The Chemical Company • Strategic performance (Outcomes), such as The first case is a Chemical Company with stakeholders’ satisfaction, social responsibility, headquarters, a global sales organization, and a number ethical behavior, social symmetry, etc.

of business units in different countries. Each business give corporate benefits when implemented all over the unit produces and delivers specified chemical products organization. The roll-out of the system was controlled to a worldwide sales organization. As main architectural by the central IT department. principles, the Chemical Company has chosen the information-driven principle for systems delineation and Case 2: The Pump Company a combination of unification and intersection for systems interoperability. In the company common information The second case is a Swedish Pump Company with the was analyzed and defined, and the drive was to create a mission to construct, produce, and sell pumps on the central system, where different sub-systems access and European market. In a number of countries sales update the common information. Sub-systems for companies are established, with local responsibility for different tasks in the enterprise may use additional local the SALES process to support customers in each information, but the main part was unified information, country (Figure 2). The DELIVERY process to fulfill centrally defined. The company invested in an ERP customer orders is centralized and handles logistics, system, proposed by a vendor. This ERP system had a including warehousing and transport to all customers. kernel containing all central information on products, There are two PRODUCTION processes that are customers, sales, warehouses, deliveries, invoicing, somewhat different; one produces small pumps for sales accounting, etc. When the system was “rolled out” into from stock, the other produces big pumps to customers’ different business units some local information could be orders. Product specifications and specifications for added. production of all pumps are given by the central PRODUCT DEVELOPMENT process. Figure 1 shows the business processes and information systems in the company. As its main architectural principles, the Pump Company chose the responsibility-driven principle for systems delineation and the interlinking principle for systems interoperability. Information systems were delineated according to responsibilities for different business processes. The SALES processes were supported by a CRM system. As the SALES process can be implemented in different ways in different countries, each country can have its own instance of the CRM system. This gives freedom of action for step-by-step development, and for future insertion of new systems to support structural changes (new, or new types of SALES processes), without major changes in existing systems. A central information system, the LOG system, was Figure 1: Business Processes and Information Systems in delineated to support the central DELIVERY process. the Chemical Company Two different systems (MPS-S and MPS-B) for material and production planning were delineated, as the two The architectural principles used in the Chemical PRODUCTION processes are different. If new Company lead to an IT investment that must be centrally production plants will be established, each plant will estimated and evaluated. The development, have a separate system. Outsourcing of (part of) the implementation, and operation of the ERP systems must production will therefore not cause changes in remaining be seen as a central infrastructural cost which is handled systems. For the PRODUCT DEVELOPMENT process a by the IT department (even if different parts of the certain system P-DEV was delineated. Central systems organization are charged using some kind of key for cost ACCOUNT and PERFORM support central distribution). management. The manager of the Swedish business unit proposed a The information systems should interoperate through local system, more adapted to the Swedish type of exchange of computerized messages, based on the production and deliveries, but this was denied, even if interlinking principle. Customer Orders, as a result of the the proposed local system was some millions SEK SALES process, are to be sent from CRM to LOG. cheaper than the estimated distributed cost for the These messages contain all information necessary for central system. The Managing Director for the Swedish order fulfillment. Confirmation and Delivery Reports business unit just stated that the central system will not should be sent back. LOG sends Refill Order to MPS–S be profitable in Sweden, and it will limit the possibility to and B-Order to MPS-B. The system P-DEV supplies all make efficient use of the IT support, but the answer from CRM systems with Product Specification and MPS the central IT manager was that the central system will systems with Production Directives. Directive information

50 © Journal of Enterprise Architecture – February 2012

for Accounting and for Performance surveillance is to be On demand from the Managing Director in The sent to the ACOUNT and PERFORM systems, Netherlands, step 2 was to specify and implement a according to specifications from central management. CRM system for the Dutch SALES process. The vendor proposed an extension of the Italian system, but again the CAO gave clear directives that an independent CRM-NL should be developed. The same specification should be used for systems interaction, but the Dutch system may select some other features from the software package, more suitable for the Dutch SALES process. The long-term ability to use different versions and even install systems from other origins is to be maintained. The MD in The Netherlands was responsible for investments in CRM-NL, for changes in the Dutch SALES process, and for the ability to reach business value from the investments.

Gradually other CRM systems were inserted in the Figure 2: Business Processes and Information Systems in structure in parallel with business process development. the Pump Company Implementations of the P-DEV systems started early. In the Pump Company information systems were When changes in the new DELIVERY process were implemented step-by-step. The strategic structure of specified, the system LOG was implemented in parallel systems was used for co-ordination of different with the new logistics. The two systems for the development projects. Standardized software packages PRODUCTION processes were developed in parallel were used and a central license contract was signed with the LOG system in order to fully replace the old with a software house. It was centrally controlled by the system. The business value from investments in each Chief Administration Officer (CAO) that every proposed project could be evaluated separately, and the time to system interacts with other systems according to the value (TTV) for each IT investment was short as the strategic structure, but features in each system (based implementation time for each project was rather short. on the software package) were selected locally. The IT manager was responsible for the IT infrastructure, The Impact of Architectural Principles on Management including the Message Handling System to support of IT Investment systems interaction, and the investment for this (which represents a minor part of the total investment) was The cases demonstrate that the choice of architectural handled centrally. The Managing Director in Italy was principles has an impact on management of IT eager to start implementation of the new SALES investments. The cases also show partly that different process, and step 1 was to specify and develop a CRM principles have different impact on management of IT system for Italy. A vendor proposed a solution with a investments. The most significant impact and differences common database for all SALES processes, but the are: CAO just stated that he controls the structure, and as • Responsibility for IT investments: In the Pump there are no common customers between different Company, the chosen delineation principle SALES processes, the system for Italy should be quite supports local, management-oriented responsibility independent from other CRM systems. Each CRM for IT investments in different parts of the system must send Customer Orders to the central organization, with a central responsibility only for system and receive Confirmation and Delivery infrastructural investments. In the Chemical messages. The CRM system must also interact with Company, almost all IT investments are seen as a central systems for accounting and for performance central responsibility. control, as specified in the strategic structure. The system CRM-IT was implemented within six months, • Time to value: In the Pump Company, it is shown closely co-ordinated with changes in the Italian SALES that the chosen architectural principles support a process. The infrastructure was financed centrally, but step-by-step development, as the interlinking both direct IT investment in the CRM system and IT- principle gives a high degree of independence related investments in the SALES process were financed between different systems. The implementation locally, which gave incentives for an efficient local time for each system is rather short, which means system. Only features that have a business value were that the business value from each local investment chosen in the CRM package. can be reached within a short period of time. In the Chemical Company, the impact from the

investment cannot be reached until the total system frameworks, are more and more critical for the creation is fully implemented. There is also a risk that of attractive information environments. If large changes in different business processes are not organizations do not succeed in managing architectural completed in time, which will still more increase issues, there is a clear risk that considerable resources time from investment to value. and efforts will be invested without achieving desirable • Long-term alignment: The architectural principles in effects. In this article we have discussed two crucial the two cases show different long-term aspects in the context of management of IT investments: perspectives. When a part of the enterprise 1. The choice of principles for delineation of structure in the Pump Company is changed, information systems independence between systems allows 2. The choice of interoperability principles replacement of corresponding system(s) without major changes in other systems. Changes in the Cases from Swedish Industry have been used to information systems architecture, and in a long- demonstrate how these principles may impact the term perspective replacement of the architecture, management of IT investments. Our findings indicate can be carried out gradually, step-by-step in that the principles have an impact on at least four parallel with changes in the business architecture. aspects: For each step, IT investments can be related to • The responsibility for IT investments possible business value. The information systems • Time to value architecture can be kept aligned with the business architecture. In the Chemical Company, system • Long-term alignment replacement is more oriented to a new big bang • Co-ordination of investments in information investment. systems with changes in business processes • Co-ordination of investments in information The study has demonstrated that the EA makes sense systems and changes in business processes: In the because it is able to hold a strong alignment between Pump Company, it is shown how the local the capabilities of information systems architecture and Managing Director coordinates changes in the the ever-changing demands of the business architecture. sales process with development and Furthermore, the capability of the EA is grounded on the implementation of the local CRM system. This is strong agreement between the EA and with the right not only a question of timing; it is also a question of choice of principle of delineation, and principle of management of IT investments in the business interoperation. Finally, the impacts of the mentioned process, necessary to make use of the information principles on the management of IT investments can be system. This improves the possibility to evaluate given in both extrinsic and intrinsic terms. The extrinsic the business value and to follow the outcome in a effects might include various kinds of performance systems lifetime perspective. The freedom of action requisites, for example. The intrinsic character of the EA to invest only in features that really can give is given in terms of issues satisfied by the goodness of business value is strengthened by the the architecture. decentralized financing principle used in the In summary, our thesis is based on two logical company. In the Chemical Company, the roll-out arguments, namely: principle supports efficient implementation of the information system, including education in how to 1. The EA always agrees with the chosen handle the system. Changes (and investments) in architectural principles. the business processes are, however, not seen as 2. The architectural principles have an impact on part of the implementation. In addition, it may be the management of IT investments. very difficult to state the outcome of corporate benefits used in central cost/benefit analysis. Therefore, EA frameworks should give guidelines for the choice of principles for systems delineation and SUMMARY AND CONCLUSION interoperation. There is a need for more research on the impact of various architectural principles on the The strategic role of IT and its significance throughout management of IT investments. Unfortunately, existing the organization increases complexity, variety, and the EA frameworks give no or unclear guidance about the need for change. Hence, IT management must deal with above issues. uncertainties and with different, conflicting, and ever- changing demands. In this sense, EA is playing an increasingly important role in improving IT management practice. Architecture matters, and therefore EA

52 © Journal of Enterprise Architecture – February 2012

ABOUT THE AUTHORS Hamilton H.: Demystifying Enterprise Architecture, Computer Associates International, Inc. (2003). Mats-Åke Hugoson is a researcher at Jönköping International Business School, Sweden, and can be Hewitt, C.: Offices are Open Systems. ACM Transactions on reached at [email protected]. Office Information Systems, Vol. 4, No. 3 (1986). Thanos Magoulas and Kalevi Pessi are researchers at IT Hendersson J.C. and Venkatraman N.: Strategic Alignment: University of Göteborg, Sweden. They can be reached at Leveraging Information Technology for Transforming [email protected] and [email protected]. Organizations, IBM Systems Journal, Vol. 36, Nos. 2&3 (1999). REFERENCES Hoffman T.: Corporate Information Systems Strategy, in Pirow P., Duffy och N., Ford J. (Eds.), Information Systems in Ackoff R.L.: Management Misinformation Systems, Practice and Theory, Elsevier Science Publishers BV (North- Management Science,Vol. 4, No. 4 (1967). Holland) (1988).

Ackoff R.L.: From Information to Control, Björn-Andersen, The Hugoson M-Å., Magoulas T., Pessi K.: Interoperability Human Side of Information Processing, North-Holland Strategies for Business Agility, Dietz J.L.G. et al. (Eds.): CIAO! Publishing Company (1980). and EOMAS, LNBIP 10, pp.108-121, Springer-Verlag Berlin Heidelberg (2008). Aerts A.T.M., Goossenaerts J.B.M, Hammer D.K., and Wortmann J.C.: Architectures in Context: On the Evolution of IEEE STD 610.12: Standard Glossary of Software Engineering Business, Application Software, and ICT Platform Terminology, IEEE, ISBN: 155937067X (May 1990). Architectures, Information & Management (2004), pp.41,781- 794. Klein H.K and Myers M.D.: A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Alberts D.S, Hayes R.E.: Understanding Command and Systems, MIS Quarterly (March 23:1), (1999), pp.67-94. Control, CCRP Publication Series (2006). Lawrence P.L. and Lorsch J.W.: Differentiation and Integration Allen B.R. and Boynton A.C.: Information Architecture: In in Complex Organizations, Administrative Science Quarterly Search of Efficient Flexibility, MIS Quarterly, Vol. 15, No. 4 No. 12 (1967). (December 1991). Magoulas T. and Pessi K.: Strategic IT Management, Doctoral Alter S.: Information Systems, The Benjamin/Cummings Dissertation, Department of Informatics Gothenburg, Sweden, Publishing Company, Inc. (1996). (in Swedish) (1998).

CIO Council: A Practical Guide to Federal Enterprise Marchand D.A. and Peppard J.: Designed to Fail: Why IT Architecture, Chief Information Officer Council, Version 1.0 Projects Underachieve and What to do about it, Cranfield (February 2001). School of Management (November 2008).

Clark T. and Jones R.: Organizational Interoperability Maturity Mathiassen L.: Collaborative Practice Research, Scandinavian Model for C2 (2003); available at: Journal of Information Systems (14), (2002), pp.57-76. www.dodccrp.org/events/1999_CCRTS/pdf_files/track_5/049cl ark.pdf. Ross J.: Enterprise Architecture: Depicting a Vison of the Firm, MIT Sloan Center for Information Systems Research (2004). Edwards C and Lambert R.: IT Investments: Effectiveness of the Appraisal Process. The IT Investment Appraisal Survey, Ross J., Weill P., and Robertson D.: Enterprise Architecture as Cranfield School of Management; Cranfield, Bedfordshire, Strategy: Creating a Foundation for Business Execution, MK43 0AL (2003). Harvard Business School Press (2006).

Emery J.C.: Organizational Planning and Control Systems, Sanchez R.: Modular Architectures, Knowledge Assets, and Macmillan Publishing Co. (1969). Organizational Learning: New Management Processes for Product Creation, International Journal of Technology Emery J.C.: Integrated Information Systems and their Effects Management (2000). on Organizational Structure, in Grochla och E. and Szyperski N. (Eds.), Information Systems and Organizational Sanchez R.: Product, Process, and Knowledge Architecture in Structure, Berlin and New York, Walter de Gruyter (1975). Organizational Competence, Business & Economics (2003).

FEAPMO: The Performance Reference Model; A Standardized Sessions R.: A Better Path to Enterprise Architecture; Approach to IT Performance, Federal Architecture Program ObjectWatch, Inc. (2006). Management Office (2003). Simon H.: The Architecture of Complexity, Proceedings of the Galbraith J.R.: Designing Complex Organizations, Addison- American Philosophical Society, Vol. 106, No. 6 (1962), Wesley (1973). pp.467-482.

Galbraith J.R.: Organizational Design, Addison-Wesley (1977).

Solotruk M. and Kristofic M.: Increasing the Degree of USAID: The Joint Enterprise Architecture Transition Strategy, Information System Integration and Developing an Integrated Department of State and US Agency of International Information System, Information & Management, Vol. 3, No. 3 Development (2008). (1980). Walsham G.: Interpretive Case Studies in IS Research: Nature Sowa J.F.and Zachman J.A.: Extending and Formalizing the and Method, European Journal of Information Systems (4) Framework for Information Systems Architecture, IBM Systems (1995), pp.74-81. Journal, Vol. 31, No. 3 (1992), pp.590-616. Zachman J.A.: A Framework for Information Systems TOGAF®: Version 8.1.1, Enterprise Edition (2007). Architecture, IBM Systems Journal, Vol. 26, No. 3 (1987), pp.276-292. Ulrich W.: The Metaphysics of Design: A Simon-Churchman Debate, INTERFACES, Vol. 10, No. 2 (1980).

Article

Can a Re-Discovery of Open Socio-Technical Systems Strengthen EA?

By James Lapalme and Donald W. de Guerre

Abstract Recent publications by reputable market research firms affirm that IT organizations and Enterprise Architecture groups are not doing very well: high project failure rates and low acceptance of the Enterprise Architecture group. These challenges can be attributed to the “mechanistic” worldview of current IT organizations according to socio-technical systems theory, a theory from the 1950s which has only recently started to be integrated in IT. Over the last decade, there has been a quasi-exponential growth in the use of the term “socio-technical systems” in the IT literature. From this, one could suggest that a possible paradigm shift is occurring in the IT space: a shift from a mechanistic view of organizations to a socio-technical one based on the rediscovery that organizations are open socio-technical systems. Keywords Enterprise Architecture, Sociotechnical Systems, Reductionism, Systems Thinking, IT

INTRODUCTION Some would say, and we would agree, that the shortcomings of our “current way” are rooted in its The purpose of this article is to raise a question: can 1 mechanist or “divide-and-conquer” approach, especially open socio-technical systems theory (OSTS) enrich with regards to the social and technological aspects of Enterprise Architecture (EA)? The article will not review organizations. Based on this approach, the social and OSTS in any depth, nor suggest that EA should adopt technological attributes of organizations are often OSTS. Rather, we simply want to point the reader to the optimized separately under the implicit assumption that possibility that exploring OSTS may be of value to EA the sum of both optimums will produce an overall optimal practitioners. solution. In many organizations, a large portion of the Recent publications by the Standish Group and technological attributes are optimized by IT, with Forrester are not very flattering for the current state of Enterprise Architects as key players, and the other IT: a majority of projects fail and most enterprise (IT) attributes by the non-IT portions of organizations. Such architecture teams are either not accepted by “the an approach often leads to lack of mutual understanding business” or are perceived as doing “IT stuff” (SGI 2009; as well as resistance (Markus 1983). The “socio- DeGennaro 2010). Some of the main reasons why IT technical way” approaches the optimization of projects fail are employee cooperation, cultural gaps, organizations with the opposite assumption; and misalignment with business objectives (Grindley consequently, both the social and technical systems 1995; Ward 2002). In a similar fashion, some of the key must be optimized together (the terms social and challenges for EA acceptance are political and cultural technical will be defined latter). Consequently, issues, the understanding and perceived relevance of organizational optimization must be addressed EA by “the business”, and the lack of understanding of holistically and not have IT addressing the technical the business context (Burton 2009, 2010). The picture portion independently of the business folk addressing that these publications paint suggests that current IT the rest. There is one architecture of the organization ways of doing lack strategic “umpf” (lack of EA and not independent sub-architectures which are acceptance) and cannot deliver the goods (project assembled. Mutual understanding across all dimensions failure). The question now is “what are we doing wrong?” is facilitated and resistance is minimized. or better yet “can we do things differently?” Actually, Before diving deeper into this new way, we want to talk maybe there is “another way” looming on the horizon about the signs that seem to point to its emergence. We and it is called “the socio-technical way”. recently did a keyword search for the adjectives «socio- technical» and «sociotechnical» on both the IEEE and ACM digital libraries. The ACM library gave more than

1 3,700 hits and the IEEE more than 1,000. As such, these We use OSTS to include socio-technical systems theory and open numbers are not significant. Some might be thinking to systems theory as one description of Organization. This is explained further in the article. themselves: “so what, 4700 IEEE and ACM papers were

published between 1950 and today about the things that Table 1: Current Way versus Emerging Way can be qualified as socio-technical!”And they would be right. However, what is of interest is the fact that of those Current Paradigm Emerging Paradigm papers more than half were published after 2008, almost Disinterest in the human Embrace of the human 20% in just 2010 alone! These numbers become even dimension dimension more intriguing when one considers that the term “socio- A mechanistic approach to A holistic approach to enterprise and IT design enterprise and IT design technical” was coined in the 1950s, more than 60 years Smart systems to replace Systems for smart people ago. These numbers seem to indicate a significant people increase in interest in socio-technical “matters” in the last few years (see Figure 1). WHAT DOES “SOCIO-TECHNICAL” MEAN ANYWAY? So what is this “socio-technical” (and sociotechnical) gibberish and why is it important? The terms are used loosely in most articles to qualify things having social and technical features (or characteristics). In contrast to former imprecise usage, since the 1950s, the term Socio-Technical Systems (STS) has a very exact definition that we will illustrate first by using analogies before offering a precise definition. There are two predominant ways one can view an organization with regards to its people, how they work, and the technology that they use.

Figure 1: Occurrence of the Terms “socio-technical” and “sociotechnical” Recently, there is a significant increase of exchanges in discussion groups such as those on Linkedin about the differences between Enterprise Architecture and IT-centric Enterprise Architecture, the latter being increasingly referred to as Enterprise IT Architecture (EITA). A key question that emerges from these Enterprises as Machines Enterprises as discussions is whether it is possible or not to architect Socio-Technical Tapestry the IT portion of an organization independently of all the other aspects of the organization, with the exception of Figure 2: Different Worldviews of Enterprises business requirements and strategy, and hope to The first sees the organization as a mechanical device. achieve an effective solution? There is clearly a socio- People and the technology used are like the mechanical technical concern behind this question. parts that make companies work (see Figure 2). To build In summary, these signs seem to foretell the rebirth of a mechanical device, the key challenges are to define socio-technical systems thinking as an evolution of the the required parts based on breaking-up the work into social dimension in EA. Being witness to these signs, clearly defined tasks (and assigning a person to each one has to wonder if there is not something more task) which creates “a part” of the whole, and then important going on such as a progressive paradigm shift making sure that the parts can be assembled into a in the EA and IT communities. The paradigm shift seems working whole. A “divide-and-conquer” approach usually to be towards an acknowledgement of the socio-cultural helps with the first challenge and standards for dimension of organizations, the holistic nature of the interconnecting parts helps with the second challenge. enterprise design challenge, and the recognition that we Also, the quality of the design will be greatly influenced should be developing technologies for smart people by the competency of the designer and the capacity of rather than smart systems to replace people (or at least the “parts” to play their role as determined by the minimize the need for people). designer’s plan. When applying this view to companies, the result is organizational structures and work designs

that are viewed as separate from the technology that In summary, according to Socio-Technical Systems supports them. Organizations are typically designed in theory (Emery 1959; Trist 1981) and its successor, Open order to allow each part to be optimized separately and Systems Theory (OST) (Emery 2000), an open socio- the key concern is making the pieces fit together, hence technical system is a system composed of a technical getting people and technology to work according to plan. system (workplace, work design, materials, tools, and Managers and remuneration policies are used as “glue” machines) which assures how the inputs to the system to connect the parts together in an often coercive are transformed into its outputs and a social system fashion. If the organization doesn’t work, either the parts (people with needs and desires, culture, interpersonal are not working according to design or the glue is not relationships, etc.) that controls and co-ordinates the working, or the design is wrong. transformation process (Trist 1981). Another key Often, an organic metaphor is used to describe characteristic of socio-technical systems, according to organizations as living systems, but organizations are OST, is that they are open systems; hence, they must not organisms. They do not occur naturally; they are co-evolve with their environment in order to be designed and thus can be redesigned. An STS sustainable (Emery 2000). The crux of OSTS theory is perspective takes a contextual view seeing organizations the principle by which optimization must be done through as a fabric (see Figure 2). They are like cloth tapestries the joint optimization of both components; all other made by weaving social and technological threads optimization strategies will offer sub-optimal solutions. together into intricate patterns. The weaving patterns will By their very nature, all organizations are open socio- be dependent on both the threads that are available and technical systems. Consequently, according to OSTS, all the purpose of the tapestry, hence highly context- organizations must jointly optimize their social and sensitive. Moreover, the fabric isn’t woven by the hands technical systems as well as co-evolve with their of a single weaver but rather through a collective environment or face high risks of failure. weaving process fuelled by the weavers making “sense” WHY IS THIS IMPORTANT? of what they are trying to accomplish together as well as by who they are as people (needs, aspirations, skills, The predominant paradigm that has shaped today’s etc.). Tapestry weaving is a socio-technical design enterprises and IT is mechanism (Pepper 1961). What is process that necessarily involves large groups of people, interesting is that both aren’t doing so well and the not just a small elite design team. The design and second paradigm foretells this outcome. Pepper (1961) weaving of the tapestry jointly considers the raw calls the second paradigm “contexualism” which uses materials, the tools, the workers, and the working “wholes and complexes” as its basic units rather than process in a holistic fashion. Obviously, this can only be “parts”. So maybe a paradigm shift is necessary, or done by a multi-disciplinary cross-functional design perhaps, according to the evidence we have presented, team. When applying this view to companies, the it’s already happening. outcome is organizational structures, work designs, and The paradigm shift requires the design processes used technology that are co-designed with the needs of the to define organizations and IT infrastructures (software, social system which is composed of people and relations hardware, telecommunication, etc.) to change amongst and between those people. Working-out the significantly. Consequently, how EA is defined and design without considering the starting materials (the executed will have to be reviewed as well as its threads and the weavers) will lead to failure. organizational role because organizational structures, The key difference between these perspectives is the work design, and social needs will become key concerns assumption (or not) that an organization can be in the design process. With regards to IT, the role of IT understood by understanding its parts. Accordingly, the specialists when defining the IT solution will shift from organization is understood by decomposing the whole that of expert solution creator to one of design process into its various parts, analyzing each of the parts facilitator so that they can “weave” a solution together separately, and then choosing how they fit together. This with business folk through a joint participative process. analysis process assumes that nothing is lost in the Socio-technical optimization is achieved by both decomposition process. This works for a mechanical addressing the social dimension in the design, but above device because it is a combination of parts working in all by addressing the social dimension of the design tandem; nothing more, nothing less. In contrast, a process itself. By having the people that will be directly tapestry is more than the individual threads. It is an inter- impacted by a solution design it, they will consciously weaving of those threads into a unique whole. On their and unconsciously address the social dimension in the own, the threads are just threads; not parts of a tapestry, design as well as their needs. and taking threads out begins to unravel the whole Some of these ideas may seem strange to some, maybe tapestry. It is not possible to understand the tapestry even crazy to others, but some examples of these shifts with its intricate patterns by looking at each thread alone. can already be seen. For example, there are a growing

number of EA frameworks such as Enterprise Canvas The second characteristic would entail two elements. (Graves 2007) and PEAF (Smith and Graves 2011) The first element is that the EA process would address which have already been rolled out. Gartner is also both the social system (people, culture, norms, incorporating social aspects into its EA articles such as interactions, roles, etc.) and the technical system hybrid thinking. Another example is the emergence of (technology, tools, materials, etc.). In modern agile delivery, in which business and IT personnel form a organizations, IT technologies play a key role in the cohesive team that is jointly responsible for defining technical system hence the traditional IT domains of solutions. The agile process allows for co-evolution of data, applications, and infrastructure must be addressed. software solutions with their associated business The traditional business architecture would be separated processes. into three portions: the social system (people, culture, In addition, key IT thought leaders such as Grady Booch roles, etc.), the technical system (process), and the have begun spreading the word in industry publications system-in-environment coherence (objectives, vision, (Booch 2010). competition, etc.). The second element is that current system boundaries (i.e., divisions, departments, sectors) WHAT DOES THIS MEAN FOR ENTERPRISE might have to be redrawn in order to achieve a coherent ARCHITECTURE? and stable OSTS. Consequently, all the organizational There are various perspectives in the community on the entities that are interacting with the system must meaning of the term Enterprise Architecture (EA). If we participate in the process in order to help determine new adopt the view that EA is about architecting the whole boundary relations. enterprise (i.e., both the social and the technical The third characteristic would require that the EA dimensions), then the application of open socio-technical process addresses a number of points: systems has profound implications. • Determining the new boundaries of the system Previously, we have explained that organizations, (including members) viewed from the perspective of open socio-technical • Learning about the environment (stakeholder systems, have two key characteristics: needs, competition, expectations, etc.) 1. They are tightly woven socio-technical tapestries • Learning about the historical context of the system whose design and optimization must jointly (how has the past shaped the current state and consider the social and technical dimensions. what to drop and what to take forward) 2. They are open systems which must co-evolve • Determining the vision and objectives of the system with their environments. According to OSTS, the design process of organizations • Influencing its environment in order to achieve co- must possess the following characteristics: evolution A consequence of the EA outcome being owned by the • Participative and democratic system is that an Enterprise Architect can’t be • Address jointly both the social and technical responsible for the outcome per se. His/her responsibility dimensions to achieve joint optimization is one of nurturing and upholding the design process • Address organization-environment co-evolution itself in order to uphold the socio-technical systems principles and open socio-technical systems design The question now is: “what would an Enterprise process characteristics (Cherns 1976; Taylor and Felten Architecture process possessing these characteristics 1993). A corollary of this latter point is that the people look like?” nurturing and upholding the design process (Enterprise The first characteristic would entail that the EA outcome Architects) must have a solid grounding in both how be owned by the organization (or sub-organization) machines/technology behave as well as the way people under design – for the remainder of the text, we will use and social groups behave. Since this double specialty is the expression “system” in place of organization (or sub- rare, an engineer-social scientist pairing is usually organization) under design. Moreover, the members of required. the system would be full participants in the process co- determining the outcome by making design decisions. HOW DOES THIS APPROACH COMPARE WITH This is a necessary condition not only because people- CONVENTIONAL METHODS? in-environment psychologically need to be involved but In order to shed more light on the consequences of to ensure implementation people need to understand enriching EA with OSTS, let us compare such an and be committed. People are committed to what they approach with current ways of doing EA. Our intent is are involved in creating. not to make side-by-side comparisons, but rather to

highlight and contrast some of the predominant 2008), most do not use a participative and democratic differences. process. They are more concerned with making the outcomes of the EA process “user-friendly”, but not the Participative versus Top-Down process itself!

In many organizations, the execution of EA is often given Mechanist versus Contextualist to an elite group of senior IT specialists (sometimes management specialists), which are typically positioned Most EA methodologies have been designed and at the higher levels of the organizational hierarchy. This supported by the engineering and computer science select group has the mandate, guided most often by EA communities. According to Pepper (1961), these methodologies rooted in strategic planning (Ansoff 1965) communities typically have a mechanistic view of the and strategy design (Christensen et al. 1982) to define world. Mechanism is a world view that is based on the the desirable future state of the system. The members of metaphor of a machine. Because of this underlying the system are typically involved in only a limited metaphor, the engineering and computer science capacity, usually for requirements gathering and final communities often hold implicit assumptions and beliefs design validation. The EA team usually selects the that an organization can be viewed as a machine which members of the design team for business requirements, can be engineered to achieve ultimate perfection. In the future business targets and objectives, as well as current extreme case, if it were possible to engineer out people irritants. In addition, the gathering of potential solutions that would be perfect because people are inherently is often avoided; it is not rare to hear requests from the unpredictable and perfect machines should be EA team such as: “please give us requirements and not predictable. These assumptions often lead to an solutions; we will propose the solution which will take overemphasis on the technical system to the detriment into consideration the larger picture”. This separation of the social. Often the objective is to adapt or coerce between those with the needs and those determining the the social system to fit the optimized technical system, solutions usually creates misunderstanding and according to “best practice”. Consequently, these resistance. It is not rare to have the system reject (even methodologies and their outcomes reflect these sabotage) the solution proposed. Both the challenges assumptions. with regards to gaps and acceptance are often In contrast, an EA process based on OSTS is grounded exacerbated by the fact that the people solicited for the in explicit ideals and values, which are humanistic. It is requirements are not those doing the work but rather also very much influenced by the social science supervisors who: research communities which have a more ecological or • Are not always aware of the workflow details that contextual view of the world and organizations (Pepper workers have long since developed and 1961). Such an EA process tries to achieve joint implemented a work-around optimization between social and technical systems and not put overemphasis on either. The underlying objective • Have divergent views from their team on how the is to achieve cohabitation between people and work should be improved technology and not replace one by the other. The EA teams typically try to get around these challenges by emphasis is on developing technologies for smart people using an iterative two-step design and validation rather than smart systems to replace people. process. They also develop a very keen sales aptitude in order to get their ideas across. However, currently, most Piecemeal versus Holistic EA teams do not have deep support within their organizations; according to Forrester, only 15% of EA Most EA methodologies that propose a process offer teams are recognized (DeGennaro 2010). This very low one that is fairly linear. Moreover, it is not rare for them rate would seem to support the predicted resistance of a to choose a starting point such as process redesign or IT top-down process. ecosystem design and then, in a linear fashion, adapt EA grounded in OSTS would be necessarily participative the other dimensions of a socio-technical system, one at in nature. EA process grounded in OSTS would be a time building on the previous decision. This linear democratic and participative. Enterprise Architects in this approach complemented with an underlying mechanistic context are guardians of the process, not the outcome. It worldview goes a long way to explain why most EA is the system that owns the outcome and the process. approaches are techno-centric and socially coercive in This difference is one of the most significant between nature. However, what underlies these shortcomings is OSTS-grounded EA and other approaches. Despite the caused by a much deeper assumption: divide-and- fact that there is an emergence of socially-sensitive EA conquer. Based on the problem-solving tools of the approaches, such as User-Centric EA (Blumenthal engineering communities, most EA methodologies

assume that the design of a system can be addressed in the system. An inquiry and learning process must be a piecemeal, linear fashion. The strategy is to recursively planned as well as time for tool creation, adaptation, and divide the larger problem into independent sub- adoption. It is important to understand that the objective problems, solve these sub-problems, and reconstitute is not to use the latest fad analytic or modeling tools, but the combined solution. At best, most mainstream EA rather to foster learning and appropriate system design. methodologies will propose iterative processes, which try In practical terms, the stance taken in an EA process to refine an optimal solution by using multiple gap-and- based on OSTS on modeling artefacts and tools is that fix steps. It is very rare to find an EA methodology which the majority of people designing and implementing the explicitly acknowledges that the design process cannot new EA must understand the design as well as be able use a linear problem-solving approach, but requires to use the tools/artifacts to redesign as necessary. rather a more holistic approach. Consequently, having only a select few EA experts is Most EA methodologies are also piecemeal in the neither appropriate nor desirable. In contrast, it could be domain that they consider. Many dimensions such as said that current EA methodologies give too much education/training, pay system, human resource policies, importance to creating comprehensive (most often very and important historical events are swept aside because complex) tools and artifacts that hinder conversation, they are judged to be unimportant to the final design. In consequently hindering EA. According to an EA process order to achieve an optimal, coherent, and stable based on OSTS, conversation, teamwork, and ongoing system, all systemic dimensions must be addressed organizational learning are the key tools of EA ... the rest together as a whole. This holistic nature of an EA is secondary. process guided by OSTS is probably one of the most challenging, but its avoidance is one of denial of the IS SOCIO-TECHNICAL SYSTEMS YET ANOTHER systemic nature of the problem at hand as well as the FAD? co-implicative nature of the system-in-environment History seems to be repeating itself. Today, relationship. organizations are struggling to get value from IT; in the past, it was the British coal mine bosses struggling to get Process versus Artifact value from their high-tech production lines.

Most current EA methodologies implicitly or explicitly use In the early 1950s, the British coal mines were one of three stances when defining Enterprise transitioning from shortwall to longwall mining because Architecture: EA as a process, EA as an artifact, or EA of projected production and financial increases (Trist and as both a process and an artifact. Bamforth 1951). The shift was made possible by the introduction of novel industrial automation tools and the The stance taken by an EA process based on OSTS is redesign of work teams based on the newly available that of a process and artifact for the key outcome of the tools. Despite significant investment in the new tools and process is a redesigned open socio-technical system, ways of doing things, the coal mines didn't see their which is capable of learning from and influencing its productivity or their profits increase significantly. In some environment as well as the necessary shared tools cases, both decreased acutely. Seeking to understand (artifacts) that are required to support the management their predicament, the coal board hired two researchers and future evolution of the system. Two things are to investigate. The conclusion from the investigation was particular about this stance. The first is that the outcome that the new technologies and work design had strong is not a repository of artifacts or a redesigned system, negative impacts on the social needs of the but rather a system which is capable of learning, the organizations and hence absenteeism and sabotage basis for continuous active adaptation. The corollary of significantly increased. This was the birth of socio- this is that the redesign process is never really finished technical systems theory. but rather is embedded in the day-to-day activities of the system, which strives to better itself. The second Since the coal mine work, socio-technical systems particularity of this stance is that the tools used to guide theory been applied in multiple organizations across the analysis and decision-making must be adapted by the world and has greatly impacted working conditions in system both during the design process and after (for certain countries. In the USA, organizations such as continuous evolution). Since the tools serve to help the Procter & Gamble, General Foods, TRW, Cummins participants in the process (the system) to make Engine, and Corning redesigned entire manufacturing decisions, this necessarily means that the participants facilities based on STS principles (Trist 1981). In Norway understand how to use the tools as well as their meaning and Sweden, legislation on work was changed in the and implications. In order to achieve this, an Enterprise 1970s in order to foster quality of work life, a key tenet of Architect cannot merely use a pick-and-choose socio-technical systems theory (Trist 1981). In the 1980s approach of best practice tools and sell (coerce) them to and 1990s OSTS spawned many different approaches to

organizational design and redesign that today are Burton B.: Top EA Challenges in Australia and Singapore are becoming standard approaches to achieve innovative People and Business Issues, Gartner, ID Number: G00170855 organizations (van Eijnatten 1993). (2009). We are well aware that what we are pointing to is a Burton B.: Enterprise Architecture Seminar Workshop Results: paradigm shift and that this shift needs to occur in Top EA Challenges, Gartner, ID Number: G00173809 (2010). management as well in as IT. What we are suggesting is Cherns A.B.: Principles of Socio-Technical Design, Human that IT could take the lead to innovate and improve EA, Relations, 29 (1976), pp.783-92. thereby helping to transform management. While many approaches to EA are already considering the human Christensen C.R., Andrews K.R., Bower J.L, Hamermesh G., dimension and working to design the whole, we believe and Porter M.E.: Business Policy: Text and Cases (5th Ed), OSTS can contribute to these efforts. Our key point is Homewood, IL:Irwin (1982). that one cannot design IT without designing DeGennaro T.: The Profile of Corporately Supported EA organizations as open socio-technical systems and that Groups: Tactics for Improving Corporate Management’s co-design or joint optimization is required to do this Support for EA in Large Firms, Forrester (September 2010). successfully. Emery F.E.: Characteristics of Socio-Technical Systems: The In the IT space, socio-technical systems theory has been Emergence of a New Paradigm of Work, Canberra, ANU/CCE applied explicitly by people such has Enid Mumford for (1959). more than 20 years (Mumford 2006). Moreover, underlying approaches such as SCRUM delivery and Emery M.: The Current Version of Emery‘s Open Systems Joint Application Design (JAD) are important extensions Theory, Systemic Practice and Action Research (13:5), (2000), of the theory. pp.685-703. Is socio-technical systems theory and thinking just a Graves T.: Real Enterprise Architecture: Beyond IT to the fad? We don’t believe so. It has been researched, Whole Enterprise, Tetradian Consulting, The Coach House documented and applied for more than 60 years Balkerne Close. Colchester, England (2007). (Mumford 2006). Discovered many decades ago, it now Grindley K.: Managing IT at Board Level (2nd Edition), London: seems poised for a rediscovery that could strengthen Pitman Publishing (1995). EA’s thinking and practice. Markus M.L.: Power, Politics, and MIS Implementation, ABOUT THE AUTHORS Communications of the ACM (26:6), (1983), pp.430-444. James Lapalme PhD is an Enterprise Architecture Mumford E.: The Story of Socio-Technical Design: Reflections consultant and researcher. He has contributed, as an on its Successes, Failures, and Potential, Information Systems Enterprise Architect, to work which has been the subject Journal, 16 (2006), pp.317–342. of case studies by Gartner and MIT-Sloan. He has also published a number of book chapters and journal articles Pepper S.: World Hypotheses: A Study in Evidence. CA:University of California Press (1961). on systems engineering-related topics. He may be reached at [email protected]. Popper K.: The Logic of Scientific Discovery, London: Donald de Guerre PhD is an associate professor at Hutchington & Co. (1959). Concordia University in Montreal. Previously, he had a Sauer C.: Why Information Systems Fail: A Case Study distinguished international career as a consultant and Approach, Oxfordshire: Alfred Waller Ltd. (1993). manager working in the private, public service, and non- profit sectors. His major area of interest is the Smit, K. and Graves T.: An Introduction to Peaf: Pragmatic development of participative governance and Enterprise Architecture Framework, Pragmatic EC Ltd. (2011). organization and the further development of open Taylor J.C. and Felten D.F.: Performance by Design: Socio- systems theory. He may be reached at Technical Systems in North America, Englewood Cliffs, [email protected]. Prentice Hall (1993). REFERENCES The Standish Group International (SGI): Chaos Summary Report, The Standish Group International (SGI) (2009). Ansoff H.I.: Corporate Strategy, NY: McGraw-Hill (1965). Trist E.: The Evolution of Socio-Technical Systems: A Blumenthal A.: An Introduction to User-Centric Enterprise Conceptual Framework and an Action Research Program, Architecture, InfoManagement Direct (May 2008) Ontario Quality of Working Life Center, Ontario Ministry of Labour (1981). Booch G.: Enterprise Architecture and Technical Architecture, IEEE Software (March/April 2010), pp.95-96.

Trist E.L. and Bamforth K.W.: Some Social and Psychological Ward J. and Peppard J.: Strategic Planning for Information Consequences of the Longwall Method of Coal-Getting, Systems (3rd Edition), Sussex: John Wiley & Sons Ltd. (2002). Human Relations (4:1), (1951), pp.3-38. van Eijnatten F.: The Paradigm that Changed the Workplace, Assen, van Gorcum (1993).

Case Study

The Enterprise Architecture Approach to Support Concept Development in a Military Context: A Case Study Evaluation of EA’s Benefits

By Jukka Anteroinen and Juha-Matti Lehtonen

Abstract The importance of Enterprise Architecture (EA) to enterprise transformation has been identified by an increasing number of companies as well as public sector actors. However, the literature to date does not provide much empirical evidence of the benefits of EA. In this article, we evaluate empirically the potential benefits of the EA approach in Concept Development and Experimentation (CD&E), which is considered a tool to drive strategic transformation in the military community. The DeLone and McLean information system success model is used as an evaluation framework. The research method in the article is a case study. The results of the case study are analyzed statistically. The results suggest that the EA approach could benefit CD&E. The EA approach supports the further utilization of the military concept, which is a life-cycle stage preceding military capability development. The applicability of the evaluation framework needs further research. Keywords enterprise architecture, concept development and experimentation, benefit of enterprise architecture, DeLone and McLean information systems success model, NATO architecture framework

commercial companies (Ross et al. 2006b; Yu et al. INTRODUCTION 2006) and public sector actors (GAO 2010; NATO C3 In the early 21st century, the environment of conflict Board 2007). However, there is not much evidence of represents a new era in warfare. Western military forces how expectations toward EAs and their frameworks are are being drawn increasingly into highly complex and met. Several academic papers (Aier et al. 2009; Kaisler lethal campaigns in urbanized terrain against irregular et al. 2005; Kamogawa et al. 2005; Niemi et al. 2009) enemies that are invulnerable to many advanced have identified the lack of research evidence with regard technologies. (Kilcullen 2005). More responsive and to benefits of EAs, including governmental organizations versatile military capabilities (i.e., the ability to deliver a (Hjort-Madsen 2006; Liimatainen 2008). specific effect or a specific course of action [NATO C3 The existing EA application studies in the military Board 2007]) are required to meet these contemporary contexts deal with capability testing (Dryer et al. 2007) challenges (Hoffman 2006). However, the time needed and mapping DODAF tools against military outcomes to transform a new idea that is potentially war-winning to (Saulson 2006), but the authors have not found any a tangible military capability (e.g., manifested in weapon research on the application of EA in CD&E. systems) is lengthy—usually 15 to 20 years (Reynolds Nevertheless, there is some practical evidence of the 2006). Thus, it is of utmost importance that the right gap between the current and best practices of EA capabilities can be identified and built. Concept application in the CD&E. Military sources recognize that Development and Experimentation (CD&E) plays an EA frameworks, such as the NATO Architecture important role in driving strategic transformation in the Framework (NATO C3 Board 2007), not only support military community by enabling the structured conventional system planning and implementation development of creative and innovative ideas for viable activities but also have an increasing role in prototyping solutions to the challenges of capability development and experimental work, because they are an excellent (NATO Military Committee 2009). way to describe military problems and potential Enterprise Architecture (EA) is defined as an integrated candidate solutions with high precision, including CD&E model of a particular enterprise (Namkyu et al. 2009). activities (The Technical Cooperation Program 2006; Organizing structures for the information contained in United Kingdom Ministry of Defence 2009). Moreover, a EAs are known as Architecture Frameworks (AF) high-level of CD&E guidance (The Technical (Namkyu et al. 2009; NATO C3 Board 2007). The Cooperation Program 2006) and code of best practice importance of EAs in supporting strategic change has (Command & Control Research Program 2002) been identified by an increasing number of both recommend using the EA approach to enhance the

products and process of CD&E. Detailed guidance for military commander, using military art and science, might the concept development process, however, does not employ the capabilities necessary to meet future military recognize the EA approach as an organic element of challenges.(Chairman of the Joint Chiefs of Staff 2006) CD&E, instead characterizing the development as Thus, there is an inevitable need to ensure that the “writing the concept” (Chairman of the Joint Chiefs of CD&E process links with the capability development Staff 2006). This implies that the document considers phases and processes (NATO Military Committee 2009). concept development more a simple writing process Concept development, in turn, is a process (NATO than a comprehensive innovation process in which Military Committee 2009) or life-cycle phase (ISO 19439 various methods, such as the EA approach, would be 2006) aimed at identifying the conceptual solutions to used. capability challenges. Experimentation is seen as a The EA approach in this article refers to modelling a controlled investigation to discover information, confirm real-life military concept in accordance with a defence or disprove a hypothesis, or formally validate a concept sector EA framework — Nato Architecture Framework based on a conceptual rationale. (NAF) — guidance and instructions. Without knowing whether the EA approach will benefit the activities it tries Enterprise Architecture Approach and its Application in to support, such as military CD&E, the danger is that this Article resources will be wasted on an EA that does not enhance the quality of information; e.g., the consistency An enterprise is one or more organizations sharing a and completeness of the processes and products it tries definite mission, goals, and objectives to offer an output, to support. It is also possible that the EA products (e.g., such as a product or service (ISO 15704 2005). Enterprise integration is the process of ensuring the EA models) are not comprehended by the users, who are not necessarily Subject Matter Experts (SMEs) in the interaction between enterprise entities necessary to EA (Chen et al. 2008; Kluge et al. 2006). In this case, achieve domain objectives (ISO 19439 2006; McGinnis 2007) and is applicable to any enterprise, regardless of the benefit of the EA would not be very great, although the EA model would be perfect from the perspective of its size and mission (ISO 15704 2005). One way of the EA SMEs. Furthermore, there should be a clear approaching the enterprise integration is through enterprise modelling (e.g., by using a consistent understanding of how the EA would provide the best support for the users; i.e., determining whether the most modelling framework) (Chen et al. 2008). Enterprise desired use of the EA is to increase communication or to Modelling (EM), in turn, is an abstraction of an enterprise act as a blueprint for further decisions or perhaps to domain that represents enterprise entities, their inter- provide means to store the strategic information in a relationships, their decomposition, and detailing to the meaningful format. extent necessary to convey what it intends to accomplish and how it operates (ISO 19439 2006). Thus, the Hence, the objective of this article is to evaluate the enterprise model is a representation of those intentions benefits of the EA approach in military concept CD&E. (ISO 15704 2005). Enterprise modelling is also seen as The article has the following structure: Section 2 how the EA is visualized and expressed and how this presents the theoretical background; Section 3 visualization serves and increases the enterprise discusses the methodology and evaluation parameters; integration (Lankhorst 2009; Yue et al. 2009). The Section 4 presents the actual case; and Section 5 architecture at the level of an entire organization is presents and discusses the results of the evaluation of commonly referred to as EA. It is a coherent whole of the case study. Finally, Section 6 concludes the findings principles, methods, and models that are used in the of the study and discusses the need for further research. design and realization of the enterprise’s organizational structure, business processes, information systems, and THEORETICAL BACKGROUND infrastructure (Jonkers et al. 2006). AF provides an organizing structure for the information contained in Concept Development and Experimentation and the architecture. AF is not an architecture, but it specifies the Current Development Practice guidance, rules, and product descriptions for developing and presenting architecture information (NATO C3 Concepts connect strategic guidance to the development Board 2007). However, based on information in ISO and employment of future military force capabilities and 15704 (2005) and IFIP–IFAC Task Force (1999), AFs therefore can be seen as an “engine for transformation”. are also seen as type 2 architecture that pursues the In military organizations, transformation may eventually structuring concepts and activities/tasks necessary to lead to doctrine, organization, training, materiel, design and build a system (Chen et al. 2008). In military leadership and education, personnel and facilities, and CD&E, AFs are seen primarily as a modelling support to policy changes. Military concepts can be seen as a capture and describe the processes, information nodes, visualization of future operations. They describe how a

data flows, and the range of different inter-relationships however, refers to out-dated versions of the AFs. being experimented with (The Technical Co-operation Consequently, the ranking results are likewise out-dated. Program 2006) and also identified as one sort of static Two of these well-known defence AFs, namely DoDAF model among all potential modelling support (Command and NAF, are described below, because they were & Control Research Program 2002). considered the most suitable candidates for application As noted above, the definitions of EM and EA are to the case project of this article. Their suitability similar. However, researchers have identified differences stemmed from the case project’s origin as part of the between these notions. On the one hand, EM describes US-led multi-national military CD&E program. the EA from various viewpoints in detail to allow the DoDAF Version 2.02 was approved for use in 2010. specification and implementation of the systems (Chen DoDAF serves as the overarching framework and et al. 2008). On the other hand, EA such as Generalized conceptual model used to facilitate the ability of Enterprise Reference Architecture and Methodology managers to make decisions more effectively through (GERAM) is a framework for practicing EM (McGinnis organized information-sharing. DoDAF focuses on 2007). Furthermore, the concept of EM is also architectural data as information required by decision- considered to be less developed than that of EA, and makers, rather than on developing individual products thus unable to achieve the effectiveness of EA (US Department of Defense 2009). Therefore, DoDAF (Kamogawa et al. 2005). does not have products, but has DoDAF-described On the basis of these definitions, the EA approach in this views. Architecture views are, in turn, organized into article refers to modelling the real-life military concept viewpoints (US Department of Defense Deputy Chief project in accordance with a defence sector EA Information Officer 2010). DoDAF consists of eight framework, Nato Architecture Framework guidance and viewpoints: capability, operational, services, systems, instructions. standards, data and information, project, and all viewpoints. The current version of NAF, Version 3, was Defence Architecture Frameworks implemented in 2007. NAF provides mechanisms that enable communication about the essential elements of Several architecture frameworks have been developed the NATO enterprise and its environment, including its particularly for defence sector needs and purposes. The partners. NAF enables architectures to contribute to most mature and widely adopted architectural acquiring and fielding cost-effective and interoperable frameworks in the defence sector (Alghamdi 2009; military capabilities. NAF includes seven views: NATO C3 Board 2007) are the Department of Defense capability, operational, service-oriented, system, of the US Architecture Framework (DoDAF) (US technical, program, and all views. Department of Defense 2009) and the UK Ministry of DoDAF is a department-level AF that was developed Defence Architecture Framework (MoDAF) (UK Ministry primarily for national purposes. In contrast, NAF is a of Defence 2009). NATO uses its own NATO multi-national framework. Currently, there are 28 NATO Architecture Framework (NAF) (NATO C3 Board 2007). member nations and 21 partner nations, including A limited amount of research compares defense Russia. Consequently, NAF emphasizes the architecture frameworks. Characteristics of DoDAF have interoperability requirements among the large number of been compared with various non-defense related AFs, multi-national users. DoDAF seeks also interoperability, based on quality attributes of EAs (Namkyu et al. 2009), but primarily just across the Department of Defense. or using the goals, inputs, and outcomes of AFs as Based on the amount of the AF documentation, the level fundamental elements in the analysis (Tang et al. 2004) of detail is considered substantial both in NAF and or comparing it against the earliest EA framework DoDAF: the NAF document has 882 pages, and (Namkyu et al. 2009): the Zachman framework DoDAF’s documentation totals 390 pages. The large (Urbaczewski et al. 2006). Earlier versions of DoDAF volume of documentation indicates AFs’ attempt to both have been evaluated using the International serve a broad audience and provide concrete support for Organization for Standardization (ISO) standard 15704 various functions of those organizations. These AFs (Noran 2005). No evidence of similar comparisons of emphasize a “fit-for-purpose” approach (US Department NAF has been found. A comparative analysis of the of Defense 2009); that is, architectures and their three aforementioned defence AFs used the analytical products should be designed for a purpose; i.e., to hierarchy process. The study ranked MoDAF as first, address a particular set of problems. One should model DoDAF as second, and NAF as third in its assessment only the required elements of the system of concern on (Alghamdi 2009). The data source used for weighing the the appropriate level of AF, based on needs and assessment criteria (Tang et al. 2004) in that paper, situational constraints. The fit-for-purpose approach means that the AFs do not guide which parts and what

levels of the framework should be used (Baumgarten et (2005) proposed an analytical framework for assessing al. 2007; US Department of Defense 2009) in specific EA effectiveness. Their paper concentrates on the situations, such as CD&E. e-business domain; i.e., business conducted by utilizing The NAF was considered more appropriate than DoDAF methods brought about by Information Technology (IT). as a method for applying an EA approach for the case Velitchkov (2009) also suggested a set of EA metrics to project. MNE 6 is a multi-national enterprise and, as measure inter-related IT goals, particularly those related such, the concepts it develops are multi-national and to EA. However, the evaluation constructs proposed by inter-agency in nature; therefore, as a method base, the Kamogawa and Velitchkov are too oriented to a NAF applies more appropriately. particular purpose, and therefore not applicable in this article. Evaluation of Benefits of the EA Approach Consequently, no single comprehensive view of the ways EA might add value to an organization exists. A The current studies about the evaluation of EA focus on systematic literature review by Boucharas et al. (2010) of presenting frameworks and methodology. The potential EA contributions to organizations found the potential benefits based on empirical evidence are, however, less benefits of EA in 29 unique contexts within which EA has studied (Niemi et al. 2009). Furthermore, the notion been found to deliver 100 unique benefits through three “benefit” or “value” has been defined in various ways. In value-generative mechanisms. However, the findings of this article, benefit is defined as a helpful and useful the study would have been difficult to operationalize (i.e., effect that something has (Hornby et al. 2005). The 100 benefits) in this article, where there is a need to current research about the frameworks and question the stakeholders about how the EA model of methodologies of EA benefits can be divided into two the case project would provide the best advantage for main categories. them. A model by Smolander et al. (2005) presents a The first category comprises research that perceives cohesive set of meanings; i.e., metaphorical forms of benefits mainly as qualitative outcomes; e.g., quality of understanding architectures, although its original area of information and potential use of EA. The DeLone and application is IT: McLean model of information systems success (Delone • Architecture as blueprint, in which architecture is et al. 2003) has been adapted to the EA benefit seen as a high-level description of the system, realization process (Kluge et al. 2006; Niemi et al. 2009). directly guiding more detailed implementation These models provide a framework for assessing EA aimed at the production of individual components benefits (e.g., assessment criteria), but do not describe • Architecture as decision, where architecture directly in detail the measures of effectiveness, which define in supports the decisions about the system structure detail the evaluation parameters. However, one of the adapted DeLone and McLean models (Niemi et al. 2009) • Architecture as language, where architecture is is applied in this article, but modified and elaborated, as considered as the enabler of a common explained in Section 3. Boster et al. (2000) divided EA understanding about the system value into three dimensions: the architect, process to • Architecture as literature, in which architecture is build the EA, and its products. They introduced several used mainly as the documentation of the solution or EA products, which, however, are too generic to be the collection of solutions made in the past applied in this work. Bucher et al. (2006) stated that benefit analysis is a complementary element for cost This study uses these four meanings to query the analysis among many analyses EA could support for the concept developers of the case project about which of mission accomplishment of an enterprise. Their these metaphorical forms are more important than approach is to list and present a comprehensive set of others. analyses rather than describe individual analysis in METHODOLOGY detail. Therefore, the article cannot directly support this work. The DeLone and McLean model of information system (D&M IS) success (Delone et al. 2003) provides a well- The second category comprises research that includes validated (Delone et al. 2003; Kluge et al. 2006; Niemi et both quantitative and qualitative dimensions in the study al. 2009) framework for assessing the benefits of of benefits. Schelp et al. (2007) proposed a multi- information systems, and has been adopted to define the perspective framework based on the concept of benefits of EA (Kluge et al. 2006; Niemi et al. 2009). The Balanced Scorecard to identify the value of EA. Their D&M IS success model is used to assess the potential framework includes assets, processes, services, and benefits of the EA approach in the case project of this financial aspects, but is too generic to provide an article. adequate foundation for this work. Kamogawa et al.

The original D&M IS success model derives from 1992 and was updated in 2003 (Delone et al. 2003). It consists of six categories of IS success, namely System Quality, Information Quality, Service Quality, Use/Intention to Use, User Satisfaction, and Net Benefit, as shown in Figure 1. The updated D&M IS success model includes arrows to demonstrate proposed associations among success dimensions in a process Figure 3: The Applied Use of the Updated Delone and sense, but does not show positive or negative signs for McLean Information Success Model in this Article those associations in a causal sense. A complete (The boxes with white background indicate the criteria, account of the updated D&M IS success model was which are included in the evaluation model of the case provided by Delone and Mclean (Delone et al. 2003). For project.) a better understanding of the nature of the model, the reader is strongly advised to refer to the original study. In addition, Measures of Effectiveness (MoE) within the criteria are needed for the evaluation. The updated D&M The updated D&M IS model and the EA adaptation of IS success model advises that the selection of MoEs the D&M IS model (Kluge et al. 2006; Niemi et al. 2009) should be contingent on the objectives and context of encourage delimiting the evaluation effort by taking on the empirical investigation. Selected MoEs for each board only the most relevant criteria for assessment. survey criterion are rationalized in the following The rationale for the model’s adaptation for this article is paragraphs, and the complete list of all MoEs used in the as follows: The system quality criterion measures the survey is shown in Table 1. system; i.e., EA project. The case project of this article focuses on the EA products to be delivered; i.e., the EA The information quality criterion has been divided into model of the case project, not the process that was used two aspects: quality of content and quality of to create the products. The adapted Delone and Mclean presentation. The MoEs used to evaluate the quality of model (Niemi et al. 2009) sees that the system quality content have been derived from generically recognized criterion is not directly applicable to EA products, but advantages the EA is believed to provide (IEEE Std refers to the information quality criterion. Thus, the 1471 2007; ISO 14258 1998; ISO 15704 2005; NATO evaluation of the system quality criterion was not C3 Board 2007; US Department of Defense 2009). included in the evaluation. Users need to understand the created EA model in order to be able to take advantage of it. This factor is more The service quality criterion draws from the notion that important than the absolute correctness of the model information system organizations work in a dual role (Kaisler et al. 2005). Therefore, MoEs measuring the both as information providers and service providers comprehensibility and self-explaining capabilities of (Niemi et al. 2009). The case project in which the D&M visualizations were used to measure the quality of IS success model is applied is a discrete project, and presentation. There is not yet a clear view of the best there is no continuum in provision of services for the use of the EA model of the case project in concept case project. Equally, the EA model of the case project development. The applicability of the metaphorical was not created by the project team, but by an external meanings of architecture by Smolander et al. (2005) for agent. Consequently, there is no service criterion in the evaluating EA benefits was discussed in a previous case project, and therefore the service quality criterion section. These four meanings are used as MoEs for was discarded from the evaluation. intention to use. However, the language dimension has The use criterion was not incorporated in this article’s EA been divided into internal and external language options model because there is not yet a clear understanding of to determine whether the EA model of the case project what would be the best use of the EA model in CD&E brings value for internal communication within the project work, which will be revealed by the present evaluation. or for external communication with other CD&E projects. That is why the criterion “intention to use” is used as an The metrics of user satisfaction have been defined to alternative to the use criterion. The updated D&M IS assess general satisfaction with the EA products. Here success model classifies intent to use as an alternative the focus is to probe how well the EA model of the case to the use criterion, although it sees intention as an project meets the anticipation of the model. Likewise, a attitude and use as behavior. Correspondingly, the question about the general value was included in the application of the updated D&M IS success model in this user satisfaction criterion to see how an individual study is illustrated in Figure 1. question about the value of the model complies with the average values of all criteria.

“develop a shared capability for coalition forces, in concert with inter-agency partners, international organizations, and other stakeholders to provide Situational Awareness of the Extended Maritime Environment to counter irregular threats.” The main product of the case project was a framework concept (i.e., the concept of operations (CONOPS)). The original concept was developed without the help of systematic and structured EA modelling as a normal CD&E development process consisting of workshops in which the concept was developed by multi-national Subject Matter Experts (SME) through brainstorming and writing in teams.

Modelling the Conceptual Framework of the Case Project in Accordance with the NAF

The EA model of the case project was created by one of the authors who is also an SME in the area of the case project. This EA model was presented to the original concept development team as a product that was complementary to the original concept. Prior to the survey it was reviewed for correctness by three case Table 1: List of the Measures of Effectiveness within all Survey Criteria project persons. The EA model was built in accordance with the Nato Architecture Framework v3 principles and Scale 1 to 5 is used in all MoEs. Value 1 stands for no instructions. The EA model consists of two abstraction change, value 2 for weak improvement, value 3 for levels of the NAF, namely capability (NCV, Nato moderate improvement, value 4 for strong improvement Capability View) and operational levels (NOV, Nato compared to the original concept of the case project, and Operational View) and 16 sub-views, as depicted in number 5 means that the EA model of the case project Table 2. As the case project concept focuses on has brought extreme value to the original concept. The processes, structures, and information requirements, it scale differs from the bipolar five-point Likert-type scale. was considered that those levels and views capture the The reason for using a different scale is that the case main essence of the concept. The case project sought to project concept acts as a baseline and, in the survey, the create a generic concept framework. For that reason, it potential benefits of the EA model to enhance the would have been difficult to define one technological baseline are queried. Hence, the scale consists of only solution to fit all situations; however, the original case positive values. project concept outlined one possible technological solution. Moreover, the technological aspects would CASE STUDY have been presented in the NATO system views (NSV), where the required granularity of information (e.g., data The Case Project: MISA-EM Project exchange by defining specific data protocols) exceeded The actual concept development project in which the EA the available level of information. Therefore, the approach was applied and evaluated is called multi- technology aspect was not included in the EA model of national inter-agency situational awareness within an the case project. extended maritime environment (MISA-EM), hereafter referred to as the case project. The case project Survey to Evaluate the Benefits of the EA Approach in belonged to an international military CD&E program, the Case Project called Multinational Experiment 6 series (MNE 6), which The aim of the survey was to evaluate the potential ran from 2008 to 2010 (US Joint Forces Command benefits of the EA model to support development of the 2010). Participants in this CD&E program were from 19 original case project’s concept. The EA model attempted NATO and non-NATO countries and organizations. One to present the original case project concept in a of its four outcomes was called situational awareness. structured, formal way and in a graphical format to The case project studied in this article was, in turn, one complement the original concept. The EA model of the of the CD&E projects within the situational awareness case project was sent to the entire multi-national case outcome. The purpose of the case project was to project team of 16 persons for review via the Internet a

week before they were asked to answer the survey. The completed, its initial results and their implications were survey was preceded by a two-hour presentation by the discussed by the case project team and the EA model EA model developer about the EA model in a case developer. In addition, when the case project was project workshop. After the EA model presentation, a finished, the contribution of the EA model to the case discussion followed to ensure their understanding of the project and its final report was discussed with the project EA model. The survey on the potential benefits of the EA custodian in Autumn 2010. model was conducted the next day. After the survey was

Table 2: The EA Model of the Case Project Built in Accordance with the NATO Architecture Framework

Table 3: The Background Variables of the Respondents in the Survey

some major differences between the average scores RESULTS OF THE SURVEY given by respondents, while the differences in the average scores of the survey questions are, at least Background Information of the Survey Respondents relatively speaking, smaller. Table 5 confirms this The background variables of the respondents, which observation, as the majority of the variance is explained describe their role and prior experience, are depicted in by the respondents, whereas the variance explained by Table 3. On average, a respondent has prior experience survey questions is less than 10% of it. Both of one to two CD&E projects, moderate experience in respondents and survey questions, however, are modelling, and minor experience in the NAF. statistically significant at p=0,01. Therefore, it can be concluded that at least some differences exist between different respondents and between different questions. Statistical Analysis of the Survey Again, Duncan’s multiple range test would shed more Figure 2 summarizes the 16 respondents’ answers to the light on pairwise comparisons. questions concerning the perceived benefit of using EA in concept development and experimentation. Questions 5 to 10 are about quality of information content, 11 to 15 about quality of visualization (presentation), 16 to 20 about intention to use, and 23 to 24 about user satisfaction. In the scale from no benefit (1) to extreme benefit (5), the average values range from 2,75 (weak to moderate) to 3,63 (moderate to strong). It can be seen that in all survey questions, the respondents perceive at least weak benefits in using the EA approach because the lower bound of the 95% confidence interval is larger than 2 (weak benefits). It can also be observed in Figure 2 that the lower bounds of items 20, 23, and 24 are above the averages of survey questions 10, 15, and 17; the lower bounds of survey questions 20 and 24 do not contain question 9. The differences among the answers to these survey questions appear to be statistically significant, although Duncan’s multiple range test would shed more light on the differences of pairwise comparison. Table 4: Two-Way ANOVA Data, including the averages of each respondent and question as well as their variances

Table 5: Summary of Two-Way ANOVA Results It was considered that the background variables, shown in Table 3, would likely explain differences in the perceived benefits of the EA approach in C&DE. As the two-way ANOVA in Table 5 shows, the differences in the individual respondents’ answers were the largest source Figure 2: Averages of Responses to the Survey Questions of variation in the answers. The ability of the background (as well as their upper and lower confidence intervals variables to explain at least part of the variability in the calculated by students’ t-test at p=0,05 level (n = 16)) responses was tested with multiple ANOVAs. Each background variable was tested in order to find some Analysis of variance (ANOVA) can be used to test for difference between the background group’s answers differences between survey questions. A two-way across all questions. The results found that, statistically, ANOVA calculates the effects of both survey questions none of the four background variables significantly and individual respondents. Tables 4 and 5 show the differentiated the observed answers. Closest to results of a two-way ANOVA analysis. Table 4 indicates

significance was the background variable 4 to question the original concept, as shown in Figure 2 (questions 5 16 EA as internal language (p=0,062), whereas for most to 10). On the one hand, the results show that in the EA of the survey questions and background variables, there model, pictorial information could capture large amounts were no clear signs of connection between background of the concept data to individual graphs that in the variables and group responses. original concept were scattered across several text sections. For instance, the NCV-3 diagram (capability Reliability and Validity of the Survey phasing) of the EA model compiles the available situational awareness capabilities at different points in Table 6 shows the correlation matrix among the survey time into one picture, whereas in the original concept the questions. The actual values of the correlations appear same information covers approximately ten text pages in high; the average of all correlations is 0,67. Moreover, at least two different sections of the concept. On the the value for the statistically significantly non-zero other hand, the results suggest that the EA model correlation for 16 respondents at p=0,05 is 0,47. Except enables the presentation of the information in a for the 10 cross-item correlations that are not statistically compressed format that communicates well. The results significant, all the other 143 cross-item correlations are on increased consistency indicate that it is easier to statistically significant at p=0,05. control and check the conformity of the used terms and their relationships in a limited number of graphs than in a large text document. The quality of the visualization of the EA model was found more than moderately comprehensible, as shown in Figure 2 (questions 11 to 15), excluding the self- explaining capabilities of the EA model that were evaluated between weak and moderate. Thus, the results suggest that the visualization formats provided by the NAF Version 3 documentation can be fairly well understood by a CD&E SME who is not necessarily Table 6: The Correlation Matrix of the Survey Questions familiar with the visualizations the NAF uses and who is One reliability metric is Cronbach’s Alpha, which not an expert in a modelling language, such as Unified measures the internal consistency of a section of a test. Modeling Language (UML). At the same time, the By using data from Table 6, the Cronbach’s Alphas for comprehensibility of the visualizations supports the content quality, presentation quality, intention to use, results shown in the information content criterion. The and user satisfaction are 0,95, 0,88, 0,93, and 0,93, positive judgements by the respondents about the EA respectively. These figures are very high, which reflects model’s ability to increase clarity, consistency, and the high correlations among the survey questions. completeness of the case project required that the Even though high internal consistency is achieved, the visualizations of the EA model could be sufficiently discriminant validity – i.e., the ability of the subtests to understood by the respondents. discriminate between each other – must also be studied. The intention to use criterion surveyed how the concept A value larger than 0,85 can be considered a lack of developers could take best advantage of the model. The discriminant validity, so the subtest structure could not documentation dimension was found the most important be validated. The values for discriminant validity are (avg 3,69) use for the model, as depicted in Figure 2 shown in Table 7. (question 20 of the questions 16 to 20). This EA aspect is oriented mainly towards past decisions and aims at transferring explicit knowledge to future use (Smolander et al. 2005). This finding indicates that the respondents value the EA model mostly as an enabler of further utilization of the concept rather than improving, for instance, the quality of the concept; i.e., the CD&E product, with the help of the EA model. This result can be explained by the fact that the EA model was Table 7: Discriminant Validity of Subtests presented to the original concept developers in the late phase of the case project when it was undesirable to Discussion of the Results change the original concept dramatically. Instead, the respondents may have perceived the EA model as a The respondents found that the EA model moderately complementary product for the original concept, which increased the clarity, consistency, and completeness of provides means to store the key information of the

original concept in a meaningful format for the future. concept developers who were not subject matter experts The respondents saw the Blueprint dimension as the in the modelling or the visualizations of EA. second most important use (avg 3,38) for the EA model; The most important use considered for EA was that it the meaning of this aspect is close to the meaning of the enables the further utilization of the concept created in most important use, documentation. In the Blueprint the case project. CD&E is the predecessor of the dimension, the EA model is seen primarily as a high- capability development life-cycle stage where the NAF or level description of the original concept, which helps the similar military sector architecture framework (e.g., transition of the concept directly to the capability DoDAF) plays a vital role. It would be very beneficial in development, whereas the documentation aspect relates subsequent capability development work to have the to saving the data in a way that facilitates the further use CD&E products already in the form of EA diagrams and of it. views to support the transition from one life-cycle stage The user satisfaction criterion measured the general to another. A common model base could provide greater satisfaction with the EA model as well as the satisfaction consistency and traceability among different compared with the perceptions of the model’s ability to development phases, which would also reduce support CD&E work as shown in Figure 2 (questions 23 redundant work. It should, however, be noted that the to 24). The questions in this criterion are more intuitive results of the meanings of the EA are case-dependent. than the explicit and in-depth questions of the other In this study, the most important meaning may be criteria. The results are slightly higher than the average different than in some other case or environment. values in the four other criteria. The results of this The benefits of the EA model for further development criterion were considered one source of verification for work were demonstrated by the fact that the EA model the other parts of the survey, where different benefit was included in the final report of the case project as a criteria of the EA model were surveyed separately. In complementary work parallel to the original project case other words, the intuitive benefit of the model (general concept. Moreover, the parts of the case project EA value) was found to correspond well with the results of model, such as individual graphs, were embedded in the the other questions in the survey. final version of the project case concept to increase its The potential benefits across the aspects of the consistency and clarity. Finally, further utilization of an evaluation framework that were applied (the updated EA approach – i.e., NAF-based modelling for future D&M IS success model) did not fluctuate greatly, which CD&E work – was recommended in the final case indicates that the criteria of the evaluation framework did project report. not have discriminant characteristics between each other From a wider, practical perspective, the identified for reasons other than those represented in the benefits the EA approach can bring to CD&E could be background variables. In contrast, among the different used to motivate practitioners to change CD&E from a respondents, the potential benefits of the EA model simple writing exercise to a comprehensive innovative varied considerably. The background variables, process in which the EA approach would be an organic however, did not explain these large differences in the part of the CD&E, as best practice has already individual answers. One explanation for the variability in recommended. the respondents’ answers could be that the EA model of the case project was not constructed by the original The results are based on a single CD&E project in which concept development team although it was consulted by the number of participants was limited. Therefore, the three team members. For that reason, some findings require further validation. However, the study respondents could have had a bias either for or against suggests that the DeLone and McLean model of it. Some respondents could have seen the EA model as information system success provides a possible a competitor for the original concept, while some others framework to assess the benefit of the EA approach in may have taken the EA model as a welcome supplement military CD&E. However, the lack of discriminant validity for the case project by introducing an innovative of the framework, observed in the survey, calls for approach to the existing CD&E. further investigation of the applicability of the Delone and Mclean model in information systems to evaluate CONCLUSIONS successfully the potential benefits of the EA approach in In this article, we presented an empirical study on the CD&E. perceptions of the benefits of the EA approach to military In this article, the evaluation of benefits included the CD&E. The results suggest that the EA approach can qualitative aspects of the benefits and excluded the cost bring value to traditional concept development by dimension. The EA approach may bring added value to increasing the clarity, consistency, and completeness of CD&E or any business process it attempts to support, the concept. Furthermore, the survey showed that as a but the benefit gained may not justify the effort used to methodology and product, EA was comprehensible for produce it. Therefore, adding the Return-on-Investment

(ROI) aspect to the empirical EA evaluation would be a Chen D., Doumeingts G., and Vernadat F.: Architectures for relevant focus in future research. Enterprise Integration and Interoperability: Past, Present, and Future, Computers in Industry (59:7), (2008), pp.647-659. ABOUT THE AUTHORS Command & Control Research Program (CCRP): Code of Best Jukka Anteroinen, Commander, MSc (SED) is a PhD Practice Experimentation, Office of the Assistant Secretary of student at the National Defence University of Finland. Defense (OASD), Washington DC, USA (2002). His doctoral studies deal with enhancement of military capabilities by systems approach, including Enterprise Delone W.H. and McLean E.R.: The DeLone and McLean Architectures. He graduated from the General Staff Model of Information Systems Success: A Ten-Year Update, J. Manage. Inf. Syst. (19:4), (2003), pp.9-30. Officers course in Finland in 2002 and received his MSc in Systems Engineering for Defence at Cranfield Dryer D.A., Bock T., Broschi M., and Beach T.D.: DoDAF University, UK in 2007. Jukka can be reached at Limitations and Enhancements for the Capability Test [email protected]. Methodology, in Proceedings of the 2007 Spring Simulation Multi-conference, Volume 3, Society for Computer Simulation Juha-Matti Lehtonen, Dr. Tech, is Professor of Defence International, Norfolk, Virginia (2007), pp.170-176. Acquisition at the National Defence University of Finland. Previously, he was Professor of Operations GAO – United States Government Accountability Office 2010. Management at Tampere University of Technology in Organizational Transformation: A Framework for Assessing 2007-2011 and is now adjunct professor. Central themes and Improving Enterprise Architecture Management (Version in his research work include industrial manufacturing, 2.0), GAO-10-846G, Washington DC, USA. supply chain and service systems, as well as simulation Hjort-Madsen K.: Enterprise Architecture Implementation and and modelling. Juha-Matti can be reached at juha- Management: A Case Study on Interoperability, in Proceedings [email protected]. of the 39th Annual Hawaii International Conference on System Sciences, Hawaii, USA, 71c-71c (January 2006). REFERENCES Hoffman F.G.: Complex Irregular Warfare: The Next Revolution Aier S., Kurpjuweit S., Saat J., and Winter R.: Enterprise in Military Affairs, Orbis (50:3), (2006), pp.395-411. Architecture Design as an Engineering Discipline, AIS Transactions on Enterprise Systems (1:1), (2009), pp.36-43. Hornby A.S., Wehmeier S., McIntosh C., Turnbull J., and Ashby M.: Oxford Advanced Learner's Dictionary of Current Alghamdi A.S.: Evaluating Defense Architecture Frameworks English, Oxford University Press, Oxford (2005), for C4I System Using Analytic Hierarchy Process, Journal of pp.xii,1790,1795,1179. Computer Science (5:12), (2009), pp.1075-1081. IEEE – The Institute of Electrical and Electronics Engineers, Baumgarten E. and Silverman S.J.: Dynamic DoDAF and IEEE Std 1471-2000: Systems and Software Engineering — Executable Architectures, Military Communications Recommended Practice for Architectural Description of Conference, IEEE MILCOM (2007), pp.1-5. Software-Intensive Systems, New York, USA (2007).

Boster M., Simon L., and Thomas R.: Getting the Most from IFIP–IFAC Task Force on Architectures for Enterprise your Enterprise Architecture, IT Professional (2:4), (2000), Integration: GERAM: The Generalized Enterprise Reference pp.43-51. Architecture and Methodology (1.6.3), (1999).

Boucharas V., van Steenbergen M., Jansen S., and ISO – International Organization for Standardization: ISO Brinkkemper S.: The Contribution of Enterprise Architecture to 14258:1998: Industrial Automation Systems – Concepts and the Achievement of Organizational Goals: A Review of the Rules ror Enterprise Model, Geneva, Switzerland (1998). Evidence, in Trends in Enterprise Architecture Research, Proper E., Lankhorst M.M., Schönherr M., Barjis J., and ISO – International Organization for Standardization: ISO Overbeek S. (Eds.), Springer Berlin Heidelberg (2010), pp.1- 15704:2005: Industrial Automation Systems – Requirements 15. for Enterprise – Reference Architectures and Methodologies, Geneva, Switzerland (2005). Bucher T., Fischer R., Kurpjuweit S. and Winter R.: Analysis and Application Scenarios of Enterprise Architecture: An ISO – International Organization for Standrardization: ISO Exploratory Study, 10th IEEE International Enterprise 19439:2006(E): Enterprise Integration – Framework for Distributed Object Computing Conference Workshops (2006), Enterprise Modelling, Geneva, Switzerland (2006). pp.28-28. Jonkers H., Lankhorst M., Ter Doest H., Arbab F., Bosma H., Chairman of the Joint Chiefs of Staff: Joint Operations Concept and Wieringa R.: Enterprise Architecture: Management Tool Development Process (JOpsC-DP), Washington DC, USA and Blueprint for the Organization, Information Systems (2006). Frontiers (8:2), (2006), pp.63-66. Kaisler S.H., Armour F., and Valivullah M.: Enterprise Architecting: Critical Problems, Proceedings of the 38th Annual

Hawaii International Conference on System Sciences, Hawaii, Saulson B.: SEAS ISR Architect: Mapping Department of USA (January 2005), pp.224b-224b. Defense Architecture Views to Military Outcome, The Journal of Defense Modeling and Simulation: Applications, Kamogawa T. and Okada H.: A Framework for Enterprise Methodology, Technology (3:4), (2006), pp.217-225. Architecture Effectiveness, International Conference on Services Systems and Services Management, Vol. 741 (June Schelp J. and Stutz M.: A Balanced Scorecard Approach to 2005), pp.740-745. Measure the Value of the Enterprise Architecture, Via Nova Architectura [online] (2007); available at: www.via-nova- Kilcullen D.: Complex Irregular Warfare: The Face of architectura.org/files/TEAR2007/Schelp.pdf (accessed June Contemporary Conflict, in The Military Balance 2005-2006, 15, 2010). London: Institute for Strategic Studies (2005), pp.411-420. Smolander K., Rossi M., and Purao S.: Going Beyond the Kluge C., Dietzsch A., and Rosemann M.: How to Realize Blueprint: Unravelling the Complex Reality of Software Corporate Value from Enterprise Architecture, in Proceedings Architectures, European Conference on Information Systems, of the 14th European Conference on Information Systems, London, UK (2005). Ljungberg J. and Andersson M. (Eds.), CD Rom, IT University of Goteborg (2006), pp.1-12. Tang A., Han J., and Chen. P.: A Comparative Analysis of Architecture Frameworks, in 11th Asia-Pacific Software Lankhorst M.: A Language for Enterprise Modelling, in Engineering Conference (November 2004), pp.640-647. Enterprise Architecture at Work (2009), pp.85-119. The Technical Co-operation Program: Guide for Understanding Liimatainen K.: Evaluating Benefits of Government Enterprise and Implementing Defense Experimentation (GUIDEx), Architecture, in the 31st Information Systems Research Canadian Forces Experimentation Centre [online] (2006); Seminar in Scandinavia, Åre, Sweden (2008). available at: www.dtic.mil/ttcp/GUIDExBookFeb2006.pdf (accessed July 1, 2010). McGinnis L.F.: Enterprise Modeling and Enterprise Transformation, Information Knowledge Systems Management United Kingdom Ministry of Defence: The MoDAF Architecting (6:1/2), (2007), pp.123-143. Process, London, UK (2009).

Namkyu L., Tae-gong L., and Sang-gun P.: A Comparative United States Joint Forces Command: Multi-national Analysis of Enterprise Architecture Frameworks Based on EA Experiment 6 Fact Sheet [online] (2010); available at: Quality Attributes, 10th ACIS International Conference on http://mne.oslo.mil.no:8080/Multinatio/GeneralInf/MNE6USJFC Software Engineering, Artificial Intelligences, Networking, and O/file/MNE%206%20Rev%20--%20JCDE%20Spotlight%20-- Parallel/Distributed Computing, Daegu, South Korea (May %2019May091.pdf (accessed July 1, 2010). 2009), pp.283-288. United States Department of Defense: DoDAF V2.0, Volume 1: NATO C3 Board: Nato Architecture Framework Version 3, Introduction, Overview, and Concepts, Washington, DC, USA Brussels, Belgium (2007). (2009).

NATO Military Committee: MC Policy for Nato Concept United States Department of Defense Deputy Chief Information Development and Experimentation, Brussels, Belgium (2009). Officer: What is New in DoDAF V2.0, Washington DC, USA (2010). Niemi E. and Pekkola S.: Adapting the DeLone and McLean Model for the Enterprise Architecture Benefit Realization Urbaczewski L., and Mrdalj S.: A Comparison of Enterprise Process, 42nd Hawaii International Conference on System Architecture Frameworks, Issues in Information Systems (7:2), Sciences, Hawaii, USA (January 2009), pp.1-10. pp.18-23.

Noran O.: A Systematic Evaluation of the C4ISR AF Using Velitchkov I.: Enterprise Architecture Metrics in the Balanced ISO15704 Annex A (GERAM), Computers in Industry (56:5), Scorecard for IT (JOnline), in: JournalOnline Vol. 3 [online] pp.407-427. (2009); available at: www.isaca.org/Journal/Past- Issues/2009/Volume-3/Documents/jpdf0903-online- Reynolds K.P.: Building the Future Force: Challenges to enterprise.pdf (accessed July 2, 2010). Getting Military Transformation Right, Contemporary Security Policy (27:3), (2006), pp.435 - 471. Yu E., Strohmaier M., and Deng X.: Exploring Intentional Modeling and Analysis for Enterprise Architecture, in Ross J.W. and Weill P.: Understanding the Benefits of Proceedings of the 10th IEEE on International Enterprise Enterprise Architecture, Cambridge, USA: MIT Sloan School of Distributed Object Computing Conference Workshops, Hong Management, Contract No. 2B (2006). Kong, China (October 2006), p.32. Ross J.W., Weill P., and Robertson D.: Enterprise Architecture Yue Y. and Henshaw M.: A Holistic View of UK Military as Strategy: Creating a Foundation for Business Execution, Capability Development, Defense & Security Analysis (25:1), Boston, Mass: Harvard Business School Press (2006), (2009), pp.53-67. pp.xviii,234.

Book Review

Thinking in Systems: A Primer Donella H. Meadows (Ed. Diana Wright), Chelsea Green Publishing (2008), ISBN 978-1-60358-055-7, xiii + 218 pps.

Review by Leonard Fehskens

It’s almost a cliché nowadays that an enterprise is a perspective, to system modeling, to believing that the system, and as such it’s worth noting that it is often the model, rather than the thing being modeled, is reality. stuff that we take for granted that is most worth There is, ironically, a perfect if unintended example of reconsidering. This book is an enjoyable way for this in Chapter 2: A Brief Visit to the Systems Zoo. The Enterprise Architects to revisit the systems perspective. example is “the thermostat mechanism that regulates the It was begun in 1993, but due to the author’s untimely heating of your room”. I looked at the graph of the death in 2001, it was never formally published until behavior of this system over time and said to myself: recently. Donella Meadows was the lead author of The “No, that’s not how it works in my house.”. In the Limits to Growth, an influential book from 1972 on the appendix is a listing of the pseudocode that implements subject of sustainability, and this book bears the mark of the model, and it was immediately apparent where the that concern, but without a political or polemical slant. discrepancy came from. The model assumes that the The book is less about what systems are than it is an furnace’s heat output is proportional to the difference informal survey of how they behave and why. It is full of between the actual temperature and the desired easily understood examples, and is written in an temperature (i.e., the temperature set on the engaging and highly readable style. thermostat). My thermostat, and I believe almost all home thermostats, sends a simple on/off signal to the The book comprises an introduction, three parts of two, furnace, and when the furnace is on, its heat output is three, and two chapters respectively, an appendix, relatively constant (it is certainly not continuously notes, and a bibliography. variable). Furthermore, the thermostat requires that the The language used to describe systems models may be room temperature be below the set temperature for at a bit unusual for Enterprise Architects; the author least some minimum time period before it will turn the describes systems in terms of stocks and flows, but this furnace on, to minimize rapid cycling. So the model is may also be a useful reminder to Enterprise Architects both too complicated in one respect, and too simple in that a lot of the stuff that flows through an enterprise is another respect, and the result is that the model material, not information. behaves somewhat differently from the real system. The Perhaps the most important lesson of this book was more complex a system, the more likely a model of it will summed up for me by the opening paragraph of Chapter suffer from such discrepancies, and contemporary 7: Living in a World of Systems: enterprises are probably the most complex systems we have ever assembled. “People who are raised in the industrial world and who get enthused about systems thinking are likely to make a terrible Maybe the author’s thermostat/furnace system actually mistake. They are likely to assume that here, in systems behaves the way it is modeled; it doesn’t really matter, analysis, in interconnection and complication, in the power of as this detracts little from the value of the book. the computer, here at last is the key to prediction and control. This mistake is likely because the mindset of the industrial I did have a few other minor quibbles. The author writes world assumes that there is a key to prediction and control.” that “a stock can be increased by decreasing its outflow rate as well as increasing its inflow rate”. This is, of This is an especially important admonition because the course, only true if the inflow rate remains greater than examples provided throughout the book are all the decreased outflow rate, which in turn requires that sufficiently simple that they are amenable to predictive the inflow rate be non-zero, a constraint the author fails computer models. I have argued elsewhere that there is to note. Another is that the author writes in one place, a far too easily overlooked danger to labeling something “system structure is the source of system behavior” but a system – the “slippery slope” from adopting a system elsewhere observes “a feedback loop is a chain of (i.e., integrative and holistic, as opposed to reductionist) causal connections from a stock, through a set of

decisions or rules or physical laws or actions that are dependent on the level of the stock, and back again through a flow to change the stock.”. I have always had a hard time thinking of “a set of decisions or rules or physical laws or actions” as being structural, but it seems that many other people are comfortable with such an inclusive notion of structure. This review glosses over most of what is most valuable in this book – the material in Chapters 4 though 7. I’m not going to try to summarize that material, because you really need to read it and think about it, and as I have noted in some of my past book reviews, especially think about its relevance to Enterprise Architecture. Whether you think you understand systems thinking or not, I think you owe it to yourself to read this book.

Len Fehskens is the Vice President, Skills and Capabilities for The Open Group. He is responsible for The Open Group's activities relating to the professionalization of the discipline of Enterprise Architecture.