Enterprise Architecture Or Legacy IT

In Business Architecture, Enterprise Architecture by IRM UKLeave a Comment

Print Friendly, PDF & Email


It has been forty years since John A. Zachman set forth the concept of Enterprise Architecture and the Zachman Framework for Enterprise Architecture (ZFEA). The ZFEA is still the platinum standard for defining and understanding enterprise architecture.  The power of the logic of the concept has endured.

Photo of Douglas T. Erickson

Douglas T. Erickson, Founder, ENTARCO USA Inc & Donald B. Phillips
Douglas will be speaking at the IRM UK Enterprise Architecture & Business Process Management Conference Europe 11-14 October 2021 on the subject, ‘Enterprise Architecture Enabled Innovations in Enterprise Data and Process Management

He will also be speaking at the IRM UK Data Governance and Master Data Management Summit Europe 15-17 November 2021 on the subject, ‘Advanced Enterprise Data and Process Innovations

Over the years, many organizations and people, recognizing a credible idea, have promoted their legacy IT knowledge and skills as Enterprise Architecture credentials.

Few people have done the hard work required to understand and develop a methodology that conforms to the logic and intent of the Zachman Framework for Enterprise Architecture.  It is not possible to change the results of what you are doing if you do not change the process for what you are doing.  IT got the marketing right, but the achievements accomplished fall far short of the inherent potential.

IT has taken the least-cost, short-term approach to delivering services based on what they knew how to do.  This approach has resulted in unnecessary misalignment, disintegration, inflexibility,  unresponsiveness, and excessive costs due to a lack of what is known today as an Enterprise Architecture capability.  IT efforts to achieve benefits as soon as possible have sacrificed the strategic (future) for the tactical (present).  Consequently, Enterprise Architecture is still a misunderstood and misrepresented concept.

Advancements in Enterprise Architecture provide a path to optimize the present without sacrificing the future.  However, this will require change.

Enterprise Architecture Foundation

Enterprise Architecture is the science of architecting, engineering, and manufacturing enterprises, a formation or construction as if the result of a conscious act, a unifying or coherent form of method or style of building.

Some people might say that Enterprise Architecture is more an art than a science.  I disagree!  Enterprise Architecture is more a science than an art, and it is becoming more of a science.  Art is heavily influenced by the artists and their perceptions and preferences.  Enterprise Architecture is increasingly a disciplined application of what John A. Zachman says: the “physics of enterprise architecture.”

Enterprise Architecture is about planning, architecting, engineering, and manufacturing an efficient and effective enterprise and maintaining it throughout its life; it is not about managing the use of the enterprise once it exists.  Enterprise Management is responsible for managing an existing enterprise!

To define Enterprise Architecture, we need to articulate the concepts required to understand what architecture is.

  1. Architecture is the set of descriptive representations for describing a complex object such that an instance of the object can be created. The descriptive representations serve as the baseline for changing an object instance.
  2. An Enterprise Architecture Framework consists of the descriptive representations for describing an enterprise, organized by a set of classifications based on the six interrogatives of What, How, Where, Who, When, and Why!
  3. Architecting an enterprise using a framework-based methodology is the process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining, and improving the enterprise architecture and the enterprise throughout the life of the enterprise.

An enterprise is a collection of resources assembled to provide its product or service to its market(s).  Further, an enterprise can be formed in the public or private sector of the economy for conducting any organized business activity, which produces any products or provides any services, either for-profit or not-for-profit.

The essence of any enterprise is the specification of the super-objective of the enterprise.  Generic examples of a super-objective would specify something like one of the following.

  1. Engage in the design, manufacture, and distribution of a product/ product line. (Airplanes, automobiles, Consumer Electronics, etc.),
  2. Provide a specified service to persons or other enterprises (healthcare, financial, etc.)
  3. Govern/administer a political jurisdiction such as federal, state, county, township, or a school district.
  4. Promote a political or religious philosophy or ideology to some specified group of people, geographical area, or political jurisdiction.

An enterprise must have authority, governance, and responsibility for performing all necessary activities to produce and provide its products or services.  (For brevity purposes, I use the phrase “products” or “services,” but by definition, it includes all products or services in a line of products or services.)

