Share This:

Four Pillars of Enterprise Architecture Driving Efficiency and Innovation by Consistently Managing Complexity and Change

By Samuel B. (Sam) Holcman

Summary: This article describes the four pillars of a holistic enterprise architecture: architectural models, framework, methodology, and solution models. It also explains the business and technology gains and demystifies the practice of implementing a successful holistic enterprise architecture.


It is only within the past 20 years that we have begun to develop an art and science for identifying and defining the graphical and textual descriptions of whole enterprises. Until this time, any art or science that we had related to this endeavor pertained to parts of enterprises—for example, organizational design and/or systems development. Because the focus of this article is on enterprise architecture, have there been successful enterprises that were never architected?

Yes. However, they were successful in relation to other non-architected enterprises. Moreover, the pace of change was slower in the industrial age, compared with the information age of today. Contemporary enterprises have to be able to adjust much more rapidly to meet changing demands in the face of global competition. This makes it critical to have readily available descriptive representations of one’s enterprise to use as a basis for making change.

The age-old question now arises in enterprises: How can one change something that one cannot “see”? How does one “see” an enterprise?

Benefits of a Holistic Enterprise Architecture

There are many benefits for both the business and technology areas of holistic enterprise architecture, but the following are a few of the greatest gains that have been observed.

Business Benefits

Technology Benefits

There is much confusion today in the terminology that surrounds enterprise architecture. Let us attempt to demystify these terms and concepts.

Demystifying Enterprise

An enterprise is any purposeful undertaking, commonly used in connection with undertakings that have ongoing operations. Mowing your personal lawn is an undertaking, but you probably would not refer to it as an enterprise. A company that mows lawns for profit is an enterprise.

All enterprises have architecture simply by virtue of their existence, whether they are explicitly represented or not. Unfortunately, this does not mean that all enterprises have been explicitly architected, for that would imply that deliberate and disciplined thinking went into their design and implementation. Most enterprises “evolve” and grow or shrink over time, without much attention being given to identifying and defining their fundamental components; so that (among other things) decisions can be made to reuse existing components to satisfy new requirements, eliminate redundancies, or eliminate activities that do not align with strategic business planning.

Enterprises are complicated, because they are composed of not only fixed, physical components, but also behavioral components such as people and business processes.

Demystifying Architecture

The architecture of anything is:

Everything that exists has architecture, whether it has been written down or not. That is the fundamental problem: Each person in an enterprise has an implicit representation of what they think the enterprise is all about. Architecture is an attribute and cannot exist by itself. A blueprint of a house is not its architecture; instead, it is one description of its architecture.

People built things for thousands of years without needing to be concerned about describing the architecture of the things they were building. As civilization evolved, however, large and complex construction projects—for example, temples, palaces, aqueducts, coliseums, and fortresses—that involved tradespeople of many skills, huge quantities of building materials of different kinds, and many years to complete, required a much more disciplined approach to building things.

Consequently, “building things” evolved into the art and science that we call architecture. As things get more complex, architecture becomes an imperative. When things are simple, you generally do not need architecture. Our complex enterprises of today need architecture.

Observations on Architecture

Architecture of Queen Anne Furniture

Architecture’s value is in its consistency across years of reuse. Queen Anne furniture is a particular architecture of centuries ago; the architecture has not changed since the early 1700s, and many items of antiquity and reproduction have been built to that design point (the Queen Anne furniture architecture). Furniture makers do not redesign the Queen Anne architecture; they build a Queen Anne desk. The design was done over 300 years ago, yet today it continues to communicate accurately the architects’ intent!

That is the beauty of architecture: When the initial investments have been made to articulate the business intent and direction within a holistic enterprise architecture, the follow-on changes and maintenance are much less costly, and the impact can be centuries of successful solution implementations!

LEGO® Blocks

Another effective analogy involves LEGO blocks. Imagine two individuals being given the task of building a play house. One has a set of LEGO blocks, and the other has to figure out what materials they are going to use and how they are going to be produced. Which one is likely to finish first? Which finished product is more likely to be changed faster to meet new requirements?

The architecture models in this example include the descriptive representations of the set of LEGO blocks, without any reference to any implementation.

The solution models include the descriptive representations of the various combinations of LEGO blocks.

Demystifying Enterprise Architecture

Enterprise architecture, as a discipline, is the art and science of building enterprises.

