Erickson Methodology for Enterprise Architecture: How to Achieve a 21St Century Enterprise Architecture Services Capability.

By Douglas T. Erickson, Donald B. Phillips and John A. Zachman

This book describes a methodology for architecting, designing, and constructing an enterprise that specifies what to do, but more importantly, how to it, and why you would want to do it that way! The methodological concepts, principles, conventions, and practices presented in this book have been developed and put into practice for over 25 years; and the results are dramatic and worthy of pursuit by any enterprise.

• Language: English
• Publisher: iUniverse
• Release date: Dec 20, 2020
• ISBN: 9781532099953

Douglas T. Erickson

Douglas T. Erickson Douglas Erickson has been an Information Management and Enterprise Architecture practitioner and consultant for over forty years. Doug has been a career-long advocate for the advancement, improvement, and formalization of the enterprise systems development process. In 1979, Doug met John A. Zachman. This started a decades-long pursuit, as a student and practitioner, to understand and apply the concepts and principles of Enterprise Architecture. By the early 1980’s, Doug had developed the beginnings of what is known today as the Erickson Methodology for Enterprise Architecture. The use of the EMEA has been used to deliver implementable Enterprise Architecture, achieve enterprise agility, business process alignment and integration, and data management that has produced results that improve data quality, shareability, and availability, across multiple organization units and applications, cost-effectively. He has extensive business and information management experience based on his work with enterprises in variety of industries including engineering and manufacturing, insurance, airline, electric utility, natural gas distribution, the U. S. Army, and state government agencies. Doug has a degree in Business Administration from Black Hills State University, with MBA coursework at Arizona State University. Donald B. Phillips Donald Phillips has over 40 years of experience in the IT industry in a variety of roles including applications development and database design in a variety of information technology environments. He has been a consultant as an information systems development facilitator leading to the successful design, development, and implementation efforts on projects based on the Erickson Methodology for Enterprise Architecture. In the course of this work, Don has contributed greatly to the innovations that led to the viability of the EMEA. Don has exceptional skills in leading, teaching, and mentoring people in their professional development. Don graduated from Pepperdine University with a B.A. in 1969. His information systems career started in the U.S. Navy as a Data Processing Technician where he completed programming school in the Navy and worked as a developer and in technical support. After the Navy, he completed graduate level courses in statistics, business, and information systems at Texas Tech University.

Book preview

Copyright © 2020 Douglas T. Erickson.

All rights reserved. No part of this book may be used or reproduced by any means, graphic, electronic, or mechanical,

including photocopying, recording, taping or by any information storage retrieval system without the written

permission of the author except in the case of brief quotations embodied in critical articles and reviews.

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.

iUniverse

1663 Liberty Drive

Bloomington, IN 47403

www.iuniverse.com

844-349-9409

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.

Any people depicted in stock imagery provided by Getty Images are models,

and such images are being used for illustrative purposes only.

Certain stock imagery © Getty Images.

ISBN: 978-1-5320-9994-6 (sc)

ISBN: 978-1-5320-9996-0 (hc)

ISBN: 978-1-5320-9995-3 (e)

Library of Congress Control Number: 2020914814

iUniverse rev. date: 09/28/2022

23049.png

TABLE OF CONTENTS

Dedication

William Darlage Testimonial

Foreword

Preface

Part One:

An Introduction to Enterprise Architecture

1.1 Enterprise Architecture: What Is It?

1.2 Enterprise Architecture versus Enterprise Management

1.3 Enterprise Architecture: What Is Its’ Value?

1.4 Choosing How to Do Enterprise Architecture

1.5 Introduction to Enterprise Architecture Services for the 21st Century

1.6 What About TAFIM, C4ISR, DODAF, MODAF, UAF, AND TOGAF?

Part Two:

The Enterprise Architecture Challenges

2.1 Introduction

2.2 The IT Job-Shop Business Model

2.3 The Obsession with Budgets and Schedules

2.4. The Search for the Silver Bullet.

2.5. The Focus on Who does What; and Lack of Focus on How and Why

2.6. The Build Versus Buy Conundrum

2.7. Overly Focusing On Projects (Tactical) Not On The Enterprise (Strategic)!

Part Three:

The Erickson Methodology for Enterprise Architecture: How to Architect an Enterprise

3.1 Introduction

3.2 How to Perform the Enterprise Architecture Planning Phase (EAPP) (ZFEA Columns 1-6, Rows 1-2)

3.2.1 Introduction

3.2.2 Establish an Enterprise Architecture Planning Phase (EAPP) Project

3.2.2.1 Establish an EAPP Leadership Team

3.2.2.1.1 Select EAPP Enterprise Sponsor

3.2.2.1.2 Select EAPP Facilitator

3.2.2.1.3 Select EAPP Project Manager

3.2.2.2 Select EAPP Project Team Members

3.2.2.3 Select EAPP Project Support Team Members

3.2.2.4 Establish EAPP Project Facilities

3.2.2.5 Establish EAPP Project Team Work Routine

3.2.2.6 Develop EAPP Project Plan

3.2.2.6.1 Enterprise Architecture Planning Criteria

3.2.2.6.2 Obstacles to Effective Enterprise Architecture Planning

3.2.2.7 Conduct EAPP Team Orientation

