IS for njosh

THIRD EDITION An Introduction to Enterprise Architecture Scott A. Bernard EA 3Cube Framework ™ Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Networks & Infrastructure Systems & Applications Data & Information Products & Services Network Infrastructure Network Infrastructure Goals & Initiatives Lines of Business C O M P O N E N T S Security / Standards / Skills Technology – Business – Strategy AuthorHouse™ 1663 Liberty Drive Bloomington, IN 47403 www.authorhouse.com Phone: 1-800-839-8640 © 2012 by Scott A. Bernard. All rights reserved.

No part of this book may be reproduced, stored in a retrieval system, or transmitted by any means without the written permission of the author.

INTERNATIONAL EDITION Copyright © 2012.

Exclusive rights by Scott A. Bernard for translation, manufacture, and export.

Published by AuthorHouse 08/07/2012 ISBN: 978-1-4772-5800-2 (sc) ISBN: 978-1-4772-5801-9 (e) Library of Congress Control Number: 2012914406 Any people depicted in stock imagery provided by Thinkstock are models, and such images are being used for illustrative purposes only.

Certain stock imagery © Thinkstock.

First published by AuthorHouse 08/25/04 (First Edition) 08/25/05 (Second Edition) This book is printed on acid-free paper.

Because of the dynamic nature of the Internet, any web addresses or links contained in this book may have changed since publication and may no longer be valid. The views expressed in this work are solely those of the author and do not necessarily reflect the views of the publisher, and the publisher hereby disclaims any responsibility for them. Table of Contents Foreword 7 Preface 11 Section I. The Concept of Enterprise Architecture 21 Case Study: Danforth Manufacturing Corporation 23 Introduction: Will this be an Architected Enterprise? 29 1An Overview of Enterprise Architecture 31 2 The Structure and Culture of Enterprises 51 3The Value and Risk of Creating an Enterprise Architecture 67 Section II. Developing an Enterprise Architecture 81 4 Implementation Methodology 89 5Documentation Framework 103 6 Architecture Components and Artifacts 117 7 Developing Current Architecture Views 141 8 Developing Future Architecture Views 165 9 Developing an Enterprise Architecture Management Plan 181 Section III. Using an Enterprise Architecture 199 10The Role of Investment Planning and Project Management 205 11 The Role of Security and Privacy 221 12 The Enterprise Architecture Repository and Support Tools 233 Section IV. Future Trends in Enterprise Architecture 251 13Future Trends in Enterprise Architecture 253 Concluding Thoughts 265 Appendices ABusiness Case for an Enterprise Architecture Component 267 BExample Approach to Architecture: Federal Government 271 CExample Approach to Architecture: State Government 277 DExample Approach to Architecture: Defense Department 279 EExample Approach to Architecture: The Open Group 281 FExamples of Enterprise Architecture Artifacts 283 Glossary of Terms 331 Subject Index 335 An Introduction to Enterprise Architecture – 3 rdEdition 7 Foreword By John A. Zachman I am delighted that Scott Bernard has written this book, “An Introduction to Enterprise Architecture.” We need as much focus on this critical issue as possible, especially in the academic environment and especially as we continue the transition into the Information Age. It is my opinion that this issue of Enterprise Architecture is not well understood in the ranks of General Management who see Enterprise Architecture as just an I/S or IT issue, nor in the ranks of I/S management who see it as taking too long and costing too much, nor in the ranks of academia who tend to focus on what they perceive constitutes current market demand, typically a promising technology. My opinion is, Enterprise Architecture may well be the “Issue of the Century.” In fact, I felt strongly enough about this issue that I published an article by that title in the year 2000, the turn of the Century.

Exacerbating the problem, we seem to have raised a generation of people, the “web generation,” who are facile with the technology, but as a result seem to think that the solution to all problems lies in technology. They are tempted to see strategy and architecture, engineering and design, modeling and methodologies as prehistoric, the preoccupation of cave men. Now, real men do Java … or whatever constitutes the current “silver bullet,” technological panacea.

I have a wise and profoundly insightful friend, Roger Greer, who was the Dean of the School of Library and Information Management at the University of Southern California. I sat on his advisory council for many years and he observed that a few decades ago, the library community became enamored with the technologies of the library and lost sight of their reason for being, which he argued was to identify problems of the community and to assemble the required knowledge to bring to bear and participate in solving the problems. Now it appears that many universities are de-committing the Library Schools because they are simply technical, storing and retrieving books. There is no conceptual substance requiring research or advanced degrees. You can learn how to store books and find them again in secondary schools. In fact, USC discontinued Roger’s School because of the persistence of the technical perceptions on the part of the Administration. In fact, I was having lunch with the Dean of the Library School at the University of California, Berkley the day they de-committed that school on the same basis. An Introduction to Enterprise Architecture – 3 rdEdition 8 In “The Next Information Revolution” article published in Forbes ASAP August 24 th, 1998, Peter Drucker observes that the present information revolution is actually the fourth information revolution. “The printing revolution (the third information revolution) immediately created a new and unprecedented class of information technologists … who became great stars … great gentlemen … revered all over Europe … courted by kings, princes, the Pope … showered with money and honors. … The printers, with their focus on technology (later) became ordinary craftsmen … definitely not of the upper class. … Their place was soon taken by what we now call publishers … whose focus was no longer on the ‘T’ in IT but on the ‘I.’… Is there a lesson in this for today’s information technologists, the CIOs in organizations, the software designers and developers, the devotees of Moore’s law?” (said Peter Drucker).

Several months ago, I saw an old friend, Gordon Everest, the originator of the “crow’s feet” in logical data models. Gordon is retiring this summer because the Information Systems Department of the Business School at the University of Minnesota is being de-committed. In fact, I am afraid that the same thing may have happened at the Business School, Information Systems Department at UCLA as I have not seen any of my academic friends from UCLA for several years.

I know I have a rather radical view of this, but my observation would be the whole reason you want people with technical skills in your Enterprise is not for building and running systems. Anybody can build and run systems, the employment of the technology. The reason you want these kinds of people in your Enterprise is because they have the capability of engineering and manufacturing your Enterprise for you. That’s the reason for their being, NOT simply for building and running systems.

I have some strong convictions that the raw material for engineering and manufacturing Enterprises are primitive models, not composite models. Composite models are for implementations, the embodiment of the technologies. Primitive models are for architecture, ENTERPRISE Architecture. I don’t think it is possible to engineer and manufacture enterprises without building and managing primitive models. It is similar to elements and compounds. Before Mendeleyev defined the periodic table of elements, chemistry was not a science. It was alchemy, working with compounds, trial and error, unpredictable. In like fashion, I believe that until Enterprise Architects understand and manage the primitive (elementary) constructs, Enterprise Architecture is dealing with composites (compounds), technical implementations. It is not a science and is not predictable and it is not engineering and manufacturing Enterprises. An Introduction to Enterprise Architecture – 3 rdEdition 9 Although, Scott does not necessarily share my rather strong and radical convictions, he graciously makes reference to them several times in the body of his work, which I greatly appreciate.

In any case, I feel strongly, we must infuse these critical Enterprise Architecture ideas into the next generation, through the academic environment. We sorely need a generation of people who understand and are committed to these complex issues that will persevere and see Enterprise Architecture become a reality. If we fail to bring these longer term issues into focus and continue only to focus on technology, on implementations, short term propositions, we will not only sacrifice our legitimacy as a discipline, but from an Enterprise standpoint, may even forfeit the Enterprise’s continued viability.

I was visiting a major telecommunications service provider recently in which some of the management folks got into a rather heated discussion about what was more important, to serve the customer … or to increase the stock price. I would not argue that it is unimportant to increase the stock price, but I would suggest that this is a very short term perspective. If somebody doesn’t pay attention to the customer in this very competitive industry, you may find yourself out of the game in the longer term and your stock price might not even appear anymore in the newspaper. It is not EITHER the short term OR the long term. It is the short term AND the long term.

I am not arguing that technical implementations, composites, building and running systems in the short term are unimportant, but I am arguing that if we don’t pay attention to our reason for being, to engineering and manufacturing Enterprises, to primitive models, ENTERPRISE ARCHITECTURE in the longer term, we may well forfeit either our relevance as a discipline … or sacrifice the continuing viability of the Enterprise in the process. Engineering and manufacturing Enterprises is the context within which building and running systems becomes relevant. By the way, this has profound conceptual implications for research and advanced degrees in academia.

Scott Bernard has taken a major step in intensifying the focus on these critical issues and I am particularly pleased that he has produced this work as a textbook for the academic environment. “Introduction to ENTERPRISE ARCHITECTURE”! Our hope lies in the new generation’s capacity to grasp its significance and persist in its realization.

Thank you, Scott Bernard!

John A. Zachman Glendale, CA 2004 An Introduction to Enterprise Architecture – 3 rdEdition 11 Preface Intended Audience An Introduction to Enterprise Architectureis intended for executives, managers, practitioners, students, and others interested in finding out what Enterprise Architecture (EA) is all about. EA is as much about the purpose, structure, and functioning of enterprises as it is about the systems and technologies that support them. The concepts presented in this book are applicable to enterprises in the public, private and non-profit sectors.

Hopefully the book will promote the discipline and support the development of new courses on EA, as well as enhance and update existing courses on business strategy and planning, information systems analysis and design, operations research, government planning, change management, knowledge management, and project management.

Typically these courses are offered in graduate programs or the later part of undergraduate programs. Though it is not a prerequisite, students using this book may benefit from having prior business management and/or information technology knowledge.

Why I Wrote This Book An Introduction to Enterprise Architectureis the culmination of several decades of experience that I have gained through work initially as an information technology manager and then as a consultant to executives in the public and private sectors. I wrote this book and produced two updated editions for three major reasons: (1) to help move business and technology planning from a systems and process-level view to a more strategy-driven enterprise-level view, (2) to promote and explain the emerging profession of EA, and (3) to provide the first textbook on the subject of EA, which is suitable for graduate and undergraduate levels of study. To date, other books on EA have been practitioner books not specifically oriented toward a student who may be learning the subject with little to no previous exposure. Therefore, this book contains references to related academic research and industry best practices, as well as my own observations about potential future practices and the direction of the profession. The response to the first and second editions of this book from teachers and practitioners was overwhelmingly positive, which I am most grateful for. The changes presented in the third edition include a discussion of EA An Introduction to Enterprise Architecture – 3 rdEdition 12 as a meta-discipline; the identification of six basic elements that an EA program must have; updates to the security and privacy chapter; a discussion of the use of EA in mergers and acquisitions; and updates that have occurred with other approaches to EA. Relationship to Systems Analysis and Design This book is a suitable companion to the numerous Systems Analysis and Design (SA&D) textbooks that are in use, as it can provide an overarching context and unifying framework for the system development approaches and documentation techniques described therein.An Introduction to Enterprise Architecture helps to set the context for SA&D courses and related professional activities. Without the context of EA, systems development efforts throughout an organization run the risk of being disjointed and duplicative…. a phenomenon that has occurred during the past several decades. This book provides a more detailed explanation of the EA concepts that are often only summarized in SA&D textbooks, in a way that compliments, extends, and refers to foundational SA&D concepts.

It should be noted that this book identifies EA documentation techniques at each level of a generalized framework and documentation methodology, called the EA 3 “Cube” Framework. These documentation techniques originate from existing methods in strategic planning, business administration, and technology development. While this book identifies and briefly describes these elements, it does not go into detail or attempt to build proficiency in a particular technique…. that is left to the many other books on strategy, business, and technology. Relationship to Strategy and Business Planning An Introduction to Enterprise Architectureprovides a clear explanation of the relationship between strategic planning, business planning, and information technology planning. While IT resources are increasingly becoming a commodity, the importance of IT services as a business enabler continues to grow in many public and private sector organizations.

In recognition of this, EA’s identification of integrated IT solutions to organization-wide (crosscutting) and mission-specific (vertical) requirements is one of the focal points of this book. Strategic goals and business requirements should drive IT solutions, and EA’s contribution to this alignment is another focal point of the book. Finally, this book An Introduction to Enterprise Architecture – 3 rdEdition 13 provides specific EA documentation techniques that create strategy and business-driven views of the enterprise, which in turn can help to identify gaps in performance that IT solutions can help to close.

Relationship to Component-Based and Service-Oriented Architectures An Introduction to Enterprise Architecturepresents EA as a holistic management, planning, and documentation activity and introduces the EA 3 Cube Framework and implementation methodology. This approach to EA identifies distinct lines of business which encompass five sub-architecture levels and three common thread areas. The five sub-architectures address strategic initiatives; business services; information flows; systems and applications; and technology infrastructure. The three threads are security, standards, and workforce. The EA 3Cube Framework is component-based in that the “building blocks” of each of the sub-architectures are ‘plug-and- play’ components. These components vary widely in their purpose and nature, but are increasingly interoperable and integrated due to the standards thread that promotes non-proprietary solutions. For this reason, architecture documentation approaches (such as the Model-Driven Architecture, or IT Infrastructure Library) can be used to populate one or more of the sub-architectures in the EA 3 Cube Framework.

The EA 3 Cube Framework not only recognizes and preserves the role of early architecture approaches that addressed data, applications, and networks, but also recognizes newer approaches that promote strategic scenario planning, the value of business supply chains, and web-based services. In particular, the ‘Business Services’ sub-architecture within the EA 3 Cube Framework (the second level) exemplifies how EA can link strategy, business, and technology components across the enterprise within a “Service Bus” that encompasses platform-independent horizontal and vertical EA components. Services extend throughout the framework, but in my opinion have their origination of purpose at level two of the EA 3 Cube… being driven by strategic goals and initiatives (the framework level above the “Business Services’ level), and calling for supporting information flows, systems, applications, and network infrastructure components (the framework levels below). Basic to the concept of EA components presented in this book is the idea that the “Standards” thread that enables interoperability within the Service Bus by promoting the use of EA components that are based on open-standards/protocols and non- proprietary solutions. An Introduction to Enterprise Architecture – 3 rdEdition 14 Organization of This Book An Introduction to Enterprise Architectureis organized into four sections of material, a case study, and several appendices of amplifying or reference material. The case study is presented at the beginning of each section and before selected chapters to reinforce the application of the concepts in a variety of settings. The four sections are intended to sequentially develop the student’s understanding of the concepts of EA, as well as methods for implementing these concepts. Section I provides an overview and context for the book, identifies the value and risk of doing an EA, discusses the structure and changing nature of enterprises, and shows how EA helps to link strategic, business, and technology planning. Section II defines and describes what an EA framework is, presents a step-by-step methodology to implement an EA through the documentation of current and future views of resources, and describes how to communicate changes in the EA through an EA Management Plan that also can serve as a “blueprint” for modernization. Section III discusses how to use and maintain EA information in an on-line repository within the enterprise, and how governance processes can be integrated (e.g., investment planning, project management, and security).

Section IV provides the author’s thoughts on EA as a profession and opinions on future trends. The Appendices amplify or extend the material presented in all Sections and are intended to be primarily for student reference. A glossary of key terms is provided along with examples of the EA documentation described in various chapters. An Introduction to Enterprise Architectureis structured such that each section and chapter builds on the material previously presented. The sections and chapters are organized to promote understanding and a consistent, cogent flow of material by using the following design:

Sections:

¾Overview . Describes the general purpose of the Section and the contribution of each Chapter.

¾Case Study . An ongoing case study from the private sector that provides scenes which make the concepts of the Section and Chapters more tangible and relevant. Chapters:

¾Overview . Describes the purpose and key concepts of the Chapter. An Introduction to Enterprise Architecture – 3 rdEdition 15 ¾Learning Objectives . Lists the learning objectives for the student in that Chapter.

¾Introduction . Provides context and introductory commentary to build student interest in the main body of material.

¾Discussion . Provides the Chapter’s concepts through descriptions, graphics, and footnoted references.

¾Analogy Boxes . The analogy of the architecture of a house is used throughout the book to assist readers in understanding and relating the various concepts of Enterprise Architecture in a context that is common to most students. 1 ¾Key Term Definition Boxes . Definitions of key terms are provided when they are first used to promote student understanding at the time that associated concepts are being presented.

¾Summary of Concepts . Provides a recap of the purpose of the Chapter and its key concepts, and introduces the following Section/Chapter.

¾Review Questions and Exercises . Provides questions that address key concepts and exercises that allow students to further explore key concepts of the Chapter and tie-in concepts from other Chapters. General Comments The EA 3Cube Framework,EA 3, and Living Enterpriseare registered Trademarks. All rights are reserved. Concepts for the EA 3 Cube Framework,EA 3,Living Enterprise, and the Organizational Network Modelwere generally influenced by the works of John Zachman, Steven Spewak, Talcott Parsons, and James Thompson, as is acknowledged throughout the book. The specific concepts for the EA 3Cube Framework, EA 3,Living Enterprise, and the Organizational Network Modelwere not developed as a result of, or influenced by, any other public or private sector enterprise architecture approach or graphic. Any similarity to other EA approaches or graphics is coincidental. Of specific note; a cubic shape is generic and may be in use with other systems development, architecture, and/or business planning approaches. The uniqueness of the EA 3“Cube” is the singular combination of all of its dimensions, functions, levels, components, and other attributes. The concepts and graphics in this book were originally presented in lectures given by Dr. Bernard at various 1Spewak, Steven. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology . New York: John Wiley & Sons Publishers. 1992. Dr. Spewak equated the disjointedness of IT planning without enterprise architecture to the haphazard construction of the 160- room Winchester House in California over a period of 38 years without a master building plan. An Introduction to Enterprise Architecture – 3 rdEdition 16 academic and professional conferences in 2002-2003 and are copyrighted by Dr. Bernard separate from this or any other publication. Permission for the use of the EA 3Cube Framework,EA 3 logo, Living Enterprise, and Organization Network Modelis given for use in this book. Acknowledgements I would like thank my colleagues and former students in the growing field of EA for their encouragement in writing An Introduction to Enterprise Architecture. John Zachman’s Foreword is a wonderful contribution to the book that in my opinion gives new students to the subject of EA the best possible beginning for their studies. In the view of many, John Zachman is the founder of Enterprise Architecture as it has come to be known, and I sincerely thank him for writing the Foreword. John got it right when he introduced the Information Systems Architecture in 1987, 2and he has continued to provide on-target architecture consulting, training, and mentoring on a global basis ever since.. remaining an active teacher, lecturer, and practitioner in 2012 as this edition is published. I believe that John’s emphasis on the basics, on using “primitive” EA artifacts that focus on discrete aspects of an architecture, is not in conflict with the EA 3 Cube framework or documentation methodology. My work is intended, in part, to extend that focus and to discuss the utilization of what John refers to as “composite” EA artifacts which combine several types of primitives to form specialized views of an enterprise…. views that are often helpful to managers and executives. My bottom line position is that without solid EA primitives, the composite artifacts are not possible to develop.

I would also like to thank and remember Dr. Steven Spewak who helped start the profession of EA. Steve was an inspirational mentor to me during my initial years as an architect. He passed away in March 2004 a few months before the first edition of this book was published…. he is sorely missed by many in our profession. It is both exciting and challenging to be part of a still young profession, and I salute those who endeavor to develop enterprise architectures for public and private sector organizations. To them I would say good luck, the work ahead of you will be frustrating at times, yet fulfilling as the contribution of EA to organizational success is fully realized. 2Zachman, J.A. A Framework for Information Systems Architecture . IBM Systems Journal: Volume 26, Number 3, Page 276. 1987. An Introduction to Enterprise Architecture – 3 rdEdition 17 One more thought. My father was a successful land developer and home builder who learned the essentials of traditional architecture on his own.

There are many parallels in our lives, and this is yet another. As the head of information technology enterprises and projects, I found that I needed some way to organize the perpetual chaos of systems development and upgrade projects, ongoing operations, and more than occasional surprises.

Because of this, I learned about EA, which helped to establish a reference framework for planning and decision-making…. the most valuable tool one can have in a dynamic field like IT management. Now, with greater appreciation, I enjoy being part of the growth of this field, which in many ways is like the one that my father came to know… a nice blessing in the journey of life. This book is dedicated with love to my wife Joyce and our children Bill, Kristin, and Katie An Introduction to Enterprise Architecture – 3 rdEdition 19 About the Author Scott Bernard has nearly thirty years of experience in information technology management, including work in the academic, federal government, military, and private sectors. Dr. Bernard has served as the United States Federal Chief Enterprise Architect with the Executive Office of the President’s Office of Management. He has also held positions as a Chief Information Officer (CIO), IT management consultant, line-of- business manager, network operations manager, telecommunications manager, and project manager for several major IT systems installations.

He has developed enterprise architectures for a number of public and private sector organizations, started an enterprise architecture practice for an IT management firm, developed his own consulting practice, and taught enterprise architecture at a number of universities, businesses, and government agencies. In 2002, Dr. Bernard created the EA 3 Cube TM framework and methodology that is featured in this book, as well as the design for an on-line EA repository that is called Living Enterprise. TM Dr. Bernard has served for over a decade on the faculty of the School of Information Studies at Syracuse University. He is also a Senior Lecturer in the Executive Program of the CIO Institute and the Institute for Software Research at Carnegie Mellon University’s School of Computer Science. Dr. Bernard was the founder of the Association of Enterprise Architects, and first editor of the Journal of Enterprise Architecture, which is still published to a world-wide readership.

Dr. Bernard earned his Ph.D. at Virginia Tech in Public Administration and Policy; a master’s degree in Business and Personnel Management from Central Michigan University, a master’s degree in Information Management from Syracuse University, and a bachelor’s degree in Psychology from the University of Southern California. He is a graduate of the Naval War College, and earned a CIO Certificate and an Advanced Management Program Certificate from the National Defense University. Dr. Bernard was designated a member of the Federal Government’s Senior Executive Service in 2011. He is also a former career naval aviator who served onboard aircraft carriers and with shore squadrons, led IT programs, and was the Director of Network Operations for the Joint Chiefs of Staff. An Introduction to Enterprise Architecture – 3 rdEdition 21 Section I The Concept of Enterprise Architecture Section I presents an introduction to the subject and concepts of Enterprise Architecture (EA), as well as an overview of the purpose and value of EA for business, government, and non-profit organizations. A case study based on a fictitious business is introduced that will help the student to understand and apply EA concepts. Section I is organized as follows: Case Study Scene 1: Possible Need for an EA Program IntroductionWill this be an Architected Enterprise?

Chapter 1 An Overview of Enterprise Architecture Chapter 2 The Structure and Nature of Enterprises Case Study Scene 2: Considering an EA Program Chapter 3 The Value and Risk of Creating an Enterprise Architecture Case Study (Scene 1) - Possible Need for an EA Program The Case Study introduces the Danforth Manufacturing Company 3 and several business and technology challenges that will cause the company to consider using EA to improve planning, decision-making, and solution implementation. Introduction – Will this be an Architected Organization?

Enterprise Architecture is becoming increasingly recognized as the only management and technology discipline that can produce holistic designs for organizations that are agile and all- encompassing. Whether an organization uses EA in this way becomes the question, and if not, what are the consequences.

Chapter 1 - An Overview of Enterprise Architecture Chapter 1 provides the student with an overview of the emerging profession and practice of EA. The chapter’s discussion introduces the concept that EA provides a holistic view of an enterprise. This differs 3The Danforth Manufacturing Company that is portrayed in this Case Study is a fictitious enterprise. Any resemblance to an actual business or similar business activities is coincidental. An Introduction to Enterprise Architecture – 3 rdEdition 22 from the more system-centric or process-centric views that previous analysis and planning approaches have emphasized. EA is both a management program and a documentation method, and comment is made on the similarities and differences of doing EA in private and public sector enterprises. Chapter 2 - The Structure and Culture of Enterprises Chapter 2 describes the structure of enterprises and why it is important to include culture in the EA documentation effort. The driving theme of this chapter is that an enterprise involves one or more social activities that involve the sharing of information. It also shows that the boundary between the structure of the enterprise and the culture is dynamic. The importance of stakeholder involvement and the management of expectations are also discussed. Case Study (Scene 2) - Considering an EA Program The Case Study continues with the Chief Information Officer of Danforth Manufacturing Company. The CIO makes a presentation regarding how an EA approach can help to evaluate several requests for IT systems, and coordinate their implementation. Chapter 3 - Value / Risk of Creating an Enterprise Architecture Chapter 3 discusses the value and risk of creating an enterprise-wide architecture. The main concepts of this chapter are (1) that EA represents a different way of looking at resources across the enterprise, and (2) that the significant cost of creating an EA must be justified by the value that it brings to the enterprise by linking strategy, business, and technology. Another key concept is (3) that an integrated set of planning, decision-making, and implementation processes can better identify and resolve performance gaps across the enterprise, and that EA promotes this type of integrated governance. The management of change is discussed in terms of why an EA may not be accepted or used if stakeholder buy-in and participation is not achieved. An Introduction to Enterprise Architecture – 3 rdEdition 23 Case Study: Danforth Manufacturing Company Scene 1: Possible Need for an EA Program The Danforth Manufacturing Company (DMC) develops, produces, and sells several lines of photovoltaic storage cells (solar-powered batteries) for use in various consumer, business, and aerospace products. Robert Danforth, the President and Chief Executive Officer (CEO) of DMC, has called a meeting of the Executive Committee to review several recent capital investment requests. The largest two of these was a request by Kate Jarvis, the Chief Operating Officer (COO), for a new sales and inventory tracking system and a request by Jim Gorman, the Chief Financial Officer (CFO) to invest in a new cost accounting system. Also invited to the meeting were Sam Young, the company’s first Chief Information Officer (CIO) who joined the company two weeks before, and Gerald Montes, the company’s Chief Counsel.

