Enterprise Architecture: What Is It?

 – By

Enterprise Architecture: What Is It?

1.0 Introduction

Much discussion and debate goes on about “What is Enterprise Architecture”? This discussion is very diverse in scope and content. As evidenced by this discussion, Enterprise Architecture has not achieved a universal, standard, generally recognized definition.

What follows is not an exhaustive answer to the question of Enterprise Architecture: What Is It? But hopefully, it will add some clarity to the subject.

To define Enterprise Architecture, we need to define the concepts and disciplines that combine to create what we have come to know as Enterprise Architecture. We need to understand what architecture is and what an enterprise is in order to understand what Enterprise Architecture is. It is also useful to understand the distinctions between Enterprise Architecture and other enterprise related concepts, practices, and disciplines.

Note: After 30 years of intimate activity regarding Enterprise Architecture as a thought leader and practitioner, I have arrived at a point where I use the Zachman Framework for Enterprise Architecture (ZFEA)—also known as the Zachman Enterprise Framework and the Zachman Framework for Information Systems—as the framework for defining Enterprise Architecture and also as the framework for defining and organizing ENTARCO’s Methodology for Enterprise Management Services (MEMS). I have found the ZFEA to be the most neutral, comprehensive, and theoretically and empirically sound basis for architecting, engineering, and manufacturing an enterprise. Therefore, the ZFEA is used as the anchor point for our definition of Enterprise Architecture.

It turns out that it is also very useful to separate the concept of Enterprise Architecture from the participants and the roles that they play in designing and constructing the enterprise; just as in the building analogy, architecture (meaning building architecture) involves many participants playing a variety of roles.

2.0 Definitions of a few basic terms.

Architecture, according to many dictionaries,is the art or science of designing and constructing buildings; a formation or construction as if the result of conscious act; a unifying or coherent form of method or style of building”.


The word “enterprise” is problematic as there are a variety of definitions or meanings, some formal, others informal, and it is often used interchangeably with words like company, corporation, partnership, agency, department, division, etc. Also, over time, definitions for the word “enterprise” evolve for purposes of clarifying what is meant by different people for different purposes.

One of the more comprehensive, formal definitions of an enterprise is the definition used by the U.S. Department of Commerce which is as follows:

“Enterprise is any organization, in the public or private sector of the economy, which is formed for the purpose of conducting any organized business activity which produces any products or provides any services, either for profit or not for profit.”

Note: This definition may vary over time, but seems to be fairly permanent and consistent.

Here is the definition that I have evolved over 30 years or so as I grappled with the concept of “enterprise”. I have found this definition to be very useful:

“An enterprise is a collection of resources assembled for the purpose of providing its product and/or service to its market, in and of itself.”

Even this definition needs some explanation.

First of all, to be a completely functioning enterprise, it must have authority, governance, and responsibility for the performance of all activities that are necessary to 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 distinctive line of products or line of services.)

The ENTARCO 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. Organizational subdivisions, by definition, cannot by themselves provide a product or service to its market.

Outsourcing some activities to another enterprise does not mean that those activities are outside the authority of the outsourcing enterprise. Outsourcing the Customer Help Desk to another enterprise does not absolve the enterprise of its responsibility for the performance of the Customer Help Desk activities.

An enterprise may exist to pursue an economic, political, social, or religious objective, or combination thereof. For all practical purposes, every enterprise, in some manner or another, has a “super objective” to provide some “product or service” to a “market”. The market may be well defined and mature, or in its infancy. A market may not even formally be known as a market, but exist only as a latent need or demand.

The most essential aspect of an enterprise is the specification of the “super-objective” of the enterprise. An example of this would be that the creators of the enterprise specify that they are going to:

  1. Engage in the design, manufacture, and distribution of a product or product line,
  2. Provide a service to persons or other enterprises,
  3. Administer a political jurisdiction, such as federal, state, province, county, parish, township, or other political jurisdiction, or
  4. Promote a political or religious philosophy or ideology to some specified group of people, or in some geographical area, or in some political jurisdiction.

These basic specifications of purpose pretty much dictate the underlying scope, content, and structure of the enterprise. The product and/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 and when it does it, who does it, and why.