3.2.3 Develop Enterprise Architecture Plan

3.2.3.1 Introduction

3.2.3.2 Develop Enterprise Scope Motivation Model (SMM) and Conceptual Motivation Model (CMM)

3.2.3.3 Develop Enterprise Scope Process Model (SPM) and Conceptual Process Model (CPM)

3.2.3.4 Develop Enterprise Scope Data Model (SDM) and Conceptual Data Model (CDM)

3.2.3.4.1 Develop Enterprise Scope Data Model (SDM)

3.2.3.4.2 Develop Enterprise Conceptual Data Model (CDM)

3.2.3.4.3 Develop Enterprise Information Architecture

3.2.3.4.4 Develop Logical Business Process Data Dependence Model

3.2.3.4.5 Develop Enterprise Entity-Relationship Model

3.2.3.5 Develop Enterprise Scope Location Model (SLM) and Conceptual Location Model (CLM)

3.2.3.6 Develop Enterprise Scope Organization Model (SOM) and

3.2.3.7 Develop Enterprise Scope Time Model (STM) and Conceptual Time Model (CTM)

3.2.3.8 Identify and Define Enterprise Strategic Issues

3.2.3.9 Develop Enterprise Architecture Implementation Prioritization

3.2.3.10 Develop Enterprise Architecture Strategy Plan (EASP)

3.3 How to Architect an Enterprise (ZFEA Row 3)

3.3.1 Establish an Enterprise Architecture Implementation Project (s) (EAIP).

3.3.1.1 Establish an EAI Oversight Group

3.3.1.2 Select EAIP EMEA Facilitator

3.3.1.3 Select EAIP Project Manager

3.3.1.4 Select EAIP EAP Facilitator (Also see Section 3.3.1.2)

3.3.1.5 Select EAIP EMEA EEP/EMP Facilitator

3.3.1.6 Select EAIP EAP Team Members

3.3.1.7 Select EAIP EEP/EMP Team Members

3.3.1.8 Establish EAP Facilities

3.3.1.9 Develop EAIP Project Plan

3.3.1.10 Conduct EAIP Team Orientation

3.3.2 Architect Enterprise Motivation (ZFEA Why Column, Row 3)

3.3.2.1 Develop Logical Product Motivation Model (PMM)/Logical Service Motivation Model (SMM)

3.3.2.2 Develop Logical Market Motivation Model

3.3.3 Architect Enterprise Data (ZFEA WHAT Column, Row 3)

3.3.3.1 The Enterprise Data Problem

3.3.3.2 The Enterprise Data Problem Solution

3.3.3.2.1 Adopt the Concept of an Enterprise Universe of Discourse

3.3.3.2.2 Adopt Fundamental Data Modeling Methodology Changes

