Bernard S. An Introduction To Enterprise Architecture 3ed 2012.pdf

THIRD EDITION An Introduction to Enterprise Architecture Scott A. Bernard 2 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) 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. 3 Contents Foreword Preface About the Author Section I The Concept of Enterprise Architecture Case Study: Danforth Manufacturing Company Introduction Will this be an Architected Enterprise? Chapter 1 An Overview of Enterprise Architecture Chapter 2 The Structure and Culture of Enterprises Chapter 3 The Value and Risk of Creating an Enterprise Architecture Section II Developing an Enterprise Architecture Chapter 4 The Implementation Methodology Chapter Overview Chapter 5 The Analysis and Documentation Framework Chapter 6 Components and Artifacts Chapter 7 Developing Current Architecture Views Chapter 8 Developing Future Architecture Views Chapter 9 Developing an Enterprise Architecture Management Plan Section III Using an Enterprise Architecture Chapter 10 The Role of Investment Planning and Project Management Chapter 11 The Role of Security and Privacy Chapter Overview Chapter 12 The Enterprise Architecture Repository and Support Tools Section IV Future Trends in Enterprise Architecture Chapter 13 Future Trends in Enterprise Architecture Appendix A Developing a Business Case for an Enterprise Architecture Component Appendix B Example Approach to Enterprise Architecture: The U.S. Federal Government Appendix C Example Approach to Enterprise Architecture: National Association of State CIOs Appendix C Example Approach to Enterprise Architecture: Department of Defense Architecture Framework Appendix E Example Approach to Enterprise Architecture: The Open Group Architecture Framework Appendix F Enterprise Architecture Artifacts Glossary of Terms 4 5 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. In “The Next Information Revolution” article published in Forbes ASAP August 24th, 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 6 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. 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 7 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 8 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 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, 9 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 EA3 “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 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 EA3 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 EA3 Cube 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 EA3 Cube Framework. The EA3 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 EA3 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 EA3 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 10 Bus by promoting the use of EA components that are based on open-standards/protocols and nonproprietary solutions. 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. 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 students1 11 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 EA3 Cube Framework, EA3, and Living Enterprise are registered Trademarks. All rights are reserved. Concepts for the EA3 Cube Framework, EA3, Living Enterprise, and the Organizational Network 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 EA3 Cube Framework, EA3, Living Enterprise, and the Organizational Network 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 EA3 “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 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 EA3 Cube Framework, EA3 logo, Living Enterprise, and Organization Network 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 EA3 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. 12 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. 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 13 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 EA3 CubeTM 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.™ 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. 14 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 Introduction Will 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 Company3 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 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. 15 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. 16 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 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 17 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.” 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 18 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 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 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 19 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.” 20 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-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- 21 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. 22 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. 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. 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. By developing current and future versions of this integrated view, an enterprise can manage the transition from current to future operating states. 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 23 duplication and inefficiency in resources, and a lack of overall agility can result. 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 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. EA = S + B + 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 14th Century form states that “entities should not be multiplied unnecessarily”. It is my hope that the equation EA = S + B + T and the EA3 Cube 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 24 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. 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 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 25 “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 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 26 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 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 an analysis and design method that 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 an analysis 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 alignment, develops standardized policy, enhances decision support, and guides development activities. EA can help to identify gaps in the performance of line of business activities/programs and the capabilities of supporting IT services, systems, and networks. 27 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 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 28 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. 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, 29 which has a cubic shape with three dimensions that relate to different aspects of modeling the abstracted enterprise. Figure 1-7: EA3 Cube Analysis & Design Framework Known as the EA3 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 Lines of Business (LOBs). For example, each LOB has a complete sub-architecture that includes all five hierarchical levels of the EA3 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 segment of the overall 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: 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. 30 EA Analysis and Design Element #2: EA Components EA components are changeable goals, 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 EA3 Cube framework, and Chapter 6 provides additional details. 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. 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 online EA repository to make them useable by various EA stakeholders. EA Analysis and Design Element #4: Future Architecture 31 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. 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 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. 32 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.). 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 EA3 Cube framework are used for illustration. Notice how the questions build in a way that reflects the hierarchical relationships between the levels of the EA3 Framework. Each area of the EA3 Framework represents a functional area of the enterprise. The EA3 Framework 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 33 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 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? 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 34 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 EA3 Cube Framework. Chapter 12 provides additional details on the design and function of an EA repository. Figure 1-10: Example EA Repository Design-Living EnterpriseTM 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 multilevel 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? 35 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 EA3 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? 36 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 culture in 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 stakeholders to 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. 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 organization 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. 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 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. 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. 37 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. Figure 2-1: Influences on the Field of Enterprise Architecture The Structure of Enterprises Figure 2-2: Leavitt Diamond 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. 38 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. 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.7Thompson 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 Structure Function Level Parson’s Purpose of each Level Thompson’s Activities of the Level Where the organization establishes rules and relates to the larger society as it The organization is very open to the derives legitimization, meaning, and environment in order to determine Institutional higher-level support, thus making its domain, establish boundaries, and possible the implementation of secure legitimacy. organizational goals. Where mediation between the organization and the immediate task environment occurs, where the A dynamic of mediation occurs Managerial organization’s internal affairs are where less formalized and more administered, and where the political activities occur. organization’s products are consumed and resources supplied. The organization is “rational” as it carries on production (input/output) Where the actual “product” of an functions and tries to seal off those Technical organization is processed. functions from the outside to protect them from external uncertainties as much as possible. Figure 2-3: Parson/Thompson Model of Enterprises 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 39 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. 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 40 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 Team sets policy and goals, approves resources, and evaluates results, while semi-autonomous Functional Teams and Independent Workers manage ongoing programs/lines of business, new development projects, and team-specific resources. The Functional Teams and Independent Workers receive 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 EA3 Cube Framework. 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. 41 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 of ve

Bernard S. An Introduction To Enterprise Architecture 3ed 2012.pdf

Document Details

Tags

Related

Full Transcript

Upgrade to continue