Robert Danforth was the last one to enter the executive boardroom. He smiled at his top management team and said, “Thank you all for coming by to talk a bit more about several investment requests that came out of our annual planning meeting last month. Sam, you hadn’t joined the company yet, so I’m particularly interested in your thoughts today. Mainly, I want to better understand from the group why our current capabilities are insufficient and how these new systems will help bottom-line performance. Kate, why don’t you go first and then we’ll hear from Jim.” Kate rose and walked to an easel that held several charts and diagrams. “Gentlemen, as mentioned at the planning meeting, my request for a new Sales and Inventory Tracking System (SITS) is based on an insufficient current ability to match inventory and production information with customer orders. We are also experiencing excessive turnaround time for orders in the industrial product lines, as compared to our competition. Our sales representatives in the field are beginning to lose orders. They can’t provide on-the-spot quotes based on real-time checks of available inventory and current pricing. The same goes for our representatives.

They are not able to see when the custom and small job production runs are being scheduled. This would help sales in this high-profit area which we will be expanding. Our major competitor fielded this information capability almost a year ago. While I was skeptical at the time about the An Introduction to Enterprise Architecture – 3 rdEdition 24 impact it would have on their sales, I now believe that it’s a successful model for them and therefore is going to make or break us in the industrial product line.” Robert leaned forward. “Kate, this sounds quite serious. Even so, from a cost perspective I am concerned about the return on investment (ROI) for SITS. Last month you stated that initial cost estimate for the development of SITS was over three million dollars. We have tight budgets for the next two years… have you looked at ROI?” “Yes,” responded Kate. “These charts show the level of investment and payback period for SITS, which I estimate to be two years, depending on how quickly and thoroughly the sales force adopts it. The lifecycle for SITS should be seven years, with positive ROI seen in years three through seven, and an average of about twelve percent per year.” Robert turned to Sam, “What do you think Sam? Isn’t part of the problem here that many of our information systems don’t talk to each other?” Sam grimaced slightly and said, “I think you’re right, from what I’ve seen in my initial survey of information technology (IT) capabilities, a lot of our systems were built as individual projects based on what then were unique requirements. We now have some duplication of functionality and evidence of inefficient support for evolving business processes.” Robert responded quickly, “Isn’t the SITS proposal just more of the same?” “Perhaps” said Sam, “I’m hearing that Kate wants to integrate information exchanges across the sales, inventory, and production lines of business.

This represents a somewhat higher-level approach to meeting several business requirements.” Robert turned to Jim, “What do you think about Kate’s problem? Jim answered with a pensive look, “Well, I agree that we need to address our competition’s capability. While our aerospace product line is the most profitable, the industrial product line brings in the most revenue, so there would be a significant impact on the entire company if we lose market share in the industrial product area.” Robert then turned to Gerald, “So what does the Chief Counsel think?” Gerald paused for a moment and then said, “I think that we must act decisively to protect market share in the industrial product line, but I’m not sure that SITS is the answer. You might be right Robert, the proposal that Kate is making might be more of the same type of technology solution that Sam says got us in this situation.” An Introduction to Enterprise Architecture – 3 rdEdition 25 Robert leaned back in his chair and said, “Before going further on this proposal, let’s talk about Jim’s investment request. I wonder if there are any parallels.” Jim activated the conference room’s projector and brought up a set of briefing slides. “My request is for a cost accounting system that would replace the current accounting system. As Robert mentioned, there are tight budgets the next two years, and having the ability to more readily see spending and profit generation within each line of business will help us to manage the budget more effectively. This system is one module of “WELLCO” a proven commercial enterprise resource planning (ERP) product. We can utilize this product by expanding it if other back office requirements emerge. The cost of the investment is just under $600,000.

According to the vendor, the historical payback period for this cost accounting module is eighteen months, with an average annual ROI of sixteen percent during the subsequent years.” “Jim, can this new accounting capability support what Kate is looking for?” said Gerald. Jim responded, “The WELLCO module can handle some of the things Kate is probably looking for, including price and volume information in sales, inventory, and production activities, but this module is not configured to specifically support all of the information I believe she will need.” “Can it be modified?” Interjected Robert. “Possibly so,” said Jim, “and if not, I would think that other modules of WELLCO could handle it. Sam, help me out with this one if you can.” Sam responded, “I know that WELLCO is one of the leading ERP products designed to support many front and back office functions. It might be possible to get enough functionality to support both Jim’s and Kate’s requirements. I am concerned that we are still looking at requirements from a program-level and systems-level viewpoint… essentially bottom-up planning. Wouldn’t the company benefit more from a more strategic approach that evaluates requirements and proposed solutions across the entire enterprise in the context of our strategic goals?” The group was silent for a moment, and then Gerald spoke. “Our annual planning retreat is where most of the company’s strategic planning happens. We look at our current strategic goals and initiatives. We look at what changes are needed to keep us competitive. As you saw from the meeting last month, new proposals are also surfaced during the retreat and then followed-up on. That is to say if they merit consideration for funding and implementation.” Sam asked, “Is there some model of the enterprise that is used to support these discussions?” “Well, if you mean our annual business plan, we have that” said Jim. “More than that” said Sam, “A model of strategy, business, and technology that enables you to see what An Introduction to Enterprise Architecture – 3 rdEdition 26 we have now and what is planned for the future. Something that gives us the ability to play with the model to see what other future investment and operating scenarios would look like.” “We don’t have anything as fancy as that” said Kate, “Though a model like that would have helped me analyze what we could do to help the field.” Robert stood up and walked to the window. “Sam, you are new to the team, but sometimes a fresh look at a situation can provide valuable insights. What I believe you are telling us is that we lack a true top-down, strategy-driven capability to surface requirements and solutions… is that right?” “Yes” responded Sam. “DMC is not alone. Many companies have the same problem because they still support program-level decision- making. We tend to let it occur in a relative vacuum with few overarching goals and standards to guide analysis, planning, documentation, and decision-making. I am going to propose that both Kate’s and Jim’s proposals be reviewed through a different lens, that of an enterprise-wide architecture. If we had this type of model, we could see current capabilities, future requirements, and gaps in our ability to meet those requirements. We could also see duplicative current capabilities and future solutions. From what I have heard at this meeting we may have some overlapping requirements which probably should not be met with separate solutions if we are to optimize our financial and technology resources.” “Interesting” said Robert. “Sounds like a silver bullet, and I am wary of those” said Gerald. Robert spoke again, “Sam, would an enterprise-wide architecture really help us? If it is doable, that’s great, but why haven’t we heard about it before? I know there are no free lunches and where is the ROI in such an architecture?” Kate added “While I appreciate the idea, I don’t have time to wait for the entire company to be modeled, I need a new capability now.” “Well,” said Sam. “You are right, establishing an enterprise architecture will not be free and it will take time. Fortunately there are approaches being used by the public and private sector that support the modeling of requirements and solutions in a standardized way between multiple lines of business, which are referred to as architecture segments. So, as each segment is completed it adds to the architecture as a whole. By treating Jim’s area as the company’s financial segment, and Kate’s area as the production segment, we can just address these areas first, thereby reducing the time for completion of the architecture part of the larger project that may implement a combined solution. We can do this by modeling only those strategic drivers, business services, and technology solutions that An Introduction to Enterprise Architecture – 3 rdEdition 27 apply to those two segments. Eventually though, for the architecture to be the most valuable to DMC, the entire company should be modeled in its current state, and several possible future states.” “As far as ROI,” continued Sam, “that is more difficult to pinpoint since the cost of doing the analysis and modeling depends on the amount of existing information and the degree of cooperation that is achieved with stakeholders. By the way, these stakeholders include our executives, managers, and support staff. But let’s say that a top-down architectural analysis reveals that there are common requirements between Kate and Jim, and we can meet those requirements either through adding functionality to SITS or by buying several more modules of the commercial WELLCO product, and doing some customization. We potentially could save several hundred thousand dollars, or perhaps millions of dollars compared to doing SITS and WELLCO separately… all of which become ROI from the architecture effort. You probably haven’t heard about enterprise architecture because when a company is doing it well, it can become a strategic asset that makes the company more efficient and agile. That type of capability is normally not broadcasted.” “So what’s the downside?” asked Gerald. “Enterprise architecture tends to be viewed as a hostile takeover by program managers and executives who have previously had a lot of independence in developing solutions for their own requirements” said Sam. “Also, architecture brings a new language and planning processes, which like any type of change can be seen as threatening to those involved and therefore may be resisted. Strong executive sponsorship and stakeholder involvement can overcome much of this.” “Sam, the architecture approach seems to make sense, but I am not completely sold yet” said Richard. “Let’s do a pilot project. I want you to work with Kate and Jim and bring me a plan and business case within two weeks to develop the part of an architecture for DMC that addresses their current capabilities and stated future requirements. We’ll use this as the test for whether we want to go forward with an enterprise-wide architecture. Thank you all for your time today, see you in two weeks.” An Introduction to Enterprise Architecture – 3 rdEdition 29 Introduction Will this be an Architected Enterprise?

Basically, I am asking whether an enterprise (often an organization or part of an organization) is going to be structured based on an over-arching agile design and set of standards for how work is done and technology employed - or is the enterprise going to consist of a collection of un-coordinated processes, programs, and systems? If the organization decides to develop and maintain an authoritative enterprise-wide architecture to serve as a primary reference for planning and decision-making, then leadership and management must embrace and implement this decision by properly resourcing the EA function and seeing that it is incorporated into all aspects of how the organization is run… called “baking it in.” A similar question is faced when an enterprise considers making a major, holistic commitment to a quality assurance (QA) approach that will be consistently applied throughout all lines of business. To date, many enterprises have decided to do this only to find that their effort fails when leadership does not continually back it, especially if that enterprise is not used to standard processes and metrics. We saw how beginning in the 1980’s QA made a tremendous difference in the competitiveness of major automotive industry players – with Japanese manufacturers being the first to take the QA plunge. Now, QA is baked into the culture of auto manufacturers around the world – and the products of the surviving companies are much better as a result. Some companies could not adapt to higher quality standards, and are no longer in business or lost major market shares. It should therefore be no surprise that many of these surviving companies began embracing EA during the past decade along the same path that their QA initiatives were implemented. Other industry sectors are doing this too – insurance, retail, and aerospace to name a few. For some governments, including the U.S. Federal Government, it is a legal mandate that agencies develop and maintain a holistic EA.

The existence of an organization chart, documentation on processes and resources, or employees who hold architect titles do not necessarily mean that the enterprise is “architected.” The litmus test for this is similar to the key question for QA adoption – does the enterprise consider the architecture to be an authoritative reference and are the associated methods baked into how things are done every day… in other words, is EA part of the culture? If not, then there is a paper architecture that may provide one- An Introduction to Enterprise Architecture – 3 rdEdition 30 time or occasional value – but not a living architecture culture that contributes to high levels of agility and performance on an ongoing basis across all lines of business, business units, and program offices.

Let’s say that an enterprise decides to not have an EA, for whatever reason. The main problems that I see are that leadership will not have the ability to generate clear, consistent views of the overall enterprise on an ongoing basis, they won’t be able to effectively compare business units, and the locus of power for planning and decision-making will be at the line-of-business, program, and/or system owner levels – with significant differences in how things are done and high potential for overlapping or duplicative functions and resources… waste and duplication.

Now let’s say that an enterprise decides to have an EA, and is prepared to maintain leadership backing and put resources behind it. This would allow the enterprise to avoid the problems just described and create a culture of ongoing controlled adaptation and optimization in response to changes in external and internal drivers. This sounds to me like a more of a recipe for success, especially in highly dynamic operating environments – but to take the test for your own enterprise – go ahead and ask “what would happen if we did not become an architected organization” and play out the costs and benefits, then ask “what if we do go with EA” and try to identify the cost, benefits, risks, and mitigation strategies. On significant benefit for large private sector companies that decide to be an architected enterprise is that EA can play a key role in evaluating merger and acquisition (M&A) opportunities, whether that company is acquiring or being acquired. In that EA helps to rationalize and align strategic, business, and technology plans – and associated processes and resources – the architecture can clarify the capabilities, assets, and value of that company – potentially adding tens or hundreds of millions of dollars to the valuation and reducing risk in the post- merger/acquisition period as the resulting company makes dozens or hundreds of decisions about what business capabilities, systems, and groups should go forward, and which should be eliminated. A historical stumbling block to M&A efforts is a lack of understanding of the culture and capabilities of the companies being brought together – and EA can help with this throughout the M&A lifecycle – from initial due diligence research, to valuation negotiations, to post merger/acquisition streamlining and new product/service rollouts. This book is for enterprises that decide to take the plunge and embrace EA - I think they will find that it is a source of competitive advantage. An Introduction to Enterprise Architecture – 3 rdEdition 31 Chapter 1 An Overview of Enterprise Architecture Chapter Overview Chapter 1 provides an overview of the discipline of Enterprise Architecture(EA). The main concept of this chapter is that EA is a strategy and business-driven activity that supports management planning and decision-making by providing coordinated views of an entire enterprise. These views encompass strategy, business, and technology, which is different from technology-driven, systems-level, or process- centric approaches. Implementing an EA involves core elements, a management program, and a framework-based documentation method.

Learning Objectives ¾Understand the purpose of EA.

¾Understand the elements of an EA management program.

¾Understand the elements of an EA documentation method.

¾Understand differences to other analysis / planning approaches. Introduction Enterprise Architecture is a management and technology practice that is devoted to improving the performance of enterprises by enabling them to see themselves in terms of a holistic and integrated view of their strategic direction, business practices, information flows, and technology resources. Key Term: Enterprise An organization or sub-activity whose boundary is defined by commonly- held goals, processes, and resources. This includes whole organizations in the public, private, or non-profit sectors, part(s) of an organization such as business units, programs, and systems, or part(s) of multiple organizations such as consortia and supply chains.

Key Term: Enterprise Architecture The analysis and documentation of an enterprise in its current and future states from an integrated strategy, business, and technology perspective. An Introduction to Enterprise Architecture – 3 rdEdition 32 By developing current and future versions of this integrated view, an enterprise can manage the transition from current to future operating states. The strategic use of resources is increasingly important to the success of public, private, and non-profit sector enterprises, including extended enterprises involving multiple internal and external participants (i.e., supply chains). How to get the most from business, technology, and human resources requires an enterprise to think in terms of enterprise-wide solutions, rather than individual systems and programs (Figure 1-1).

Doing this requires a new approach to planning and systems development, an approach that has come to be known as Enterprise Architecture. The word ‘enterprise’ implies a high-level, strategic view of the entire entity, while the word ‘architecture’ implies a structured framework for the analysis, planning, and development of all resources in that entity. 4 Figure 1-1: The Organizing Influence of Enterprise Architecture 4The term “enterprise architecture” most likely came from Steven Spewak, Ph.D. in his book Enterprise Architecture Planning . John Wiley & Sons, 1992. Video Network Strategy Business Information Systems Business & Technology Alignment IT Systems Web Services Process 1 Process 2 Data Network Applications Voice Network Systems Web Services Process 1Process 2 Data Network Applications Voice Network Video Network Process 3 Strategic Initiative 2 Strategic Initiative 1 Strategic Initiative 1 Strategic Initiative 2 Data Dictionary Object Reuse Data Flows Object Reuse Data Dictionary Data Flows Video Network Strategy Business Information Systems Networks Business & Technology Alignment IT Systems Web Services Process 1 Process 2 Data Network Applications Voice Network Systems Web Services Process 1Process 2 Data Network Applications Voice Network Video Network Process 3 Strategic Initiative 2 Strategic Initiative 1 Strategic Initiative 1 Strategic Initiative 2 Data Dictionary Object Reuse Data Flows Object Reuse Data Dictionary Data Flows EA = S+B+T NetworkVideo Network Strategy Business Information Systems Business & Technology Alignment IT Systems Web Services Process 1 Process 2 Data Network Applications Voice Network Systems Web Services Process 1Process 2 Data Network Applications Voice Network Video Network Process 3 Strategic Initiative 2 Strategic Initiative 1 Strategic Initiative 1 Strategic Initiative 2 Data Dictionary Object Reuse Data Flows Object Reuse Data Dictionary Data Flows Video Network Strategy Business Information Systems Networks Business & Technology Alignment IT Systems Web Services Process 1 Process 2 Data Network Applications Voice Network Systems Web Services Process 1Process 2 Data Network Applications Voice Network Video Network Process 3 Strategic Initiative 2 Strategic Initiative 1 Strategic Initiative 1 Strategic Initiative 2 Data Dictionary Object Reuse Data Flows Object Reuse Data Dictionary Data Flows EA = S+B+T Home Architecture Analogy: Building a house one room at a time without the blueprints for the whole house can lead to a poor result. It is analogous to developing organizations, business units, programs, and systems without an enterprise-wide architecture for reference, as duplication and inefficiency in resources, and a lack of overall agility can result. An Introduction to Enterprise Architecture – 3 rdEdition 33 With regard to resources, one of the greatest challenges that many enterprises continue to face is how to identify the business and technology components of strategic initiatives. A big part of this challenge is that technology, information technology (IT) in particular, has historically not been viewed as a strategic asset. As such, planning activities often have focused on the development of individual technology solutions to meet particular organizational requirements. What is Enterprise Architecture?

The following equation is the ‘sound bite’ version of what EA is all about, and is intended to help readers remember the distinct difference between EA and other types of IT planning… that EA is driven by strategic goals and business requirements. E E A A = = S S + + B B + + T T Enterprise Architecture = Strategy + Business + Technology This is a straight-forward, simple representation of the unique holistic value of EA, as is the geometry of the “cube” framework that it derives from. I am a believer in the principle captured by Occam’s Razor, which in the philosopher Occam’s original 14 thCentury form states that “entities should not be multiplied unnecessarily”. It is my hope that the equation EA = S + B + T and the EA 3Cube Framework are easy to understand and highly useful in many contexts because they adhere to this principle and capture the essential elements that characterize human organizations. EA is primarily about designing virtual things - organizations and their capabilities, whereas traditional architecture is primarily about designing physical things. There are many parallels in these two disciplines and there are a number of intersecting areas such as creating work environments that promote productivity and support agility. EA is both a noun and a verb. The architecture of an enterprise is a thing – a collection of models and information. Creating an enterprise-wide architecture is accomplished through a standardized process that is sustained through an ongoing management program. EA provides a strategy and business- driven approach to policy, planning, decision-making, and resource development that is useful to executives, line managers, and support staff.

To be effective, an EA program must be part of a group of management practices that form an integrated governance structure, as is shown in Figure 1-2 on the next page. An Introduction to Enterprise Architecture – 3 rdEdition 34 Figure 1-2: Major Areas of Integrated Governance Enterprise Architecture as a Meta-Discipline An enterprise-wide architecture should serve as an authoritative reference, source of standards for processes / resources, and provider of designs for future operating states. An EA is therefore THE architecture of the enterprise and should cover all elements and aspects. Having a single source of reference is essential to avoiding waste and duplication in large, complex organizations. It also resolves the “battle of best practices” and competition between sub-architectural domains which can be problematic for organizations that are trying to become for efficient. Developing an enterprise-wide architecture using the EA methods described in this book is a unique and valuable undertaking for organizations, in that the EA is holistic and serves as an umbrella or “meta- context” for all other management and technology best practices. The EA also creates abstract views, analyses, and models of a current or future enterprise that helps people make better plans and decisions. EA extends beyond technology planning, by adding strategic planning as the primary driver of the enterprise, and business planning as the source of most program and resource requirements. There is still a place for technology Inte gr a te d Gov e r na nc e Strategic Planning Enterprise Ar c hite c tur e Capital Investm ent Planning Workf orce Planning Knowledge Managem ent Program Managem ent Risk Managem ent Operations and Security An Introduction to Enterprise Architecture – 3 rdEdition 35 planning, which is to design systems, applications, networks, call centers, networks, and other capital resources (e.g. buildings, capital equipment) to meet the business requirements… which are the heart of the enterprises activities… creating and delivering those products and services that accomplish the strategic goals of the enterprise.

Regarding the “battle of the best practices”, organizations in the public and private sectors are often faced with decisions about which practices to adopt as they pursue quality, agility, efficiency; manage risk, and adopt new technologies. There are dozens of best practices out there, and most of them were created in isolation – relative to the other best practices. I call this the “battle of the best practices” and it creates an expensive dilemma for organizations – what to adopt? Because the implementation and maintenance methods for many of the best practices are very resource intensive, and the scope is not all-inclusive, the organization is faced with the challenge of deciding which to adopt, how to do it, and what overlaps, contradictions, and gaps are produced from the resulting collection. When EA is THE architecture of an organization in all dimensions, it becomes the over-arching, highest level discipline and the authoritative reference for standards and practices. This is a tremendous and unique contribution, because when EA is used in this way, the dilemma disappears and organizations can use the EA framework to make rational decisions about which best practices need to be adopted, what they will cover, and how they can relate to each other. Figure 1-3 illustrates how EA serves as an organizing context for the adoption and use of best practices.

Figure 1-3: Enterprise Architecture as a Meta Discipline Strategic Level Business Level Technology Level The Enterprise Architecture Balanced Scorecard SWOT BPI / BPR Business CasesAlternatives Analysis SOA ITIL CORBAObject-Oriented Design & Analysis SDLC Six Sigma EA is the organizing meta-context and standards authority for implementing all management and technology best practices In f o rma tio n As su ranc e CPIC Cloud ComputingMobile PMBOK An Introduction to Enterprise Architecture – 3 rdEdition 36 The Enterprise Architecture Approach For an EA approach to be considered to be complete, the six core elements shown in Figure 1-4 must be present and work synergistically together.

Figure 1-4: Core Elements of an Enterprise Architecture Approach Governance The first core element is “Governance” which identifies the planning, decision-making, and oversight processes and groups that will determine how the EA is developed and maintained, accomplished as part of an organization’s overall governance.

Methodology The second core element is “Methodology” which are specific steps to establish and maintain an EA program, via the selected approach.

Framework The third core element is “Framework” which identifies the scope of the overall architecture and the type and relationship of the various sub- architecture levels and threads. Not all frameworks allow for sub-domains or are able to integrate strategy, business, and technology planning.

Artifacts The fourth core element is “Artifacts” which identifies the types and methods of documentation to be used in each sub-architecture area, including strategic analyses, business plans, internal controls, security Framework Artifacts Best Practices Methodology Governance Framework Artifacts Best Practices Methodology Standards Framework Artifacts Best Practices Methodology Standards Governance An Introduction to Enterprise Architecture – 3 rdEdition 37 controls, and models of workflow, databases, systems, and networks. This core element also includes the online repository where artifacts are stored.

Standards The fifth core element is “Standards” which identify business and technology standards for the enterprise in each domain, segment, and component of the EA. This includes recognized international, national, local, and industry standards as well as enterprise-specific standards. Best Practices The sixth core element is “Associated Best Practices” which are proven ways to implement parts of the overall architecture or sub-architectures, in context of the over-arching EA.

Enterprise Architecture Activities Enterprise architecture is accomplished through a management program and ananalysis and design methodthat is repeatable at various levels of scope. Together the EA program and method provide an ongoing capability and actionable, coordinated views of an enterprise’s strategic direction, business services, information flows, and resource utilization. As a management program, EA provides: ¾Strategic Alignment: Connects goals, activities, and resources ¾Standardized Policy:Resource governance and implementation ¾Decision Support:Financial control and configuration management ¾Resource Oversight:Lifecycle approach to development/management As ananalysis and design method, EA provides:

¾EA Approach:The framework, analysis/design method, and artifact set ¾Current Views:Views of as-is strategies, processes, and resources ¾Future Views:Views of to-be strategies, processes, and resources ¾EA Management Plan:A plan to move from the current to the future EA EA as a Management Program EA an ongoing management program that provides a strategic, integrated approach to capability and resource planning / decision-making. An EA program is part of an overall governance process that determines resource An Introduction to Enterprise Architecture – 3 rdEdition 38 alignment, develops standardized policy, enhances decision support, and guides development activities. EA can help to identify gaps in the performanceof line of business activities/programs and the capabilities of supporting IT services, systems, and networks.

Strategic Alignment EA supports strategic planning and other operational resource planning processes by providing macro and micro views of how resources are to be leveraged in accomplishing the goals of the enterprise. This helps to maximize the efficiency and effectiveness of these resources, which in turn will help to promote the enterprise’s competitive capabilities.

Development projects within the enterprise should be reviewed to determine if they support (and conform to) one or more of the enterprise’s strategic goals. If a resource and/or project is not aligned, then its value to the enterprise will remain in question, as is shown in Figure 1-5.

Figure 1-5: Strategic Alignment of Capabilities and Resources Standardized Policy EA supports the implementation of standardized management policy pertinent to the development and utilization of IT and other resources. By providing a holistic, hierarchical view of current and future resources, EA supports the establishment of policy for:

ƒIdentifying strategic and operational requirements Enterprise Strategic Goals Line of Business #1 Goals Enterprise-Wide Strategic Initiatives Line of Business #2 Goals Line of Business #3 Goals Line of Business #1 Program Group Line of Business #2 Program Group Line of Business #3 Program Group Project 1-1 Project 1-2 Project 1-3 Project 2-1 Project 2-2 Project 2-3 Project 3-1 Project 3-2 Project 3-3 Capability Alignment Resource Alignment An Introduction to Enterprise Architecture – 3 rdEdition 39 ƒDetermining the strategic alignment of activities and resources ƒDeveloping enterprise-wide business and technology resources ƒPrioritizing the funding of programs and projects ƒOverseeing the management of programs and projects ƒIdentifying performance metrics for programs and projects ƒIdentifying and enforcing standards and configuration management Policy documents include those which can be categorized as general guidance (e.g., high-level directives and memos); specific program guidance (e.g., plans, and manuals); and detailed process guidance (e.g., standard operating procedures). By using these hierarchical categories of documents, succinct and meaningful policy is established. It does so in a way that no single policy document is too long and therefore not too burdensome to read. It is also important to understand how the various areas of policy are inter-related so that program implementation across the enterprise is coordinated. EA policies must integrate with other policies in all governance areas, so as to create an effective overall resource management and oversight capability. Decision Support EA provides support for IT resource decision-making at the executive, management, and staff levels of the enterprise. At the executive level, EA provides visibility for large IT initiatives and supports the determination of strategic alignment. At the management level, EA supports design and configuration management decisions, as well as the alignment of IT initiatives with technical standards for voice, data, video, and security. At the staff level, EA supports decisions regarding operations, maintenance, and the development of IT resources and services. Resource Oversight EA supports standardized approaches for overseeing the development of capabilities and optimizing supporting resources. Depending on the scope of the resources involved and the available timeframe for development, various system development lifecycle methods can be used to reduce the risk that cost, schedule, or performance parameters may not be met. EA further supports standardized, proven approaches to project management that promote the comprehensive and effective oversight of ongoing programs and new development projects. Finally, EA supports the use of a standardized process for selecting and evaluating investment in IT resources from a business and financial perspective. An Introduction to Enterprise Architecture – 3 rdEdition 40 EA as an Analysis and Design Method References to EA began to emerge in the late 1980’s in various management and academic literatures, with an early focus on technical or systems architectures and schemas for organizing information. The concept of ‘enterprise’ architecture analysis and design emerged in the early 1990’s and has evolved to include views of strategic goals, business services, information flows, systems and applications, networks, and the supporting infrastructure. Additionally, there are ‘threads’ that pervade every level of the architecture: standards, security, and skills.

EA analysis and design are accomplished through the following six basic elements: (1) an EA documentation framework, and (2) an implementation methodology that support the creation of (3) current and (4) future views of the architecture, as well as the development of (5) an EA Management Plan to manage the enterprise’s transition from current to future architectures. There are also several areas common to all levels of the framework that are referred to as (6) “threads” as shown in Figure 1-6.

Figure 1-6: Basic Elements of EA Analysis and Design EA Analysis and Design Element #1: The Framework . The EA framework identifies the scope of the architecture to be developed and establishes relationships between the architecture’s areas. The framework’s scope is reflected through its geometric design and the areas that are identified for documentation. The framework creates an abstracted set of “views” of an enterprise through the way that it collects and organizes architecture information. An example that will be used throughout the book is the framework that is illustrated in Figure 1-7, Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Networks & Infrastructure Systems & Applications Data & Information Products & Services Network InfrastructureNetwork Infrastructure Goals & Initiatives Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Optimized Networks and Infrastructure Integrated Systems and Applications Enhanced Data and Information Flows Improved Business Products and Services Network InfrastructureNetwork Infrastructure Updated Strategic Goals & Initiatives CURRENT ARCHITECTURE FUTURE ARCHITECTURE Lin es of Bu sin ess Highest Level & View Lowest Level & View C O M P O N E N T S Architecture Management Plan EA Framework 2 Lin es of Bu sin ess C O M P O N E N T S Security / Standards / Skills 1 3 4 5 6 An Introduction to Enterprise Architecture – 3 rdEdition 41 which has a cubic shape with three dimensions that relate to different aspects of modeling the abstracted enterprise. Figure 1-7: EA³ Cube Analysis & Design Framework Known as the EA³ Cube Framework ™ the levels of this example framework are hierarchical so that the different sub-architectures (that describe distinct functional areas) can be logically related to each other.

This is done by positioning high-level strategic goals/initiatives at the top, business products/services and data/information flows in the middle, and supporting systems/applications and technology/infrastructure at the bottom. In this way alignment can be also be shown between strategy, information, and technology, which aids planning and decision-making.

Chapters 4 through 6 provide more details on EA frameworks, components, and methods. To lower risk and promote efficient, phased implementation methods, the EA framework is divided into segments of distinct activity, referred to as Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Networks & Infrastructure Systems & Applications Data & Information Products & Services Network Infrastructure Network Infrastructure Goals & Initiatives Lines of Business C O M P O N E N T S Security / Standards / Skills Technology – Business – Strategy Framewo rk D imens io n 3 :Artifacts The d o c umentatio n o f c o mp o nents at eac h level of the architecture, including all threads Framewo rk D imens io n 1 :Levels Sub-architectures; distinct f unctional areas and their relatio ns hip s An Introduction to Enterprise Architecture – 3 rdEdition 42 Lines of Business(LOBs). For example, each LOB has a complete sub- architecture that includes all five hierarchical levels of the EA³ framework.

The LOB therefore can in some ways stand alone architecturally within the enterprise except that duplication in data, application, and network functions would occur if each LOB were truly independent. An architecture encompassing all five framework levels that is focused on one or more LOBs can be referred to as a segmentof the overall EA.

EA Analysis and Design Element #2: EA Components EA components are changeablegoals, processes, standards, and resources that may extend enterprise-wide or be contained within a specific line of business or segment. Examples of components include strategic goals and initiatives; business products and services; information flows, knowledge warehouses, and data objects; information systems, software applications, enterprise resource programs, and web sites; voice, data, and video networks; and supporting infrastructure including buildings, server rooms, wiring runs/closets, and capital equipment. Figure 1-8 on the next page provides examples of vertical and crosscutting EA components at each level of the EA³ Cube framework, and Chapter 6 provides additional details. Key Term: Architecture Segment A part of the overall EA that documents one or more lines of business at all levels and threads. A segment can exist as a stand-alone part of the EA.

Key Term: Line of Business A Line of Business (LOB) is a distinct area of activity within the enterprise. It may involve the manufacture of certain products, the provision of services, or internal administrative functions.

Key Term: Vertical Component A vertical component is a changeable goal, process, program, or resource (equipment, systems, data, etc.) that serves one line of business. Key Term: Horizontal (Crosscutting) Component A horizontal (or crosscutting) component is a changeable goal, process, program, or resource that serves several lines of business. Examples include email and administrative support systems that serve the whole enterprise. An Introduction to Enterprise Architecture – 3 rdEdition 43 Figure 1-8: Examples of EA Components EA Analysis and Design Element #3: Current Architecture The current architecture contains those EA components that currently exist within the enterprise at each level of the framework. This is sometimes referred to as the “as-is” view. The current view of the EA serves to create a ‘baseline’ inventory of current resources and activities that is documented in a consistent way with the future view of the EA so that analysts can see gaps in performance between future plans and the current capabilities. Having an accurate and comprehensive current view of EA components is an important reference for project planning, asset management, and investment decision-making. The current view of the EA is composed of ‘artifacts’ (documents, diagrams, data, spreadsheets, charts, etc.) at each level of the framework, which are archived in an on- line EA repository to make them useable by various EA stakeholders.

EA Analysis and Design Element #4: Future Architecture The future architecture documents those new or modified EA components that are needed by the enterprise to close an existing performance gap or support a new strategic initiative, operational requirement, or technology solution. Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Technology & Infrastructure Systems & Applications Data & Information Products & Services Network Infrastructure Network Infrastructure Goals & Initiatives Examples of EA Components •Information Systems •Web Sites •Desktop Applications •Intranets & Extranets •Telecommunications •Buildings & Equipment •Knowledge Warehouse •Databases & Data Marts •Data Interchange •Manufacturing •Financial Services •Marketing & Sales •Mission Statement •Strategic Goals •Strategic Initiatives Vertical Components Crosscutting Components Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Technology & Infrastructure Systems & Applications Data & Information Products & Services Network Infrastructure Network Infrastructure Goals & Initiatives Examples of EA Components •Information Systems •Web Sites •Desktop Applications •Intranets & Extranets •Telecommunications •Buildings & Equipment •Knowledge Warehouse •Databases & Data Marts •Data Interchange •Manufacturing •Financial Services •Marketing & Sales •Mission Statement •Strategic Goals •Strategic Initiatives Vertical Components Crosscutting Components An Introduction to Enterprise Architecture – 3 rdEdition 44 As is shown in Figure 1-9, the future architecture is driven at both the strategic and tactical levels in three ways: new directions and goals; changing business priorities; and emerging technologies. The EA cannot reflect these changes in the future architecture unless the enterprise’s leadership team provides the changes in strategic direction and goals; unless the line of business managers and program managers provide the changes in business processes and priorities that are needed to accomplish the new goals; and unless the support/delivery staff identifies viable technology and staffing solutions to meet the new business requirements.

Figure 1-9: Drivers of Architectural Change The future architecture should cover planned changes to EA components in the near term (tactical changes in the next 1-2 years), as well as changes to EA components that are a result of the implementation of long-term operating scenarios that look 3-10 years into the future. These scenarios incorporate different internal and external drivers and can help to identify needed changes in processes, resources, or technology that translate to future planning assumptions, which in turn drive the planning for new EA components. An example future scenario and additional details on the future architecture are provided in Chapter 8. EA Analysis and Design Element #5: EA Management Plan The EA Management Plan articulates the EA program and documentation approach. The EA Management Plan also provides descriptions of current and future views of the architecture, and a sequencing plan for managing the transition to the future business/technology operating environment.

The EA Management Plan is a living document that is essential to realizing the benefits of the EA as a management program. How the enterprise is going to continually move from the current architecture to the future architecture is a significant planning and management challenge, especially if IT resources supporting key business functions are being Capabilities of the Current Enterprise Capabilities of the Future Enterprise Emerging Technologies (Support Team) New Business Priorities (Management Team) New Direction & Goals (Leadership Team) Strategic Tactical Operating Scenarios Program Plans Capabilities of the Current Enterprise Capabilities of the Future Enterprise Emerging Technologies (Support Team) New Business Priorities (Management Team) New Direction & Goals (Leadership Team) Strategic Tactical Operating Scenarios Program Plans An Introduction to Enterprise Architecture – 3 rdEdition 45 replaced or upgraded. Chapter 9 provides additional details on the development of an EA Management Plan.

EA Analysis and Design Element #6: Threads EA documentation includes ‘threads’ of common activity that are present in all levels of the framework. These threads include IT-related security, standards, and skill considerations. Security . Security is most effective when it is an integral part of the EA management program and documentation methodology. A comprehensive IT Security Program has several focal areas including:

information, personnel, operations, and facilities. To be effective, IT security must work across all levels of the EA framework and within all of the EA components. Chapter 11 provides more information on security.

Standards . One of the most important functions of the EA is that it provides technology-related standards at all levels of the EA framework. The EA should draw on accepted international, national, and industry standards in order to promote the use of non-proprietary solutions in EA components. This in turn enhances the integration of EA components, as well as better supporting the switch-out of components when needed.

Skills . Perhaps the greatest resource that an enterprise has is people. It is therefore important to ensure that staffing, skill, and training requirements are identified for LOB and support service activities at each level of the EA framework, and appropriate solutions are reflected in the current and future architectures. Reference Architecture / Segment Architecture A reference architecture is the part of an EA that provides standards and documentation for a particular type of capability throughout the enterprise – such as mobile services or cloud computing. A segment architecture is somewhat similar, but usually focuses one or more particular business units or functions – such as the finance and accounting group, or how a financial ERP system and all of its modules are going to be implemented (general ledger, accounts payable, accounts receivable, payroll, benefits, etc.). An Introduction to Enterprise Architecture – 3 rdEdition 46 Fitting the Architecture Elements Together While the basic elements of EA analysis and design provide holistic and detailed descriptions of the current and future architecture in all areas of the underlying framework, it is important to also be able to articulate these relationships in discussions and presentations with executives, managers, support staff, and other EA stakeholders. Being able to understand and relate how the architecture fits together is essential to being able to use the EA in planning and decision-making throughout the enterprise. This communication is supported through two EA program resources: the EA Management Plan and the EA Repository. As was mentioned in the previous section, the EA Management Plan is a living document that is periodically updated so that it remains relevant as the ongoing primary reference for describing where the current and future architectures are at. The EA Repository is the on-line archive for EA information and the documentation artifacts that are described in the EA Management Plan.

The EA Repository is described in the next section of this chapter.

The following is an example of how to communicate about EA with stakeholders. In this example, some questions are presented about how to apply an EA framework to an enterprise, which subsequent chapters of the book answer. These are the types of questions that should be answered in the first few sessions of EA program and documentation meetings in order to promote an understanding of how the EA framework and documentation can reflect the enterprise. In the following example of how to talk about EA, the five levels and three vertical threads of the EA 3Cube framework are used for illustration. Notice how the questions build in a way that reflects the hierarchical relationships between the levels of the EA 3 Framework. Each area of the EA 3Framework represents a functional area of the enterprise. The EA3Framework can be used in a top-down, bottom- up, or single-component manner. To begin to use the framework in a top down-manner, a series of questions at each level should be asked in order to determine how information about the enterprise will fit within that level of the framework. The first questions to ask relate to the strategic ’Goals and Initiatives’ level of the framework. The questions are: (1) for what purpose does the enterprise generally exist (usually expressed in the mission statement) and (2) what kind of organization does the enterprise generally intend to be (often given in the vision statement)? What are the primary goals (strategic goals) of the An Introduction to Enterprise Architecture – 3 rdEdition 47 enterprise? What then are the strategic initiatives (ongoing programs or new projects) that will enable the enterprise to achieve those goals? Finally, for this level, when will the enterprise know that it has successfully reached these strategic goals or is making progress toward these goals (outcome measures)?

Second is the business ‘Products and Services’ level of the framework, and it is important to first ask what are the ongoing activity areas (lines of business) that the enterprise must engage in to support and enable the accomplishment of both strategic initiatives and normal ‘maintenance/housekeeping’ functions? What then are the specific activities in each line of business (business services)? What are the products that are delivered in each line of business? How do we measure the effectiveness and efficiency of the line of business processes (input/output measures) as well as their contribution to strategic goals (outcome measures)?

Do any of these business services or manufacturing processes need to be reengineered/improved before they are made to be part of the future architecture? What are the workforce, standards, and security issues at this framework level?

Third is the ‘Data and Information’ level of the framework. When the lines of business and specific business service/products have been identified, it is important to ask what are the flows of information that will be required within and between activity areas in order to make them successful? How can these flows of information be harmonized, standardized, and protected to promote sharing that is efficient, accurate, and secure? How will the data underlying the information flows be formatted, generated, shared, and stored? How will the data become useable information and knowledge? Fourth is the ‘Systems and Applications’ level of the framework and it is important to ask which IT and other business systems and applications will be needed to generate, share, and store the data, information, and knowledge that the business services need? How can multiple types of IT systems, services, applications, databases, and web sites be made to work together where needed? How can configuration management help to create a cost-effective and operationally efficient ‘Common Operating Environment’ for systems and applications? What are the workforce, standards, and security issues at this level? An Introduction to Enterprise Architecture – 3 rdEdition 48 Fifth is the ‘Network and Infrastructure’ level of the framework and it is important to ask what types of voice, data, and video networks or computing clouds will be required to host the IT systems/applications and to transport associate, data, images, and conversations, as well as what type of infrastructure is needed to support the networks (e.g. buildings, server rooms, other equipment). How can these networks be integrated to create a cost- effective and operationally efficient hosting and transport environment? Will these networks and clouds extend beyond the enterprise? What are the workforce, standards, and security issues at this level? What are the physical space and utility support requirements for these infrastructure resources? The EA Repository Providing easy access to EA documentation is essential for use in planning and decision-making. This can be accomplished through the establishment of an on-line EA repository to archive the documentation of EA components in the various areas of the EA framework. The EA repository is essentially a website and database that stores information and provides links to EA tools and other EA program resources. Figure 1-10 provides an example of how an EA repository might be designed. This example is called Living Enterprise™ and it is designed to support documentation that is organized through the use of the EA³ Cube Framework. Chapter 12 provides additional details on the design and function of an EA repository.

Figure 1-10: Example EA Repository Design – Living Enterprise TM Detailed View Mid Level View High Level View Current EA Views Enterprise Architecture Repository Perf o rmanc e Meas ures Strategic Plan Go als & Initiatives Investment Portf o lio Business Plan Business Processes Data D ic tio nary Knowledge Wareho us e Inf o rm at i o n Flo ws Application Inv ent o ry Business Systems Support Systems Buildings & Eq uip ment Wid e Area Net wo rk Lo c al Area Net wo rk Data Privacy Security Program System Certif ications Goals & Initiatives Products & Services Data & Information System s & Applications Networks & I nfrastructure Security Solutions Site Map EA Tutorial EA Program Future EA Views EA Standards EA Manag ement Plan An Introduction to Enterprise Architecture – 3 rdEdition 49 Summary of Concepts A program or systems-level perspective is not sufficient for the management and planning of technology and other resources across enterprises with significant size and complexity. EA is the one discipline that looks at systems holistically as well as provides a strategy and business context. EA was described as being as both a management process and an analysis and design method that helps enterprises with business and technology planning, resource management, and decision- making. The purposes of an EA management program were described:

strategic alignment, standardized policy, decision support, and resource development. The six basic elements of an EA analysis and design method were presented: the EA documentation framework, EA components, current EA views, future EA views, an EA Management Plan and multi- level threads that include security, standards, and workforce planning. An example of how to communicate the various areas of an EA framework was also provided. The following chapters of Section I will describe why EA is valuable to many types of enterprises, what the risks of doing EA are, and how to ensure that an architecture is driven by strategic goals and business requirements.

Chapter 1 Questions and Exercises 1. What are some of the differences between enterprise architecture (EA) and a systems-level planning approach? 2. Why is EA described as both a management program and an analysis and design method?

3. What are the four elements of an EA management program and the six elements of an EA analysis and design method?

4. What are some of the EA components and documentation artifacts that would be included in current and future views at each level of the EA³ Cube framework?

5. Can EA be used by all types of enterprises? If so, why?

6. How does an EA repository support the implementation methodology?

7. Choose a real-world large-sized enterprise and determine:

a. Is information technology seen as a strategic asset?

b. Does an enterprise architecture program exist?

c. Are there gaps in business/technology performance that an enterprise architecture program could help identify and correct? An Introduction to Enterprise Architecture – 3 rdEdition 51 Chapter 2 The Structure and Culture of Enterprises Chapter Overview Chapter 2 discusses the need for enterprise architects to understand the role of organizational structure and culturein developing an EA. Structure and culture are important to include in the EA in order to accurately reflect the true nature of organizational goals, processes, and informal structures which influence the current and future views of the architecture.

Understanding structure and culture are also important in working with stakeholdersto gain their support and manage expectations for the development and implementation of the EA program. Enterprises are types of social organizations and as such, the concepts of organizational theory presented in this chapter are applicable to the practice of EA. Learning Objectives ¾Understand the structural and cultural aspects of an enterprise ¾Understand the differences between an organization and an enterprise ¾Become familiar with models of organizations and enterprises ¾Be able to tie structural and cultural aspects of the enterprise to the architecture Key Term: Culture The beliefs, customs, values, structure, normative rules, and material traits of a social organization. Culture is evident in many aspects of how an or ganization functions. Key Term: Stakeholder Everyone who is or will be affected by a policy, program, project, activity, or resource. Stakeholders for the EA program include executive sponsors, architects, program managers, users, and support staff. An Introduction to Enterprise Architecture – 3 rdEdition 52 Introduction Enterprise architecture is as much about people and social interaction as it is about processes and resource utilization. Understanding each of these aspects of an enterprise is essential to the development of accurate views of the current architecture and relevant, meaningful views of the future architecture. Insight into the “people aspect” of enterprises is also important to the development of policy, standards, and an EA Management Plan that will be accepted by the enterprise. Moving from current to future states of the EA involves changes in processes and how people will communicate. Change involves moving from what is familiar to something unfamiliar, which is uncomfortable and/or threatening to many people. Therefore, there may be resistance to programs such as EA that cause or support changes in resources and processes throughout the enterprise.

Discussion Influences on the Field of Enterprise Architecture Developing an enterprise-wide architecture involves an evaluation and depiction of people, processes, and resources. Some of the areas of practice and theory that have influenced the EA practices include business administration, public administration, operations research, sociology, organizational theory, management theory, information science, and computer science. Understanding the mission, goals, and culture of an enterprise is as important to implementing an EA as the selection of analytic methods and documentation techniques. The EA approach described in this book is based on theories of how social organizations are structured and how systems and activities function within enterprises. Figure 2-1 on the next page shows the academic fields and areas of theory/practice that influence EA. Home Architecture Analogy: An architect needs to understand the composition, preferences, and activities of the occupants to be able to produce an effective design for their new or remodeled home. How they will use the rooms, their activity patterns, and storage needs are examples of the factors to be considered. An Introduction to Enterprise Architecture – 3 rdEdition 53 Figure 2-1: Influences on the Field of Enterprise Architecture The Structure of Enterprises In this part of Chapter 2 there will be some references to organizations instead of enterprises because the concepts come from established organizational theory. The concepts of organizational theory also apply to enterprises because they are types of social organizations. Organizations and enterprises are essentially complex social systems, which regardless of mission, share many similarities in their basic structure and functions. The Leavitt Diamond Model One of the early models of general organizational structure is the “Levitt Diamond” presented in 1965 and shown in Figure 2-2. 5 Leavitt argued that a change in any of these four components will have an effect on the others and that the interaction of the components underlies organizational success.

Figure 2-2: Leavitt Diamond 5Leavitt, H.J. 1965. Applied Organizational Change in Industry: Structural, Technological and Humanistic Approaches in: Handbook of Organizations, edited by J.G. March. Chicago, Rand McNally Organizational Theory Systems Theory Enterprise Architecture Contributing Concepts Contributing Concepts• • Beliefs Beliefs • • Values & Ethics Values & Ethics • • Leadership Leadership • • Culture Culture • • Language & Meaning Language & Meaning • • Competition Competition • • Bureaucracy BureaucracyContributing Concepts Contributing Concepts • • Process Process • • Technology Technology • • Management Management • • Quality Quality • • Environment Environment • • Reengineering Reengineering • • Risk Risk Contributing Fields Contributing Fields Psychology Psychology Sociology Sociology Political Science Political Science Public Administration Public AdministrationContributing Fields Contributing Fields Engineering Engineering Computer Science Computer Science Business Administration Business Administration Operations Research Operations Research Emerging Fields Emerging Fields Information Resources Mgmt Information Resources Mgmt Information Security Information Security Enterprise Architecture Enterprise Architecture Records & Data Mgmt Records & Data Mgmt Emerging Concepts Emerging Concepts Systems Lifecycle Development Systems Lifecycle Development Information Assurance Information Assurance IT Program Mgmt IT Program Mgmt Knowledge Mgmt Knowledge Mgmt IT Capital Planning IT Capital Planning E E - - Government & Commerce Government & Commerce Digital Divide Digital Divide Organizational Theory Systems Theory Enterprise Architecture Contributing Concepts Contributing Concepts• • Beliefs Beliefs • • Values & Ethics Values & Ethics • • Leadership Leadership • • Culture Culture • • Language & Meaning Language & Meaning • • Competition Competition • • Bureaucracy BureaucracyContributing Concepts Contributing Concepts • • Process Process • • Technology Technology • • Management Management • • Quality Quality • • Environment Environment • • Reengineering Reengineering • • Risk Risk Contributing Fields Contributing Fields Psychology Psychology Sociology Sociology Political Science Political Science Public Administration Public AdministrationContributing Fields Contributing Fields Engineering Engineering Computer Science Computer Science Business Administration Business Administration Operations Research Operations Research Emerging Fields Emerging Fields Information Resources Mgmt Information Resources Mgmt Information Security Information Security Enterprise Architecture Enterprise Architecture Records & Data Mgmt Records & Data Mgmt Emerging Concepts Emerging Concepts Systems Lifecycle Development Systems Lifecycle Development Information Assurance Information Assurance IT Program Mgmt IT Program Mgmt Knowledge Mgmt Knowledge Mgmt IT Capital Planning IT Capital Planning E E - - Government & Commerce Government & Commerce Digital Divide Digital Divide An Introduction to Enterprise Architecture – 3 rdEdition 54 The Parsons/Thompson Model Another model of general organizational structure is a three-level view that was originally envisioned by sociologist Talcott Parsons in the 1950’s and further developed by sociologist James Thompson in the 1960’s. 6 Parsons’ research identified three general levels that are common to most social organizations (technical, managerial, and institutional), based on the observation that different types of activities occur at each level. 7 Thompson built on Parsons’ ideas by further identifying the different types of activities that occur at each level. 8 Figure 2-3 summarizes the Parsons/Thompson Model of social organizations. Organizational LevelStructure Parson’s Purpose of each Level Function Thompson’s Activities of the Level Institutional Where the organization establishes rules and relates to the larger society as it derives legitimization, meaning, and higher-level support, thus making possible the implementation of organizational goals.The organization is very open to the environment in order to determine its domain, establish boundaries, and secure legitimacy. Managerial Where mediation between the organization and the immediate task environment occurs, where the organization’s internal affairs are administered, and where the organization’s products are consumed and resources supplied.A dynamic of mediation occurs where less formalized and more political activities occur. Technical Where the actual “product” of an organization is processed.The organization is “rational” as it carries on production (input/output) functions and tries to seal off those functions from the outside to protect them from external uncertainties as much as possible. Figure 2-3: Parson/Thompson Model of Enterprises 6Bernard, S. A. Evaluating Clinger-Cohen Compliance in Federal Agency Chief Information Officer Positions . Doctoral Dissertation, Virginia Polytechnic Institute & State University, April 2001. 7Thompson, James D. Enterprises in Action . New York: McGraw-Hill. 1967. 8Ibid. An Introduction to Enterprise Architecture – 3 rdEdition 55 The geometry of the Parson/Thompson Model has been adapted by the author to resemble a series of concentric circles. This may provide a more useful image for depicting a social organization that interacts with its environment via the model’s Institutional Level, facilitates internal resources via the Managerial Level, and protects a “core” of essential processes and resources at the Technical Level. Figure 2-4 shows this spherical version of the Parsons/Thompson Model, which also is more useful in relating it to how an EA framework can document organizational functions.