This definition eliminates the idea that you can create an enterprise architecture for something referred to as a department, division, operation, or any other segmentation of a corporation or company.  By themselves, Enterprise organizational subdivisions cannot provide a product or service to the enterprise’s market.

If the scope of enterprise architecture is anything less than an “enterprise,” it compromises the value and benefit of the enterprise architecture.  It is a misuse of the enterprise architecture concept if applied to only a division, operation, or department within an enterprise.  It is also critical to recognize that there can only be one enterprise architecture for an enterprise at a time.

By basing the context of an enterprise on its product or service, we have a very stable basis for defining the scope of the Enterprise.  The scope of the Enterprise will be permanent as long as the Enterprise’s purpose is to provide that product or service to its market.

Therefore, it is beneficial to base the scope of an enterprise on the definition of its product or service.

Enterprises that provide the same product or services will have virtually the same or very similar enterprise architectures, especially Rows 1-2 of the Zachman Framework for Enterprise Architecture.

What will distinguish one Enterprise from another is “How” it performs one or more of those business processes, and the “How To” is specified in Row 3.  A well-designed Enterprise Logical Process Model (LPM) will be complete with no redundancies or gaps.  However, the LPMs for similar enterprises (same product or services) can be pretty similar, but this is also where they become unique.  All enterprises that design and build cars fundamentally perform the same business processes.  Some perform some of those business processes more effectively and efficiently than their peers.  It is important to recognize that changing management will most often not warrant changes in process management.  Innovations in process design and advancements/changes in technology may impact how the processes are performed but seldom impact what the process does.

The words corporation, company, partnership, trust, sole proprietor, etc., are not names that specify an enterprise; they are names of forms of enterprise organization.  An enterprise may start as a sole proprietor, change and become a partnership, and change again to become a corporation.  This is an example of an enterprise changing its form of organization over time.  This transformation may cause some new processes and data to be relevant to the Enterprise, but the essential scope and content of the Enterprise will stay very stable.  If an enterprise that designs, builds, and sells cars starts up a consumer finance enterprise, there is now a new, second enterprise.  An example of this situation is the case where General Motors Corporation started General Motors Credit Corporation.  They were both called corporations and not the determining factor in whether they are one or two enterprises.

Furthermore, it is essential to understand that an enterprise exists only in concept.  You cannot see “the enterprise.” Yes, we know it exists in some form, but it does not exist in the sense that a car, a house, or a building exists.  We can create an enterprise, we can define it, we can design it, and we can create physical objects that represent artifacts of an enterprise.  When you look at the building referred to as the headquarters for an Enterprise, you are not looking at the Enterprise; you are looking at a building occupied by the Enterprise.  The enterprise headquarters could be moved to a different building, and the Enterprise would still exist as it did before, but it then resides at a different address.  The building exists physically, but the Enterprise exists only as a concept.  In this case, the building and the Enterprise are both independent variables.

This idea also applies to the concept of an organization.  An organization does not exist in a physical sense.  You can draw me a picture of an organization chart that shows me the positions and their relationships, and you can show me where the manager and the staff sit, but you cannot see a thing called an organization.  This is the nature of concepts – they exist, but they only exist because someone recognizably describes them.

The product or service provided by an enterprise will define what the enterprise is and what it needs to know, how it does what it does, and pretty much where it does it, when, by whom, and why.

The principle is that the enterprise product or service will extensively dictate the:

1.   business processes the enterprise will perform,
2.   data the enterprise will require,
3.   human resources skills the enterprise will require,
4.   location(s) where the enterprise will perform its activities,
5.   kinds of facilities the enterprise will require, and
6.   the organizational structure the enterprise will use!

Why Enterprise Architecture?

Enterprises tend to evolve 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 be a complex enterprise designing complex products produced at multiple geographically dispersed operations.  As this evolution progresses, knowing and understanding what was happening in the offices, factories, warehouses, and sales offices becomes a management challenge.

In the early stage of this evolution, the proprietor practices 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.  It was relatively easy to determine if there was an excess of revenue over costs at the end of each day.