3.3.3.3 Develop Enterprise Logical Data Model (ZFEA WHAT Column, Row 3, and Enterprise Database (ZFEA WHAT Column, Row 4)

3.3.3.3.1 Introduction

3.3.3.3.2 Criteria for Achieving High Quality, Cost-Effective Enterprise Data

3.3.3.4 Adopt Enterprise Database (EDB) Concept

3.3.3.5 Adopt Enterprise Data Services (EDS)

3.3.4 Architect Enterprise Business Processes (ZFEA HOW Column, Row 3)

3.3.4.1 The Business Process Problem

3.3.4.2 The Business Process Problem Solution

3.3.4.3 Develop Enterprise Business Process Architecture

3.3.4.3.1 Extend the Logical Business Process Decomposition to the Elementary Business Processes

3.3.4.3.2 Develop Business Process Specifications

3.3.5 Architect Enterprise Location (ZFEA WHERE Column, Row 3), Architect Enterprise Organization (ZFEA WHO Column, Row 3)

3.3.5.1 Develop Enterprise Logical Location Model (ZFEA WHERE Column, Row 3)

3.3.5.2 Architect Enterprise Organization (ZFEA WHO Column, Row 3)

3.3.6 Architect Enterprise Time (ZFEA WHEN Column, Row 3)

3.4 Enterprise Architecture (EA) Facilitation Skills

3.4.1 General Knowledge, Skills, and Expertise

3.4.1.1 Language Skills

3.4.1.2 Socratic Questioning Technique

3.4.1.3 Thinking Skills

3.4.1.4 Inductive and Deductive Reasoning

3.4.1.5 Facilitator Education, Background, and Experience

3.4.1.5 Facilitator Attitude, Character, and Behavior

3.4.2 General Enterprise Knowledge

3.5 Summary

APPENDIX A:

Graphics Legend

Douglas T. Erickson

Donald B. Phillips

DEDICATION

I dedicate this book to my parents, Lawrence and Agnes Erickson. They exemplified, to me, what parents should be and do. They set the example of how to be a person who could be courageous, respected as a person, and who had value to others. I am profoundly glad that I am their son! However, I am still striving to meet their example!

My special recognition of Catherine Banning for sharing her life, and sustaining and abiding me through my effort to write this book. Along the way she taught me something about love and appreciation for another.

— Doug Erickson

To my wife, Diann, for her patience and understanding – for enduring those times I was away on projects - for calling her on our anniversary while I was having dinner with Doug many miles away.

— Don Phillips

William Darlage Testimonial

"It is my opinion that the methodology used on this project to define and understand explicitly (to the excruciating level of detail) the business processes and needs, and then to develop a system that meets those needs has been successful. From a data integrity perspective, having each piece of information identified by date/time, stored only once, and used as required exceeded our expectations.

Based on our experience this combination of methodology, tools, and skills should be the platinum standard employed on all future projects since it produces an exceptional level of quality and efficiency.

Willian Darlage, CPCU, Director, Actuarial Department, Ohio Bureau of Workers’ Compensation referring to results achieved using the Erickson Methodology for Enterprise Architecture.

FOREWORD

I have known Douglas T. Erickson almost before he became known as Doug Erickson! It was probably about 1980 when we first met. Sometime in 1980, I was traveling through Phoenix, Arizona. I called Doug from the airport about 4:30 in the afternoon and asked him if I could come to his office for a discussion on an idea I had. He said he would wait for me at his office. Little did he know, nor I, that that conversation would last until after 1:00 AM the next morning. I did not have prepared architecture material at the time, but I had the initial concept in mind.

During that extended discussion, I drew the rudiments of what would eventually become the Zachman Framework for Enterprise Architecture on his whiteboard. Of course, it did not take me seven to eight hours to draw my idea on Doug’s whiteboard, but the exchange of ideas was productive, encouraging, and time-consuming. After all of these years, that conversation continues.

At that time, Doug was the Manager, Data Management for Motorola Government Electronics Group, working for Carl Simcox, the Director, Management Systems.

Doug, and one of his direct reports, John Kuzmic, was beginning to build relational data models. However, Doug was also in a position to apply some of the architecture concepts he and I had discussed.

In 1980, a decision was made to redevelop an existing system.

Doug and John convinced Carl to require the programming folks to use the normalized data that Doug and John had defined in the logical data model.

The systems development staff, managed by Joe Burda, to say the least, was not enthused! It is impossible! The system performance will be unacceptable, and it will take more time since we have never done this before! Besides, we don’t even have a Relational DBMS!

I don’t know exactly what Carl did or said, or what exactly changed people’s minds, but knowing Carl, he encouraged his staff to listen to and consider the possibilities. Within a couple of weeks, Joe Burda, with the recommendation of the Project Manager, Dale Whitmarsh, agreed to proceed as Doug was proposing.

The implemented systems performed better than anything they had done before, and the project was completed on schedule and under budget!

Sometimes the stars do align just right!

Carl ultimately went on to become the Director, Telecommunications for Motorola Inc. in Chicago, and Doug became the author of the Erickson Methodology for Enterprise Architecture.

In fact, Doug shatters a number of IT shibboleths in the book, including why you should design databases, one-for-one identical to the normalized logical data models, AVOIDING DE-NORMALIZATION FOR PERFORMANCE REASONS … a common, misguided myth in IT!

I sketched out the early versions of my framework around 1980, wrote the original article in ’82, published internally in IBM in ’84, and in the IBM Systems Journal in 1987.

Any of you who might read this book may well have heard me talk about Enterprise Architecture and know that I ALWAYS say that I did not invent my framework (the Zachman Framework for Enterprise Architecture). I saw the pattern in Buildings (the older discipline of Architecture and Construction) and Industrial Products (the older discipline of Engineering and Manufacturing). I changed the names to be enterprise names rather than Building or Industrial Product Names.

Doug began his Motorola life in Logistics and really knew Engineering and Manufacturing. He was infinitely helpful to me for understanding the Engineering/Manufacturing pattern and its correlation with enterprise Engineering and Manufacturing. In fact, many times, I say that I learned everything I know from Doug Erickson … but Doug says that he learned everything he knows from me! In fact, he quotes me extensively in the book, which I humbly and immensely appreciate.

What’s important is what we learned, not who learned from whom. I was learning and validating the conceptual, ontological classification structure for all the facts that exist and that are relevant to the existence of the enterprise. Doug was learning his methodological formalism for populating my ontological structure with actual enterprise descriptive representations. Clearly, it was mutually beneficial and has resulted in a lengthy and continuing association and discussion.

Our association and discussion illustrates a profoundly essential and far-reaching principle that I am confident is a law of nature that few people understand.

Enterprise Architecture requires a methodology that populates an Ontological Structure and provides ORDER and NORMALIZATION of all the relevant facts about the enterprise.

In contrast, a methodology that does NOT populate an Ontological structure WILL produce implementations that are NOT ordered, NOT integrated, NOT reusable, NOT interoperable, NOT aligned with management requirements, NOT accommodating extreme enterprise complexity, and NOT facilitating extreme enterprise change.

In fact, a methodology that does not populate an Ontological Structure produces a plethora of implementations of such cumulative technical diversity and complexity that they become virtually unintelligible and fraught with potential unintended consequences such that the risk of change becomes prohibitive.

In the words of Fred Brooks (author of The Mythical Man-Month and There Are No Silver Bullets) a brand new, from-the-ground-up redesign is necessary … and Fred was only referring to a system, not to the entire enterprise, the totality of ALL the systems.

If you have been building systems for 50 years or so with no ontological structure, what I am observing is that at some point, you will be faced with talking about a brand new, from-the-ground-up, redesigned enterprise. (By the way, there are ways for doing this incrementally and seamlessly based on resource and time availability when it becomes an issue.)

In retrospect, I explicitly KNOW that I accidentally happened to stumble across what I am confident now is THE ontological structure of descriptive representations for Enterprises. We looked at buildings, airplanes, automobiles, computers, ships, every complex object we had access to, including enterprises, and the pattern is the same. It matters not what the architectures are describing, the ontological pattern is identical: "Architecture IS Architecture IS Architecture¹."

My framework is (and ANY ontologically-defined framework should be) completely neutral as to how one chooses, methodologically, to populate the descriptive representations, that is, the contents (the models): top-down, bottom-up, left-to-right, right-to-left, where to start, what composite implementations to support, etc., etc. The Architecture population Methodology is one significant thing that makes one product (result) different from another. In fact, the Japanese taught the Western manufacturers that if you change the process, you change the result.

I have spent 50 years doing research around my framework, and although, in my 1993 article in the IBM Systems Journal, I made reference to the fact that there were at least four relevant, different, meta-related frameworks in every enterprise, I have not publically elaborated this fact extensively because one need not know about this to begin formalizing the architectural design of an enterprise.

The learning curve is a little flat, and the nature of the Framework (and authentic Architecture in general) makes it relatively easy to adjust for the meta structures after the fact. I only mention this because I am sure there are some adjustments I could discuss with Doug that might be helpful to include in future editions of the Methodology book.

You might not think that a discussion of my framework, the Zachman Framework, the Enterprise Ontology, is appropriate in the Foreword to the Erickson Methodology for Enterprise Architecture book. However, this is an extremely significant discussion because the subject of this discussion is precisely what differentiates the Erickson Methodology for Enterprise Architecture from all other Enterprise Architecture methodologies!

In 2020, I do not know of ANY other methodology² that deliberately and precisely employs the concepts of my framework.

From this limited discussion, I hope I have been able to make clear that my Framework for Enterprise Architecture IS actually ENTERPRISE ARCHITECTURE. It is identical to the framework of descriptive representations for architecting and constructing Buildings as well as for designing and manufacturing every other existing industrial product.

It is not reasonable to suggest that the descriptive representations for designing and manufacturing an enterprise are going to be any different from the descriptive representations required for designing and manufacturing every other complex object that humanity has ever created.

You can argue with me that enterprises are different … but airplanes are different from buildings, which are different from computers, which are different from coffee cups, etc., etc. as well. The characteristics that make enterprises different from buildings and computers and airplanes and battleships and every other created object are the very characteristics that make Enterprise Architecture more critical and yet identical to the descriptive representations of every complex object … in fact, identical to every other object, however complex or simple the object may be.

To be VERY direct, what I am observing is: if you (your methodology) are not producing the Primitive, single-variable, ontologically-defined, normalized, descriptive representation as prescribed by the Zachman Framework, the Enterprise Ontology, you are NOT doing Enterprise Architecture! The Enterprise Ontology is architecture for every other object created by humanity. If you are not producing those ontologically-defined descriptive representations, models, you may be doing something useful, and I would never suggest that you stop doing it, especially if it is helpful. So, forgive me for being so dogmatic, but it simply is NOT Enterprise Architecture.

The Foreword to Doug’s book is not the place to discuss the logic and foundation for my somewhat irreverent and epigrammatic assertion. I can only hope that you can hear the gist of my observations and indulge me long enough to understand the implications.

As evidence that the Erickson Methodology for Enterprise Architecture is actually producing Enterprise Architecture, the resultant enterprises are a) designed for extreme complexity and b) designed for extreme rates of change. The data and process implementations are high-performance, enterprise-wide, normalized, integrated, reusable, flexible, aligned, able to reproduce any snapshot of the enterprise at any given moment in time, in whatever state the enterprise existed or will exist at any precise moment, stable with only minor modifications for however many years the enterprise has existed or will exist.