Figure 2-4: Relating Models of Organizational Function and Structure The value of the Parsons/Thompson Model is its use as an authoritative reference for developing EA views of structure and process for an organization. Regardless of the model’s wide acceptance in academia, the question of whether this fifty year old view would be relevant and useful to understanding the structure of current public and private sector organizations is answered by observing that many large and medium sized corporations and government agencies continue to be hierarchical, rule- based, and goal-oriented. These were some of the primary characteristics of the “rational” organization that Parsons and Thompson originally studied. Evidence of this still being a valid model is also seen in the rational nature of organizational charts, mission statements, strategic plans, operational plans, and business services of these types of organizations. Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Networks Networks & & Infrastructure Infrastructure Systems Systems & & Applications Applications Data Data & & Information Information Products Products & & Services Services Network Network Infrastructure InfrastructureNetwork Network Infrastructure Infrastructure Goals Goals & & Initiatives Initiatives Lines of Business Lines of Business C C O O M M P P O O N N E E N N T T S S Security / Standards / WorkforceSecurity / Standards / Workforce Technology Technology –– Business Business –– StrategyStrategy Technical Level Managerial Level Institutional Level Parsons/Thompson Model of Generic Organizational Structure EA3 Cube Architecture Documentation Framework Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Networks Networks & & Infrastructure Infrastructure Systems Systems & & Applications Applications Data Data & & Information Information Products Products & & Services Services Network Network Infrastructure InfrastructureNetwork Network Infrastructure Infrastructure Goals Goals & & Initiatives Initiatives Lines of Business Lines of Business C C O O M M P P O O N N E E N N T T S S Security / Standards / WorkforceSecurity / Standards / Workforce Technology Technology –– Business Business –– StrategyStrategy Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Networks Networks & & Infrastructure Infrastructure Systems Systems & & Applications Applications Data Data & & Information Information Products Products & & Services Services Network Network Infrastructure InfrastructureNetwork Network Infrastructure Infrastructure Goals Goals & & Initiatives Initiatives Lines of Business Lines of Business C C O O M M P P O O N N E E N N T T S S Security / Standards / WorkforceSecurity / Standards / Workforce Technology Technology –– Business Business –– StrategyStrategy Technical Level Managerial Level Institutional LevelTechnical Level Managerial Level Institutional Level Parsons/Thompson Model of Generic Organizational Structure EA3 Cube Architecture Documentation Framework An Introduction to Enterprise Architecture – 3 rdEdition 56 However, there are new types of organizations that have emerged due to technology-based changes in how people communicate and work. Global telecommunications and the Internet have made location a largely irrelevant factor in terms of where some types of work are being done (e.g., knowledge work and on-line services). Two primary changes related to organizational structure and function have resulted. First, more organizations are becoming regional or global in nature, and are relying on remote sub-groups to do significant amounts of the work. Second, more people are becoming self-employed knowledge workers who contract their services remotely to various enterprises depending on their interest, skills, and availability. Examples include people who process digitized health care forms, software developers, web site developers, distance learning instructors, financial traders, insurance salespeople, and telemarketers.

Because these organizations can get certain functions accomplished remotely, their structure may become less hierarchical and more collaborative. While it can be argued that these new networked organizations exhibit many of the structural and functional characteristics found in the Parsons/Thompson Model, there are enough differences to merit discussion of a variation of that model which may better describe how organizations operate in a more global on-line business environment.

The Organizational Network Model New types of organizations and enterprises are appearing which are based on cooperative networks of local and remote individual workers and semi- autonomous teams who carry out key functions. In these enterprises, greater cost efficiency and more mission flexibility are achieved by removing layers of management that are not needed in a decentralized operating mode. These teams are actually sub-groups that have their own management level and technical level with core processes, and therefore will still exhibit some of the characteristics of the Parsons/Thompson Model. The difference presented here is that the organization/enterprise’s structure is based on these teams and remote workers, whose goals and functions may change depending on internal and external influences.

Called the Organizational Network Model (ONM), an Executive Teamsets policy and goals, approves resources, and evaluates results, while semi- autonomous Functional Teams and Independent Workersmanage ongoing programs/lines of business, new development projects, and team-specific resources. The Functional Teams and Independent Workers receive An Introduction to Enterprise Architecture – 3 rdEdition 57 policy, goals, and general direction from the Executive Team, yet carry out organizational functions in an independent and/or cooperative manner, depending on the goal(s). Figure 2-5 provides an illustration of the ONM.

Figure 2-5: Organizational Network Model Being less hierarchical, these “flatter” and more flexible ONM organizations can respond to changing requirements more quickly by creating, modifying, or eliminating Functional Teams and/or adjusting the number and type of Independent Workers. These types of ONM organizations and enterprises can also exist as extended supply chains or networks of teams from inside and outside the traditional organizational boundary. This includes trusted business partners and independent consultants who are allowed to share sensitive information and key resources with the enterprise as part of the activities of the Functional Teams and Independent Workers. Figure 2-6 on the next page shows how Functional Teams in ONM organizations can be related to an enterprise’s Lines of Business (LOBs) in the EA 3 Cube Framework. An Introduction to Enterprise Architecture – 3 rdEdition 58 Figure 2-6: Relating Functional Teams to EA Lines of Business Organizations and Enterprises Organizations and enterprises are similar in that they are both types of social entities that have a culture, a formal and informal structure, goals, activities, and resources. The difference is that an enterprise can be defined as a subset of an organization or can involve multiple organizations. Why isn’t this book called An Introduction to Organizational Architecture? Because that would largely limit the subject to architectures that encompass an entire organization, and while those architectures are important, a more versatile concept is an enterprise, which can cover part of the organization, all of the organization, or multiple organizations. Enterprises are normally made up ofvertical,horizontal, and extended components. Vertical components (also known as lines of business or segments) are activity areas that are particular to one line of business (e.g., research and development). Horizontal components (also known as crosscutting enterprises) are more general areas of activity that serve multiple lines of business. Extended components comprise more than one organization (e.g., extranets and supply chains).

EA views of vertical components are complete stand-alone architectures in that they contain documentation from all levels of the EA framework. These types of vertical components are also known as “segments.” When vertical segments are documented using the same EA framework, they can Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Technology Technology Infrastructure Infrastructure Systems & Systems & Services Services Information Information Flows Flows Business Business Processes Processes Network Network Infrastructure InfrastructureNetwork Network Infrastructure Infrastructure Strategic Strategic Initiatives Initiatives LOB LOB - - 3 3 Security, Standards, WorkforceSecurity, Standards, Workforce LOB LOB - - 2 2 LOB LOB - - 1 1 Lines of Business (LOB) Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Technology Technology Infrastructure Infrastructure Systems & Systems & Services Services Information Information Flows Flows Business Business Processes Processes Network Network Infrastructure InfrastructureNetwork Network Infrastructure Infrastructure Strategic Strategic Initiatives Initiatives LOB LOB - - 3 3 Security, Standards, WorkforceSecurity, Standards, Workforce LOB LOB - - 2 2 LOB LOB - - 1 1 Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Network Network Infrastructure Infrastructure Technology Technology Infrastructure Infrastructure Systems & Systems & Services Services Information Information Flows Flows Business Business Processes Processes Network Network Infrastructure InfrastructureNetwork Network Infrastructure Infrastructure Strategic Strategic Initiatives Initiatives LOB LOB - - 3 3 Security, Standards, WorkforceSecurity, Standards, Workforce LOB LOB - - 2 2 LOB LOB - - 1 1 Lines of Business (LOB) An Introduction to Enterprise Architecture – 3 rdEdition 59 be aggregated into a larger architecture picture that may cover several or all lines of business. This may be a preferable way to develop the first version of an enterprise’s EA as it allows them to undertake a more manageable amount of work at less initial cost (compared to attempting to do the EA for the entire enterprise all at once, without prior experience).

This is called a “segmented approach” to documenting the overall EA.

The segmented approach is also useful in large and/or decentralized enterprises where parts of the architecture may need to be developed and maintained by a number of different groups. Understanding Culture Understanding the culture of an enterprise is essential to developing realistic views of how strategic goals are established, how processes function, and how resources are used. Every enterprise is different in some way, as are the vertical, horizontal, and/or extended sub-enterprises. This is due to the culture of the enterprise being an amalgamation of the values, beliefs, habits, and preferences of all of the people throughout the enterprise or sub-enterprise.

Managing Change Changes within the enterprise will happen regardless of the presence of an EA program, however they will happen in a more disjointed or completely independent manner without EA. The effect of the EA program is to coordinate change such that it is much more driven by new strategies and business requirements, and less by new technologies. According to John Kotter, “To date, major change efforts have helped some organizations adapt significantly to shifting conditions, have improved the competitive standing of others, and have positioned a few for a far better future. But in too many situations the improvements have been disappointing and then carnage has been appalling, with wasted resources and burned-out, scared, or frustrated employees.” 9 People can be resistant to changes in their environment, whether it is at home or the workplace. If the EA program promotes changes in the enterprise, and if people are often resistant to any type of change when they do not have some level of control, then the EA program may be resisted by stakeholders unless something is done to increase their level of 9Kotter, J.P. 1996. Leading Change . Harvard Business School Press. Boston, MA. An Introduction to Enterprise Architecture – 3 rdEdition 60 control. Increasing their level of control helps to successfully manage change, and can be accomplished in several ways, including:

xInvolving stakeholders in the EA program’s establishment and management.

xRegularly and effectively communicating EA activities to stakeholders.

xAllowing for stakeholder input to EA planning and decision-making.

xManaging stakeholder expectations as to what the EA program can do.

Those who are affected by the EA program are called “EA stakeholders” and they are the ones most likely to resist the program and/or changes that are perceived to be the product of the EA program. Therefore, one of the things that the EA program manager needs to ensure is that there is stakeholder involvement in as many aspects of the EA program as is possible. This includes governance and oversight activities, the selection of an EA framework and methodology, participation in and reviews of documentation activities, and participation in the development of and updates to the EA Management Plan.

Another aspect of managing change within the EA program is regular and effective communication on program activities with all stakeholders. This includes formal documents such as an EA Program Communication Plan, the EA Management Plan, and notices regarding the periodic update of the current and future EA views. It also includes informal communication on an ongoing basis with all stakeholders to ensure that their participation and support is maintained.

The details of EA program governance are discussed in Chapter 4, but it is sufficient to say that it is important to provide “a place at the table” for as many stakeholders as can be accommodated. This increases buy-in for EA policy and decision-making, as well as the success of implementing changes called for in the future architecture.

Expectation management is yet another way to promote the success of the EA program and help stakeholders deal with change. Expectation Key Term: Change Management The process of setting expectations and involving stakeholders in how a process or activity will be changed, so that the stakeholders have some control over the change and therefore may be more accepting of the change. An Introduction to Enterprise Architecture – 3 rdEdition 61 management is about identifying realistic outputs and outcomes. It can be accomplished by collaboratively assessing the capability of the EA program to document current and future architectures, the timeframe and resources that will take, and the obstacles to acceptance by stakeholders. Expectation management is an ongoing aspect of the EA program.

Summary of Concepts This chapter described how enterprises are types of social organizations and discussed the importance of understanding the structure and culture of the enterprise that an EA is documenting. While it is also important to understand the enterprise’s processes and supporting technologies, it is the people of the enterprise who make plans and decisions about strategic direction, business activities, and resource utilization. The chapter also covered influences on the field of EA and presented two models of organizations and enterprises that can assist in the development of current and future EA views. Finally, the importance of managing change was discussed in that EA program activities may be resisted by stakeholders who feel a loss of input or control. Chapter 2 Questions and Exercises 1. Why is it important to understand the “people side” of EA?

2. Compare and contrast an organization and an enterprise.

3. What are some of the academic fields that influence the field of EA?

4. Describe the purpose of each level of the Parsons/Thompson Model.

5. How is the Organization Network Model different from the Parsons/Thompson Model of organizations?

6. Who are stakeholders in the EA program and associated activities and might they want to resist the EA program and associated activities?

7. What are four ways to manage change with stakeholders?

8. Select a large or mid-size enterprise from business or government and describe the following:

a. What structural and cultural aspects should be captured by EA?

b. Who are the potential stakeholders in an EA program?

c. What strategies for gaining stakeholder buy-in could be used?

d. Relate strategies for managing change to various stakeholders. An Introduction to Enterprise Architecture – 3 rdEdition 63 Case Study: Danforth Manufacturing Company Scene 2: Considering an EA Program Robert Danforth, the President and CEO of DMC, has called a follow-on meeting of the Executive Committee to review several recent capital investment requests and the suggestion to use an enterprise architecture approach to evaluate these requests and coordinate potential implementation projects. COO Kate Jarvis has requested a new custom Sales and Inventory Tracking System (SITS), and CFO Jim Gorman, has requested a new cost accounting system that is part of a commercial software package. Also invited to the meeting is CIO Sam Young, who joined the company one month ago, and who is giving a briefing on how enterprise architecture can help in this review.

“Good morning everyone” said Robert. “I’m eager to hear what you have to say about the architecture initiative. Sam, why don’t you lead off, and then let’s hear from Kate and Jim.” “Thank you Robert” said Sam as he handed out an 8-page document entitled DMC Enterprise Architecture Plan – Financial and Production Segments. “Kate, Jim, and I have spent a good deal of time together during the last two weeks and I believe that we have found several interesting things about their requirements and how an architecture approach can save us money and provide a more valuable long-term solution. We formed a working group to do the analysis and included an experienced enterprise architect and a senior systems analyst who I know from some past work, as well as several managers and staff from Kate and Jim’s groups, including two sales representatives from the field. The architect, Vince Albright, provided some background on what enterprise architecture is all about and how to document and evaluate current and future views of resources and requirements. With that, the group documented the current business services and associated IT resources that might be replaced or modified by Kate’s and Jim’s proposals. Then, the group documented Kate’s and Jim’s requirements from a business process perspective and looked for areas of commonality or duplication. Finally, Vince and the systems analyst, Lily Jefferson, led the group in a scenario planning exercise that developed two plausible business and technology solutions that meet both of their requirements in an integrated manner. An Introduction to Enterprise Architecture – 3 rdEdition 64 Either of these integrated solutions look to be less expensive to implement than it will be to do Jim’s and Kate’s systems independently.” Jim then spoke to the group. “I was really impressed with what the group did in only two weeks. Sam is right about looking at these types of requirements from an architecture perspective. What I realized is that my back office support systems can have more types of direct feeds of information from Kate’s line of business systems. In fact, the more we do this, the more timely and accurate the information across the company will be. The big thing here is that we eventually need to look at all of our business and technology requirements from a company-wide standpoint so that we can start to integrate and streamline our processes and capabilities.” Kate then spoke. “I agree with Jim that this was an eye-opener. There are flows of information between Jim’s financial group and my business managers, but these flows and the supporting systems have been developed independently with no overarching plan in mind. Sam and his associates showed me an architecture approach and implementation process that can be completed for our respective areas within the next two months and then be used to guide the implementation of a solution that I believe will meet my requirements and those that Jim has as well. This is a win-win that can lead to more of the same. Even the sales reps were getting into the game, and provided a couple of ideas about automatically pushing sales and inventory data to them that I had not considered. I am recommending that we go with this approach to refine and select a solution so that I don’t lose any more time on my competition.” Gerald leaned forward and looked at Sam. “Sam, I remember you saying that enterprise architecture links strategy, business, and technology. I am not hearing about strategy…. was that left out?” “Good question Gerald” responded Sam. “We did not go too much into company strategy because of the two-week timeframe for developing the initial architecture plan. However, that is an area that we will have to quickly address if the architecture plan for these two segments is approved for implementation. The way that I would pursue this is to identify DMC’s strategic goals that relate to Kate and Jim’s requirements, and ensure that the solutions align with the accomplishment of those goals. For example, I see that the company will be opening a new custom order line of business next year that builds on what we are doing on an ad-hoc basis right now. I would want to see if the solution for Kate and Jim’s requirements could also be able to support similar requirements for the custom order business.” An Introduction to Enterprise Architecture – 3 rdEdition 65 Robert then spoke. “I always want to talk about value and risk before approving any project. I am seeing value through cost savings and potential scalability of the solution. So, what is the cost of doing these segments and then the whole architecture? And, what are the risks and how do we mitigate those risks?” “The cost of doing a complete and detailed architecture for a mid-size company like DMC may be considerable” said Sam. “And I therefore recommend this type of segmented approach to developing a company- wide architecture, where we take one line of business at a time. In the plan we developed, you will see that the cost for the first two segments is $105,000, which covers analysis, modeling, documentation, and an EA tool. There is also an $11,600 cost for documenting and applying the general architecture methodology, framework, and standards, that is largely reused in subsequent segment efforts. The analysis of these two segments should take two to three weeks, and depending on which of the two solutions is selected, the supporting documentation will take another month. So this plan delays Jim and Kate approximately two months, but saves the company well over the $121,600 cost if a combined solution is adopted.” Sam continued. “By having a standardized architecture approach, we ensure alignment in each completed segment and can also use it to guide each new development and upgrade projects throughout the company, so that architecture alignment occurs much more quickly. This approach is also a risk mitigation strategy, in that we are spreading out the cost and effort over time, involving stakeholders in the development of each segment, and incorporating lessons learned from each segment effort. Two of the most important success factors for doing an enterprise architecture are the strong support of executive leadership, and buy-in from stakeholders. If you see value in having an architecture, and have a say in how it affects you, then the architecture can become a powerful planning and decision-making tool for DMC.” Robert thought for a moment about what Sam had said and then addressed the group. “I am inclined to approve the plan to develop a standardized architecture approach and these first two segments, are there any objections?” There were no other comments. “Ok Sam, let’s proceed with the plan and get together every two weeks for a progress report.” An Introduction to Enterprise Architecture – 3 rdEdition 67 Chapter 3 The Value and Risk of Creating an Enterprise Architecture Chapter Overview Chapter 3 discusses the value and risks associated with creating an enterprise-wide architecture. The main concepts of this chapter are that EA represents a different way of looking at resources across the enterprise, and that the significant cost of creating an EA must be justified in terms of the value that it will bring to users of EA products in their planning and decision-making activities.

Learning Objectives ¾Understand the potential value of the EA.

¾Understand the risks associated with implementing an EA.

¾Learn an approach for measuring the costs and benefits of an EA program.

¾Understand how EA helps integrate strategy, business, and technology. Introduction There is both value and risk associated with the establishment of an EA program in an enterprise. On the value side, EA has the unique capability to bring together views of strategy, business, and technology that allow an enterprise to see itself in current and future operating states. EA also supports the modeling of different future operating scenarios, which may help the enterprise survive (or thrive) as it responds to changes in the internal and external operating environment, some of which can be unexpected. Additionally, an EA program establishes an integrated set of IT resource planning, decision-making, and implementation processes that can better identify and resolve performance gaps across the enterprise. An Introduction to Enterprise Architecture – 3 rdEdition 68 On the risk side, creating an EA for an entire enterprise can be time- consuming, costly, and disruptive to business services. Also, developing detailed EA documentation that covers strategy, business, and technology within each area of the enterprise can be time consuming and costly. Hiring and/or training architects and supporting analysts is one element of the cost. Another cost element is the time it takes line of business managers and support staff away from their normal work. Finally, the cost of EA documentation tools and on-line repositories has to be factored in as well. Further, there is the risk that the EA will not be used by stakeholders if they do not buy-in to the concept of EA or its perceived value.

On the value side, EA is unique in its ability to promote enterprise-wide thinking about resource utilization. EA replaces the systems-level approaches to IT resource development that have characterized the last several decades, and has left many enterprises with stovepipe and/or duplicative IT resources. EA promotes the development of more efficient enterprise-wide common operating environments for business and technology, within which more capable and flexible business services and systems can be hosted. This in turn makes an enterprise more agile and able to respond to internal and external drivers of change, which promotes greater levels of competitiveness in the marketplace. The benefits should outweigh the costs of doing an EA, or the program should not be established. In the Case Study example, if an EA program helps DMC’s executives find a combined solution to two sets of business and technology requirements, then a significant amount of money can be saved. Multiply this by several of these situations each year, and the EA program may very well pay for itself. Further, EA helps to identify existing duplication in functional capability, which can generate additional savings. Finally, EA documentation helps to identify current and future performance gaps that may not be otherwise realized, which enables the enterprise to be more proactive and cost-efficient in addressing solutions. Home Architecture Analogy: A set of comprehensive blueprints for building a home takes an architect a fair amount of time and money to create. Without them though, any construction that occurs is an uncoordinated activity, and the home that results may not function properly. An Introduction to Enterprise Architecture – 3 rdEdition 69 Discussion Value The value of EA is that it enhances resource-planning capabilities and supports better decision-making. This is accomplished through communication improvements in respect to current and future resources.

Ideas are conveyed more rapidly while differences in interpretations and misunderstandings are reduced. The overall value of EA will vary with the size and complexity of the enterprise, the type and number of IT-related performance gaps, duplication within current IT resources, and stakeholder acceptance. For those larger, less centralized enterprises that are regional or global in nature, EA can be an effective governance process for IT resources. For smaller more centralized enterprises, EA can help to ensure that the organization remains able to align business requirements with technology solutions, and enhance inventory, security, and configuration management activities. Improved Planning EA enhances both top-down and bottom-up approaches to planning. Top- down planning begins with considerations for strategy and business, which are enhanced by the holistic perspectives of the enterprise that EA provides. Bottom-up planning is also enhanced, as EA coordinates what would otherwise be disparate and separate program-level planning activities. EA also enhances strategic planning as it helps to bring together multiple perspectives of business and technology at various levels of the enterprise. Finally, EA supports program and project management by providing a baseline of reference documentation for business alignment, standards, and configuration management.

Decision-Making EA improves decision-making by providing comprehensive views of current capabilities and resources, as well as a set of plausible future operating scenarios that reveal needed changes in processes and resources (see Chapter 8 for additional details on future scenarios). By having an on- line EA repository of information that is updated at regular intervals, An Introduction to Enterprise Architecture – 3 rdEdition 70 decision-makers have real-time access to higher-quality information at various levels of detail.

In that the EA program links to other areas of resource governance (e.g., capital planning, project management, and security), decision-makers can obtain coordinated information on operations, support, and development activities. Chapters 10 and 11 provide additional details on the relationship between EA, capital planning, project management, and security.

Communications EA improves communication throughout the enterprise by providing a regularly updated baseline of integrated information on strategy, business, and technology. Also, the EA program and implementation methodology bring standardized approaches and terminologies for the development and management of enterprise resources. This standard EA language and methodology is especially helpful in large, complex enterprises that are geographically dispersed, and which may have multiple social and work cultures that have promoted different ways of doing things. EA should not stifle the creativity that cultural diversity can bring, but should augment and enhance that creativity by improving the alignment of business and technology to the strategic goals and initiatives of the enterprise.

The old saying is that “a picture is worth a thousand words.” Having an on-line repository of EA information is like having a 24x7 gallery of electronic documents and drawings that can be useful in a variety of activities throughout the enterprise. It is tremendously valuable if the members of an enterprise can electronically call-up the same set of EA reference materials at financial planning meetings, research and development seminars, sales and marketing reviews, and daily operations and support activities. With an updated repository of EA materials available, meetings can convey greater amounts of information in shorter periods of time, achieving higher levels of understanding based on a common set of EA terms and information.

Managing Risk Risk is related to uncertainty, and in applied form is the potential source(s) for the failure or underperformance of a program or project. The management of risk involves lowering or eliminating the uncertainty that An Introduction to Enterprise Architecture – 3 rdEdition 71 desired outcomes will not be realized. There are several types of risk that relate to the implementation and maintenance of an EA program, including:

Financial . Implementing an EA involves establishing current and future views of enterprise resources, an EA Management Plan, and updates to this information at regular intervals. Like any implementation project, establishing the initial set of EA information will require start-up funding that is more than what will be required for the periodic updates. Even after the EA is established, cuts in an EA maintenance budget can severely affect the program, to the point of making the EA information eventually become of little or no use if it becomes too out of date.

Lack of Acceptance . EA represents a new way of looking at enterprise resources by providing an integrated view of strategy, business, and technology that supports the consolidation or re-engineered of these resources to produce additional value. Former approaches to program management that supported systems level planning will be replaced with EA level planning that is promoted through the EA program. This will most likely create some tensions between program level stakeholders, EA stakeholders, and other affected groups.

Loss of Key Personnel . EA is an emerging area of professional practice that requires architects, analysts, developers, and programmers. Each of these skill sets is important to the program and the loss of members of the EA team with those skills can create delays in program implementation, as well as effect implementation costs.

Schedule Delays . As with all implementation projects, the documentation of current and future EA views as well as the creation of the initial EA Management Plan is approached as a project that has milestones and a specific schedule for completion. Delays to the schedule can come from many sources and depending on the point at which a delay occurs during EA implementation, and how long the delay is, the effect can go from being negligible to being catastrophic for the EA program.

