Enterprise Architecture or Legacy IT

February 1, 2022 – By #Douglas T. Erickson, President, ENTARCO USA Inc.

Introduction

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.

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 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, and unresponsiveness.  IT efforts to achieve benefits as soon as possible have sacrificed the strategic (future) for the tactical (present) at the least possible cost.  Consequently, Enterprise Architecture is still a misunderstood and misrepresented concept.

The following two paragraphs describe an essential difference between building a house and the current approaches that have led to the IT legacy of high costs, process fragmentation, data quality issues, unending and expensive efforts to compensate for these deficiencies, and lost opportunities.

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 component (like a room in the house) of the enterprise.  All the participants work on that component to the exclusion of all the other components of the enterprise.  This approach is further constrained by the short-term efforts to minimize cost and schedule for each project.

Subsequently, a different group of people proceeded to build another component (room) in the enterprise using different methods,  with varying skills, using different tools, all the while expecting all the enterprise "rooms" to form a coherent, cohesive, integrated, integrated, integrated enterprise.  This approach has been the IT routine for 60 years or so.  Good Luck!

Too often, what is portrayed as Enterprise Architecture is traditional IT 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 but how to do it.  It is not a new program.  It is doing what is already being done but doing it much better.

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 what Enterprise Architecture is, 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.

What Is An 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 enterprise super-objective.  Generic examples of a super-objective would specify something like one of the following.

1. Engage in designing, manufacturing, and distributing a product/ product line. (Airplanes, automobiles, Consumer Electronics, etc.),
2. Provide a specified service to persons or other enterprises (healthcare, financial service, labor union, industry association, 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 and responsibility for performing all necessary processes from conception to delivery of 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 critical to recognize that there can only be one enterprise architecture for an enterprise at a time.  If you develop a desired-state enterprise architecture, you can be in the process of implementing the new architecture.

Basing the context of an enterprise on its product or service establishes 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 the specified/defined 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 and 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.  The "How" is specified in the ZFEA Row 3 artifacts.  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 those business processes more effectively and efficiently than their peers.  It is important to recognize that changing management will not warrant changes in what processes must be performed or how they are performed.  Innovations in process design and advancements/changes in technology may impact how the processes are performed but seldom impact what the processes are.

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, can 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 but not the determining factor in whether they were 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 following:

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 20^th 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 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, 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 produced for ZFEA Column 1, Row 3, is the second most essential enterprise architecture element.  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 be intimately involved in guiding the design and manufacture of the enterprise to ensure that the enterprise architecture is not compromised during the engineering 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 designed.  If the building is large and complex, several builders (subcontractors) may be involved in building what the architect designed.

The General contractor (to a significant extent, is the equivalent of an 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.

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 people take 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 operating 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 knowledge, understanding, capability,  and application of these management concepts, principles, and techniques is essential.  One of my favorite examples from this list is "decentralization." If management is currently operating with centralized management, beware.  They can as easily decide to change to decentralized management in the future.  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 and designed to accommodate change.

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 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.

Enterprise Architecture Value

1. Improved:
   1. alignment of the structure of the enterprise with the requirements of the product or services delivered by the enterprise,
   2. the vertical and horizontal integration of the enterprise infrastructure to optimize cohesive operations,
   3. design for change to achieve the flexibility to adapt to internal and external opportunities for achieving effective and efficient operations and, and
   4. timely responsiveness to opportunities and challenges.
2. Improve data quality – available, correct, shareable, and accessible data at lower cost and effort.
3. Improve process quality – consist, efficient, and effective processes and supporting applications.
4. Reduce cost and effort to develop and maintain enterprise operations and management innovations.
5. Capability to develop and implement high quality enterprise systems at one-fifth the cost of typical in-house tradition development methods; and less than one-third the cost of purchased information systems without incurring ongoing annual maintenance costs.

Last Modified: 02/01/2022 8:55:03 am MST

Back