As enterprises grew and became more complex, increasing amounts of resources were required to support the ability of enterprises to produce their products and services.

Initially, the way for enterprises to increase their output and sales was to increase the number of people required to perform the business processes to produce more products and services.

During the last half of the 20th century, the advances in automation technology dramatically changed the equation between enterprise human resources and the work needed to be performed.  Not only could these advances in technology perform office and factory business processes faster, but error-free.  An enterprise could also vary the output without adding a full complement of resources to add another hour of work without the additional cost of another person.  Theoretically, they could add an entire eight-hour shift without adding another person to their payroll.  The tradeoff was between capital expenditures and labor expenses.  The introduction of the concept of depreciation of assets made capital expenditures the preferred choice.  When the depreciation expense per hour or unit produced was less than the cost of human labor per hour or per unit produced, automation technology became the path to lower cost, perhaps better quality, and increased efficiency.  This led to phenomenal growth in factory automation.

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

People working in complex enterprises need a robust 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 raw material for enterprise information and knowledge!

The Enterprise Universe of Discourse (EUD) consists of two essential sets of data.  One set is the data that records the enterprise’s planning, control, and operation, and the other set is the data that describes the enterprise’s architecture.  Consequently, the Enterprise Logical Data Model (artifact) produced for ZFEA Column 1, Row 3, is the second most essential element of the Enterprise Architecture.  Of course, the enterprise’s primary resource (product or service) is the most essential enterprise resource!

Enterprise changes have often been incremental, piecemeal, reactions to changes and problems, often by trial-and-error, unnecessarily costly, and disruptive to other parts of the enterprise.  In other words, change has not always been achieved effectively and efficiently.  Fundamentally, there was no structure.  Without a structure for managing change, it is difficult to manage change!

Significant progress has been achieved by applying automation technology in the production of products and services and the administration of an enterprise.  However, improvements in enterprise alignment, integration, flexibility, and responsiveness have not accompanied this progress.

More specifically, these issues are expressed as:

  1. required data not available or accessible,
  2. high maintenance costs and time,
  3. too often fail to meet requirements,
  4. takes too long,
  5. costs too much,
  6. difficult to change.

After decades of advances in automation technology and IT practices, why do the issues of alignment, integration, flexibility, responsiveness, cost, quality, and lead time persist?

If anyone claims they are doing Enterprise Architecture and do not solve or significantly minimize these issues, they are not doing credible Enterprise Architecture.

Enterprise Architecture, if done well, will provide solutions to these issues!

Enterprise Architecture Basics

As we commonly know them, an Architect is a person or an enterprise that designs buildings; and in many cases, oversees the construction of those buildings.  This dual role of the Enterprise Architect is critical to the discipline of Enterprise Architecture.  The Enterprise Architect must guide and be intimately involved in the design and manufacture of the Enterprise to ensure that the enterprise architecture is not compromised during the design and manufacture of the Enterprise.

In the building analogy, an Architect designs the building to an excruciating level of detail.  A builder (General Contractor) takes the architect’s design and builds whatever the architect (s) designed.  If the building is large and complex, several builders (subcontractors) may be involved in building what the architect designed.

In Enterprise Architecture, the Enterprise Architect architects the Enterprise and must oversee the engineering and construction of the Enterprise to ensure that the integrity of the architectural drawings ends up in the Enterprise’s physical manifestation.

The General contractor (to a significant extent, is the IT organization) uses various sub-contractors who construct, test, and implement the components of the Enterprise.

In the context of the ZFEA, the Enterprise Architecture is specified in the artifacts (models) developed for each cell in Rows 1-3 of the ZFEA.  The artifacts (models) specified as needed in Rows 4 and 5 of the ZFEA are the engineering and manufacturing artifacts produced by the General Contractor in building the Enterprise.  It is critical the Row 4 and 5 models do not compromise the intent and integrity of the Row 3 models.

Accordingly, the word “architecture” in Enterprise Architecture, by definition, includes architecting the Enterprise, engineering the Enterprise, and the construction (design and development of its systems) of the Enterprise.

The following paragraph describes an essential difference between building a house and the current approaches to IT projects.