This is not some fluke, aberration, result of sunspots, or something! Doug has the evidence to prove the results.

This book is full of Enterprise Architecture wisdom including EA Team composition, modeling session facilitation, organizing for Architecture management, and a lot of actual model examples for standard entities including Person, Enterprise, Project, etc., etc. that show how to model for change by adding data rather than changing record structure (which would require rewriting all the code that touches the changed record) and how to accommodate time and timing events to create snapshots of the enterprise state at any moment in enterprise history of the enterprise’s existence.

What really adds credence to this book is the participation of Don Phillips. He contributed the material that explains how actually to use EA models to deliver enterprise architected systems. Don Phillips, whom Doug claims through several years of working together and who collaborated extensively with Doug for the book, is a ZFEA Row 4 Engineering and Row 5 Manufacturing master. Don is exceptional in that he is one of the very few people who have extensive database and application development experience in the non-EA world and the EA world. As a matter of fact, I normally say, I don’t do actual work, I only think about work!. I used to say Doug Erickson does actual work … but to be precise, it is Doug and Don who do actual work.

I hope you enjoy and learn as much as I have learned from this book … and I hope that both Doug and I keep learning together as there is MUCH more to learn about Enterprise Architecture. The world does not have a thousand years of accumulated wisdom around Enterprise Architecture. We have only a few decades of accumulation … and it is my concerted opinion that our destiny may well rest on our ability to put into practice these enterprise Architecture concepts.