Documentation Tools . One of the greatest challenges for a Chief Architect is to develop current and future views of the EA that are rich in detail, easy to access, and which can support modeling and decision- making types of queries. The capabilities of EA tools and supporting An Introduction to Enterprise Architecture – 3 rdEdition 72 applications at present are such that intuitive and informative “management views” of EA information are difficult to produce with these tools. Further, because more than one software application is normally required in an EA program, tool integration is an issue that must be dealt with. As new commercial tools are introduced a Chief Architect has to consider what the effect will be on overall documentation if that product does not integrate with other tools. Mitigating Risk Risk mitigation plans and activities reduce the likelihood that sources of risk will emerge and negatively impact a program such as EA. Actions that mitigate risk (lower uncertainty) include strengthening executive support for the EA program, solidifying budgets, not being the first adopter of EA tools and documentation techniques, ensuring there are trained back-ups on the EA team, and using a detailed EA implementation methodology to guide the overall program. Additionally, basic program management skills address potential problems of key personnel turnover, cost and schedule overruns, performance issues, and stakeholder acceptance. Overcoming issues related to technology compatibility among EA products is achieved through the use of commercial tools that are based on open standards, and which are mature and have significant market share.

Risk identification and mitigation is not a one-time activity, it is an ongoing management review item that will assist in making an EA program successful.

Quantifying EA Program Value How to translate value to the bottom line is one of the biggest questions executives and Line of Business (LOB) managers have about EA programs. Building a business case that includes an alternatives analysis, cost-benefit analysis, and return on investment calculation is the primary measure for evaluating the contribution to profitability and/or mission success (see the example Business Case in Appendix A). Many aspects of EA value can be quantified, including the following areas:

Shortening Planning Cycles . EA can help shorten planning cycles by providing a robust repository of on-line information regarding current and future processes and resources. While EA does not replace strategic An Introduction to Enterprise Architecture – 3 rdEdition 73 planning or business process improvement activities, it does enhance them through contribution of useful information that that would otherwise be gathered separately.

More Effective Planning Meetings . EA information allows for the presentation of a common baseline of planning and reference information. It reduces ambiguity and increases levels of common understanding.

Shorter Decision-Making Cycles . The time it takes to gather and cross- walk strategy, business, and technology information is greatly reduced by having a repository of EA information that was developed through the use of a logical framework and archiving method. Decision-making processes can be streamlined to reflect the availability of this new resource of integrated baseline information.

Improved Reference Information . By using an EA documentation framework and implementation methodology, information on processes and resources is gathered in a standardized method using the same tools and applications. Additionally, the method for storing the information is coordinated through the use of the on-line EA repository, which requires the use of standardized data and document formats. This in turn creates the ability to perform queries for information across otherwise disparate activities and resources. It also supports a more robust data mining and business analysis capability.

Reduction of Duplicative Resources . One of the greatest contributions an EA makes to an enterprise is aiding the visualization of the value that current resources provide, where those value areas overlap, and where performance gaps exist. For example, duplicative data represents low-hanging fruit ready for elimination through the implementation of the future architecture. Subsequent improvements might then focus on the introduction of new technologies and improvements in efficiency.

Reduced Re-work . By approaching the planning and execution of new resources in a holistic manner, potential re-work that might have been created through individual program level initiatives (containing duplicative and/or conflicting capabilities) can be avoided. Also, re- work is reduced through the use of a step-by-step EA methodology and framework (see Chapters 4 and 5), that call for standard approaches to An Introduction to Enterprise Architecture – 3 rdEdition 74 documentation that are based on mature modeling and analysis techniques. Improved Resource Integration and Performance . EA promotes integration through the planning and utilization of resources on an enterprise-wide basis. EA also helps to compare current and future requirements for business and technology, in order to identify performance gaps and solutions. This result is contrasted with stovepipe program-level inputs to provide incremental improvements within individual LOBs.

Fewer People in a Process . EA supports business process reengineering (BPR) and business process improvement (BPI) activities by encouraging planning in the context of both enterprise-wide crosscutting requirements and particular LOB requirements. Quantifying this includes the elimination of parts of a process that are repetitive. Also, streamlined processes that use resources more efficiently can equate to position requirement reductions and payroll savings.

Improved Communication . EA helps to promote a common language and central approach that can reduce misunderstandings of resource requirements and potential solutions. This can reduce re-work. Whole processes may require repetition due to misunderstandings of different interpretations of requirements and/or solutions.

Reduction in Cycle Time . EA can help an enterprise to reduce the time it takes to plan, develop, implement, and retire resources within its business and technology operating environment. By using an EA methodology and framework (see Chapters 4 and 5), each resource is evaluated from the same holistic strategy, business and technology viewpoint, and is documented using the same set of EA tools and techniques. Further, EA compliments capital planning and program management reviews of completed projects (see Chapters 10 and 11) so that the ‘lessons learned’ can be applied to subsequent efforts. In this way, the enterprise can improve efficiency and reduce the amount of time it takes to implement similar resources. For example, using an integrated enterprise architecture/capital planning/project management approach to selecting, controlling, and evaluating investments in web sites, the enterprise will be more effective and efficient in implementing each subsequent web site, and can avoid creating duplicative capabilities. An Introduction to Enterprise Architecture – 3 rdEdition 75 Quantifying EA Program Costs The cost of EA should be approached from a program lifecycle view that centers on phases for implementation, maintenance, and refreshment. One way to estimate EA program costs is to look at each area of the EA implementation methodology (see Chapter 4), and identify the direct and indirect costs to accomplish each of the steps. In general, this would include the following:

xEA program administration and other enterprise administrative tie-ins xSalary/benefits for a Chief Architect and EA team staff xMeetings, facilities, materials, and support for stakeholder planning sessions xComputers, applications, and web developers to establish the EA repository xInterviews and materials to document EA current views xFuture scenario planning sessions with stakeholders xInterviews and materials to document EA future views xDevelopment and documentation of the EA Management Plan xPurchase, use, and refreshment of EA modeling applications and computers xRegular (e.g., annual) updates to EA documentation and the online repository The cost of establishing an initial version of the EA will be more than the cost of updating and maintaining it, due to the direct and indirect costs associated with establishing new EA processes and capabilities, and gaining stakeholder support. The full lifecycle cost of the EA program should be established and presented to the EA program sponsor, so that there is a clear understanding of the one-time costs for implementation of the EA and the ongoing costs for EA maintenance and refreshment activities. As with any program, this budget picture should be baselined relative to the EA program activities that are approved by the sponsor, so that any approved changes to the scope of those EA activities are accompanied by a change to the budget. If this is not done, the EA program may evolve to a position of being responsible for too much relative to the resources it has available. An Introduction to Enterprise Architecture – 3 rdEdition 76 In that EA is an advanced analytic type of activity, most of the cost of developing and maintaining EA documentation will be the cost of labor for trained architects. The second largest cost area will be the supporting technology (hardware, software, web applications, databases, EA tools, etc.). The other major cost area will be the facility costs for the EA team’s work area and meetings with stakeholders. Those who do EA (in total or in part) for a living work under a variety of job titles, including Chief Architect, Solution Architect, Systems Architect, Data Architect, Network Architect, Security Architect, IT Consultant, Management Consultant, and a number of related analyst titles.

Furthermore, there tends to be a set of classifications for senior, mid-level, and junior positions for many of these jobs. From an informal survey of EA salaries in 2012 conducted by the author, a senior enterprise architect’s position can command over $100,000 per year. 10 Mid-level positions (3-5 years of experience) can earn in the range of $60,000 to $80,000.00 per year, and the junior positions for beginning architects can earn in the range of $40,000 to $50,000 per year. As expensive as this seems, the cost to outsource these positions is even greater. The industry average for one work year is about 2,060 hours (this is Monday-Friday 8-hour days and accounts for time away for holidays and personal time off). Some federal government contract labor rates for the outsourcing of a Chief Architect and/or Senior Consultant position are over $200 per hour, which translates to over $412,000 per year. The rate for mid-level EA professionals can range from $125 to $175 per hour, so at the upper end of this range the outsourcing of one of these positions can cost over $360,050. The rate for junior EA professionals can range from $55 to $85 per hour, and at the upper end of this range the cost of outsourcing can be over $175,100. This significant level of cost for EA labor has caused some enterprises to pause in considering the implementation of an EA program. However, when the potential savings generated by the EA program are factored in, there can be a very high return on investment, especially in enterprises where EA can reduce duplicative capabilities and help identify common solutions to otherwise separate requirements. With costs for information systems in the many millions of dollars, the consolidation of even a few of 10 The labor cost estimates are based on commercial rates used in federal sector information technology support service and consulting contracts, as surveyed by the author in 2012. The labor rates cover salary and benefits, but do not cover facilities support, desk, computer, phone, and administrative costs. An Introduction to Enterprise Architecture – 3 rdEdition 77 those systems can make the EA program more than pay for itself, as well as enable the enterprise to re-direct the funding from duplicative resources to other business requirements.

Linking Strategy, Business, and Technology For EA to support an enterprise holistically, it must link strategy, business and technology. EA is most effective when it simultaneously supports top- down executive planning and decision-making across the enterprise and bottom-up management planning and decision-making within each LOB. In this way, EA helps to ensure that strategy drives business and technology planning. From a business perspective EA provides the context and purpose of business activities by ensuring technology is implemented only after business requirements are identified. From a technology perspective, EA provides the strategy and business context for resource planning. This can be critical when working with multiple organizations to create common resources (i.e., supply chains) or in merging / acquiring organizations into one enterprise.

Linking EA and Strategy The EA framework and methodology organizes EA documentation in a way that allows strategy to influence business and technology planning and decision-making. This is important especially in the documentation of future EA views. By first identifying what changes are anticipated in strategic goals and initiatives, subsequent documentation of business activities and technology resources can be completed in such a way as to promote alignment, efficiency, and effectiveness. Documenting strategy involves the identification of goals, initiatives, and outcome measures.

Strategic Goals . These are the primary objectives of the enterprise.

Strategic goals typically require several years to accomplish. Changes in strategic goals are made in response in internal and external business and technology drivers and/or changes in laws and regulations.

Strategic Initiatives . These are the business and technology activities, programs, and projects that enable accomplishment of strategic goals, such that they can effect the fundamental direction of the enterprise.

Strategic Measures . These are outcome measures that identify when a strategic initiative has successfully met a strategic goal. Outcome goals define when an enterprise is accomplishing its mission… when it ‘wins.’ An Introduction to Enterprise Architecture – 3 rdEdition 78 Linking EA and Business Planning As is reflected in the design of the EA framework, strategy creates business requirements and technology supports solutions for meeting those requirements. EA documents three primary issues at the business level:

Supporting Strategic Goals . Touch points between strategic initiatives and business activities need to be clearly documented. Not all business activities are strategic, and it is important to distinguish in the EA documentation between those that directly link to strategic initiatives and those that provide general support functions for the enterprise.

Documentation of Business Activities . Documenting the creation and delivery of business products and services is important in supporting Business Process Improvement (BPI) and Business Process Reengineering (BPR) projects, and in documenting business activities to show inputs, outputs, outcomes, and other elements of influence regarding each business process. It’s also important to identify how business processes are linked to one another.

Identifying Supporting Technologies . Analyzing business requirements and activities can reveal critical supporting technologies (e.g. marketing activities require sales trend analysis data, and a manufacturing process requires various types of resources including raw materials, facilities, labor, computers, data, and/or robotics). EA helps to identify and document these supporting technologies. Linking EA and Technology Planning Technology is a type of resource that enables information and other resource flows to support the creation and delivery of business products and services, which in turn enables the achievement of strategic goals. It is important that technology not drive business and strategy planning, especially in resource-constrained enterprises, where the expense of duplicative non-strategic technologies cannot be afforded. Bottom-up planning (e.g. where technology is the catalyst for change) is a viable use of EA; however it’s not the normal process for resource implementation. It’s more important for the enterprise to understand its primary directions and priorities, plan necessary business activities, and then identify the supporting resources, including IT. An Introduction to Enterprise Architecture – 3 rdEdition 79 Summary of Concepts This chapter provided a detailed discussion of the value and risk of establishing an EA program. A clear articulation of the business case for EA is needed to obtain executive sponsorship and resources for EA program implementation and maintenance. Quantifying the areas of value that the EA program will contribute is important, and those include improved communication, planning, and decision-making. A total lifecycle approach to estimating costs is used to differentiate the one-time direct and indirect costs associated with program start-up and initial EA documentation from the ongoing costs of EA program management and documentation updates. Comparisons were made in the area of EA labor costs between in-house salaries and the expense of paying for external EA consulting support. In concluding the discussion of EA value, the linkage between EA, strategy, business, and technology was shown. Chapter 3 Questions and Exercises 1. What are some of the areas of value that are generated by an EA program?

2. What are some of the risks associated with implementing an EA program?

3. How does EA help an enterprise to view its strategic direction/goals?

4. How does EA help an enterprise to view its business services?

5. How does EA help an enterprise to view technology resources?

6. What is meant by managing risk? Provide two methods to manage risk.

7. How does EA link to strategy, business, and technology?

8. Select a real-world medium- or large-sized business and identify the following:

a. Areas of potential value that an EA program would provide.

b. Areas of potential risk to the implementation and acceptance of an EA program, and strategies to mitigate those risks.

c. How EA can help develop views of this business’ strategic direction and goals; business services; and supporting resources. An Introduction to Enterprise Architecture – 3 rdEdition 81 Section II Developing an Enterprise Architecture Section II defines and describes how to accomplish and implement an Enterprise Architecture. It covers what an EA framework is, presents a step-by-step methodology to implement an EA, discusses how to document current and future views of the EA, and describes how to articulate the EA in an “EA Management Plan,” which also serves as a transition and sequencing plan from the current to the future architecture. Foundational elements of an EA program are the documentation framework and the implementation methodology. The EA documentation framework defines what the EA program will document, and the EA implementation methodology defines how that documentation will be gathered and used. By documenting current and future views, along with an EA Management Plan, the EA improves planning agility, helps to prioritize resource utilization, and helps to lower the risk of project failures. Section II is organized as follows: Case Study Scene 3: The Importance of a Methodology Chapter 4 The Implementation Methodology Chapter 5The Documentation Framework Chapter 6 Components and Artifacts Case Study Scene 4: Developing Current and Future EA Views Chapter 7 Developing Current Architecture Views Chapter 8 Developing Future Architecture Views Chapter 9 Developing an EA Management Plan Case Study (Scene 3) - The Importance of a Methodology The Case Study continues the scenario at Danforth Manufacturing Company that was presented in Section I. Now that the CEO has decided to proceed with an EA program, this part of the Case Study will focus on how the EA program and implementation methodology will be implemented. The CIO has hired a Chief Architect, who describes the need for and purpose of an EA methodology. An Introduction to Enterprise Architecture – 3 rdEdition 82 Chapter 4 - The Implementation Methodology Chapter 4 describes the EA implementation methodology, which is the detailed procedure for doing an EA. The EA³ ‘Cube’ is used as the example framework for discussing an implementation methodology. The value of adopting an EA methodology is discussed in terms of providing a detailed, comprehensive approach to EA governance and documentation, reducing the risk of producing an EA that’s not useful to stakeholders. Chapter 5 - The Documentation Framework Chapter 5 describes the purpose of an EA documentation framework and how it establishes the scope of the EA. Several existing EA frameworks are presented as examples that have different areas of focus and relationships for EA documentation. Also, a the EA³ Framework is presented in detail, as it becomes the basis for further discussion about how an EA framework can link strategy, business, and technology together to help improve resource planning and decision-making throughout the enterprise. Chapter 6 - EA Components and Artifacts Chapter 6 describes EA components and related artifacts. EA components are those plug-and-play ‘changeable’ items that provide capabilities at each level of the framework. Examples include strategic goals and measures, business services, information objects, software applications, and network hardware. EA artifacts are the descriptions of the EA components. Types of EA artifacts include text documents, manuals, guides, technical reference material, graphics, drawings, pictures, raw data, information, presentations, spreadsheets, and videos. Case Study (Scene 4) - Developing Current / Future EA Views This part of the Case Study illustrates how current and future EA views will be developed. The context is that of evaluating several proposed IT systems and looking for common requirements and combined solutions. Following this evaluation, two segments of the DMC architecture will be developed that cover several lines of business. Chapter 7 - Developing Current Architecture Views Chapter 7 covers the development of artifacts that reflect current views of EA components, within the context of the EA³ framework and the An Introduction to Enterprise Architecture – 3 rdEdition 83 related implementation methodology. Current EA views are important to an enterprise in that they establish and/or verify what resources (including IT) are being used in the lines of business to support the achievement of strategic goals. The current EA views become a reference baseline much like an inventory that then supports planning and decision-making regarding the future architecture. Chapter 8 - Developing Future Architecture Views Chapter 8 covers the development of future views of EA components, again within the context of the EA³ framework and the related documentation methodology. The future views of the EA are important to the enterprise as they encompass one or more possible future states, which represent strategies for successful performance in response to internal and external influences. The future views of the EA are developed in ways that allow them to be directly related to the EA’s current views at each level of the framework, so that planned changes are evident, and various types of changes can be modeled. The chapter also provides a description of a method for developing future views that is called “scenario planning.” Future scenarios can help the enterprise to envision one or more potential future business/technology operating states in a way that helps to identify areas of change that will be important to the successful attainment of strategic goals. Chapter 9 - Developing an EA Management Plan Chapter 9 discusses the development of an EA Management Plan, which is the document that describes how an enterprise will manage the transition of its current processes and resources to those which will be needed in the future. This transition from the current EA to the future EA is an ongoing activity, as new resources that are identified in the future EA are implemented and therefore become part of the current EA. The purpose of configuration management and version control are also discussed, along with the need to sequence implementation projects. An Introduction to Enterprise Architecture – 3 rdEdition 85 Case Study: Danforth Manufacturing Company Scene 3: The Importance of a Methodology At a meeting of the Executive Committee several weeks before, Robert Danforth, the President and CEO of Danforth Manufacturing Company (DMC), had approved the request of CIO Sam Young to use an EA approach to evaluate two sets of IT system requirements that COO Kate Jarvis and CFO Jim Gorman had brought to the executive leadership group. Sam is now moving forward on a plan and a business case to develop an architecture for several lines of business related to Kate and Jim’s requirements. These “segments” of the DMC enterprise architecture will help Kate and Jim to evaluate their recent requests for new information systems to see if there were overlapping requirements. To properly provide leadership and resources for the project, Sam worked with DMC’s Executive Committee during the past week to obtain approval to establish an EA Program that would be led by a qualified Chief Architect. The newly appointed Chief Architect reports to Sam. He selected Vince Albright, whom he had known from earlier work. Also, Sam was given a budget for this initial EA project within the EA Program, and a working area that can accommodate several people who will be hired and/or “borrowed” from other business areas for the period of the project.

This initial architecture effort is the test case for considering the development of a company-wide EA for DMC. Scene 3 describes the first meeting of the EA Working Group, which includes Sam, Kate, Jim, Vince, several line of business managers, Lily Jefferson a senior systems analyst at DMC, and several end users of DMC’s current sales and finance systems.

“Hello, and welcome to the Enterprise Architecture Working Group” said Sam. We are going to develop two segments of the company’s enterprise architecture, which cover several lines of business. These are lines of business that need more IT support. Before we can do that, we need to have a detailed methodology that will guide our efforts and reduce the risk that we will not be successful in developing the EA segments. I have handed out a one-page outline of an EA methodology that I used with another enterprise and it helped tremendously. The four phases of the An Introduction to Enterprise Architecture – 3 rdEdition 86 methodology cover program establishment, methodology development, documentation activities, and maintenance. During the past several weeks, I have worked with the Executive Committee to formally establish the EA Program and bring Vince Albright on board as our new Chief Architect. Vince, congratulations and welcome. Vince was with me during the prior project that we used this EA methodology, so I am going to turn it over to him to tell us about that and guide the EA Working Group through a review to see if we want to make any changes.” “Thank you Sam” said Vince. “It is a pleasure to be at DMC and to be working with you again on an EA program, especially one that promises to bring great value to this enterprise. The first thing I would like you to know is that as Chief Architect, I will be very inclusive regarding stakeholder involvement in the development of the EA program and all EA segments. This is because I have seen that down-road acceptance can only be gained through the ongoing participation of those who will be using the EA information, and those who are impacted by the EA program. Second, I’d like to tell you briefly about my very first EA project, one where we did not use a methodology. This project started ok, but lost its way as the segments were being developed. Why? Because the EA Team did not have anything to use with participants to keep things standardized, or maintain stakeholder interest with, and we ended up with segments that did not integrate into an overall EA… so the project did not produce the amount of value that was expected, and the EA information was rarely used.” “Since then, I’ve learned to let the business requirements drive the architecture, and to develop segments collaboratively with those who will use them, so they can ensure that the types of EA information are there when they need it…. not just the IT information we think they will need.” Vince continued. “What you received several weeks ago was the DMC Enterprise Architecture Plan – Financial and Production Segmentsreport that Sam, Lily, and I developed with Jim, Kate, and several members of this EA Working Group. That report lays out the business case for this EA project, which is to evaluate the business and technology requirements for two proposed systems. To do that type of analysis, we need several segments of an overall DMC enterprise architecture, to provide reference views of the current and planned process and resources involving DMC’s strategic goals, business activities, and technology capabilities. To develop these segments for the finance and production lines of business, we need a methodology. As Sam said, this methodology will help keep us on track and reduce the risk of project failure.” An Introduction to Enterprise Architecture – 3 rdEdition 87 Jim asked, “What do I need to do to help with this methodology?” Sam answered, “Look at the outline and tell us what is not there, perhaps there is something more that you as a business executive might need to have as part of our EA Program or documentation process. Also, when we get to the modeling steps, we need to know from you, Kate, and your respective staff what kind of planning and decision-making information you need in your lines of business. We also need to know the formats you would require. From that, the EA Working Group can refine the requirements that we will use to select modeling techniques and tools. Once we get the current views established for your and Kate’s EA segments, we can develop some future operating scenarios and identify planning assumptions. This is the baseline of EA information that we can finally use to evaluate your proposals for separate system. We’ll see if they fit into the future architecture as proposed, or we will be able to determine if there is a better way to meet your requirements.” Vince spoke up. “Sam talked about a lot of interdependent parts there, which hopefully reinforces our comments about the value of having a methodology to guide EA activities. Also, Sam alluded to different types of EA information that we will be gathering and you may be wondering what that is and how it is organized? The short answer is that we will use an EA framework. One of the foundational elements of any EA program is the selection of an EA framework that defines the scope of the overall architecture and its sub-segments. Further, the graphic depiction of the EA framework provides a visual image of the areas of the EA and how they relate. In our project, we will review several frameworks during this meeting that are in use and select the one that best serves our needs. So, let’s get on with the review of the EA implementation methodology.” The EA Working Group meeting finished its review of the EA methodology and selected an EA documentation framework. Vince called for a meeting later that week to discuss how the methodology and framework would be used to document the current and future views of the two EA segments that the project is responsible for. Sam will brief the selected methodology and framework to the Executive Committee at the next bi-monthly status meeting. The CEO had requested these meetings to stay in touch with the EA project. An Introduction to Enterprise Architecture – 3 rdEdition 89 Chapter 4 The Implementation Methodology Chapter Overview This chapter describes the EA implementationmethodology(EA methodology), which is a detailed procedure for establishing, maintaining and using an EAframeworkand documentation approach. The EA methodology is the first step in coordinating the EA documentation approach. The value of adopting an EA methodology is that it reduces the risk of creating an ineffective EA program and/or inaccurate EA documentation.

Learning Objectives ¾Understand the purpose of an EA methodology within the EA program.

¾Understand the steps of an example EA methodology.

¾Understand the relationship between an EA framework and EA methodology. Introduction An EA methodology is a detailed, step-by-step description of how the EA program is to be established and run, and how the documentation of the Key Term: EA Methodology The EA methodology defines how the EA will be implemented and how documentation will be developed, archived, and used; including the selection of a framework, modeling tools, and on-line repository. Key Term: EA Framework The EA framework is a structure for organizing information that defines the scope of the architecture; what the EA program will document and the relationship of various areas of the architecture. An Introduction to Enterprise Architecture – 3 rdEdition 90 EA is to be developed, maintained, and used. The EA methodology presented in this book is flexible enough to support the use of many of the popular EA frameworks, tools, and repositories. Figure 4-1 provides an overview of the six basic elements of EA documentation that were presented in Chapter 1. This Chapter builds on the basic elements by establishing a four phase/twenty-step methodology to establish an EA program and implement the six EA documentation elements.

Figure 4-1: The Basic Elements of EA Documentation Discussion The establishment of an EA program has many facets and one of the keys to success is to use a detailed documentation methodology to get the program started, and then to guide the EA documentation effort. The EA methodology described in this book is generalized so it can be used in a wide variety of public and private sector enterprises, and can support many types of EA frameworks, tools, and repositories. Depending on the type of enterprise, some parts of the EA methodology may need to be changed. Home Architecture Analogy: An EA methodology is like the standard approach that architects are taught for designing and constructing a home. There are things that must be done in a certain way and order for the design to be successful and for the home to be properly constructed. Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Networks & Infrastructure Systems & Applications Data & Information Products & Services Network InfrastructureNetwork Infrastructure Goals & Initiatives Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Optimized Networks and Infrastructure Integrated Systems and Applications Enhanced Data and Information Flows Improved Business Products and Services Network InfrastructureNetwork Infrastructure Updated Strategic Goals & Initiatives CURRENT CURRENT ARCHITECTURE ARCHITECTUREFUTURE FUTURE ARCHITECTURE ARCHITECTURE Lines of Business Highest Level & View Lowest Level & View C O M P O N E N T S Architecture Management & Transition Plan EA Framework 2 Lines of Business C O M P O N E N T S Multi-Level Threads (Security/Standards/Workforce) 1 3 4 5 6 Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Networks & Infrastructure Systems & Applications Data & Information Products & Services Network InfrastructureNetwork Infrastructure Goals & Initiatives Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Networks & Infrastructure Systems & Applications Data & Information Products & Services Network InfrastructureNetwork Infrastructure Goals & Initiatives Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Optimized Networks and Infrastructure Integrated Systems and Applications Enhanced Data and Information Flows Improved Business Products and Services Network InfrastructureNetwork Infrastructure Updated Strategic Goals & Initiatives Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Optimized Networks and Infrastructure Integrated Systems and Applications Enhanced Data and Information Flows Improved Business Products and Services Network InfrastructureNetwork Infrastructure Updated Strategic Goals & Initiatives CURRENT CURRENT ARCHITECTURE ARCHITECTUREFUTURE FUTURE ARCHITECTURE ARCHITECTURE Lines of Business Highest Level & View Lowest Level & View C O M P O N E N T S Architecture Management & Transition Plan EA Framework 2 Lines of Business C O M P O N E N T S Multi-Level Threads (Security/Standards/Workforce) 1 3 4 5 6 An Introduction to Enterprise Architecture – 3 rdEdition 91 It is important to develop an EA methodology as one of the first steps in establishing the EA program, because it forces the enterprise to ‘think through’ the following important considerations:

xWhich areas of the enterprise the EA will cover (scope) xThe approach to EA governance (e.g., centralized or decentralized) xThe types of EA documentation (known as artifacts) that will be needed to support business and technology resource planning and decision-making xThe EA documentation framework that best supports the needs of the enterprise xThe methods and techniques for gathering or developing EA documentation xThe software modeling tools, web applications, and databases that will be needed to automate documentation techniques and enable future scenario modeling xHow EA users will access and share EA documentation (e.g. an EA repository) xHow often EA documentation will be updated The 20-step process presented on the following pages is an example EA implementation methodology that contains all of the general steps that would support the creation of a new, comprehensive EA program. It should be noted that the revitalization of an existing EA program will involve additional steps that will vary with each situation. Revitalization could focus on the selection of a different EA framework and implementation methodology, and/or the identification of new vertical and horizontal partitions of the enterprise that is being documented (segments and crosscuts).

Enterprise Architecture Implementation Methodology Phase I: EA Program Establishment Step 1: Establish the EA Management Program and identify a Chief Architect.

Step 2: Establish an EA implementation methodology. An Introduction to Enterprise Architecture – 3 rdEdition 92 Step 3: Establish EA governance and links to other management processes.

Step 4: Develop an EA Communication Plan to gain stakeholder buy-in.

Phase II: EA Framework and Tool Selection Step 5: Select an EA documentation framework.

Step 6: Identify EA Lines of Business/Crosscuts and the order of their documentation.

Step 7: Identify the EA components to be documented framework-wide.

Step 8: Select documentation methods appropriate for the framework. Step 9: Select software applications/tools to support automated EA documentation.

Step 10: Select and establish an on-line EA repository for documentation and analysis.

Phase III: Documentation of the EA Step 11: Evaluate existing business and technology documentation for use in the EA.

Step 12: Document current views of existing EA components in all framework areas (levels/threads). Store artifacts in the on-line repository.

Step 13: Develop several future business/technology operating scenarios.

Step 14: Identify future planning assumptions for each future scenario.

Step 15: Use the scenarios and other program/staff input to drive the documentation of future EA components in all framework areas. Store artifacts in the on-line EA repository.

Step 16: Develop an EA Management Plan to sequence planned changes in the EA. Phase IV: Use and Maintain the EA Step 17: Use EA information to support planning and decision-making. An Introduction to Enterprise Architecture – 3 rdEdition 93 Step 18: Regularly update current and future views of EA components. Step 19: Maintain an EA Repository for modeling and analysis products.

Step 20: Release annual updates to the EA Management Plan.

This EA implementation methodology addresses the establishment of a new EA program and documentation set. The revitalization of existing, but unproductive EA programs, or switching approaches, key personnel, or contracted support should be handled through the addition of Steps in Phase I and/or Phase II to address these changes. The following are more detailed descriptions of each step in the example EA methodology:

Phase I: EA Program Establishment Phase I activities are designed to get the EA program initially started, identify key players, and communicate the EA implementation plan to the executive sponsorand other stakeholders in order to gain buy-in and support. These pre-documentation activities are important to ensuring that the EA program has clear goals, remains focused, and is accepted throughout the enterprise.

Step 1: Establish the EA Management Program and identify a Chief Architect. The first step is for an executive sponsor to establish an EA program and identify a Chief Architect to lead the Program. The EA program is initially a start-up project (Phases I-III) and then an ongoing program (Phase IV). The executive sponsor must provide the Chief Architect with enough resources (e.g., budget, personnel, hardware/software, and facilities) and the authority to be able to properly establish the EA program. The Chief Architect should be accountable for EA program resources. One of the Chief Architect’s first actions should be to establish an EA team that consists of trained EA architects and representatives of various stakeholder groups. Key Term: Executive Sponsor The executive who has decision-making authority over the EA program and who provides resources and senior leadership for the EA program. An Introduction to Enterprise Architecture – 3 rdEdition 94 Step 2: Establish an EA implementation methodology.

The second step in the EA methodology is for the Chief Architect and EA team to identify all of the steps in the methodology that the enterprise needs in order to create an effective EA program. The example EA methodology discussed in this chapter can be used as it is presented or it can be modified to meet the particular needs of the enterprise. Other methodologies from the public and private sector can be used. The important thing to remember in starting an EA is to have a detailed methodology that will guide program implementation and subsequent documentation activities, as well as reduce the risk of the EA program losing focus, effectiveness, and value.

Step 3: Establish EA governance and links to other management processes.

The third step is for the executive sponsor and Chief Architect to co- develop an approach to EA governance that enables effective policy, planning, and decision-making within the EA management program. This approach to EA governance should include links to other management processes for strategic planning, capital planning, project management, security, and workforce skills planning.

Step 4: Develop an EA Communication Plan and gain stakeholder buy-in.

The next step is to develop an EA Communication Plan that articulates the EA documentation methodology and a schedule for Phase II and III activities. The EA Communication Plan should be written in plain language to gain stakeholder buy-in from non-technical executives, line of business managers, support staff, and other potential end users of EA documentation. The Communication Plan should include statements about the purpose and vision of the EA, examples of how the EA will bring value to the enterprise, where EA documentation will be available for access, a summary of the methodology used, and the general principles that will be used for EA development. Phase II: EA Framework and Tool Selection Phase II activities take place when the initial set of EA documentation is developed. This begins with the selection of an EA documentation framework that will identify the scope of the architecture, guide the techniques for the modeling of current views, develop future scenarios and associated modeling, and establish an on-line EA repository that will archive all of the EA documentationartifacts. An Introduction to Enterprise Architecture – 3 rdEdition 95 Step 5: Select an EA documentation framework.

The first step of Phase II involves the selection of an EA documentation framework by the Chief Architect, with input from the EA team and stakeholders. The framework should identify the areas of the enterprise that the EA will cover, and how those areas relate. For example, the EA³ framework identifies five functional areas and three ‘thread’ areas to be documented, organizes different types of components, and then orients the components into lines of business. These relationships are important in conveying how the enterprise uses its processes and resources in accomplishing its goals.

Step 6: Identify the EA Lines of Business and Crosscuts and the order of their documentation.

The second step of Phase II involves the identification of vertical Lines of Business (also known as Segments) and horizontal crosscutting initiatives within the enterprise that can be separately architected, and when combined, will represent the EA for the entire enterprise. Sometimes distinct vertical LOBs are readily apparent such as functional sub-units of an organization (e.g., the Manufacturing Division, Sales and Marketing Division, Research and Development Division, Administration and Finance Division). Sometimes however, the LOB/Segment is something that makes sense within the EA and is not an established organizational boundary, so it must be identified through work with stakeholders (e.g., vertical supply chains, mission- specific capabilities). Crosscutting initiatives are those horizontal activities which function in a “common operating environment” across several LOBs. Examples of horizontal crosscuts include web services, knowledge warehouses, network infrastructure, security solutions, ERP modules, and back-office systems/applications (e.g. email, document tracking, finance and accounting, human resources).

Step 7: Identify the EA components to be documented.

Step 7 of the EA documentation methodology is to identify the EA components that will have to be documented in each functional area of the framework. For example, the EA³ framework has six functional areas (strategy, business, information, services, networks, and vertical Key Term: EA Artifact An EA artifact is a documentation product, such as a text document, system specification, application interface information, diagram, spreadsheet, briefing slides, and/or video clip. An Introduction to Enterprise Architecture – 3 rdEdition 96 threads). Each of these areas represents a distinct set of activities that extend across the enterprise, which are represented by EA components.

EA components are plug-and-play goals, processes, measures, projects, data, services, and IT resources in the various functional areas. An EA component therefore is unique in the capability and resources that it represents within the EA framework. Each EA component is documented using information gathering methods and modeling techniques that are appropriate for the type of things that are contained in the EA component. For example, at the strategic level the enterprise’s strategic goals, activities, and outcome measures are the primary items to be documented. At the business level, the line-of business services and associated measures are documented. At the information level, the flows of information, databases, knowledge warehouses, and data standards are documented. At the services and applications level, the various web services, office automation services, and software applications are documented. At the technology infrastructure level the voice, data, and video networks, as well as associated cable plants and equipment facilities are documented. For the vertical threads, IT security information, IT standards, and IT workforce information are gathered for associated activities and resources in each of the five other functional areas.

Step 8: Select documentation methods appropriate for the framework. The next step is to select the methods that will be used to gather and develop EA documentation artifacts. For example, the following are methods for modeling in the six functional areas of the EA³ Cube framework (five levels and three threads). Appendix E provides examples of EA artifacts that can be used with the EA 3Cube and other frameworks. Strategic Level: Strategic Plan, Scenarios, Balanced Scorecard Business Level: IDEF-0 Diagrams, Flowcharts, Swim Lane Charts Information Level: Data Models, Object Diagrams, Data Dictionary Services Level: System Diagrams, Web Service Models, APIs Technology Level: Voice/Data/Video Network Diagrams/Documents Vertical Threads: Security Diagrams, Standards, Workforce Skills It is important to choose documentation techniques that will provide the information that is needed for resource planning and decision-making. Therefore, the Chief Architect should consult with EA stakeholders and An Introduction to Enterprise Architecture – 3 rdEdition 97 the EA team in selecting the methods for artifact development and what type of information will be gathered. Step 9: Select software applications/tools to support automated EA documentation.

Once the functional areas/levels of the framework and the types of EA components are known, EA documentation and artifact modeling requirements can be established. Without doing Steps 7 and 8, it would be difficult for the Chief Architect and EA team to know the particular modeling techniques that they will have to support. For example, if object-oriented methods are being used to develop artifacts at the information level of the framework, then an EA modeling tool that has capability with the Unified Modeling Language (UML) is called for. Also, several types of EA documentation tools may be required, as there may be a requirement for a general EA modeling tool, several specialty modeling tools, and general document, spreadsheet, and graphics applications.

Step 10: Select and establish an on-line EA repository for documentation.

The last step in Phase II is for the Chief Architect and EA team to select an EA repository software application and database. The EA repository should be hosted on the enterprise’s internal Local Area Network for security and ease of access to EA documentation. The EA repository is a database and file directory where all EA documentation is archived.

One method to promote ease-of-use is to establish an EA web site that is the “front door” for all EA Program activities and documentation. This website’s homepage can be designed to promote a clear view of the scope of the EA documentation that is available. Chapter 12 provides more information on the design of the EA repository. Phase III: Documentation of the EA Phase III activities are where the actual development of the EA occurs in the form of documentation artifacts. This involves analyzing and documenting the current strategy, business, information, services, and infrastructure of the enterprise. It also involves the development of artifacts that reflect changes in resources in the short-term and the development of a group of long-term future scenarios to identify possible courses of action and resource changes that would be needed in response to different internal and external influences. The activities in this phase of the EA documentation methodology conclude with the development of an An Introduction to Enterprise Architecture – 3 rdEdition 98 EA Management Plan that summarizes the current and future views of the architecture and provides a transition and sequencing plan for short term and long term changes.

Step 11: Evaluate existing business and technology documentation for use in the EA.

The first step of Phase III is the beginning of actual EA documentation activities. Preceding activities established what would be documented, how it would be documented, and who would do the documentation. The current view of EA components is what is now being documented through the identification of what the EA components are at each level of the framework and then using existing and new artifacts to document the EA components that currently exist. In many ways this activity is like taking an “inventory” of the components (strategic goals, business services, measures, data, services, and IT resources) that already exist in the enterprise and mapping them to existing documentation.

Step 12: Document current views of existing EA components in all framework areas.

The second step of Phase III is the development of new artifacts to complete the documentation of all existing components. The documentation methods and tools identified in Step 8 are used to gather and standardize existing artifacts, as well as to develop new artifacts. These documentation artifacts are organized by levels of the framework and are stored in the EA repository that was established in Step 10.

Additional details developing on the current architecture are provided in Chapter 7.

Step 13: Develop several future business and technology operating scenarios.

Prior to developing future views of EA components, it is helpful to gain a high-level understanding of the possible future directions that the enterprise could take, depending on how it responds to internal and external influences. Three or more future scenarios should optimally be developed with EA and line of business stakeholders to reflect what may occur if (1) the status quo is maintained; (2) an optimal business/technology operating environment is encountered; and (3) a high threat survival situation. There are several beneficial outcomes from the development of the scenarios. First, the enterprise is more prepared and organized to handle future situations and plan needed resources. Second, a number of planning assumptions are identified in each scenario that reveal what the priorities of the enterprise might be if An Introduction to Enterprise Architecture – 3 rdEdition 99 that scenario is pursued. Third, the planning for future capabilities is more coordinated, as opposed to simply gathering separate inputs from line of business managers and technology managers. Separate inputs are known to perpetuate stovepipe capabilities. Chapter 8 provides additional details about how to develop future scenarios and the future architecture.

Step 14: Identify future planning assumptions for each future scenario. Each future scenario describes, in story form, a possible business/technology operating environment that the enterprise might pursue or face. In this step, the key elements of each future scenario are analyzed to reveal what things are important to the enterprise and what changes have to occur for the scenario to become reality. For the purposes of the EA, these key elements become the planning assumptions that can then be grouped together to represent changes in each of the functional areas of the framework. One of the benefits of having the scenario and planning assumptions is that they were developed with stakeholder buy-in, which will help when future changes are implemented.

Step 15: Use scenarios, program inputs, and scheduled updates to drive documentation of future components in all framework areas.

This step involves the documentation of changes to EA components in the near term (1-2 years) and the longer term (3-5 years). These changes should be derived from the input by the leadership team (CXOs) via the operating scenarios’ planning assumptions, and from program and project managers who know what the future business requirements are, as well as planned system implementations, upgrades, and retirements.. By doing it this way, the changes are more coordinated and aligned with the strategic direction of the enterprise. Future views of EA components should be developed using the same artifact documentation and modeling techniques that were used to develop the current views. This helps to more clearly identify what the changes are in each of the functional levels of the EA framework, which helps in planning and decision-making.

Step 16: Develop an EA Management Plan to sequence planned changes in the EA. The final step in Phase III is the development of an EA Management Plan. This Plan serves to articulate how the EA was developed and provides a synopsis of the current and future views. The Plan also An Introduction to Enterprise Architecture – 3 rdEdition 100 provides a transition and sequencing sub-plan for the near term changes, which may already be in the project pre-implementation stage. Also, a long-range sequencing sub-plan is provided that covers the potential changes associated with the future scenarios. Chapter 9 provides more detail on the development of an EA Management Plan. Phase IV: Use and Maintain the EA Phase IV is an ongoing set of activities that promotes the use of EA information by all stakeholders, and establishes an annual cycle for updates. This is where the value of the EA Program is realized, as planning and decision-making throughout the enterprise are supported. This value is maintained through regular updates of the current and future views of the architecture. Value is also gained in the maintenance of the EA repository and the maintenance of all associated software licenses for modeling and archiving.

Step 17: Use EA information for resource planning/decision-making.

Upon the completion of Phase III, the current and future views of the architecture are stored in the EA repository and are ready to be used by the enterprise to support planning and decision-making. These EA stored artifacts become a baseline of reference information that can be used in a wide variety of executive, management, and staff activities. When this is done, a greater level of understanding is developed of capabilities and performance gaps among a wider group within the enterprise. Further, by having the EA documentation in an on-line repository, this information can be called up and referred to in meetings, which reduces the time it takes to convey an idea, increases comprehension, and reduces interpretation errors among meeting participants. For example, if in a planning meeting, one of the participants wanted to show needed improvements in information exchange within a particular line of business, EA documentation on the current and possible future views of that information flow could be called up from the repository and projected at the meeting. This, along with information on the associated business services, support applications, and networks can be referenced meaningfully. The time to convey the ideas is significantly reduced when diagrams and text are being shown to everyone at the meeting. This can stimulate more productive discussions and informed decisions. An Introduction to Enterprise Architecture – 3 rdEdition 101 Step 18: Regularly update current / future views of EA Components.

The information in the EA repository is valuable for planning and decision-making only as long as it is comprehensive and accurate. Therefore, it is important to regularly update the current and future views of EA components in all areas of the framework. Further, it is helpful to users of EA information if the updates are made on a regular schedule, perhaps twice a year. Also, it is important to maintain version control in between updates, so that all of the users of the EA information know that they are conducting planning and decision-making activities based on the same information. Since what is planned in the future EA views will eventually become the current architecture (at least some of it), it should be recognized that EA updates are ongoing activities that do not cease.

Future EA plans will continue as an organization grows and changes.

Consider a time when the enterprise no longer needs changes in future capabilities and resources. Should this occur, the EA program transitions from focusing on the establishment of the EA to maintaining the EA and seeing that it continually brings value to the enterprise.

Step 19: Maintain the EA repository and modeling capabilities.

The Chief Architect and EA team need to ensure that the EA repository and support applications/tools are kept current in terms of licensing and functionality. The requirements for archiving and modeling should be reviewed annually, and new products should be regularly reviewed to ensure that the EA team has the right application support capability. The team should be on the lookout for new improvements in tool functionality so that these improvements can be applied to the advantage of the enterprise. The costs for software purchases and license renewals should be part of the annual EA program budget.

Step 20: Release yearly updates to the EA Management Plan.

The Chief Architect needs to regularly inform EA stakeholders about the status of the EA. This is done through the annual release of an updated EA Management Plan that discusses changes that were made to the current and future views of the EA during the past year. The communication should provide a transition and sequencing plan for changes anticipated during the coming year. Also, the ongoing value of the EA needs to be communicated through the citation of examples of where EA documentation supported planning and decision-making, helped reduce duplicative capabilities, saved costs, improved alignment, and increased communication. An Introduction to Enterprise Architecture – 3 rdEdition 102 Summary of Concepts This chapter presented a comprehensive methodology for the implementation of an EA program and associated documentation activities. The four phases and twenty steps of the example EA methodology are generalized so they can be used in many types of public and private sector enterprises. Phase I activities serve to establish the EA program, identify a Chief Architect to lead the program, create an EA governance capability to run the EA program in a way that integrates with other IT management processes, and issue an EA Communication Plan to gain stakeholder buy- in and support. Phase II activities serve to select an EA framework that defines the scope of the architecture, the EA components that will make up the architecture in each functional area, and software applications/tools to automate the documentation of EA components. Phase III is where the actual documentation of current and future views of the architecture occurs, as well as the development of an EA Management Plan to describe how the architecture will transition over time. The final Phase IV activities are where the EA is used throughout the enterprise to support planning and decision-making and regular updates are performed to keep the EA relevant and adding value.

Chapter 4 Questions and Exercises 1. What is an EA implementation methodology?

2. What is the role of an EA framework within the EA methodology?

3. What is the purpose of Phase I activities in the EA methodology?

4. Why are Phase III activities dependent on the completion of Phase II?

5. Compare and contrast the purpose of Phase II and Phase IV activities.

6. Can the steps of the EA methodology be changed for different enterprises?

7. Who is responsible for execution of the EA program and EA methodology?

8. How often should an EA be updated? Why?

9. Select a real-world medium or large size enterprise and provide:

a. The phases and steps of an appropriate EA implementation methodology.

b. The way that EA stakeholder support will be obtained.

c. The recommended schedule for updating the EA. An Introduction to Enterprise Architecture – 3 rdEdition 103 Chapter 5 The Analysis and Documentation Framework Chapter Overview Chapter 5 defines and describes the purpose of the EA analysis and documentation framework, provides examples of existing frameworks and discusses the EA³ Cube Framework which is a generalized framework that is suitable for use in public and private sector enterprises. Learning Objectives ¾Understand the purpose of an EA framework as part of an EA implementation methodology.

¾Understand how an EA framework establishes the scope of an EA.

¾Become familiar with the origin of EA frameworks and several examples.

¾Understand the design of the EA³ Cube framework. Introduction The foundational elements of an EA program are the analysis and documentation framework (EA framework), and the implementation methodology (EA methodology). The EA framework defines what the EA program will document, and the EA methodology defines how that documentation will be developed and used. By defining what parts of the enterprise are included in the EA, the framework defines the scope of the architecture. The design of the framework communicates the relationship of the areas of the EA that are documented. Home Architecture Analogy: The EA documentation framework is like the structural skeleton of a home. It is the framing that defines the size and relationship of parts of the house and individual rooms. An Introduction to Enterprise Architecture – 3 rdEdition 104 Discussion The EA analysis and documentation process is accomplished through an EA implementation methodology that includes (1) the framework, (2) components, (3) current architectural views, (4) future architectural views, (5) a plan for managing the ongoing transition between these views, and (6) vertical threads that effect the architecture at all levels. Analysis and documentation, as organized through an EA framework, provides standardized, hierarchical views of the enterprise from an integrated strategy, business, and technology perspective, as is shown in Figure 5-1.

Figure 5-1: EA³ Cube Framework The Origin of Frameworks Information modeling and documentation frameworks emerged during the era of mainframe computing as data, software, and hardware requirements became more complex and multifaceted, and as the types of end-users Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Networks Networks & & Infrastructure Infrastructure Systems Systems & & Applications Applications Data Data & & Information Information Processes Processes & & Services Services Network Infrastructure Network Infrastructure Goals Goals & & Initiatives Initiatives Hierarchical Levels Lines of Business Crosscutting Components Vertical Components Security, Standards, WorkforceSecurity, Standards, Workforce Common Threads Technology – Business – Strategy Functional Areas Segments Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Networks Networks & & Infrastructure Infrastructure Systems Systems & & Applications Applications Data Data & & Information Information Processes Processes & & Services Services Network Infrastructure Network Infrastructure Goals Goals & & Initiatives Initiatives Hierarchical Levels Lines of Business Crosscutting Components Vertical Components Security, Standards, WorkforceSecurity, Standards, Workforce Common Threads Technology – Business – Strategy Functional Areas Segments An Introduction to Enterprise Architecture – 3 rdEdition 105 increased and their locations became more distant. Reflecting the nature of that era, most early architectures were technically-oriented, often vendor and/or product-specific. Vendors of software and hardware products increasingly touted their own proprietary solutions, standards, and product lines under the banner of information or systems architectures. While this vendor-driven approach to architecture did serve to advance the capability of computing in general, it also created significant incompatibility problems for enterprises that operated a collection of IT products from multiple vendors.

In addition to the issue of product incompatibility, there was a focus on developing and operating individual information systems versus the creation of an overall IT capability within an enterprise. Furthermore, systems-level IT planning grew out of an approach to analysis and design that focused on meeting a specific set of requirements within the enterprise. For example, many enterprises introduced IT in response to a perceived need for automated support for accounting, payroll, and administrative business functions. This often grew to include manufacturing, service, and sales support. In most cases, each of these business requirements were met by individual system solutions based on proprietary vendor approaches and products. The result was a heterogeneous collection of IT resources that independently supported business areas, but could not exchange information outside of a particular system or business area. It was this scenario that gave rise to terms like “stovepipe systems” and “islands of computing capability.” This scenario was increasingly problematic to enterprises that sought to share information between lines of business and support functions. Further, the duplication in systems capability and cost of operating and maintaining a myriad of independent systems became a focal point for improvement. A desire to create interoperability, reduce costs, and increase capability was the organizational driver that changed things. During the mid-1970’s and 1980’s this change came in two main areas:

database and network design. First, an approach to information systems analysis and design that was based on the enterprise’s information requirements came about through the introduction of standardized methods for modeling data, structure, and process. Second, the era of distributed client-server computing came into being as “dumb” mainframe terminals began to be replaced by “smart” desktop computers that could be networked in a client-server design that reached throughout an enterprise. An Introduction to Enterprise Architecture – 3 rdEdition 106 In the first area, an approach to database design, now known as the “structured” approach, was developed for modeling the processing and structure of data. Data Flow Diagramming (DFD) techniques allowed enterprises to identify how an information system would process data in support of a business function. The Entity-Relationship Diagram (ERD) technique allowed analysts to identify the types of data items that an enterprise wanted to collect along with the attributes and relationships of those data items. Through these two analysis methods, enterprises could design more efficient and capable “relational” databases that used procedural programming languages (e.g., COBOL, FORTRAN, C) which were capable of serving multiple information systems and business processes. Further, this shifted the analysis and design focus from proprietary solutions to generic information requirements.