By basing the context of an enterprise on the definition of its products or services, we have a very stable basis on which to define the scope of the enterprise. The context of the enterprise will be stable because, as long as the enterprise’s purpose is to provide that product or service to its market, the architectural foundation for the enterprise will not change.

For Enterprise Architecture purposes, it is therefore very useful to set the boundaries for an enterprise around a specification of a product or service. The result of this concept is that what is known as a corporation many in fact be many enterprises.

As an example, many people are familiar with PEP Boys auto stores. When looking at a PEP Boys store, you are actually seeing the manifestation of two enterprises: 1) the auto parts store, and 2) the auto repair store. PEP Boys Auto, the corporation, consists of two enterprises – one an automotive parts enterprise, the other an automotive repair enterprise. These can easily be seen as highly related enterprises, but distinct in that one is primarily a product-based enterprise and the other is a highly services-based enterprise.

These two enterprises are fundamentally different because their products and services are different. However, there may be commonality that can be leveraged between the two enterprises. Once the individual Enterprise Architectures exist, it will be fairly easy to identify and take advantage of these commonalities. These two architectures, as a set, could be considered a “Federated Enterprise Architecture”. In this case, it is very important to maintain the distinction between the two enterprises; this includes designing an Enterprise Data Architecture that explicitly preserves the data relative to the two, distinct enterprises.

Sometimes a corporation, in its entirety, is the enterprise. However, sometimes it may, in fact, be two or more enterprises. General Electric Corporation is more than one enterprise for Enterprise Architecture purposes. General Electric, in its entirety, likely involves more than one corporation because it may wholly-own enterprises that are also corporations.

On the other hand, if the enterprise that designs, builds, and sells cars decides to stop doing that and decides to become a home builder, it will become a different enterprise for Enterprise Architecture purposes, because the basic product and/or service it provides is now different and the fundamental nature of the enterprise will have changed.

Corporation, company, partnership, trust, and sole proprietor are not names that specify an enterprise; they are forms of organization for an enterprise. An enterprise may start out as a sole proprietorship, grow and become a partnership, and grow again to become a corporation. This is a case of the same enterprise changing its form of organization over time.

This transformation may cause some additional processes and data to be relevant to the enterprise, but the basic scope and content of the enterprise, based on its products and services, will remain very stable. If an enterprise that designs, builds, and sells cars starts up a consumer finance enterprise, there is now a new, second enterprise, such as the case with General Motors Corporation when they started General Motors Credit Corporation. The fact that they were both called “corporations” is not the determining factor in whether they are one or two enterprises.

It is very important 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, or 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 elements of an enterprise. When you stand and look at the building that houses the headquarters or home office of an enterprise, you are not seeing “the enterprise”, you are seeing a building that may or may not be owed by the enterprise. The enterprise headquarters could be moved to a different building and the enterprise would still exist as it did before, but now it occupies or resides at a different address. The building exists physically, but the enterprise exists only as a concept.

This idea also applies to the concept of “organization”. The 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; however, you cannot see a physical thing called an “organization”. This is the nature of concepts – they exist, they can be described, but they only exist because someone conceived them, defined them, and described them in a recognizable manner.

An Architect is a person who designs buildings and, in many cases, also supervises the construction of those buildings.

In the building analogy, the Architect designs the building to an excruciating level of detail. Then a builder (i.e. general contractor) takes the architect’s design and builds whatever the architect(s) designed. If the thing to be built is large and/or complex, there may be several builders (i.e. subcontractors) involved in building the thing the architects designed.

Within the realm of Enterprise Architecture, the Enterprise Architect designs the enterprise and must supervise the construction of the enterprise from the architect’s designs in order to ensure the integrity of the architectural drawings and/or models. The enterprise engineers (i.e. applications or systems analysts) design the applications using the Enterprise Architect’s drawings as their specifications. The General Contractor (usually the IT organization) using various sub-contractors, such as programmers, database administrators, user-manual writers, and application testers actually construct, test, and implement the components of the enterprise.

Enterprise Architecture