The Industrial Age was all about marshaling the world resources to create tools to support and extend human productivity. My opinion is, the next age, the Information (or Knowledge or Digital) Age, is all about human collaboration (enterprises) in the effective employment of these Industrial Age tools.

We have a lot more to learn, and Doug Erickson and the Erickson Methodology for Enterprise Architecture is getting us started and well on the way. This book is a very substantive, thoughtful, and pragmatic contribution!

Thank you, Doug!

John A. Zachman

Bakersfield, California 2020

PREFACE

Enterprises are, or should be, formed for the purpose of organizing and employing society’s resources to perform the economic activities for the benefit of the members of that society.

As civilizations have evolved, efforts to organize its social, economic, political, and spiritual activities have evolved. Various enterprises have evolved to organize and perform these activities. As society and these enterprises have evolved, the need to optimize the use of available resources is never-ending. Enterprises, public and private, are in a constant search for effectiveness and efficiency. Sometimes these efforts fail, and an enterprise ceases to exist.

Over time, changes have occurred that have been mostly incremental, sometimes detrimental, sometimes advantageous, often occurring randomly without much structure or formal means to develop and manage the changes to achieve the desired outcomes.

Before the last half of the 20th century, enterprises performed their business processes, and the associated data was recorded and managed by people using pencils and paper to record the planned and actual performance of the enterprise for use in operating and managing the Enterprise. This activity was highly dependent on people, their knowledge, and their skills related to this activity.

Enterprises have evolved from simple one-person operations performing single product design and development at one location for a local market of tens or maybe a few hundred customers to complex enterprises designing complex products produced at multiple geographically dispersed operations. As this evolution progressed, the ability to know and understand what was happening in the offices, factories, warehouses, and sales offices became a management challenge.

In the early stage of this evolution, the proprietor practiced line-of-sight management. Each day the proprietor, and maybe a few employees went to work, always working to produce a product, engaging with customers, continually being in a position to know, in real-time, the inventory of materials needed to make the product, who the customers were, how many orders they had and when the product deliveries were due. At the end of each day, it was relatively easy to determine if there was an excess of revenue over costs.

Well, things changed! As enterprises grew and became larger and more complex, management’s ability to practice line-of-sight management became impossible. It also became harder for a group of people performing one process to communicate with another group of people performing preceding or succeeding processes.

People working in a complex enterprise need a robust enterprise universe of discourse, data that is, to be a surrogate for their ability to practice line-of-sight- management. That universe of data needs to be collected, recorded, preserved, available, and accessible. The universe of discourse consists of the data that records the existence and actions of the Enterprise because it is the basis for enterprise knowledge!

During the last half of the 20th century, enterprises have increasingly employed automation in efforts to improve enterprise effectiveness and efficiency. The function, now known as Information Technology (IT), has been one of the primary implementers of the automation technology.

Factory automation technology has made dramatic advances in improving the productivity and quality of products produced on the factory floor in everything from various electronics products to automobiles, large construction equipment, to retailing, and various services.

This book, however, focuses on architecting, engineering, and manufacturing the enterprise itself. This book does not address the automation of subsets of the Enterprise, such as product engineering and manufacturing, pipeline operation, electricity generation, all of which are essential subsets of an enterprise. However, many of the concepts in this book are relevant to those efforts since the planning and control activities using those forms of automation need to be integrated with the other operational and administrative enterprise systems.

Significant progress has been achieved by applying automation technology. However, significant issues have accompanied this progress. These issues are:

1. takes too long,

2. costs too much,

3. doesn’t meet requirements,

4. difficult to change,

5. high maintenance costs and time, and

6. required data not available or accessible.

Why, after decades of advances in information technology and IT practices, do the issues of alignment, integration, flexibility, responsiveness, cost, and lead time persist?

If you want better results, you have to change the processes that produce those results.

What should we do?

You might want to spend some time studying the content of this book if you want to address those issues and achieve better, much better results.

This book is the result of re-thinking what IT is and what it should be. IT should not be about information technology. The function, now known as IT, should be called Enterprise Architecture Services. Enterprise Architecture Services (EAS) should be chartered to architect, engineer, and manufacture the Enterprise. Information technologies are the tools of their trade, and they need to have the expertise to use the available tools and technology effectively and efficiently. Enterprise Architecture Service’s primary focus must be on architecting, engineering, and manufacturing the Enterprise. Appropriately, it should excel at applying automation technology to serve the requirements of the Enterprise. I would question the likelihood of success in any attempt at pursuing an Enterprise Architecture initiative without re-inventing IT along the lines of the concept of Enterprise Architecture Services.

My motivation for writing this book is to provide a methodology that leads the way for developing aligned, integrated, flexible, responsive enterprise infrastructures that are dramatically more effective and efficient than has been experienced up to the present time, i.e., 2020.

The result of this effort is the Erickson Methodology for Enterprise Architecture (EMEA). The EMEA has evolved over 45 years of thinking about and striving to architect, engineer, and manufacture an enterprise; and help resolve the persistent IT issues. The EMEA is the culmination of years of effort involving trial and error, some good fortune, a lot of hands-on experience, and the encouragement of several thoughtful and generous people.

