Driving Efficiency and Innovation by Consistently Managing Complexity
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.
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 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.
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:
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.
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:
If we look at chemistry, music, language, electrical engineering, civil engineering, and chemical engineering, all of their unique frameworks have these requirements and characteristics.
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:
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:
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:
For a technology solution, delivery is the process of:
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:
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)
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)
Expand Your Holistic Enterprise-Architecture Coverage
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.
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:
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 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.
Software Architecting and CMMI
Eltjo Poort, Herman Postema, and Robert L. Nord
Even though architecture modeling is an established practice for the realization of high-quality software, Capability Maturity Model Integration (CMMI) is silent on architecting practices. This limits the effectiveness of CMMI, because a high-quality architecture is a prerequisite for successful software-development projects.
There is some implicit architecting guidance in CMMI version 1.2— specifically, in the following process areas:
Apart from the preceding, however, there are some serious gaps in CMMI version 1.2 with respect to architecture:
The authors have proposed a number of enhancements to make architecting more explicit in CMMI, such as a more prominent role for quality attributes. These enhancements for the new CMMI version 1.3 are under consideration by the CMMI Product Development Team, which includes members from government, industry, and the Carnegie Mellon Software Engineering Institute (SEI).
Eltjo Poort is currently Lead Architecture Expert at Logica in theNetherlands, where he is responsible for assessing feasibility of solutions and improving architecting practices. Eltjo is also a member of Working Group 42 “Architecture” of ISO/IEC JTC1/SC7, as well as IFIP working group 2.10 “Software Architecture.”
Herman Postema is a Principal Management Consultant at Logica Management Consulting. He has an extensive track record in CMMI-based (software) process improvement. Herman has been a lead appraiser in many CMMI appraisals and has participated in a large number of SCAMPI appraisals.
Robert L. Nord is a senior member of the technical staff in the Research, Technology, and System Solutions Program at the Software Engineering Institute, where he works to develop and communicate effective methods and practices for software architecture. Robert is a published author, as well as a member of the ACM and International Federation for Information Processing Working Group 2.10 Software Architecture.
Implementation of Microsoft
Solution Framework in
Distributed Extreme Programming
Microsoft Solution Framework (MSF) is a practical, flexible, and proven approach to delivering software solutions through various artifacts. Frankly speaking, there are two main models in MSF: CMM models
and agile models. People will choose the CMM model to provide an enterprise-class software blueprint and the agile model to provide rapid software development. The problem is that many clients want rapid software and need sufficient artifacts. The happy fact is that more than 60 percent of developed software is separated geographically and has limitations in speed and agility.
Distributed extreme programming provides (DXP) a set of methods, process discipline, and certain tools to improve the agility in distributed software development. DXP works by creating a set of mechanisms to implement extreme programming in remote or geographically distributed software development.
The key phenomenon of DXP is the way in which communication, coordination, and control happen in distributed software development. The phenomenon is initially solved through various live document artifacts that provide sufficient understanding about the project in distributed software development.
The idea behind this column is to construct an artifact model that mimics how MSF uses artifacts as an indirect communication tool in its phases. DXP has requirements phases, architectural phases, project phases, and product-development phases:
Those artifacts work as live documents and work great if they are stored in a collaboration portal such as Windows SharePoint Services (WSS) or Visual Studio Team System (VSTS). The former provides a lightweight portal that is sufficient for small - to medium-size distributed projects, while the latter is great for working in enterprise-class software development.
How sufficient artifacts are composed, what kind of base template is needed, and how it will be implemented is a cool discussion that we can share together at https://ridilabs.net/.
Ridi Ferdiana ( email@example.com), Microsoft MVP, Gadjah Mada University Lecturer, Indonesia.