Therefore, Enterprise Architecture is theis the art or science of designing and constructing enterprises; a formation or construction as if the result of conscious act; a unifying or coherent form of method or style of building”.

Accordingly, the word “architecture”, by definition, includes both the design of an enterprise and the construction of an enterprise.

A key clarification here, which I will address more fully later, is that architecture is about designing and building an enterprise and perhaps maintaining it throughout its life; it is not about managing the use of the enterprise once it exists. Managing the use of the enterprise once it exists is called Management or Enterprise Management.

Enterprise Architecture produces the conceptual or metaphysical enterprise and its transformation into a functioning enterprise. Enterprise Architecture is about:

  1. The processes an enterprise must perform to provide its products or services to its market(s),
  2. The data that describes the performance of the activities that are performed by the enterprise in the course of providing its products or services to its market(s),
  3. The geographical placement (i.e. the kinds of logical business units) where the enterprise conducts its affairs,
  4. The organization of the enterprise’s resources for use in conducting its affairs,
  5. The tracking of the conduct of the enterprise’s affairs over time, and
  6. The basic motivations (i.e. the products and services) that cause the enterprise to exist.

The Enterprise Data Architecture is one of the six (6) primary sub-enterprise architectures. This architecture consists of the identification and definition of the “things” the enterprise needs to know about, and the business rules that govern the relationships amongst the “things”.

The Data Architecture includes the Database Architecture. The Database Architecture consists of the System, Technology, and Detailed Representations of the Data Architecture. The Database Architecture must map to the ZFEA System Data Model.

The Enterprise Process Architecture consists of the identification, decomposition (i.e. structure), and specification of the processes that the enterprise must perform in order to provide its product or service to its market.

The Process Architecture includes the Applications Architecture. The Applications Architecture consists of the System, Technology, and Detailed Representations of the Process Architecture. The Applications Architecture must map to the ZFEA System Process Model. The applications are the physical manifestation of the business processes. If an enterprise exists and is operating, all of its processes and the automated and manual applications are in place. However, the critical issues are:

  1. How well are the business processes designed, and
  2. How well do the applications implement the business processes?

The Enterprise Geographic Architecture consists of the identification and definition of the locations of activities and/or locations of properties controlled by the enterprise.

The Geographic Architecture is the Network Architecture, as referred to in the Zachman Framework for Enterprise Architecture. The lower two (2) Rows in the Network column in the Zachman Framework for Enterprise Architecture are often referred to as the “Information Technology Architecture”. People tend to think that these two (2) Rows constitute the “architecture of interest” to the enterprise and therefore erroneously refer to it as the Enterprise Architecture.

The Enterprise Organization Architecture consists of the aggregate of units of resources and their structure created for the purpose of carrying out the activities of the enterprise.

The Organization Architecture is the equivalent of the People column in the Zachman Framework for Enterprise Architecture. People in positions of authorized Job Classifications assigned to organizational units actually perform the activities of the enterprise.

The Enterprise Temporal Architecture consists of units of time and the relationships among them. The structure of time is used to reflect the events and their occurrences in relationship to each other and their duration.

The Temporal Architecture corresponds to the Time column in the Zachman Framework for Enterprise Architecture.

The Enterprise Motivation Architecture consists of the governance established for the enterprise. The governance includes the declaration of the purpose of the enterprise and the policies that are enacted to provide the guidance necessary to achieve the expected behavior of the enterprise.

Each of the above sub-architectures is refined based on the representations of the five (5) perspectives as specified by the Zachman Framework for Enterprise Architecture. The five (5) perspectives are:

  1. Scope (Model) – Planner’s perspective,
  2. Business Model – Owner’s perspective,
  3. System Model – Designer’s perspective,
  4. Technology Model – Builder’s perspective,
  5. Component Model – Subcontractor’s perspective, and
  6. Operations Model – the functioning enterprise.

A very important aspect of these perspectives is that each perspective is not always the result of adding more detail at each level. Level 2 has more detail than Level 1, and Level 3 has an excruciating level of detail. Level 3, the System Model is a complete, detailed specification of the design of the enterprise.