As has occurred in other disciplines, we have evolved from being person dependent to being methodology dependent. Mature disciplines have evolved from having the right person in the right place at the right time to having a formalized method (methodology) that was the means by which a process can be repeated consistently by any person that is proficient in the methodology to achieve predictable, desired outcomes.

As the EMEA matured, it became apparent to me that the focus of what IT was doing needed a shift in emphasis from being a tool vendor to the enterprises to instead being the architect, engineer, and manufacturer of the enterprise. As the body of knowledge known today as Enterprise Architecture has evolved, it has become apparent that enterprises have evolved somewhat randomly without a rigorous discipline designed to create an effective and efficient enterprise.

The EMEA has been a continuous effort of discovery, refinement, invention, innovation, and practice beginning with some of the earliest efforts that used to be known as Data Processing. The EMEA had its initial incubation in the structured methodologies (Structured Programming, Structured Design, and Structured Analysis) back in the 1970s and early 1980s. The most prominent people in this movement were Peter Checkland’s (Soft Systems Methodology), Larry Constantine’s (Structured Design), Edward Yourdon’s (Yourdon Structured Method), Michael A. Jackson’s (Jackson Structured Programming), and Tom DeMarco’s (Structured Analysis). These people and their ground-breaking work had a significant impact on how to develop applications. However, in hindsight, they did little to advance the knowledge of how to develop aligned, integrated, flexible, responsive information systems, much less how to effectively and efficiently manage enterprise data.

It was during this same period that the concepts and principles of relational data modeling were becoming known and put into practice. The work of Edgar F. Codd laid the foundation for relational data modeling, and Chris Date and Hugh Darwen have been significant contributors to the body of relational data modeling knowledge.

Peter Chen’s work developing the entity-relationship model concept and entity-relationship diagraming (ERD) conventions was ground-breaking work in identification, definition, and modeling data; and specifying the translation rules from the ERD model to database implementation.

The next significant influence in the development of the EMEA was Clive Finkelstein. Clive is the father of Information Engineering. Initially, we called the EMEA the Enhanced Information Engineering Methodology. One of the most significant concepts we adopted from the Information Engineering body of knowledge was the treatment of data and processes as independent variables. The idea of architecting and designing data independently of business processes was a significant innovation. This innovation led the way to figure out how to achieve data reuse and shareability, dramatically reduce data redundancy, and significantly reduce development time and effort.

David Moore has been a motivator for the production of this book. David has been a long-time student and advocate of Enterprise Architecture. He has generously contributed his time and effort to help develop and promote the practice of Enterprise Architecture in Canada and provide guidance in the maturation of the body of knowledge we know as Enterprise Architecture.

The second most consequential event in my professional journey was meeting Don Phillips. Fortunately, he agreed to join me in this journey. Without Don by my side, and even leading the way at times, this book would not exist. Donald B. Phillips has been an invaluable contributor to the EMEA. Don has been most instrumental in taking many of the innovations in the front end of the EMEA and figuring out how to transition those concepts, principles, and practices through to applications and database design and development without making many of the detrimental compromises that have been so common throughout the IT industry. Don is a significant contributor to the content of this book.

Three additional individuals warrant acknowledgment and my expression of appreciation. Nary Loganathan, Stacy Pickett, and Tony Hohenbrink with the mentorship of Don Phillips and myself, through their knowledge, skills, and willingness to embark on an effort that has endured and now proven to achieve exceptional results due to our collective efforts.

The most profound and enduring influence has come from John A. Zachman and his creation of what we know today as the Zachman Framework for Enterprise Architecture (ZFEA).

John has been my mentor and collaborator since before the creation of the ZFEA– since the days of the IBM Business Systems Planning (BSP) methodology. (John is also known as the father of BSP.)

The ZFEA specifies the artifacts necessary to effectively plan for, architect, engineer, and manufacture an enterprise. Until we had the ZFEA, IT primarily delivered what is known in the engineering world as black boxes of functionality without adequate consideration for the alignment, integration, flexibility, and responsiveness of the Enterprise.

John was the first person I heard articulate the evolution and maturation process for how products and services are engineered and manufactured that has had a profound impact on the survival of enterprises engaged in providing those products or services to their markets.

John’s next most important contribution, in my opinion, is his simplification and articulation of a fundamental concept that is essential to making a quantum leap forward in the effective and efficient evolution of an enterprise. John refers to this concept as the Strategy Pattern. I call it the Enterprise Product Strategy. This concept identifies and defines the three basic strategies used to produce products or services.

I am going to use John’s writing here because I think he did an excellent job of explaining the concept, it is entertaining, and; why should I try to redo what already exists.

"I want to develop a pattern, a Strategy Pattern, for you. I am sure it is a universal pattern. I use Manufacturing, tangible products because they are easier to conceptualize than intangible products like services, but I am sure this is a universal pattern. We live in buildings, fly in airplanes, ride in automobiles and type or touch computers. They represent the reality around us that we can physically sense and easily conceptualize.

When a new industry starts out, they tend to start out with a Make-to-Order strategy... because it is the easiest, cheapest, and fastest way to get into business. You don’t need a plant. You don’t need raw material. You don’t need employees. You don’t need money. All you need is an office with a sign in front that says Open for Business and you wait for a customer to walk in the door.

