An introduction to enterprise architecture ea3 free download

Transcription

1

2

3 THIRD EDITION An Introduction to Enterprise Architecture Scott A. Bernard Security / Standards / Skills Technology Business Strategy Lines of Business Goals & Initiatives Products & Services Data & Information Systems & Applications s & EA 3 Cube Framework C O M P O N E N T S

4 AuthorHouse 1663 Liberty Drive Bloomington, IN Phone: 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 Exclusive rights by Scott A. Bernard for translation, manufacture, and export. Published by AuthorHouse 08/07/2012 ISBN: (sc) ISBN: (e) Library of Congress Control Number: 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.

5 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 1 An Overview of Enterprise Architecture 31 2 The Structure and Culture of Enterprises 51 3 The Value and Risk of Creating an Enterprise Architecture 67 Section II. Developing an Enterprise Architecture 81 4 Implementation Methodology 89 5 Documentation Framework Architecture Components and Artifacts Developing Current Architecture Views Developing Future Architecture Views Developing an Enterprise Architecture Management Plan 181 Section III. Using an Enterprise Architecture The Role of Investment Planning and Project Management The Role of Security and Privacy The Enterprise Architecture Repository and Support Tools 233 Section IV. Future Trends in Enterprise Architecture Future Trends in Enterprise Architecture 253 Concluding Thoughts 265 Appendices A Business Case for an Enterprise Architecture Component 267 B Example Approach to Architecture: Federal Government 271 C Example Approach to Architecture: State Government 277 D Example Approach to Architecture: Defense Department 279 E Example Approach to Architecture: The Open Group 281 F Examples of Enterprise Architecture Artifacts 283 Glossary of Terms 331 Subject Index 335

6

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 rd Edition 7

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 rd Edition 8

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 rd Edition 9

10

11 Preface Intended Audience An Introduction to Enterprise Architecture is 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 Architecture is 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 rd Edition 11

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 Architecture provides 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 rd Edition 12

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 Architecture presents 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 3 Cube Framework is component-based in that the building blocks of each of the sub-architectures are plug-andplay 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 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 nonproprietary solutions. An Introduction to Enterprise Architecture 3 rd Edition 13

14 Organization of This Book An Introduction to Enterprise Architecture is 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 Architecture is 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 rd Edition 14

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 3 Cube Framework, EA 3, and Living Enterprise are registered Trademarks. All rights are reserved. Concepts for the EA 3 Cube Framework, EA 3, Living Enterprise, and the Organizational Model were 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 3 Cube Framework, EA 3, Living Enterprise, and the Organizational Model were 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 1 Spewak, Steven. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. New York: John Wiley & Sons Publishers 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 rd Edition 15

16 academic and professional conferences in and are copyrighted by Dr. Bernard separate from this or any other publication. Permission for the use of the EA 3 Cube Framework, EA 3 logo, Living Enterprise, and Organization Model is 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, 2 and 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. 2 Zachman, J.A. A Framework for Information Systems Architecture. IBM Systems Journal: Volume 26, Number 3, Page An Introduction to Enterprise Architecture 3 rd Edition 16

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 rd Edition 17

18

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-ofbusiness 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 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 Operations for the Joint Chiefs of Staff. An Introduction to Enterprise Architecture 3 rd Edition 19

20

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 Introduction Chapter 1 Chapter 2 Case Study Chapter 3 Scene 1: Possible Need for an EA Program Will this be an Architected Enterprise? An Overview of Enterprise Architecture The Structure and Nature of Enterprises Scene 2: Considering an EA Program 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 allencompassing. 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 3 The 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 rd Edition 21

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 rd Edition 22

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 rd Edition 23

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 rd Edition 24

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 rd Edition 25

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 decisionmaking. 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 rd Edition 26

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 rd Edition 27

28

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 rd Edition 29

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 rd Edition 30