No enterprise design elements can be introduced in Levels 4 and 5. Very limited content can be introduced at Levels 4 and 5 and only for very limited reasons. Additionally, Levels 4 and 5 must conform to the design as specified in the Level 3 perspective. If the people working at Level 4 and 5 have an issue with the content of the Level 3 perspective, they must get agreement from the Enterprise Architect to affect a change to the Level 3 content.

Therefore, Enterprise Architecture is the discipline of designing and constructing an enterprise. It is the collective actions to create the Data, Process, Geographic, Organizational, Temporal, and Motivation Architectures for an enterprise. The result of a completed Enterprise Architecture is an enterprise.

The most essential sub-architectures are the Data and Process Architectures. However, these aspects of an enterprise have been pretty much ignored in terms of management attention and effort.

Many other disciplines necessary to ensure the effective functioning of an enterprise have experienced dramatic changes over the last 50 years or so. Data or Information Management and Business Process Management have existed pretty much on the margins of enterprise management in most enterprises. Enterprise management teams have too often abdicated their responsibility for these activities to the IT organization; and the IT organization has too often assumed that whatever enterprise staff told them was sufficient to deliver information systems.

It is time for these disciplines (i.e. Data/Information Management and Business Process Management) to be recognized as critical to the future well-being of any enterprise. If these two aspects of Enterprise Architecture are not at the forefront of an Enterprise Architecture program, it should not be called an Enterprise Architecture program. If these two sub-architectures are not most prominent during the definition of the program, then the program is probably something much less than it needs to be and is probably one of more of the following impostors, posing as Enterprise Architecture:

  1. Applications Architecture,
  2. Database Architecture,
  3. Network Architecture, and/or
  4. Infrastructure Architecture.

The manifestation of the enterprise is the data, databases, processes, procedures and applications, organization structure, kinds of geographical locations where the enterprise resides, its history, and its motivations as represented by:

  • Row 6 in the ZFEA,
  • As they are constructed in Rows 4 and 5 by the Builders, such Systems Analysts, Programmers, and Database Designers (in the case of computerized implementation of the business processes and data) or by Procedural Analysts and Writers (in the case of manual systems), and
  • The architected models produces by Enterprise Architects in ZFEA Columns 1-6, Rows 1-3.

All of the above constitutes the foundation of any enterprise. Without this foundation there is no functioning enterprise. Whether or not all of the enterprise artifacts exist explicitly or implicitly for the enterprise, all the fundamental elements of the Zachman Framework for Enterprise Architecture will be present in some form, to some extent.

When an enterprise exists and is operating, all of the ZFEA Row 6 manifestations of the enterprise exist. However, all of the ZFEA Rows 1-5 artifacts may not exist explicitly. If they do not exist, then the explicit Enterprise Architecture for the enterprise does not exist. The implied Enterprise Architecture is embedded in the ZFEA Row 6 manifestations of the enterprise. If you want to create the “as-is” Enterprise Architecture of a given enterprise, you are going to have to reverse-engineer and reverse-architect the ZFEA Row 6 manifestations of said enterprise.

The Enterprise Architecture, that portion which addresses the architecture and design of the enterprise is represented by ZFEA Columns 1-6, Rows 1-3.

The ZFEA Columns 1-6, Rows 4-5, address the design and construction of the enterprise architecture.

2.0 Distinguishing Between Enterprise Architecture and Management Techniques

Enterprise Management is the actions taken by people with the responsibility and authority to manage (i.e. plan and control), decide, and direct the affairs of the enterprise. Enterprise Management is primarily engaged in the operation of the enterprise and is rather casually involved in the architecting, designing, and construction of the enterprise.

One of the major areas of confusion about what Enterprise Architecture is and what management techniques are arises from being confronted with the myriad of management concepts, principles, and techniques that exist as the panacea for correcting the ills of an enterprise or for 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 (JIT) Inventory Management,
  11. Customer Relationship Management (CRM),
  12. Balanced Scorecard (BSC), and
  13. Enterprise Resource Planning (ERP).

You will notice no mention of Enterprise Architecture in this group. The above list, except possibly Business Process Re-engineering, are “management techniques”, they are not Enterprise Architecture techniques. Every one of the techniques cited above could just as easily be applied to the function of Data Processing, Information Systems, or Information Technology management, as to any other functional area of the business.

