THIRD EDITION An Introduction to Enterprise Architecture Scott A. Bernard NetLwinoesr okf Business NInefrtawsotrrkucture InfrastructuGroeals & Network C y Initiatives kills rateg InfPrNInaresforttawdrusoutcrrctkuutcsrte u&re OMP S t ds / ss –S NIneStfwrNeaoersvtrtwkricuoecrstkure ONE dar ne InfrastruDcatutare & N an usi InforNmeatwtioornk TS St B NIentfwraosrtkructure curity / nology – InAfprNSapIneysltfstiwrNrcatuoeaescmtrtttwkiruousornc er&tskure e h S c InfNraesttwruocrtkusre & e T Infrastructure EA3Cube Framework™ AuthorHouse™ 1663 Liberty Drive Bloomington, IN 47403 www.authorhouse.com Phone: 1-800-839-8640 © 2012 by Scott A. Bernard. All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted by any means without the written permission of the author. INTERNATIONAL EDITION Copyright © 2012. Exclusive rights by Scott A. Bernard for translation, manufacture, and export. Published by AuthorHouse 08/07/2012 ISBN: 978-1-4772-5800-2 (sc) ISBN: 978-1-4772-5801-9 (e) Library of Congress Control Number: 2012914406 Any people depicted in stock imagery provided by Thinkstock are models, and such images are being used for illustrative purposes only. Certain stock imagery © Thinkstock. First published by AuthorHouse 08/25/04 (First Edition) 08/25/05 (Second Edition) This book is printed on acid-free paper. Because of the dynamic nature of the Internet, any web addresses or links contained in this book may have changed since publication and may no longer be valid. The views expressed in this work are solely those of the author and do not necessarily reflect the views of the publisher, and the publisher hereby disclaims any responsibility for them. Table of Contents Foreword 7 Preface 11 Section I. The Concept of Enterprise Architecture 21 Case Study:Danforth Manufacturing Corporation 23 Introduction: Will this be an Architected Enterprise? 29 1 An Overview of Enterprise Architecture 31 2 The Structure and Culture of Enterprises 51 3 The Value and Risk of Creating an Enterprise Architecture 67 Section II. Developing an Enterprise Architecture 81 4 ImplementationMethodology 89 5 Documentation Framework 103 6 Architecture Components and Artifacts 117 7 Developing Current Architecture Views 141 8 Developing Future Architecture Views 165 9 Developing an Enterprise Architecture Management Plan 181 Section III. Using an Enterprise Architecture 199 10 The Role of Investment Planning and Project Management 205 11 The Role of Security and Privacy 221 12 The Enterprise Architecture Repository and Support Tools 233 Section IV. Future Trends in Enterprise Architecture 251 13 Future Trends in Enterprise Architecture 253 Concluding Thoughts 265 Appendices A Business Case for an Enterprise Architecture Component 267 B Example Approach to Architecture: Federal Government 271 C Example Approach to Architecture: State Government 277 D Example Approach to Architecture: Defense Department 279 E Example Approach to Architecture: The Open Group 281 F Examples of Enterprise Architecture Artifacts 283 Glossaryof Terms 331 Subject Index 335 Foreword By John A. Zachman I am delighted that Scott Bernard has written this book, “An Introduction to Enterprise Architecture.” We need as much focus on this critical issue as possible, especially in the academic environment and especially as we continue the transition into the Information Age. It is my opinion that this issue of Enterprise Architecture is not well understood in the ranks of General Management who see Enterprise Architecture as just an I/S or IT issue, nor in the ranks of I/S management who see it as taking too long and costing too much, nor in the ranks of academia who tend to focus on what they perceive constitutes current market demand, typically a promising technology. My opinion is, Enterprise Architecture may well be the “Issue of the Century.” In fact, I felt strongly enough about this issue that I published an article by that title in the year 2000, the turn of the Century. Exacerbating the problem, we seem to have raised a generation of people, the “web generation,” who are facile with the technology, but as a result seem to think that the solution to all problems lies in technology. They are tempted to see strategy and architecture, engineering and design, modeling and methodologies as prehistoric, the preoccupation of cave men. Now, real men do Java … or whatever constitutes the current “silver bullet,” technological panacea. I have a wise and profoundly insightful friend, Roger Greer, who was the Dean of the School of Library and Information Management at the University of Southern California. I sat on his advisory council for many years and he observed that a few decades ago, the library community became enamored with the technologies of the library and lost sight of their reason for being, which he argued was to identify problems of the community and to assemble the required knowledge to bring to bear and participate in solving the problems. Now it appears that many universities are de-committing the Library Schools because they are simply technical, storing and retrieving books. There is no conceptual substance requiring research or advanced degrees. You can learn how to store books and find them again in secondary schools. In fact, USC discontinued Roger’s School because of the persistence of the technical perceptions on the part of the Administration. In fact, I was having lunch with the Dean of the Library School at the University of California, Berkley the day they de-committed that school on the same basis. An Introduction to Enterprise Architecture – 3rdEdition 7 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 fact, I am afraid that the same thing may have happened at the Business School, Information Systems Department at UCLA as I have not seen any of my academic friends from UCLA for several years. I know I have a rather radical view of this, but my observation would be the whole reason you want people with technical skills in your Enterprise is not for building and running systems. Anybody can build and run systems, the employment of the technology. The reason you want these kinds of people in your Enterprise is because they have the capability of engineering and manufacturing your Enterprise for you. That’s the reason for their being, NOT simply for building and running systems. I have some strong convictions that the raw material for engineering and manufacturing Enterprises are primitive models, not composite models. Composite models are for implementations, the embodiment of the technologies. Primitive models are for architecture, ENTERPRISE Architecture. I don’t think it is possible to engineer and manufacture enterprises without building and managing primitive models. It is similar to elements and compounds. Before Mendeleyev defined the periodic table of elements, chemistry was not a science. It was alchemy, working with compounds, trial and error, unpredictable. In like fashion, I believe that until Enterprise Architects understand and manage the primitive (elementary) constructs, Enterprise Architecture is dealing with composites (compounds), technical implementations. It is not a science and is not predictable and it is not engineering and manufacturing Enterprises. An Introduction to Enterprise Architecture – 3rdEdition 8 Although, Scott does not necessarily share my rather strong and radical convictions, he graciously makes reference to them several times in the body of his work, which I greatly appreciate. In any case, I feel strongly, we must infuse these critical Enterprise Architecture ideas into the next generation, through the academic environment. We sorely need a generation of people who understand and are committed to these complex issues that will persevere and see Enterprise Architecture become a reality. If we fail to bring these longer term issues into focus and continue only to focus on technology, on implementations, short term propositions, we will not only sacrifice our legitimacy as a discipline, but from an Enterprise standpoint, may even forfeit the Enterprise’s continued viability. I was visiting a major telecommunications service provider recently in which some of the management folks got into a rather heated discussion about what was more important, to serve the customer … or to increase the stock price. I would not argue that it is unimportant to increase the stock price, but I would suggest that this is a very short term perspective. If somebody doesn’t pay attention to the customer in this very competitive industry, you may find yourself out of the game in the longer term and your stock price might not even appear anymore in the newspaper. It is not EITHER the short term OR the long term. It is the short term AND the long term. I am not arguing that technical implementations, composites, building and running systems in the short term are unimportant, but I am arguing that if we don’t pay attention to our reason for being, to engineering and manufacturing Enterprises, to primitive models, ENTERPRISE ARCHITECTURE in the longer term, we may well forfeit either our relevance as a discipline … or sacrifice the continuing viability of the Enterprise in the process. Engineering and manufacturing Enterprises is the context within which building and running systems becomes relevant. By the way, this has profound conceptual implications for research and advanced degrees in academia. Scott Bernard has taken a major step in intensifying the focus on these critical issues and I am particularly pleased that he has produced this work as a textbook for the academic environment. “Introduction to ENTERPRISE ARCHITECTURE”! Our hope lies in the new generation’s capacity to grasp its significance and persist in its realization. Thank you, Scott Bernard! John A. Zachman Glendale, CA 2004 An Introduction to Enterprise Architecture – 3rdEdition 9