Enterprise architecture products are the graphical and textual descriptions that are used in the planning, design and implementation of, and ongoing changes to enterprises.

Architecture is the object—the end “product” that is to be achieved via an enterprise-architecture planning-and-design methodology (represented as a set of up-to-date, consistent, artifacts [written, drawn, recorded—communicated in persistent fashion]). Artifacts are statements of the enterprise’s intended state of being—its essence.

Holistic Enterprise Architecture

A holistic enterprise architecture is an invaluable communications vehicle that consistently conveys in a precise, accurate fashion, business items of importance, including assets, direction, and intent, to all stakeholders of the enterprise. Holistic enterprise architecture is “consumable” (usable) by both business and technology stakeholders. Successfully capturing the value of a holistic enterprise architecture is very achievable, if you approach the task in a thoughtful, guided fashion. This article shares the four significant components, or four “pillars,” of any successful holistic enterprise architecture effort.

Figure 1. Generic Four Pillars Model Click image to open large version



Your Goal: To Realize and Deliver Consistent Value
Survive. Grow. Thrive. Exceed expectations. Enjoy your efforts!

Successful leaders must prepare for opportunities and risks. They must endure difficult economies, surviving to seize emerging opportunities in the economic recovery, growing their business. These forward thinking leaders will exceed expectations by linking productive initiatives to desired goals and results; they will foster working conditions that are consistent and predictable in delivering true value. Workers enjoy their efforts when they know that there is a reasonable, thoughtful plan that the organization is following, and that their input is valued and recognized in defining and achieving the next level of success.

A tall order? Bold optimism? No, not at all! This is attainable, if the leaders recognize the need for, support, and advocate the consistent use of a practical, tailored, holistic enterprise architecture as a competitive differentiator. Holistic enterprise architecture is about understanding your enterprise. Writing more computer code just will not get you there. Holistic enterprise architecture—a concept that is about two decades old—is the linchpin to delivering consistent value every time.

We have begun to discover through thoughtful practice, the process of successfully achieving a practical holistic enterprise architecture. Through many real-world holistic enterprise architecture engagements, our experience reveals several consistent and key “pillars” of success in achieving usable architecture—the design for your enterprise. Your architecture will become the business solution engine.

Note the Difficulties in Achieving a Successful Enterprise Architecture

There are unfortunate cases of enterprise architecture efforts that stall or fail to deliver the envisioned value. At the core of such experiences lie confusion, expensive investments, and unbounded, unmet expectations. Some experts, vendors, approaches, and authors hype beyond reason, and they overuse and misuse the “enterprise architecture” phrase itself. Some improper uses include that it engulfs many business skills such as planning, forecasting, budgeting and project selection; these are separate, important skills that benefit from an enterprise architecture, but they themselves are not part of an enterprise architecture. The enterprise architecture participants becomes confused, “architecture paralysis” sets in, and may set misdirected expectations on the value and scope of an enterprise architecture.

Designing an enterprise architecture is a people-oriented analysis and solution, not one only of technology. The business knowledge of people forms your enterprise foundation.

Where to Begin?

We recognized in many actual holistic enterprise architecture engagements, a consistent set of required components for success; these four “pillars” are:

The outputs of the holistic enterprise architecture effort are the architectural and solution models. Why both architectural models and solution models? Simply stated, beginning with architectural models simplifies the effort, while beginning with solution models leads to undue complexity, as will be elaborated.

Defining Key Terms

It is very important to define accurately and consistently use terms in order for them to be meaningful or useful in any context. This article strives to use accepted grammatical forms, to avoid later confusion and miscommunication.

Refer to the Key Term Definitions section for definitions.

The Four Pillars of Success

Pillar 1: Architectural ModelsPillar 2: FrameworkPillar 3: MethodologyPillar 4: Solution Models
Architecture is about identifying and understanding the “independent” artifacts (architectural elements); therefore an architectural model is a representation of one artifact from the perspective of one business view.

Observations on Architectural Models

From a business perspective, tremendous value has been obtained by providing graphical representations and textual descriptions of the six architectural artifact types. If no more than this amount of holistic enterprise architecture is completed, never-before-realized understandings and insights will be obtained. We call this “quick-strike” architecture—a common way of beginning holistic enterprise architecture.

In total, there are 30 possible architectural models: six artifact classifications, across five perspectives; two business-role perspectives; and three technology-role perspectives.