3.0 Enterprise Architecture: What it is not.

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

The problem is that, in the past, what would be considered Enterprise Architecture efforts were very sporadic, fragmented, random, un-disciplined, trial-and-error activities. From an Enterprise Architecture point of view, looking backward or looking at where we have come from, we can view these activities in the context of what we now know as Enterprise Architecture. Over the last 40 years there have been many ideas, concepts, techniques, and initiatives that, in retrospect, can be seen as efforts that we now understand as honest attempts at Enterprise Architecture. A very short list of these follows:

  1. Hierarchical Input Process Output Technique,
  2. Structured Programming,
  3. Structured Design,
  4. Structured Analysis,
  5. Busienss Systems Planning
  6. Non-procedural Programming Languages,
  7. Rapid Application Development,
  8. Relational Modeling,
  9. Object-oriented Analysis and Design,
  10. Information Engineering,
  11. Enterprise Architecture
  12. Client-Server,
  13. Web Services,
  14. Middleware,
  15. Computer-aided Software Engineering,
  16. Customer Relationship Management,
  17. Business Transformation Enabling Program (BTEP)
  18. Process Engineering/Re-engineering,
  19. Agile methods,
  20. Use Cases, and
  21. Conical data modeling
  22. Government Strategic Reference Models (GSRM)
  23. Etc, etc.

Each of the approaches cited above represents honest efforts to address recognized issues or problems, or efforts to improve the activities undertaken to provide “systems” that are a manifestation of the implementation of an enterprise. However, none of these ideas, concepts, techniques, and initiatives was ever part of an integrated, coordinated plan for engineering and manufacturing the enterprise.

Furthermore, Enterprise Architecture, as it is practiced today by most people, is still a pretty random, un-disciplined, fragmented, and trial-and-error activity.

What is most often being portrayed as Enterprise Architecture today are most often traditional and conventional practices and evolving technology being repackaged and sold as Enterprise Architecture.

Customers have become convinced they need Enterprise Architecture, but don’t know much about it. This is yet another situation which is ripe for the selling of another “silver bullet” solution. It is not the acquisition and implementation of new technology; it is developing the capability to define and analyze the requirements of the enterprise (i.e. architect the enterprise), design the enterprise (i.e. engineer the enterprise using the architectural drawings), and construct the enterprise (i.e. transform the architectural drawings and engineering designs into physical manifestations of the enterprise) that ultimately implement the enterprise in a much improved manner.

4.0 Choosing How to Do Enterprise Architecture

Enterprise Architecture should be viewed as a comprehensive definition of the framework for re-inventing the function known over time as data processing, information systems, or information technology, or whatever label you choose. It is a framework for at last having a comprehensive, integrated, rational, structured means to manage the architecting, engineering, and manufacturing of an enterprise.

A very significant step forward would be to re-name the function commonly known as Information Technology. The term “Information Technology” sometimes causes very negative reactions—it promotes an emphasis on the subjects “information” and “technology”. This is a great boon to the “information technology vendors”! However, it says nothing about a function whose primary purpose is to architect, engineer, and manufacture an enterprise. I suggest that collectively we seriously consider a new term—something like “Enterprise Management Services”, which would lead us to think in terms of an “enterprise”, “enterprise management”, and providing services that enhance our ability to manage and operate an enterprise.

I believe that the current IT function is quite well positioned to assume this role. However, the IT leadership, along with enterprise leadership, needs to recognize that their primary responsibility is to facilitate the architecting, engineering, and manufacture of the enterprise they support in a more disciplined manner in order to achieve dramatically better results than are currently being achieved. Their role is not only to be the “technology acquirer and implementer” for the enterprise. It should also be to lead the architecting, engineering, and manufacture of the enterprise. (Let me strongly emphasis that this does not imply assuming the role of managing the enterprise.)

This is a dramatic shift in the traditional role of a CIO. Adopting an approach to Enterprise Architecture based on the Zachman Framework for Enterprise Architecture is the first step in fulfilling that responsibility.