When building a house, all participants (carpenters, concrete workers, electricians, plumbers, etc. all participate in constructing the entire house.  The current IT approach does not include architecting the Enterprise as would occur in building a house. Current IT projects begin by designing a segment (like a room in the house) of the Enterprise, and all the participants work on that segment to the exclusion of all the other segments of the Enterprise. 

Subsequently, they, or a different group of people, proceed to build another segment (room) in the Enterprise using different methods, different materials, even different tools, all the while expecting all the enterprise “rooms” to form a coherent, cohesive, integrated enterprise.  Good Luck!

Too often, what is portrayed as Enterprise Architecture is traditional practices and evolving technology being repackaged and sold as Enterprise Architecture.   Enterprise management has become convinced they need Enterprise Architecture but do not know much about it.  This is a situation ripe for selling another “silver bullet” solution.

Enterprise Architecture is architecting the Enterprise, engineering the Enterprise (design the Enterprise using the architectural drawing), and manufacturing the Enterprise (transforming the architectural drawings and engineering designs into physical manifestations of the Enterprise) that implement an improved and continuously improving Enterprise.

Enterprise Architecture is not a program or project that management chooses to implement.  Enterprise Architecture is inherent and always present.  The issue is not whether to do Enterprise Architecture or not, but how to do it.  It is not a new program.  It is doing what is already being done but doing it much better.

Enterprise Architecture and Enterprise Management

Enterprise Architecture is the science of architecting, engineering, and manufacturing enterprises, a formation, or construction as if the result of a conscious act, a unifying or coherent form of method or style of building.

Enterprise Architecture is about planning, architecting, engineering, and manufacturing an efficient and effective enterprise and maintaining it throughout its life.  Enterprise Architecture is not about managing the operation of the Enterprise once it exists.

Enterprise Management is the actions taken by people with the responsibility and authority to operate the Enterprise.  Enterprise Management plans, staffs, organizes, directs, and controls the operation of the enterprise.  Good Enterprise Management is a prerequisite to being able to operate an enterprise efficiently and effectively.

General Management, be it the owner, partners, or corporate leadership, establishes the primary purpose of the enterprise – to provide a product or service to its market.

The role of Enterprise Architecture is to architect and construct an enterprise capable of efficiently and effectively providing the product or service to the market.

One of the significant areas of confusion is what Enterprise Architecture is and what Enterprise Management is.  There have been many proposed management concepts, principles, and techniques for correcting an enterprise’s ills or positioning the enterprise to thrive in today’s world.  The list of these is long and will get longer.  A few of these that have achieved some degree of acceptance at one time or another are:

  1. Management by Objectives (MBO)
  2. Management by Walking Around (MBWA)
  3. Zero-Based Budgeting
  4. Quality Circles
  5. Participative Management
  6. Total Quality Management (TQM)
  7. Six Sigma Quality
  8. Decentralization
  9. Responsibility Accounting
  10. Just-In-Time Inventory Management
  11. Customer Relationship Management (CRM)
  12. Balanced Scorecard (BSC)
  13. Enterprise Resource Planning (ERP)
  14. Business Process Re-engineering

You will notice no mention of Enterprise Architecture in this group.  The above list, except for possibly Business Process Re-engineering, are management techniques.  They are not Enterprise Architecture techniques.  The items on the above list could be applied to the management of Data Processing, Information Systems, or Information Technology, and any other functional area of the business.

However, an Enterprise Architect’s capability, knowledge, understanding, application of these management concepts, principles, and techniques is essential.  One of my favorite examples from this list is “decentralization.” If management is currently promoting centralized management, beware.  In the future, they can as easily decide to change to decentralized management.  A capable Enterprise Architect will recognize that architecting for one or the other at the exclusion of the other is a recipe for causing future change.  This is a situation where it is highly recommended that you architect, engineer, and manufacture for both cases to the extent possible.  It is a lot less expensive and provides maximum flexibility (which also dramatically reduces the time to adapt) for management when changing these kinds of decisions.  The essential knowledge and skill of an Enterprise Architect is understanding and knowing how things can change in an enterprise.

Currently, Enterprise Architecture is not recognized as an enterprise function.  Engineering, Manufacturing, Finance, Accounting, Actuary, Claims Processing, and Power Generation are examples of currently recognized enterprise functions.  However, most enterprises have a function called Information Technology.  Some people might suggest that the role of the Chief Information Officer (CIO) represents the function that embodies Enterprise Architecture.  Enterprise management collectively manages all of these functions.  Each of these functions has management which is expected to provide expertise to optimize the performance of their function for the benefit of the enterprise.

Consequently, we see little responsibility and accountability for the architecture of the enterprise or capability to architect, engineer, and manufacture an enterprise.

Notwithstanding the current state of affairs, every enterprise has an enterprise architecture – it might be a good enterprise architecture, or it might not be a good one.  How would you know if it was good or not so good if you did not know about or have expertise and experience in the science of enterprise architecture?

Enterprise management and an enterprise are two independent variables.  You can change enterprise management without changing the architecture of the enterprise.

The question often arises regarding who is responsible for Enterprise Architecture – Enterprise Management or Information Technology.  Enterprise General Management is ultimately responsible for ensuring that there is an Enterprise Architecture function; and that it is as capable as any other functions performed for the enterprise.  Just as General Management does not perform Marketing, Sales, Engineering, Manufacturing, it would not perform the Enterprise Architecture function.  Perhaps it would make more sense to have an Enterprise Architecture Services function that manages the enterprise architecture.

Enterprise Management makes decisions regarding goals, strategies, plans, allocation of resources, and directing the use of those resources in the operation of the enterprise.  For example, enterprise management may decide they want to:

  1. Adopt Zero-Based Budgeting as the way to prepare their annual budgets.  This decision will not change the fact that there is a budgeting process.  It will probably mean a change in how the budgeting process is performed.
  2. Pay employees using direct deposit instead of using only checks.  This decision will not change much of the “Pay Employees” process except for the part that issues the payment by adding the capability to make direct deposits to employees’ bank accounts.  That part of the Pay Employees process that calculates the gross and net pay would not be affected.
  3. Changing the logic of calculating insurance policy premiums would cause a change in the details of the process that calculated premiums.
  4. Develop and market a significantly different product or service, such as an automobile design and manufacturing enterprise; deciding to develop, design, and build housing developments would cause a new enterprise and enterprise architecture.

On the other hand, if the implemented enterprise architecture is designed to be integrated, flexible, and designed for change, enterprise management can make many decisions that will not cause a change or impact the enterprise architecture.

On the other hand, if Enterprise Management decides to change the current product or service to a different product or service, the enterprise architecture will be significantly impacted, and Enterprise Architecture Services will be very busy.

Enterprise Management is the actions taken by people with the responsibility and authority to operate the enterprise.  Enterprise Management plans, staffs, organizes, directs, and controls the operation of the enterprise. 

The primary role and competency of Enterprise Management are to operate the enterprise!  Enterprise Architecture’s role is to architect the enterprise.




PS The Erickson Methodology for Enterprise Architecture, based on the Zachman Framework for Enterprise Architecture, can reduce the cost of architecting, engineering, and manufacturing an enterprise to one-third the cost of purchasing and implementing purchased packages, and up to one-fifth the cost of conventional development.

Douglas T. 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 1980, Doug met John A. Zachman. This meeting started a decades-long pursuit, as a student and practitioner, to understand and apply the concepts and principles of Enterprise Architecture. By the early 1980s, Doug had developed the beginnings of what is known today as the Erickson Methodology for Enterprise Architecture (EMEA). 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 organizational units and applications, cost-effectively. He has extensive business and information management experience based on his work with enterprises in various industries, including engineering and manufacturing, insurance, airline, electric utility, natural gas distribution, the U. S. Army, and state government agencies. Doug is a recipient of the DAMA International 2021 Data Management Excellence Award. Doug has a degree in Business Administration from Black Hills State University, with MBA coursework at Arizona State University. Doug is the founder of ENTARCO USA Inc.

Copyright Douglas T. Erickson, Founder, ENTARCO USA Inc & Donald B. Phillips

Read more from IRMConnects and subscribe to the monthly newsletter here.

Leave a Comment