In the second area, the movement from mainframe to distributed computing also served to change the way that information systems and networks were designed. While structured information modeling techniques promoted new relational database designs, networked computing promoted the hosting of these databases in multiple locations on smaller computer “servers” that could be located closer to the end-user. Information systems standards based on international and industry agreements emerged, as did new designs for the hosting and transport of the information. Important examples include the Open Systems Interconnection (OSI) Reference Model for information networks that was proposed by J.D. Day and H. Zimmerman in 1983. 11 This model has seven layers that address services, interfaces, and protocols. In 1974 the Transport Communications Protocol/Internet Protocol (TCP/IP) was proposed by Vinton Cerf and Robert Kahn 12 11Day, J.D., and Zimmermann, H. “The OSI Reference Model.” Proceedings of the IEEE. Volume 71, pages 1334-1340. December 1983. that led to work on a dedicated data network that connected universities and selected military and business enterprises throughout the nation (known as the ARPANET). The acceptance of TCP/IP on a broad scale in the late 1980’s and early 1990’s promoted the integration of telecommunications and data network infrastructures and provided the catalyst for the dramatic growth of the global Internet. Other standards for data transfer emerged in the late 1980’s and early 1990’s including a standard that defined “Ethernet” local area networks and ‘Asynchronous Transport Mode’ (ATM) networks that promoted integrated voice, data, and video transmission. 12Cerf, V. and Kahn, R. “A Protocol for Packet Network Interconnection.” IEEE Transactions on Communication. Volume COM-22, pages 637-648. May 1974. An Introduction to Enterprise Architecture – 3 rdEdition 107 Data hosting also changed as developments in computer micro processors, hard drive storage, removable disk storage, and telecommunications interfaces all made the desktop computer, also known as the personal computer (PC), a viable candidate to support print, file, and application hosting functions. Since the early 1980’s the performance capability of PCs has risen dramatically each year, while the cost of PCs has dropped. This dynamic boosted the movement away from mainframe computing to networked computing based on ‘client’ and ‘server’ PCs working together to share data and applications. Standardized approaches to application development began to emerge as a result, along with protracted competitive battles among vendors to develop products that would dominate in the new networked computing environment. The early 1990’s also saw the introduction of a new approach to designing databases. Focusing on the problem of separating structure from process in modeling relational databases, an “object-oriented” approach was developed that took advantage of new programming languages (i.e., Java, C++) that could support data objects that had attributes and behaviors. Additionally, these data objects could encapsulate (prohibit changes to) certain areas of their code to protect them from alteration. This was significant in that objects then represented reusable code whose quality in key areas was assured. Finally, the non-encapsulated areas of code offered users the ability to customize or add attributes and behaviors such that objects became a reliable and flexible building block for application and database development.

It was in this time that some of the first writing on information architecture frameworks began to emerge. In 1987 Dennis Mulryan and Richard Nolan wrote about “Undertaking and Architecture Program” 13 and in 1991 Brandt Allen and Andrew Boynton wrote an article entitled ”Information Architecture: In Search of Efficient Flexibility.” 14 In 1989 and 1992, John Zachman published seminal articles in the IBM Systems Journal about an idea for an Information Systems Architecture (ISA) that served to organize the documentation of information hierarchically and by function. 15 16 13Richard Nolan & Dennis Mulryan. “Undertaking an Architecture Program.” Stage by Stage.

Volume 7, Number 2. March/April 1987. Note: Nolan later introduced the concept of the “Balanced Scorecard” for use in IT strategic planning (with Richard Kaplan).

Zachman’s work served to elevate the discussion of architectures to the 14Brandt Allen & Andrew Boynton. “Information Architecture: In Search of Efficient Flexibility.” MIS Quarterly. December 1991. 15Zachman, 1989.16John Zachman and J. Sowa. “Extending and Formalizing the Framework for Information Systems Architecture.” IBM Systems Journal. Vol.31, No. 3. 1992. An Introduction to Enterprise Architecture – 3 rdEdition 108 level of the enterprise and stimulated additional writing on enterprise-wide information architectures that was to continue throughout the 1990s. In 1992, Steven Spewak built upon Zachman’s work and developed the concept of ‘Enterprise Architecture Planning’ (EAP). 17 The EAP method represented a distinct departure from the technically-oriented architectures of previous years, as it focused on how IT would be used to support business functions on an enterprise-wide (enterprise) basis. It is the combined work of John Zachman and Steven Spewak that form the basis of most of the enterprise architecture frameworks that are in use today throughout business and government, including the EA³ Cube framework introduced in this book. Examples of Enterprise Architecture Frameworks The Zachman ISA Framework (1987 and 1992) In the mid-1980’s John Zachman observed that the data processing requirements of many of his IBM clients were becoming more complex. There was a need to show information systems from several perspectives that addressed this complexity and promoted planning, design, and configuration management. Zachman drew from both the aircraft and construction industries in developing a highly intuitive and comprehensive schema for documenting information systems architecture (ISA) in the context of several hierarchical perspectives characteristics. Zachman’s ISA framework is a schema with rows and columns that functions much like a relational database in that he calls for the development of basic or “primitive” architectural artifacts for each of the 30 cells in the schema, such that none of these artifacts are repeated in other cells or combined to create what Zachman calls “composite” products. By documenting the ISA (now known as the Zachman EA Framework) in detail at each level of the EA framework, an enterprise develops multiple views of their processes and resources that are useful to senior executives, line managers, and support staff. Further, Zachman’s approach addresses the what, how, where, who, when, and why questions about an enterprise. Figure 5-2 provides the current version of the Zachman Framework for EA (v3.0). 18 17Spewak, S. 1992. Note: the Foreword of his book was written by John Zachman.18Zachman, J. 2011. Zachman Framework for EA: The Enterprise Ontology. www.zachman.com An Introduction to Enterprise Architecture – 3 rdEdition 109 Figure 5-2: The Zachman Framework v3.0 Since 1992, John Zachman has gone on to influence a number of different EA frameworks and writings on the EA, including the author’s EA 3 framework and this textbook. While the basic ISA approach is evident in the current Zachman EA Framework, many new concepts have been addressed such as how IT security is an implicit element in each cell’s artifact(s). Zachman has written a number of papers that are available through his website on how his approach to EA addresses a number of old and new issues and how it is used in current work with organizations worldwide. See Appendix B (Figure B-11) for mappings of other EA approaches to the Zachman Framework.

The Spewak EA Planning Method (1992) About the time that John Zachman was releasing his second article to expand the original ISA Framework, Steven Spewak was further extending these ideas into a planning-oriented framework that incorporated new features including a focus on business, an implementation approach that includes principles and values, a migration strategy, and ties to project management. Spewak was the Chief Architect for DHL Systems Inc. at the time of developing his “Enterprise Architecture Planning” (EAP) method. He was also the first person to prominently feature the term “enterprise” in his framework as a way to emphasize the need for architecture to move beyond individual systems planning. Spewak’s definition of the term architecture is as follows: Cl a ssi f ica t ion Names Audienc e Pers pec tives What How Where Who When Why Classification Names Mo d el Names Executive Perspective (Planners ) In ven tory Id en ti fi cationPro cess Id en ti fi cationDi s tri bution Id en ti fi cationRes p o nsi bili ty Id en ti fi cationTimin g Id en ti fi cationMo ti vati on Id en ti fi cationSco p e Contexts Ma na ge m e nt Perspective (Ow ners ) In ven tory Defi n i ti onProcess Defi n i ti onDi s tri bution Defi n i ti onRes p o nsi bili ty Defi n i ti onTimin g Defi n i ti onMo ti vati on Defi n i ti onBusiness Concepts Architect Perspective (D es igners ) In ven tory Rep res entati onProcess Rep res entati onDi s tri bution Rep res entati onRes p o nsi bili ty Rep res entati onTimin g Rep res entati onMo ti vati on Rep resentati onSystem Logic Engine e r Perspective (Builders ) In ven tory SpecificationProcess SpecificationDi s tri bution SpecificationRes p o nsi bili ty SpecificationTimin g SpecificationMo ti vati on SpecificationTechnology Ph ysics Technician Perspective (Implementers) In ven tory ConfigurationProcess Co n fi gurati onDi s tri bution Co n fi gurati onRes p o nsi bili ty ConfigurationTimin g Co n fi gurati onMo ti vati on ConfigurationTool Components Enterprise Perspective (U s ers ) In ven tory In s tan ti ationsProcess In stan ti ationsDi s tri bution In s tan ti ationsRes p o nsi bili ty In s tan ti ationsTimin g In s tan ti ationsMo ti vati on In stan ti ationsO perational Instances Audienc e Pers pec tives En t erp rise Names Inv entory Sets Proc es s FlowsDis tribution NetworksRes pons ibility As s ignmentsTiming Cy c lesMotivation Intentions An Introduction to Enterprise Architecture – 3 rdEdition 110 “Since the aim of EAP is to enable an enterprise to share data, the term enterprise should include all areas that need to share substantial amounts of data. A good and proper scope for enterprise often equates to a business unit, division, or subsidiary because such enterprise units include all of the business functions for providing products and services to customers. Also, with responsibility and control of the bottom line, the economic benefits and justification of EAP can more easily be established”. 19 Spewak states that EAP is a method for developing the top two levels of Zachman’s Framework. The seven phases of EAP are grouped into a four- layer “wedding cake” shaped model that crates an implementation sequence, as is shown in Figure 5-3.

Figure 5-3: The Spewak Enterprise Architecture Planning Approach The EA³ Cube Framework (2004) A generalized framework for EA analysis and documentation is introduced in this book, which can be used in both the public and private sectors. The concepts used in the “EA³ Cube” Framework are founded on the works of Talcott Parsons, James Thompson, John Zachman, Steven Spewak, and the creators of the FEAF. The EA³ Framework employs the generic shape of a cube, to show multiple vertical levels that are different EA documentation areas; multiple layers of depth that are distinct activity areas – referred to 19Spewak, 1992. EA PRINCIPLES BUSINESS MODELING CURRENT SYSTEMS & TECHNOLOGY APPLICATIONS ARCHITECTURE DATA ARCHITECTURE TECHNOLOGY ARCHITECTURE IMPLEMENTATION PLAN - MIGRATION STRATEGY PLANNING INITIATION PLANNING CONCLUSION FINAL REPORT AND PRESENTATION P R O J E C TM A N A G E M E N T EA PRINCIPLES BUSINESS MODELING CURRENT SYSTEMS & TECHNOLOGY APPLICATIONS ARCHITECTURE DATA ARCHITECTURE TECHNOLOGY ARCHITECTURE IMPLEMENTATION PLAN - MIGRATION STRATEGY PLANNING INITIATION PLANNING CONCLUSION FINAL REPORT AND PRESENTATION P R O J E C TM A N A G E M E N T An Introduction to Enterprise Architecture – 3 rdEdition 111 as lines-of-business; and multiple sub-cubes at each level that represent plug-and-play EA components. Enterprises can implement the EA³ Framework directly, or can use it as an initial baseline for the development of their own EA management and documentation approach. Many enterprises will most likely need to modify certain elements of the EA³ Framework to fit their particular needs, which is encouraged as it is recognized that business, government, military, non-profit, and academic enterprises have fundamentally different cultures, economic drivers, and critical success factors. These differences may require adjustments in the framework in order to best implement an EA program that captures the current and future business and technology environment. Common characteristics of most EA frameworks that the EA³ Framework also captures are that they address multiple, often hierarchical views of the enterprise and technology, and that they support integrated systems planning and implementation. The EA³ Framework serves primarily to organize IT resource planning and documentation activities. The framework is hierarchical to distinguish high-level views that are of value to executives and planners from the more detailed views that are of value to line managers and support staff. Figure 5-4 shows the design and key features of the EA³ Framework.

Figure 5-4: The EA³ Cube Analysis and Documentation Framework Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Networks & Infrastructure Systems & Applications Data & Information Products & Services Network Infrastructure Network Infrastructure Goals & Initiatives Lines of Business C O M P O N E N T S Security / Standards / Skills Technology – Business – Strategy An Introduction to Enterprise Architecture – 3 rdEdition 112 Hierarchical Levels of the EA³ Cube Framework The five levels of the EA³ Framework are hierarchical and integrated so that separate sub-architectures are not needed to reflect different levels or functional areas of the enterprise. The architectural areas covered at each level are arranged to position high-level strategic goals at the top, general business services and information flows in the middle, and specific support applications and the network infrastructure at the bottom. In this way alignment can be shown between strategy, information, and technology, which aids planning and decision-making. Goals and Initiatives . This is the driving force behind the architecture. The top level of the EA³ Framework identifies the strategic direction, goals, and initiatives of the enterprise and provides clear descriptions of the contribution that IT will make in achieving these goals. Strategic planning begins with a clear statement of the enterprise’s purpose and/or mission, complimented by a succinct statement of the vision for success. This is followed by descriptions of the strategic direction the enterprise is taking, scenarios that could occur, as well as the competitive strategy that will ensure not only survivability, but success in terms that the enterprise must define. These overarching statements are then supported through the identification of goals and supporting initiatives that include measurable outcomes and performance measures. Products and Services . This is the architecture’s intended area of primary influence. The second level of the EA³ Framework identifies the business products services of the enterprise and the contribution of technology to support those processes. The term ‘business service’ is used to mean processes and procedures that accomplish the mission and purpose of the enterprise, whether that is to compete in the private sector, provide public services, educate, provide medical services, or provide a defense capability. Strategic planning helps to direct and prioritize the various business services and product delivery activities in an enterprise to ensure that they are collectively moving the enterprise in the strategic direction that is set out in the Strategic Plan. Business services then need to be modeled in their current state and if change is anticipated, also modeled in the envisioned future state. Business services and product delivery processes should be eliminated if they are not adding sufficient value to the enterprise’s strategic goals and initiatives. Business services and product delivery activities should be modified if change can increase value to the enterprise, be it a minor adjustment or a major shift in how that activity is accomplished. An Introduction to Enterprise Architecture – 3 rdEdition 113 Technology is often a key enabling element in increasing value, but should not be the driving factor in the reengineering or improvement of business services and product delivery processes. It is important to review and adjust the process before IT is applied to ensure that optimal value and efficiency are achieved.

Data and Information . Optimizing data and information exchanges is the secondary purpose of the architecture. The third level of the EA³ Framework is intended to document how information is currently being used by the enterprise and how future information flows would look. This level can be reflected through an IT Strategy document that ties into the enterprise’s Strategic Plan and/or Business Plan. The purpose of the IT strategy is to establish a high-level approach for gathering, storing, transforming, and disseminating information throughout the enterprise. The use of concepts such as knowledge management, data mining, information warehouses, data marts, and web portals can be organized through the IT strategy. The design and functioning of databases throughout the enterprise are also documented at this level as are standards and formats for data, data dictionaries, and repositories for reusable information objects.

Systems and Applications . The fourth level of the EA³ Framework is intended to organize and document the current group of information systems, and applications that the enterprise uses to deliver IT capabilities. Depending on changes at the upper levels of the EA³ framework (Business services or Information Flows) there may be planned changes to systems/applications that must be reflected in the architecture’s future views. This area of the EA³ framework is also where components are a prominent feature in service-oriented architectures, as increasingly interoperable commercial applications are available to enterprises (e.g., J2EE and .NET industry standards). Large, modular applications can handle entire lines of business and/or back office functions (i.e., financial systems, manufacturing control systems, and supply chain management systems). Often referred to as Enterprise Resource Planning (ERP) systems, these commercial applications may offer modules of functionality that can be customized to allow an enterprise to reduce the overall number of applications that they operate and maintain. While ERP systems rarely provide all of the functionality that an enterprise needs for business functions and administrative support, this modular approach is reflective of a “plug- and-play” strategy that enterprises can adopt at this level of the EA³ Framework to increase interoperability and reduce costs. An Introduction to Enterprise Architecture – 3 rdEdition 114 Networks and Infrastructure . This is the connectivity grid of the architecture, the host environment for applications and systems. The fifth and bottom level of the EA³ Framework is intended to organize and document current and future views of the voice, data, and video networks that the enterprise uses to host systems, applications, websites, and databases. This level also documents the infrastructure of the enterprise (e.g. buildings, server rooms, capital equipment). Local Area Networks (LANs), Wide Area Networks (WANs), System Application Networks (SANs), Intranets, Extranets, Wireless Networks, Mobile Networks, and Computing C louds are documented at this level so that efficient designs can be implemented through the future architecture that reduce duplication, increase cost and performance efficiency, and promote availability and survivability. Often, an enterprise will determine that certain IT capabilities are critical to the success of the enterprise, and in these areas the architecture should reflect redundant resources in different locations such that these capabilities could continue to be available if the primary resource became unavailable. Lines of Business within the EA³ Cube Framework A Line of Business (LOB) is a distinct area of activity within the enterprise. LOB can also be referred to as ‘vertical’ mission areas. It may involve provision of services, product development/delivery, or internal administrative functions. Each LOB has a complete architecture that includes all five hierarchical levels of the EA³ framework. The LOB therefore can in some ways stand alone architecturally within the enterprise, except that duplication in data, applications, and network functions would occur if each LOB were truly independent, and crosscutting activities that reduce this duplication would not be represented. There may be cases where an enterprise would want to incrementally develop their EA due to cost or other considerations, and architecting individual LOBs is one way to do this. The LOB architectures then must be tied together so that the EA correctly represents the entire enterprise, which is what is needed for the EA to be of maximum value to executives, management, and staff.

Crosscutting Components within the EA³ Cube Framework To avoid the inefficiencies of duplicative support within LOBs, crosscutting business and technology components are established to provide common service and product delivery capabilities, databases, application suites, and network infrastructures. Crosscutting services are An Introduction to Enterprise Architecture – 3 rdEdition 115 aimed at reducing application hosting costs, increasing the sharing of information, and enabling enterprise-wide infrastructure solutions. Examples of crosscutting initiatives include email service, administrative services, telephone service, video teleconferencing facilities, and computer server rooms.

Planning Threads within the EA³ Cube Framework EA documentation includes “threads” of common activity that pervade all levels of the framework. These threads include security, standards, and workforce considerations. Security . Security is most effective when it is an integral part of the EA management program and documentation methodology. A comprehensive security and privacy program has several focal areas including: information, personnel, operations, and facilities. To be effective, IT security must work across all levels of the EA framework and within all of the EA components. Chapter 11 provides more.

Standards . One of the most important functions of the EA is that it provides technology-related standards at all levels of the EA framework. The EA should draw on accepted international, National, and industry standards in order to promote the use of non-proprietary commercial solutions in EA components. This in turn enhances the integration of EA components, as well as better supporting the switch- out of components when needed.

Skills . One of the greatest resources that an enterprise has is its people. It is therefore important to ensure that staffing, skill, and training requirements are identified at each level of the EA framework, and appropriate solutions are reflected in the future architecture. A Workforce Plan (Human Capital Plan) is perhaps the best way to articulate how human capital will be employed in enabling technology capabilities, which underlie business services and information flows. Summary of Concepts This chapter described how an EA framework is one of the foundational elements of an EA program and implementation methodology. The EA framework establishes the scope of the EA documentation effort, and relates the areas of the architecture together. EA frameworks were first developed in the 1980’s and have evolved in the public and private sectors, An Introduction to Enterprise Architecture – 3 rdEdition 116 as well as internationally to provide support for particular approaches to EA. The EA³ Cube Framework was described in detail, as part of an overall EA methodology. Chapters 6 and 7 will provide information on how to develop current and future views of EA documentation using this framework.

Chapter 5 Questions and Exercises 1. Why does an EA implementation methodology begin with the selection of an EA framework?

2. What are some of the basic characteristics of an EA framework?

3. Why are hierarchical levels of an EA framework helpful in documenting an enterprise?

4. Why is it necessary to show current andfuture views of EA documentation?

5. How does the Spewak Enterprise Architecture Planning approach relate to the Zachman EA framework?

6. Would the Federal EA Framework be useable in private sector (business) enterprises? If so, how? If not, why?

7. Choose a medium or large size enterprise and provide the following regarding the areas of the EA³ Cube framework:

a. List examples of documentation from the enterprise that would be appropriate at each of the five functional levels.

b. List examples of documentation from the enterprise that would be appropriate for the three common planning threads.

c. List examples of documentation from the enterprise that would illustrate Lines of Business.

d. List examples of documentation from the enterprise that would illustrate crosscutting and vertical EA components. An Introduction to Enterprise Architecture – 3 rdEdition 117 Chapter 6 Components and Artifacts Chapter Overview Chapter 6 defines and describes EA components and artifacts within the context of an EA framework. Using the EA³ Framework as an example, EA components are replaceable elements within the framework that come and go with changes in strategy, business services, and new designs for resources involving information flows, applications, networks and other infrastructure. Descriptions are provided of example EA components at each level of the framework. Appendix E gives examples of each artifact. Learning Objectives ¾Understand what EA components are and their role in an EA framework.

¾Understand how EA artifacts describe EA components.

¾See examples of EA components and artifacts throughout an EA framework.

¾Understand how management views help executives understand EA components. Key Term: EA Artifact An EA artifact is a documentation product, such as a text document, diagram, spreadsheet, briefing slides, or video clip. EA artifacts document EA components in a consistent way across the entire architecture.

Key Term: EA Component EA components are those ‘plug-and-play’ changeable resources that provide capabilities at each level of the framework. Examples include strategic goals and initiatives; business services; information flows and data objects; information systems, web services, and software applications; voice/data/video/mobile networks, cable plants, equipment, and buildings. An Introduction to Enterprise Architecture – 3 rdEdition 118 Introduction While an EA framework provides an overall structure for modeling the enterprise’s business and technology operating environment, EA components are the working elements of the framework at each level. In other words, EA components are “building blocks” that create discrete parts of the overall IT operational capability. EA artifacts describe EA components. Discussion EA components are the active elements of the enterprise’s business and technology operating environment. EA components include IT-related strategic goals and initiatives, supply chains, information systems, software applications, knowledge warehouses, databases, websites, and voice/data/video networks, and the security solution. These EA components should function together to create a robust and seamless IT operating environment that effectively supports the enterprise’s business needs. Availability, reliability, security, scalability, and cost effectiveness are key performance measurement areas for the general IT operating environment. These areas apply to each EA component, along with measures for integration and reuse. EA artifacts are types of documentation that describe components, including reports, diagrams, charts, spreadsheets, video files, and other types of recorded information. High-level EA artifacts are often text documents or diagrams that describe overall strategies, programs, and desired outcomes. Mid-level EA artifacts are documents, diagrams, charts, spreadsheets, and briefings that describe organizational processes, ongoing projects, supply chains, large systems, information flows, networks, and web sites. Low-level EA artifacts describe specific applications, data dictionaries, technical standards, interfaces, network components, and cable plants. When these EA artifacts are harmonized through the organizing taxonomy of the EA framework, new and more useful views of the functioning of EA components are generated. This is one of the Home Architecture Analogy: EA components are like the rooms of the house. Rooms can be added, remodeled, or taken away. EA documentation products are the description of each room, and can include statements, stories, pictures, and/or videos. An Introduction to Enterprise Architecture – 3 rdEdition 119 greatest values of EA as a documentation process… creation of the ability to see a hierarchy of views of the enterprise that can be examined from several perspectives. For example, by recognizing that EA components are the building blocks of the an EA framework, and that most IT hardware and software is now commercially procured (versus being custom developed in-house), the stage has been set for a “plug-and-play” approach to IT support that must be reflected at all levels of the EA framework. Figure 6-1 provides examples of EA components and artifacts at each level of the EA³ Cube Framework.

Figure 6-1: EA Components and Artifacts The following are detailed descriptions of EA components at each level of the EA³ Cube Framework. A more detailed description of the current view of EA components and artifacts is provided in Chapter 8, and a description of the future view of these components/artifacts is provided in Chapter 9. Appendix E provides detailed examples of each type of artifact. Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Technology & Infrastructure Systems & Applications Data & Information Products & Services Network Infrastructure Network Infrastructure Goals & Initiatives Examples of EA Components •Information Systems •Web Sites •Desktop Applications •Intranets & Extranets •Telecommunications •Buildings & Equipment •Knowledge Warehouse •Databases & Data Marts •Data Interchange •Manufacturing •Financial Services •Marketing & Sales •Mission Statement •Strategic Goals •Strategic Initiatives Vertical Components Crosscutting Components Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Network Infrastructure Technology & Infrastructure Systems & Applications Data & Information Products & Services Network Infrastructure Network Infrastructure Goals & Initiatives Examples of EA Components •Information Systems •Web Sites •Desktop Applications •Intranets & Extranets •Telecommunications •Buildings & Equipment •Knowledge Warehouse •Databases & Data Marts •Data Interchange •Manufacturing •Financial Services •Marketing & Sales •Mission Statement •Strategic Goals •Strategic Initiatives Vertical Components Crosscutting Components An Introduction to Enterprise Architecture – 3 rdEdition 120 EA Components at the Goals and Initiatives Level EA Components : xStrategic Plan xE-Commerce/E-Government Plan EA Artifacts : xStrategic Plan (S-1) xSWOT Analysis (S-2) xConcept of Operations Scenario (S-3) xConcept of Operations Diagram (S-4) xBalanced Scorecard™ (S-5) Large, complex enterprises often require a formalized approach to planning that accounts for changing conditions, participants, and goals. An enterprise’s purpose and direction, as well as its approach to leveraging resources, are documented at the strategic ‘Goals and Initiatives’ level of the framework. Strategic Plans should be viewed as “living documents” which are updated periodically and which help an enterprise understand itself and adapt to changing conditions. Strategic Plans almost never are implemented without changes to the original version, because unforeseen internal and/or external events make elements of the plan unfeasible or sub-optimal for ensuring survival and maximizing success. The value of strategic planning is more in the process than in the product. By having a rational, repeatable process for dealing with the chaos and complexity of many operating environments, enterprises can better and more rapidly set a direction and goals in a formal plan that provides a common referent. The plan can be then modified periodically in response to changes in the environment.