The next step—choosing how to do Enterprise Architecture—is critical and difficult. The principles, concepts, goals and objectives, the methods, tools and skills, and the organization of these is what will determine whether you achieve the potential that is now being recognized as the value of Enterprise Architecture.

One of the basic ways to separate the Enterprise Architecture “wheat from the chaff”, so to speak, is to closely examine the methodology espoused by the Enterprise Architecture practitioner, or Enterprise Architect, if you will. Most so-called Enterprise Architects don’t have a formal, defined, rigorous, practiced methodology. Also, because the concept of Enterprise Architecture is not well defined, just about anything can be presented as being “Enterprise Architecture”. As a matter of fact, even some of the leading advocates for Enterprise Architecture declare that there are “many ways to implement Enterprise Architecture”. There may be more than one, but I can guarantee you that there are not many!

Suffice it to say that listening to a 1, 2, or 3-hour presentation by a consulting firm, or attending a 2, 3, 4, or 5-day seminar is not adequate to understand and select a methodology for Enterprise Architecture. Anyone undertaking an Enterprise Architecture effort should invest a good amount of time and effort in examining the methodologies that are being promoted as Enterprise Architecture methodologies.

In accordance with the Zachman Framework for Enterprise Architecture, the Row 1 – Scope Models must establish the complete context for the development of the Row 2-through-5 models of the Enterprise Architecture.

The EA practitioner must be able to demonstrate that they have a methodology for implementing the entire Zachman Framework for Enterprise Architecture. By demonstration I mean that:

  1. The EA practitioner can provide documentation that articulates the methodology that is proposed,
  2. The methodology that is proposed has been applied successfully in at least two (2) enterprises where the Row 1 Models have been developed followed by the development of the Row 2-through-5 Models,
  3. At least three (3) large enterprise applications and enterprise databases have been implemented in production using the proposed methodology, and
  4. Experienced personnel who have led such efforts are available and will lead the effort.

The proposed methodology and its demonstrated use must result in:

  1. Alignment of implementations with the requirements from Row 3. This means that the Row 3 models (especially the Data and Process column models), which specify the business requirements (i.e. specification of the business data and processes), must be fully incorporated in the implemented Databases (i.e. Column 1, “Data”) and applications (i.e. Column 2, “Process”). In other words, the Databases and Applications that are implemented must incorporate/reflect the business requirements as specified in the Row 3 Models.
  2. Models which eliminate, or minimize, redundant data and processes throughout the enterprise,
  3. Applications and databases which eliminate, or minimize non-redundant data and processes,
  4. Engineering of the business processes. This means that the methodology must incorporate methods and techniques that provide for the identification, design/specification, and documentation of “how” the business processes are to be performed. The engineering or specification of the business processes are requirements that must be incorporated in any application acquired to support the business process(es),
  5. Integration of data and processes across the enterprise, and
  6. Enhance the ability to responsively manage and implement changes to the enterprise.

The above criteria will help ensure that the EA practitioner has the knowledge, experience, and credentials required to function as a legitimate Enterprise Architect.

There are emerging, though sparse, metrics that demonstrate phenomenal value and benefits for a “good” Enterprise Architecture program. What is critical to recognize is that the value and benefits are not inherently achieved just because an Enterprise Architecture program is put in place. The extent and type of changes introduced by the entire Enterprise Architecture program are what will determine the value and benefits achieved. Implementing an Enterprise Architecture program while not changing any of the existing or current methods of managing data and business processes will yield marginal, disappointing, and suboptimal results.

In conclusion, an Enterprise Architecture methodology must be designed to produce specified, predictable results. It must specify not only “What to do” but most importantly, “How to do it” and “Why”. Moreover, it must be based on a set of concepts and principles that theoretically, logically, and empirically establish a basis for producing an Enterprise Architecture that can be used to architect, engineer, manufacture, and implement an enterprise and that the underlying architecture can be demonstrated to be aligned, integrated, flexible, and responsive to change.

Douglas T. Erickson, President ENTARCO USA Inc.

Copyrighted 2011 by ENTARCO USA Inc.

Last Modified:


© 2021 ENTARCO USA, Inc.