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?
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.
There is much confusion today in the terminology that surrounds enterprise architecture. Let us attempt to demystify these terms and concepts.
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.
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.
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!
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.
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.
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.
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.
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:
Technology people (and some business people) will want to understand at least three other views of the enterprise—specifically, the:
Assign each architectural artifact to one business view, which will result in a nonredundant understanding.
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.
Classic examples of a “framework” are the following:
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 has proven processes that can be followed in planning, defining, analyzing, designing, building, testing, and implementing the chosen artifacts.
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:
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:
There are 57 interrelations between the six artifact-classification types that can be defined, for each business view:
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.”
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:
For a technology solution, delivery is the process of:
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
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.
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.
Expand Your Holistic Enterprise Architecture Coverage
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.
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 nonredundantly 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:
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 nonreflective 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.
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.This entry was posted in Business Communication, Business Transformation, Enterprise Architecture, Enterprise Transformation, Information Technology, IT, IT Transformation. Bookmark the permalink. ← Measuring an Organizations Capability Ability EACOE & The Open Group Comparison →
Comments are closed.