A framework is a logical structure that organizes for a specific subject, a set of related artifacts, shows the relationships of the artifacts of the chosen subject area, and brings a totality perspective to otherwise individual ideas. A framework, therefore, makes the unorganized both organized and coherent.

Three requirements of a complete framework are:
1. Consistent naming of the components and artifacts of the framework.
2. Fully defined and consistently templated terms for the components and artifacts of a framework.
3. A consistent and expressive set of graphical representations for each component and artifact.

Five Business Views of an Enterprise

We recognize two primary “types” of people who must understand the holistic enterprise architecture: business people and technology people. Each of these types has multiple views of how they understand the enterprise; each view covers the entire enterprise, yet describes it from a differing perspective or value understanding. Moving from one perspective to the next represents a transformation of understanding of the enterprise—from business understanding to potential solutions.

Business people (and some technology people) will want to have at least a view of the:

  • Business-understanding view.
  • Business-interactions view (between business artifacts).

Technology people (and some business people) will want to understand at least three other views of the enterprise—specifically, the:

  • Technology-neutral view.
  • Technology-oriented view.
  • Selected-technology view.

Assign each architectural artifact to one business view, which will result in a nonredundant understanding.

Six Artifact-Classification Types: The Classic Language Interrogative Abstractions

  • Why—Classifies goals and motivations of the enterprise
  • How—Classifies processes and functions that are important to the enterprise
  • What—Classifies things and data groups that are important to the enterprise
  • Who—Classifies people and organizations that are important to the enterprise
  • Where—Classifies locations and networks that are important to the enterprise
  • When—Classifies events and times that are important to the enterprise

Assign each architectural artifact to one interrogative classification type, which will result in a nonredundant understanding.

If we look at chemistry, music, language, electrical engineering, civil engineering, and chemical engineering, all of their unique frameworks have these requirements and characteristics.

Observations on Frameworks

Classic examples of a “framework” are the following:

  • The periodic table of the chemical elements
  • Musical notes and “structures.”
  • The 26 letters of the English alphabet

These are all “architectural frameworks,” as they contain only “elements” (architecture) and not “compounds” (implementations).
There is nothing in these frameworks that tell you how to build anything, whether top-down, bottom-up, or middle-out.

A methodology consists of practices and procedures applied to a specific branch of knowledge. A methodology tells you how to build a particular type of thing. The methodology is, therefore, dependent on the selected framework. For example, the methodology to “make music”, is much different than that to “make water” (chemistry framework), and is much different than that to “make words or sentences” (alphabet framework).

A methodology has proven processes that can be followed in planning, defining, analyzing, designing, building, testing, and implementing the chosen artifacts.

Observations on Methodology

The concept of a methodology that is “framework-neutral” would be so abstract and arbitrary that it would have limited value. A “framework-neutral” methodology would look something like the following:

Plan, analyze, design, construct, implement

This “methodology” could be used in any domain to do anything (of questionable quality).

Test your enterprise-architecture methodology to see if it can be used to bake a cake (seriously!).

The author suggests that we can all agree that this “methodology” would have limited value.

A successful methodology:

  • Guides a process.
  • Simplifies a process.
  • Standardizes a process.
  • Can be customized to meet specific standards and practices of the organization that is using it.
  • Is accurate, as demonstrated through repeated practice.
  • Is up to date.
  • Is complete.
  • Is concise.
  • Defines deliverables and metrics.
  • Has methods, techniques, standards, practices, roles, deliverables, and associated education.
Solution models are about understanding and combining “independent” architectural elements to begin to build something. Each solution model focuses on a single solution description, and each is chosen to perform or contribute a given thing of value.

Solution models and their implementations achieve the realization, application, or execution of a plan, idea, model, design, specification, standard, algorithm, or policy.

Examples of typical solution models would include the following:

Solution-Model Interrelations

There are 57 interrelations between the six artifact-classification types that can be defined, for each business view:

  • 15 possible two-dimensional interactions
  • 20 possible three-dimensional interactions
  • 15 possible four-dimensional interactions
  • 6 possible five-dimensional interactions
  • 1 possible six-dimensional interaction

Thus, there are 285 possible solution models: five business-view perspectives, each of which holds the set of 57 artifact interactions.

You certainly need not build all of these models. It is suggested only that these are all of the possibilities, and our “profession” has been looking at only a very few of the possible solution models, without understanding all of the possibilities for solution models. Furthermore, this could be why all of the desirable features of any specific technique have not led to the consistent benefits that we are seeking: portability, interoperability, reusability, scalability, reduced time to market, reuse, simplification, and so on.