The customer walks in the door and says, Orville, I need an airplane. Orville says, What kind of an airplane do you have in mind? The customer says, Well, I want to dust some crops. Orville says, Okay, we’ll build a Crop-Duster for you.

Now that Orville has an order, he has to get an Engineer to design a Crop-Duster. After he gets the Crop-Duster designed, he has to get a Manufacturing Engineer to figure out how to build it. After he figures out how to build it, now he has to get a plant, some raw material, some machine tools, some employees, some money and then he builds the airplane. The end result is a custom product, custom to the specifications of the order. It all starts out with, Tell me what you want the thing to do.

The strategy is Make-to-Order a classic manufacturing Job Shop, a custom house that produces one-of-a-kind, custom products. The management control system is order-driven: cost against the order, schedule against the order; single-use engineering, project managed, expense-based business.

The operational characteristics of a Job Shop are:

Long lead-time - from the time you get the order until you produce the product is measured in years, not days... especially if you are talking about complex engineering products. You want a Boeing 747?... That will be a decade!

High per unit product cost - one product bears the total weight of the engineering, manufacturing engineering, production, tooling, testing... custom products are expensive.

No product flexibility - once you get the product built, it will only do whatever you designed it to do. If you build a crop-duster, it will dust crops. It won’t carry passengers, it won’t carry mail... it won’t go into orbit. It will dust crops.

Low reliability/availability - you have a customer that has a whole fleet of your airplanes, they are all airplanes... but they are custom airplanes. The Crop-Duster is down…that is the one they want tomorrow morning. The Mail-Carrier is up…that’s the one they don’t want tomorrow morning. But, you can’t take a part off of the Mail-Carrier to put it on the Crop-Duster to make the Crop-Duster work because there is no parts interchangeability. You customized the parts (material) to the functionality of the products. You can’t take part off of one product and put it on a different product. Low reliability/availability.

High maintenance costs - if you break a part on a custom product, you can’t go to a generic parts store and get a replacement part. You have only one place to go... original manufacturer. You say, hey, I have this broken part! The manufacturer says, Gee, I never thought that part would ever break. Let me see if I have any diagram that shows me how I built that part... oops! I don’t have any diagrams. That takes time and costs money you know! Let me get my micrometers out here and measure this thing... tell me what this thing does again. It’s expensive... you are starting with a blank sheet of paper for a replacement part... actually, it’s worse. You are starting with a broken part and have to reverse engineer the sheet of paper.

They all start out this way. For example, how does Data Processing work? Think about it. It wasn’t that many years ago that we actually had a sign on the computer room door that said: Open Fridays 9AM to 5 PM to Accept Orders for New Applications (or something like that.)

Incidentally, we changed the name a number of times over the years... at first, we were called Automated Data processing (ADP) or Electronic Data Processing (EDP). Then we changed it to Data Processing (DP), to Management Information Systems (MIS), to Information Systems (IS), then sometimes to Information Management (IM), then to Information Technology (IT). We changed the name on the door a bunch of times but nothing changed behind the door... it has always been: data processing.

Anyway, a user would walk up in the door and say, I need a new application. DP would say, what kind of an application do you have in mind? They would say, I want to cut some payroll checks... Okay, we’ll build you a payroll system.

Once they get the order, then they have to get an Analyst (engineer) to design the payroll system. After they get it designed, they have to get a Programmer (manufacturing engineer) to figure out how to build it... then they need a plant (a computer room), some machine tools (computers), some raw material (data), some employees (operators), some money... and they build a payroll system.

The end result is a custom system, custom to the specifications of the order. It all starts out with, Tell me what you want the thing to do.

The strategy is Make-to-Order a classic manufacturing Job Shop, a custom house that produces one-of-a-kind, custom products. The management control system is order-driven: cost against the order (project), schedule against the order (project); single-use engineering, project managed, expense-based business.

The operational characteristics are:

Long lead time - from the time you get the order for the new application until you deliver something useful, you measure it in years... not days, especially if you are talking about a complex engineering system. You want an Enterprise Resource Planning system... that will be about a decade.

High per unit product cost - those custom applications are expensive. One application bears the total weight of the systems analysis and design (the engineering) the programming (the manufacturing engineering) the tooling, testing, production conversion, operations all born by a single system... expensive.

No product flexibility - once you get the system built, it will only do what you designed it to do. It will cut payroll checks. It won’t keep accounts against a ledger. It won’t give you management information... it will cut payroll checks.

Low reliability/availability - you have a customer (the Enterprise) who has a whole fleet of your systems (an application portfolio) but they are all custom applications. One application is down, the payroll system... that’s the one they need tomorrow morning. The general ledger system is up, but that is the one they don’t need tomorrow morning. But, you can’t take a data element off of the general ledger system and put it on the payroll system to make the payroll system work because there is no data reusability. You customized the data to the functionality of the application. Low reliability/availability.