The two EA components at this level are (1) the Strategic Plan, and (2) E- Commerce or E-Government Plan. EA artifacts at this level are the mission and vision statements, scenarios, strategies, goals, and initiative measures that are developed through the strategic planning process. While the basic mission, purpose, and/or direction of an enterprise may change infrequently; the scenarios, goals, initiatives, and measures are the flexible components of the process that can be changed as needed to reflect new mission areas, market opportunities, competitor actions, laws and regulations, economic conditions, resource constraints, and/or management priorities. An Introduction to Enterprise Architecture – 3 rdEdition 121 Strategic Plan Strategic planning produces a high-level view of the direction that an enterprise sets for itself. This direction is further articulated in long-range scenarios, strategies, goals, and initiatives that serve as the baseline for short-term tactical (operational) planning that is updated annually. Strategic Plans for enterprises in dynamic and/or highly competitive environments should look three to five years into the future and be updated annually. Strategic Plans for enterprises in more stable environments should look five to ten years into the future and be updated approximately every three years. A Strategic Plan is a composite EA artifact that should guide the enterprise’s direction over a 3-5 year period in the future by providing the following items, each of which are primitive (basic) EA artifacts. Full versions of abbreviated primitive artifacts are separate artifacts.

xProvide a Mission Statement and a Vision Statement that succinctly captures the purpose and direction of the enterprise. xDevelop a Statement of Strategic Direction that fits the enterprise’s purpose, ensures survivability, allows for flexibility, and promotes competitive success. This statement is a detailed description of where the enterprise intends to go.

xSummarize the results of a SWOT Analysis that is based on the statement of strategic direction and which identifies the enterprise’s strengths, weaknesses, opportunities, and threats. The full SWOT analysis is artifact S-2.

xSummarize the situation and planning assumptions for several ‘Concept of Operations’ CONOPS Scenarios that support the enterprise’s strategic direction. This summary should include one current scenariothat describes at a high-level the coordination of ongoing activities in each line of business, as well as several future scenariosthat account for different combinations of internal and external drivers identified through the SWOT Analysis. The complete scenarios are artifact S-3.

xDevelop a CONOPS Graphic that in a single picture captures the essence of and participants in the current operating scenario. This graphic is artifact S-4.

xDevelop a General Competitive Strategy for the enterprise that incorporates the current and future CONOPS scenarios and moves the enterprise in the intended strategic direction in a way that and address internal/external drivers such as culture, line of An Introduction to Enterprise Architecture – 3 rdEdition 122 business requirements, market conditions, competitor strategies, and risk.

xIdentify Strategic Goals that will accomplish the competitive strategy, and specify the executive sponsors who are responsible for achieving each goal.

xIdentify Strategic Initiatives and resource sponsors for the initiatives, which are the ongoing programs or development projects that will accomplish each Strategic Goal.

xSummarize Outcome Measures for each Strategic Goal and Initiative, using the Balanced Scorecard™ or similar approach. The full scorecard is artifact S-5. Because some of these areas will contain sensitive information that the enterprise will want to protect from its competitors, the full Strategic Plan should be written for internal use by decision-makers. A generalized version can then be developed for external distribution.

By using proven approaches to developing the Strategic Plan, such as the Balanced Scorecard ®, enterprises are able to identify IT-related goals for the enterprise that support overall strategic goals, as well as initiatives for achieving those goals and measures for tracking progress within each initiative. Figure 6-2 shows these relationships. IT Component IT Component IT Component IT Component IT Component IT Component Mission Statement Vision Statement Strategic Goal #1 Intended Outcome (s) Initiative 2-3 Initiative 2-2 Strategic Goal #2 Performance Measure(s) Performance Measure(s) Performance Measure(s) Intended Outcome (s) IT Implementation and Support StrategyStrategic Plan Performance Measure(s) Performance Measure(s) Performance Measure(s) Initiative 1-1 Initiative 1-2 Initiative 1-3 Initiative 2-1 Figure 6-2: Relationship of Strategic Level Artifacts An Introduction to Enterprise Architecture – 3 rdEdition 123 Mission Statement An enterprise’s Mission Statement succinctly describes the purpose and direction of the enterprise. This statement should be long enough to get the point across but provide no detail (1-2 sentences is recommended).

The Mission Statement answers the “who are we” question at the level of the entire enterprise. Examples are provided below.

Mission Statement Example – Business: “The Acme Insurance Company provides high-quality, affordable business insurance to small business owners and farmers.” Mission Statement Example – Government:

“The Orange County Highway Department provides safe and efficient roadways and bridges for pedestrian and vehicle traffic.” Vision Statement An enterprise’s Vision Statement describes in abbreviated form the competitive strategy of the enterprise. This statement should be short and memorable. The Vision Statement answers the “how are we getting there?” question at the level of the entire enterprise. The following are examples of Vision Statements from business and government:

Vision Statement Example – Business: “In offering unbeatable value and service, the Acme Insurance Company will be the insurance provider of choice for small business owners and farmers.” Vision Statement Example – Government: “State-of-the art planning, execution, and responsiveness will make Orange County’s roads and bridges the safest and most efficient in the State.” Vision statements are more than advertising slogans, they are meant to help members of the enterprise understand the primary direction that is being pursued, and then be able to communicate that inside and outside of the enterprise. Strategic Direction Statement This statement establishes the strategic direction that the enterprise will pursue during the period covered by the Strategic Plan. It builds on the statements of purpose, mission, and vision, and identifies the character of the enterprise in its envisioned future state. While protecting sensitive competitive information, the statement of strategic direction should provide a guidepost for members of the enterprise to use in understanding general expectations for their contribution to survival and competitive An Introduction to Enterprise Architecture – 3 rdEdition 124 success. It should also promote understanding among external stakeholders such that trust and perceptions of value are increased.

SWOT Analysis One of the earliest activities the enterprise performs in developing a strategic plan is a ‘Strength, Weakness, Opportunity, Threat’ (SWOT) Analysis. 20 This analysis looks at internal and external factors to determine areas that the enterprise should focus on to increase its survivability and success, as well as areas that the enterprise should avoid, or decrease its exposure to. The results of the SWOT Analysis should be summarized in the Strategic Plan, and the full SWOT Analysis is archived in the EA Repository as a separate primitive artifact (S-2). Figure 6-3 provides an example of how to present the results of a SWOT Analysis.

Figure 6-3: Example of a SWOT Analysis Summary Table Concept of Operations Scenarios Enterprises may find it helpful to develop detailed current and future ‘Concept of Operations’ (CONOPS) scenarios that encompass several years of operating activity, and which take into account different combinations of internal and external drivers that were identified in the SWOT Analysis. In so doing, the enterprise can evaluate the planning assumptions and expected outcomes in each scenario and evaluate the relative merit and danger of pursuing a particular course of action. Additionally, the enterprise can refine and maintain an ongoing file of 20The SWOT analysis method was developed by Albert Humphrey in the 1960’s. Internal Factors WT W4/T1: Funding Data ST S1/T2: FED Requirements S6/T5: IT Training S1/T5: IT Awareness External Threats (T) T1. Funding T2. Market DriversT3. MergerT4. Advanced TechnologyT5. IT Adoption Rate WO W4/O4: EA Sharing SO S5/O3: Legacy Web Portals S1/O3: Security External Opportunities (O) O1. Contracting O2. GovernmentO3. New TechnologyO4. Partnerships Internal W eaknesses (W ) W1. Policy / Regulations W2. Governance ValueW3. IT Skills – SystemsW4. Enterprise ArchitectureW5. IT Skills – ProcessW6.Low Usability/Implementation Internal Strengths (S) S1. User Community S2. RelationshipsS3. Involved LeadershipS4. In-house TechnologyS5. Legacy ArchitectureS6.Training BudgetS7.Culture External Factors WT W4/T1: Funding Data ST S1/T2: FED Requirements S6/T5: IT Training S1/T5: IT Awareness External Threats (T) T1. Funding T2. Market DriversT3. MergerT4. Advanced TechnologyT5. IT Adoption Rate WO W4/O4: EA Sharing SO S5/O3: Legacy Web Portals S1/O3: Security External Opportunities (O) O1. Contracting O2. GovernmentO3. New TechnologyO4. Partnerships Internal W eaknesses (W ) W1. Policy / Regulations W2. Governance ValueW3. IT Skills – SystemsW4. Enterprise ArchitectureW5. IT Skills – ProcessW6.Low Usability/Implementation Internal Strengths (S) S1. User Community S2. RelationshipsS3. Involved LeadershipS4. In-house TechnologyS5. Legacy ArchitectureS6.Training BudgetS7.Culture External Factors An Introduction to Enterprise Architecture – 3 rdEdition 125 information on several of the most plausible scenarios in order to be able to “bracket” a range of suitable strategies and goals for successful competition. The scenario development activity may be particularly valuable to enterprises in highly dynamic and turbulent operating environments. A summary of the scenarios and planning assumptions (matrix format) is included in the Strategic Plan, while the full version of the scenarios is a separate ‘primitive’ artifact (S-3). Chapter 8 provides more details on the development of future scenarios.

Concept of Operations Graphic The CONOPS Graphic is very important to the enterprise, as it describes in one picture all of the major activities in the current CONOPS, as well as the relationship of those activities. The CONOPS graphic becomes a touchstone to help the enterprise understand what it does at a basic level.

Competitive Strategy This area of the Strategic Plan identifies how the enterprise will achieve success in pursuing its stated strategic direction. This is done at two levels: first, a general strategy related to growth, and second, a more specific strategy related to competition and/or differentiation.

First, at a general level the enterprise establishes that it intends to grow, shrink, or stabilize. Whether it is a turnaround strategy to recover lost ground, a growth strategy to enter new markets or provide new services, or a stabilization strategy to absorb and solidify recent growth or reduction, the competitive strategy must first and foremost be flexible enough to ensure survival in the face of unplanned internal and external events, and then promote success in the goals that the enterprise decides to pursue during the period of the Strategic Plan. Second, the competitive strategy is detailed in a statement regarding service and/or product differentiation and delivery. This area identifies one or more methods that the enterprise will pursue to achieve success in what it produces. Examples include delivering the highest quality; delivering the lowest price; having the most flexibility and/or options; being first-to-market; being a niche player; dominating market share; and acquiring competitors. These statements involve sensitive information, which the enterprise may want to hold in a separate addendum to the Strategic Plan. An Introduction to Enterprise Architecture – 3 rdEdition 126 Strategic Goals The enterprise’s strategic goals are those objectives that when achieved together will ensure survival and attain success, as defined in the outcome measures and performance metrics that the enterprise develops for itself. Strategic goals also serve to logically divide enterprise activities into areas that will make a meaningful and valued impact on the enterprise to move it in the direction that the Strategic Plan sets forth.

Strategic Initiatives The enterprise’s strategic initiatives are those activities which are chartered by and support strategic goals. Not all of an enterprise’s activities are strategic in nature, as some activities are support functions (i.e., payroll, accounting, IT infrastructure management, and human resources). Initiatives that are strategic in nature include those ongoing programs and specific projects that accomplish one or more strategic goals. One of the questions that executive decision makers often ask when funding decisions are made for an initiative is whether there is strategic value in the planned outcome(s). Investments that have a linkage to strategic goals are said to be “aligned”.

Outcome Measures Knowing that progress is being made on strategic goals and initiatives is imperative for an enterprise’s success. By definition, these are the activities that are the most important to the enterprise and therefore require regular review and refinement. By identifying goals and initiatives that can be measured, the enterprise is able to manage these activities. Measures are the most detailed EA component at the strategic level of the EA framework, and are found at each of the other levels as well.

It is important to understand the difference between “outcome” measures and “output” measures. Outcome measures identify progress being made toward some new end-state, such as better product quality, increased customer satisfaction, or more efficient processes. Output measures provide data on activities and things, such as how many cars are produced in a day, how many new customers are gained or lost each month, or how closely an activity meets a quality checklist. Outcome measures often have both quantitative and qualitative elements to them, while output measures are usually quantitative. Output measures are important for indicating progress in an initiative area, but it is the attainment of outcomes that correlate to goal attainment, and an enterprise’s strategic progress. Examples of outcome and output measures are provided below. An Introduction to Enterprise Architecture – 3 rdEdition 127 Outcome Measure #1: Improve the factory safety environment by reducing injuries by 5 percent within one year.

Output Measure #1-1: Increase the number of safety inspections by 10 percent.

Output Measure #1-2: Require 100 percent use of safety helmets and eyewear.

Output Measure #1-3: Require accident report completion within 24 hours. E-Commerce/E-Gov Plan An E-Commerce/E-Government Plan is often needed by an enterprise in addition to the general Strategic Plan. This is because the general Strategic Plan usually does not address IT in sufficient detail to identify the various IT-related initiatives that may enable many of an enterprise’s strategic goals. This is said in recognition that many enterprises are becoming “information centric”, in that they depend on information and on IT resources to successfully accomplish key business, manufacturing, service, research, financial, human resources, and office automation functions. The E-Commerce/E-Government Plan is more like a tactical plan due to the dynamic nature of IT resources and the processes they support. The E- Commerce/E-Government Plan should provide specific program, outcome, and performance information for a two or three-year timeframe. Beyond about three years, it is difficult to predict with accuracy what new capabilities IT will be able to provide. The E-Commerce/E-Government Plan should be updated every 1-2 years.

EA Components at the Products & Services Level EA Components : xBusiness Services xBusiness Products xIT Capital Planning Portfolio EA Artifacts : xBusiness Plan (B-1) xNode Connectivity Diagram (B-2) xSwim Lane Process Diagram (B-3) xBusiness Process/Service Model (B-4) xBusiness Process/Product Matrix (B-5) xUse Case Narrative and Diagram (B-7) xInvestment Business Case (B-8) An enterprise’s key business and support processes are documented at the Business level of the EA framework. EA components at this level include An Introduction to Enterprise Architecture – 3 rdEdition 128 business process documentation and an IT capital planning portfolio that provides business case documentation on each investment in IT that meets operational and financial thresholds. Relationships between participants in E-Commerce and E-Government activities are often referred to as “B” for business, “G” for government, and “C” for citizen, resulting in acronyms such as B2B for business-to-business and G2C for government-to-citizen. Business Services Business services are those enterprise activities that directly contribute to mission accomplishment. This can be in the form of strategic initiatives to develop new or improved services or artifacts, ongoing manufacturing activities, public service delivery, and “back office” finance, accounting, administrative, and human resource functions. Business process documentation includes flow charts and modeling techniques that detail the inputs, outputs, enabling resources, and controls of an enterprise activity. It also includes the documentation of activities that completely reengineer an organizational process (called Business Process Reengineering - BPR), and activities that provide minor adjustments to a process (called Business Process Improvement - BPI). Business Products Business products are the tangible and intangible goods that the enterprise produces in pursuit of business and strategic goals. Examples include manufactured items, financial instruments, vehicles, structures, intellectual capital, art, music, and special events. Business product documentation is important to an enterprise as it captures and protects intellectual capital and various patent, trademark, and copyrights. Also, documentation of products is useful in BPR and BPI activities. EA artifacts that document business products contain sensitive information that should be protected when it is archived in the EA repository (see Chapter 12).

IT Capital Planning Portfolio Because resources are limited in most enterprises, the value of making a significant investment in IT should be shown in order to identify the costs, benefits, and rate of return on capital. It may be shown in a manner to justify not using those resources on other initiatives (opportunity cost). A ‘business case’ for any investment is a standardized format for developing and presenting the various aspects of alternatives, cost and benefit, and return that executives are interested in. A business case should include: An Introduction to Enterprise Architecture – 3 rdEdition 129 xRequirement Statement xAlternatives Analysis xCost-Benefit Analysis xNet Present Value Calculation xReturn on Investment Calculation The IT Capital Planning and Investment Control (CPIC) process is a key management activity that is designed to plan, select, control, and evaluate the enterprise’s major investments in IT. The CPIC process works in concert with the EA Management Plan to move an enterprise from the current architecture to the future architecture on an ongoing basis. The use of standardized IT Project Management Plans helps make the CPIC process more efficient and more useful to project managers (see Chapter 10 for more information). EA Components at the Data and Information Level EA Components : xKnowledge Warehouses xInformation Systems xDatabases EA Artifacts : xKnowledge Management Plan (D-1) xInformation Exchange Matrix (D-2) xObject State-Transition Diagram (D-3) xObject Event Sequence Diagram (D-4) xLogical Data Model (D-5) xPhysical Data Model (D-6) xActivity/Entity (CRUD) Matrix (D-7) xData Dictionary/Object Library (D-8) How an enterprise uses data and information is documented at the ‘Data and Information’ level of the EA³ Cube Framework. EA components at this level include documentation on the design, function, and management of information systems, databases, knowledge warehouses, and data marts. It also includes detailed documentation on the structure and processing logic of data that the enterprise is interested in. An Introduction to Enterprise Architecture – 3 rdEdition 130 Knowledge Warehouses Knowledge warehouses evolved from large mainframe databases that served multiple applications and user groups across multiple systems and networks. A knowledge warehouse is a one-stop-shop for data and information about various activities and processes in the enterprise. The more types of data and information in the knowledge warehouse, the more valuable it is for analysis activities that extend beyond simple queries and report generation, but enable ‘data mining’ wherein all levels of the enterprise can look for patterns or new information from otherwise disparate data. This helps build new views of these activities and the enterprise.

Typically, users interact with a knowledge warehouse through a portal-like interface that enables customized access to various elements such as databases, presentations, and data, audio, and video files. A knowledge warehouse may be developed for a specific use or bought as a customizable product. Information Systems Information comes in three forms: data, information, and knowledge. Aggregation, meaning, and context are what differentiate each of these forms. Definitions are provided as follows: 21 Data : Raw facts about people, places, events, and things that are of importance in an organization. Each fact is, by itself, relatively meaningless.

Information : Data that has been processed or reorganized into a more meaningful form for someone. Information is formed from combinations of data that hopefully have meaning to the recipient.

Knowledge : Data and information that is further refined based on the facts, truths, beliefs, judgments, experiences, and expertise of the recipient. Ideally information leads to wisdom. 21Jeffrey L. Whitten, Lonnie D. Bentley. Introduction to Systems Analysis and Design . McGraw- Hill/Irwin Publishers. New York. 2006. Data Information Knowledge An Introduction to Enterprise Architecture – 3 rdEdition 131 Information systems consist of hardware and software that work together to efficiently collect and disseminate data, as well as to enable the development and analysis of information. Information systems serve many lines of business in enterprises including administrative and financial support, manufacturing, marketing and sales, government regulation, public services, and defense systems.

Information systems originally were designed to support a particular need in an enterprise and connect to a single database. As enterprises developed more uses for information systems, greater efficiencies were achieved when several information systems shared one or more databases. This movement from “stovepipe” information system designs to more distributed and integrated designs, which span the entire enterprise and which tie together via information warehouses, is one of the driving factors in the development of the concept of enterprise architecture.

Databases Databases are software applications that are designed to support the storage, retrieval, updating, and deletion of data elements and/or data objects. Data elements are the fundamental facts and values that are stored in databases. Data elements and their identifying and characteristic attributes are usually stored in relational databases that consist of data tables which are logically related to create a speedy, efficient, and flexible query capability. Data objects are discrete ‘blocks’ of code that contain attribute information about a data element as well as behaviors that create an ability for objects to interact with each other in different ways, depending on the type of triggering event. EA Components at the Systems and Applications Level EA Components : xSoftware Applications xWeb Services xService Bus and Middleware xEnterprise Resource Planning (ERP ) Solutions xOperating Systems EA Artifacts : xSystem Interface Diagram (SA-1) xSystem Communication Diagram (SA-2) An Introduction to Enterprise Architecture – 3 rdEdition 132 xSystem Interface Matrix (SA-3) xSystem Data Flow Diagram (SA-4) xSystem/Operations Matrix (SA-5) xSystems Data Exchange Matrix (SA06) xSystem Performance Matrix (SA-7) xSystem Evolution Diagram (SA-8) xWeb Application Diagram (SA-9) The systems and applications that an enterprise uses to support its business services, product delivery processes, and information flows are documented at the ‘Systems and Applications’ level of the EA³ Framework. One of the purposes of EA is to improve the integration and efficiency of the support systems and software applications across the enterprise. Duplication of functions and a lack of interoperability can be addressed through the establishment of technical and product standards for software. Components at this level range in size and complexity from large multi-function ERP solutions that extend throughout the enterprise to single-user desktop tools that enhance productivity. Software Applications Applications are software programs that provide a functional capability for “front-office” IT systems (e.g., manufacturing, sales, government services, logistics, and knowledge warehouses) or “back-office” IT systems (e.g., financial systems, human resources systems, e-mail, and office automation products such as word processors, spreadsheets, diagramming tools, photo editors, and web browsers). Enterprises often possess a myriad of applications from different vendors that are limited in their ability to function together. The selection of applications from a controlled number of vendors and/or which adhere to widely accepted standards is a method that can be used to promote the interoperability of software applications.

Web Services Just as EA trends are emphasizing the use of plug-and-play software applications; the use of web-based IT services is significantly extending and accelerating this concept. These open-standards based web services are replacing software applications that have unique hosting and access requirements. By using the TCP/IP, SOAP, and UDDI protocols for web service management and internationally-accepted formats for information retrieval/exchange (e.g., HTTP, HTML, J2EE, and XML), a common hosting and operating environment is created for web services. A web service is defined as any IT resource (e.g., application, program, database, An Introduction to Enterprise Architecture – 3 rdEdition 133 or information portal) that functions through a web-based graphical user interface (GUI), such as a web browser. Web services include email, web- based ERP applications, websites, electronic commerce systems, web- based knowledge warehouses…. virtually any front or back-office function that is web-based and which operates within the enterprise on TCP/IP based compliant internal networks (Intranets). Service-Oriented Architecture (SOA) is the EA-related movement that focuses on web services.

Service Bus/Middleware The “Service Bus” is a SOA term for a common operating environment for systems, applications, and web services that is characterized by non- proprietary open standards protocols and middleware for data exchange, software/hardware interfaces. The Service Bus is platform independent and allows any system/service to interoperate with any other system/service that is logically and physically linked to the Bus. SOA approaches promote the support of business functions through the use of shared, reusable services, which increasingly are web-based. The term that SOA approaches use for this capability is a “Virtual Enterprise Network”, and the SOA term for the Service Bus is a Network Application Platform.

Middleware is a software program that links other applications together which otherwise would not be able to exchange data and information. Examples include integrating older mainframe applications and databases to those which are web-based, or enabling the sharing of data between artifacts from different vendors that may have different application programming interfaces (APIs) that incorporate standards such as the Simple Object Access Protocol (SOAP) or the Representational State Transfer (REST) . Enterprise Resource Planning (ERP) Solutions ERP solutions are marketed by vendors as one way to increase application interoperability and reduce the duplication of functions. Often based on “modules” of capability, ERPs are essentially a suite of applications offered by the same vendor that are designed to work together to create an enterprise-wide capability. ERP solutions exist for finance, marketing, human resources, payroll and accounting, and supply chain management, all of which can be interconnected to create a relatively seamless environment for sharing information. While ERPs accomplish some of the goals of EA, they fall short of providing the holistic planning, documentation, and decision-making support that EA is intended to develop and maintain. Also, ERPs normally are not able to support all of the application requirements of the enterprise (i.e., office automation, An Introduction to Enterprise Architecture – 3 rdEdition 134 finance and accounting, product line support, executive decision-making, e-mail). This wider yet incomplete coverage of application component requirements is one of the shortfalls of ERP solutions, which the EA program can address by establishing standards for the integration of ERP modules with other applications.

Operating Systems Operating systems are applications that enable computers to provide basic networking and processing functions. Differences in operating systems are a large part of what distinguishes older centralized mainframe designs from newer decentralized client-server designs. Larger enterprises may operate computers that use several different types of operating systems, which may hinder the interoperability of these component resources. Commercial vendors traditionally have produced operating systems that are proprietary and are designed to limit integration to their own products; however, the proliferation of client-server network designs and the emergence of the Internet have forced vendors to offer operating systems that are increasingly interoperable.

EA Components at the Network & Infrastructure Level EA Components : xData Networks xTelecommunications Networks xVideo Networks xMobile Networks xCable and Wireless Backbones xSecurity Solutions xBuildings and Server Rooms xEquipment EA Artifacts : xNetwork Connectivity Diagram (NI-1) xNetwork Inventory (NI-2) xCapital Equipment Inventory (NI-3) xBuilding Blueprints (NI-4) xNetwork Center Diagram (NI-5) xCable Plant Diagram (NI-6) xRack Elevation Diagram (NI-7) An Introduction to Enterprise Architecture – 3 rdEdition 135 The Technology Infrastructure level of the EA³ Cube Framework functions to integrate and connect the enterprise’s IT resources at the application and information levels. Seamless integration of voice, data, video, and transport (cable/wireless) resources is one of the keys to creating an operationally effective and cost-efficient IT infrastructure. Data Networks Data networks are designed to transport data and information in coded digital form between various computers that support storage, retrieval, updates, and processing for end-users. These networks have a logical design that identifies how data and information will flow between systems, applications, databases, and websites. The network also has a physical design that consists of a data transmission “backbone”, an information hosting environment, and external interface points (unless it is a stand- alone system). The network backbone often consists of commercially procured routers, switches, hubs, security equipment, backup power units, equipment racks, and cable. The hosted network environment includes commercially procured computers for storage, processing, and end-users, as well as commercial software for business and office automation requirements and custom-developed software that is designed to support unique requirements. Data networks within an enterprise, referred to as Local Area Networks (LANs) or Internal Networks (Intranets) normally interface with a telecommunications network to connect to the global Internet. Enterprise-specific External Networks (Extranets) are also known as Wide-Area Networks (WANS).

Telecommunications Networks Telecommunications networks are designed to transport voice signals in coded form (analog waves or digital electron/photon flows) between end- users. These networks also have a logical design that