This fundamentally incomplete model might be leading us to believe that we are designing our “architecture,” when actually we are performing the design phase of our “implementation.”

  • “Object model”—Relates data (what) to methods (how) to actors (who)
  • “Dataflow diagram”—Relates data (what) to processes (how)

Architecture models are engineering models; solution models are manufacturing models. Both are required in the “physical world”; both are required in the “information world.”

This article does not suggest that solution models are bad, but that architecture models are different from solution models. It also suggests that architecture (engineering) models come first (as in any profession that is known to humankind, to date), and we should derive the required solution (manufacturing) models from the architecture models.

Implementation of the definitions of these solution models consists of two primary parts: construction and delivery.

For a technology solution, construction includes the:

  • Selection of hardware, software, and vendors for the implementation.
  • Planning and preparation of risk mitigation (disaster recovery, data backup, distributed and clustered processing, hot-swap, and so on).
  • Building and testing of the network-communication systems.
  • Building and testing of the data stores.
  • Writing and testing of the new program modifications, including iterative business-user test feedback.
  • Installing and testing of the total system from a technical standpoint, and so on.
  • Planning, preparing, documenting self-service helpdesk resources, and training staff for providing warm-body helpdesk services.

For a technology solution, delivery is the process of:

  • Conducting final system and user-acceptance testing.
  • Preparing the conversion plan.
  • Installing the production data stores.
  • Providing training or training materials to new users, including helpdesk services.
  • Converting all relevant operations to the new services.

Meta-Methodology to a Holistic Enterprise Architecture

We can demonstrate the context of the pillars through a “meta-methodology.” While some of the described steps might be one-time, initial preparation, most are applicable to each phase or pass through the holistic enterprise architecture activities. (See Figure 1.)

Briefly, we could simply define our required meta-methodology to be the following:

This is too brief to be really useful, so let us elaborate with more detail.

Partition the Scope: Establish Bounds of Coverage Click image to open large version

Set clear and attainable bounds upon the area of the enterprise to be investigated as the area of interest to be architected and designed. For example, boundaries could be corporate strategic planning, human resources, a subsidiary, or a large department. Of course, the whole enterprise (or more than just one enterprise) could be the bounds of coverage. See Figure 2 below.

Select a Dedicated Team of Key Individuals

It is desirable to have the business area of the enterprise being exercised dedicated to discovering and defining the key business artifacts for their scope of influence. However, proven techniques are available to begin holistic enterprise architecture without strong business support (of course, not as desirable). It is better to represent the best understanding available than to move directly to implementation.

Define and Represent Your Architecture

You will place the initial focus on the architecture “designers’” domain for understanding, and later focus on the “builders’” domain of implementation.

Figure 4. Pillar 2: Framework

Figure 5. Pillar 3: Methodology

Execute Your Architecture Design

The “builders’” domain hopefully will contain an ever-accumulating and reusable set of solution models. Here, you use the architectural models to derive and develop solution models. See figure 6 below. Click image to open large version

Figure 6. Pillar 4: Solution Models

Expand Your Holistic Enterprise Architecture Coverage

Figure 7. Complete Four Pillars Model

Demystifying the Practice of Holistic Enterprise Architecture

We are now at a point in the maturity of holistic enterprise architecture where all of the required “pillars” are becoming consistently achievable. All of them—architectural models, framework, methodology, and solution models—are required for success. “Best of breed” will not work; it has not worked in other disciplines outside of information technology, and it is doubtful whether it will work for enterprise understanding and information technology.

When your enterprise has a consistent body of knowledge through these pillars, the resulting intellectual capital will define a complete and executable set of consistent practices and designs that will provide measurable (and immeasurable) value to your enterprise. Your enterprise will dramatically increase its success rate for delivery of valued business solutions, as all parties will understand your enterprise through its up-to-date holistic enterprise architecture, and all implemented solutions will derive from your architecture. That day is very near in some organizations.


Any article of this length can just provide an overview for understanding these pillars. It is hoped the reading audience will understand that this is just a high-level summary. At least four years (and many books!) are required to get a bachelor’s degree (a substantial but not exhaustive level of understanding) in all of the fields of precision, such as electrical engineering, music, and chemistry.