High maintenance costs - You break a data element on one of those systems... you can’t go down to a generic data element store and get a replacement data element. You have one place to go... original manufacturer... Data Processing. Hey... I have this broken data element ‘yy/mm/dd’ (or something). Data Processing says, Gee... I never thought that data element would ever break! Let me see if I have a model that shows me how I built that data element. Oops! I don’t have any models... that takes time and costs money you know... analysis-paralysis. Pull up a chair. Let me get my micrometers out... tell me what this data element does... It’s expensive... you are starting with a blank sheet of paper for a broken data element... it’s actually worse, you are starting with a broken data element and reverse engineering the model. It’s expensive.

Initially, the customer is willing to accept these limitations... they don’t know any better. But, over long periods of time, 50 or a hundred years, they get frustrated and the drive the manufacturer out of a Job Shop into a Standard Production Environment (mass production) in order to solve the problems. Actually, the problem is the strategy. As long as the strategy is make-to-order... those are the problems. If you want to solve those problems, you have to change the strategy. Provide-from-Stock. Manufacture standard products to inventory before you ever get an order and then when you get an order, deliver the standard product off the shelf. That will fix some of, but not all of, the problems.

Lead time - goes to zero. You deliver the product off the shelf.

Per unit product cost - way down. You spread the engineering, manufacturing engineering, production costs over many products.

Reliability/availability - way up. You reuse the same parts on all the standard products.

Maintenance costs - way down. You can make a profit on the spare parts. In fact, spare parts can be manufactured by Other Equipment Manufacturers (OEM’s). Generic spare parts - low maintenance costs.

You know the one I left out?... Product flexibility. You can have any color you want as long as its black. (Henry Ford) The customer takes the standard product. They change the use of the product to fit the product. You buy a Buick off of the shelf... and you want to haul chickens in it. Well... you haul them in the trunk. What you don’t do is, you don’t reverse engineer the Buick into parts and then re-engineer it into a Toyota pickup truck! That will take longer and cost more. You would be better off going to a job shop and getting them to custom build a pick-up truck for you than to reverse engineer a standard product into parts and re-engineer them into a different product!

Changing the strategy from Make-to-Order to Provide-from-Stock fixes a lot of the problems... not all but a lot, BUT, it is a different kind of business. Now you have to have a capital investment in plant, raw material, machine tools, people, operating money... you have to have product forecasting because you don’t want to manufacture finished goods that the market won’t buy. You have to have material management because you have a large investment in in-process inventory and finished goods inventory. You have to have production scheduling, quality management, marketing, distribution, product support, and a bunch of other things... BUT, you stay in business.

You have probably already figured out the Data Processing parallel to provide-from-stock... Commercial Off the Shelf Software - COTS. Management says, "why are we building these applications? Buy them! We get immediate delivery, low per unit product cost, high reliability, low maintenance cost... Buy them... don’t build them!

But, remember... you take the standard product off the shelf. You can have any color you want as long as it’s black. You change the use of the product to fit the product... that is, you change the Enterprise to fit the package... don’t start changing the package to fit the Enterprise... if you start changing the package to fit the Enterprise, all the reasons you bought the package will evaporate in about 13 milliseconds! To reverse engineer the package into data elements and instructions and re-engineer it into a different package…it would take longer and cost more. You would be better off to go to your old Data Processing shop and get them to build you a custom application than to take a standard (COTS) application of the shelf and change it into a different application. And, by the way, the moment you touch that COTS application, you own it! The warranty no longer applies. If the original manufacturer ever changes the application (which they will about every three months) YOU are now responsible for all changes.

So, do not buy the package unless you have an architectural fit.... but that presumes that the package has an Architecture... and that you have an Enterprise Architecture to which to compare the package. Otherwise, just do yourself a favor and change the Enterprise to fit the package.

So, you can see the strategy pattern...

Make-to-Order ---> Provide-from Stock.

But... what happens to the supplier when the customer doesn’t know or can’t define the characteristics of the product they want to take delivery on until the moment they want to take delivery? Now what?

...You can’t wait until you get the order to engineer and manufacture the product.

...You can’t anticipate every product that any customer will ever want to take delivery on, the killer product, and already have it in stock.

Clearly, you have to change the strategy... to an Assemble-to-Order strategy... Mass-Customization, "custom products, mass-produced in quantities of one for immediate delivery.".. but this is a completely different kind of a business. You have to have PARTS in inventory... NOT finished goods... and those parts have to be engineered such that they can be assembled into more than one product. How do you engineer parts that can be assembled into more than one thing? You have to know the total set of things you have to assemble at any given point in time. You do the engineering Enterprise-wide. After you engineer the parts to assemble the Enterprise set of products, you can pre-fabricate the parts and have them in inventory before you get the order. Then when you get the order, the only time it takes to produce the custom product is the time it takes to map the specifications of the product in the order to the inventory of parts, pick the parts and assemble the custom product to order.

So, the pattern is...

Make-to-Order ---> Provide-from Stock ---> Assemble-to-Order

Having engineered parts that can be assembled into the Enterprise set of products at any given point in time provides substantial flexibility to support changes in the Enterprise Product set. However, when products are demanded that are beyond the ability to support with the current inventory of parts, it is a matter of a delta to parts... not a major overhaul of the manufacturing process and the product line.

I am sure you have already figured out the Enterprise Engineering and Manufacturing equivalent for the assemble-to-order strategy. If you engineer the Enterprise, Enterprise-wide, creating the set of Primitive models as