Driving Efficiency and Innovation by Consistently Managing Complexity

and Change

Samuel B. (Sam) Holcman
Managing Director of the Enterprise Architecture Center of Excellence (EACOE).
President of the Zachman Institute for Framework Advancement (ZIFA).

 

March 2010

 

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.

 

Introduction

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

• Developing and communicating a broad understanding of your business—a confirming enterprise-self realization that is clear and concise.
• Identifying and mitigating potential risk in your selected paths of action or investment—thereby, reducing unintended consequences.
• Clarifying your business priorities and identifying your core competencies—enabling you to assign key resources to projects confidently, and leveraging top talent for critical needs.

Technology Benefits

• Creating a practical and efficient means to manage your information-technology portfolios, rationalizing your existing systems and projects to gain significant cost reductions, and helping you remove waste and redundancy in your information-system deployments.
• Aligning your technology investments and assets to project initiatives that demonstrate direct support of priority business goals, competencies, and needs.
• Identifying, classifying, representing, developing, and accumulating in an accessible portfolio your architected, highly reusable technology assets.
• Identifying and mitigating potential impacts of your proposed solutions, services, or changes—thereby, addressing all areas that are affected in the design and negotiation of new or updated solutions, and reducing your exposure to the risk of unintended impacts and degradation.

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:

• Its fundamental organization—embodied in its components and their relationships to each other and their environment.
• The principles that govern its design and evolution.

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 trades people 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. (See Figure 1.)

Figure 1. Four pillars, generic model

 

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 become 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 analysisand solution, not one of technology only. 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:

• Architectural models.
• Framework.
• Methodology.
• Solution models.

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

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

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.

 

Six Artifact-Classification Types:The Classic LanguageInterrogative 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.

 

Five Business Views of an Enterprise We recognize two primary “types” of people who must understand the holistic enterprise architecture: businesspeople 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 ofunderstanding 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.

 

Pillar 2: Framework

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.

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.

 

Pillar 3: Methodology

A methodology consists of practices and procedures applied to a specific branch of knowledge. A methodology tells youhow 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.

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.

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.

 

Pillar 4: Solution Models

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:

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

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

 

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 know 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 on page 19.)

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

• Develop architectural (engineering) models.
• Develop solution (manufacturing) models by drawing upon architecture models and architecture elements.
• Assemble implementations from these solution models.

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

Figure 2. Potential architectural coverage (Click on the picture for a larger image)

 

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. (See Figure 3.)

Figure 3. Pillar 1: Architectural models (Click on the picture for a larger image)

 

• Step 1: Select and prioritize architectural modelsthat are of value to the enterprise.
• Step 2: Organize the architectural models, as defined in the architectural framework. (See Figure 4.)
• Step 3: Follow a lean and proven methodology that supports the framework to develop architectural models. (See Figure 5.)
• Step 4: Describe and represent the enterprise within the architectural models.

Figure 4. Pillar 2: Framework (Click on the picture for a larger image)

 

Figure 5. Pillar 3: Methodology (Click on the picture for a larger image)

 

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

Figure 6. Pillar 4: Solution models (Click on the picture for a larger image)

 

• Step 1: Select an implementation domain team of key individuals from both business- and technology-perspective groups.
• Step 2: Educate the Implementation domain team on the architectural models, framework, and methodology.
• Step 3: Select and prioritize solution models that are of value to the enterprise.
• Step 4: Describe and represent the solution models to exercise the architecture in defining viable candidate solutions and services.
• Step 5: Educate the architectural-domain, business-project, and information-technology project teams on the solution models. Share the wealth!

Expand Your Holistic Enterprise-Architecture Coverage

• Step 1: Select the next “slice” of the enterprise to address, expanding upon the work that is already completed. Adjust the coverage of the models to reflect discovered value. (See Figure 7.)
• Step 2: At this time, both the business- and information-technology project teams can begin to implement priority candidate solutions and services, based upon the solution models.

Figure 7. Four pillars, complete model (Click on the picture for a larger image)

 

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.

 

Conclusion

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 architecturemeans “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:

• A set of independent and non redundant artifacts.
• The interrelations between these artifacts.
• Communicating these understandings to the numerous people who make up the enterprise.

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:

• Process (how) relates to another process (how).
• Data group (what) relates to another data group (what).

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

• “Object model”—Data (what) relates to a method (how) relates to an actor (who).
• “Dataflow diagram”—Data (what) relates to a process (how).

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 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 Sam@EACOE.org, or via telephone at (810) 231-0531.