It is hoped also that this article provides a beginning for those in our profession pursuing their “bachelor’s degree in holistic enterprise architecture,” an understanding for those who are responsible for enterprise architecture activities, an understanding of the enterprise architecture for the “receiving” community, and a wider understanding of these pillars for holistic enterprise architecture success!

It is time to move from the hype stage of enterprise architecture to holistic enterprise architecture. It is time to move from theory into practice and action. Holistic enterprise architecture drives enterprise efficiently and innovation by consistently managing complexity and change.

Key Term Definitions

Architectural elements: Each instance of an architectural model is an architectural element of the architecture. Note that this is a subset of “artifact,” in that not all artifacts are architectural elements.

Architectural models: Each model is a representation of one artifact from the perspective of one view.

Architecture: The art and science of building something, and the manner in which its components and artifacts are organized and related. The Greek root of architecture means “master builder.”

Artifact: Each artifact uniquely and non-redundantly defines a “thing” of interest to the enterprise, and each can be classified with one artifact-classification type, and with one view.

Artifact-classification types: Classify each architectural artifact as answering one of the six classic language interrogatives: Why? How? What? Who? Where? When?

This classification helps organize ideas and concepts into logically common groups. This classification helps discover overlaps, gaps, and opportunities.

Business views of an enterprise: Five views that gather artifacts across all six artifact-classification types, where all such grouped artifacts help to define the enterprise perspectives. Each view represents a transformation of understanding of the same architectural artifacts:

  1. Business-understanding view:
    This view represents models of the architectural elements.
  2. Business-interactions view:
    This view represents models of interactions between each artifact, models of their relations, and constraints.
  3. Technology-neutral view:
    This view represents architectural models to reflect an architectural element in a robust yet non-technology-dependent manner.
  4. Technology-oriented view:
    This view represents the manner in which architectural models reflect existing or proposed technologies, including alternatives.
  5. Selected-technology view:
    This view identifies choices of technology, and the manner in which architectural models are to take advantage of those selected technologies.

Enterprise: Any collection of organization-related or people-related things, all of which have a common set of interests (such as goals, principles, or a single bottom line). In this sense, an enterprise can be a whole corporation, a division of a corporation, a government organization, a government agency, a single department, or a network of geographically distant organizations that are linked together by common objectives, a project, a team, and so on.

Enterprise architecture: Enterprise architecture is about understanding the enterprise through:

Framework: A logical structure that organizes, for a specific subject, a set of related artifacts, shows the relationships of the artifacts of the chosen subject area, and brings a totality perspective to otherwise individual ideas. A comprehensive framework has a consistent naming of the components and elements of the framework, all terms for the components and elements fully defined, and a consistent and expressive set of graphical representations for each component and element.

Holistic enterprise architecture: An enterprise architecture that is developed and maintained by using the full complement of the four pillars of successful architectures: architecture models, framework, methodology, and solution models.

Interrelations: These are the relationships, interactions, and constraints that individual elements and artifacts have to each other. A reflective relationship is an artifact of one classification type being related to other artifacts of that same type.

Examples of architectural-model reflective interrelations would be a:

Examples of solution-model non-reflective interrelations would be a(n):

Methodology: Consists of practices and procedures that are applied to a specific branch of knowledge.

People: We recognize two primary “types” of people who need to understand the holistic enterprise architecture: business-focused people and technology-focused people.

Solution models: Each solution model is about being able to understand and combine “independent” architectural elements. Each focuses on a single solution description; each is chosen to contribute a given specific entity of business value.

About the author

Samuel B. (Sam) Holcman is the Managing Director of the Enterprise Architecture Center Of Excellence (EACOE), the Business Architecture Center Of Excellence (BACOE), the Chairman of Pinnacle Business Group, Inc., and the President of the Zachman Institute for Framework Advancement (ZIFA). He is considered the practitioners’ practitioner in enterprise architecture, and a leading implementer of and worldwide educator in enterprise architecture methodologies and techniques. Sam can be reached via e-mail at [email protected], or via telephone at (810) 231-0531.

Four Pillars of Enterprise Architecture
Article Name
Four Pillars of Enterprise Architecture
This article describes the four pillars of a holistic enterprise architecture: architectural models, framework, methodology, and solution models. It also explains the business and technology gains and demystifies the practice of implementing a successful holistic enterprise architecture.
Publisher Name
Enterprise Architecture Cener of Excellance
Publisher Logo

Share This: