The Business Architecture Core Artifact

Just about any serious Business Architecture (BA) discussion these days will include some reference to a model or artifact within the BA approach.  This article will discuss what the author believes is the “core artifact” of the Business Architecture.

The core artifact of the BA must indeed represent the metaphorical “blueprint” of a business.  However, before jumping into a description of the BA core artifact, some context is needed and some references are required.  To begin with, one must define and understand the basic term, “architecture” as it applies to an enterprise.

• An IEEE 1471 website (1) defines architecture as “The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
• The Open Group Architecture Framework (TOGAF) web site (2) defines architecture as “The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.”

Given these two similar and accepted definitions of architecture, one must then qualify for the Business Architecture its organizing principle – “the fundamental organization of a system, embodied in its components” (referring to the IEEE definition) or “the structure of components” (referring to the TOGAF definition).  The oft-familiar value stream used in Six Sigma, Lean Manufacturing and strategic BPM initiatives satisfies this “organizing principle” requirement, and placed in the context of other Enterprise Architectures, enables integration with other linked components.  Before illustrating this integration and linking, the reader is encouraged to examine Table 1 to understand the context of the Business Architecture and its organizing principle with other Enterprise Architectures and their respective organizing principles.

Table 1.

Reflecting on the information presented in Table 1, one might consider that the Business Architecture defines the enterprise value streams and their relationships to all external entities, other enterprise value streams, and the events that trigger instantiation (an occurrence, activation or execution).  It is a definition of what the enterprise must produce to satisfy its customers, compete in a market, deal with its suppliers, sustain operations, and care for its employees(3).   And a value stream is an end-to-end collection of activities that creates a result for a “customer,” who may be the ultimate customer or an internal “end user” of the value stream.  The value stream has a clear goal: to satisfy (or, better, to delight) the customer(4).  While this definition has not been formally adopted, it fits well with architectural and strategic disciplines.

Understanding the true meaning of architecture is critical to accepting the core artifact of the Business Architecture with its organizing principle, the value stream.  The references to “components, relationships and structure” in both the IEEE and TOGAF definitions are quite formal in their context rather than casual.  John Zachman states that “Architecture is the set of descriptive representations that are required in order to create an object.  If you can’t describe it, you can’t create it. Also, if you ever want to change the object you created, architecture constitutes the baseline for changing the object once it is created(5).”  Contrast this formal context with a far more casual example; a list of building materials at a construction site.  Clearly, this list does not accurately represent the building’s architecture.  And by the way, a list of business functions and other interesting things about an enterprise with references to some processes, databases or applications does not correctly represent the Business Architecture either.  And realize too, that these lists can never constitute the baseline for change as described by Zachman.  However, some business and IT professionals believe that these kinds of lists represent a “blueprint” or an architectural model of the business, but that is an “innocent misuse of architectural concepts.”

An architectural model represents the purposeful integration of components and elements that are intentionally linked and connected to form a unified whole.  For example, consider the technology related inputs/outputs of the value streams found in the Business Architecture and the repositories of data found in the Data Architecture.  In the Order-to-Cash Value Stream for a build-to-order manufacturer, an output – the “Order” – is created in the “Order” repository during processing.  The highest level architectural representation of this value stream is illustrated in Figure 1.  Notice that all inputs/outputs represented by the slanted boxes are connected to their appropriate sources and destinations.  On the connecting lines, a create uses the + symbol, an update uses the r symbol and a retrieve uses the u symbol.  The “Order” repository, rendered in the lower left corner of Figure 1, is but one example of an entity that is linked between the Business Architecture and Data Architecture.

Figure 1.

Further examination in the Business Architecture will discover the “Order” is defined as depicted in Figure 2.  This figure describes the various states of the “Order” – Entered through Paid in full – and a just a few attributes contained in the “Order” – Order Number, Customer Number and Item Number.

Figure 2.

In the Data Architecture, one will find this very same “Order” described in the Entity Relationship Diagrams as depicted in Figure 3.  One will notice the similarities in information captured, but the model’s formats and constructs are quite different.  Since a commonly accepted modeling notation across all Enterprise Architectures does not exist, both architectures will represent the “Order” differently and capture different information even though both are referring to the very same entity, but in a different architectural domain and used for different purposes.

Figure 3.

With the understanding of architecture in a formal context and the illustration of integration and linking just presented, one can start to realize some important characteristics of the core artifact of the BA.  Obviously, one cannot represent the core artifact as an independent, classified list of functions, processes and activities, but this representation must illustrate a true architectural “blueprint” type model and clearly show linked components, entities and information.

As for another example in the context of IEEE’s “relationships to each other and the environment” and TOGAF’s “inter-relationships,” again the reader is referred to Figure 1.  Notice the relationships between the Order-to-Cash Value Stream (depicted in the center), the external entities (e.g. Customer), and other value streams (e.g. Prospect-to-Customer).  These relationships are defined by the inputs/outputs and represent the purposeful integration of components and elements that are intentionally linked and connected to form a unified whole.  Readers wishing to examine a more comprehensive BA core artifact (6) are encouraged to review the one found within the embedded link.  This case study shows that the value streams are linked and integrated with external entities and other value streams through their inputs and outputs.  All the reader needs to do is visit the web site and click on the value streams – the multi-colored vertical rectangles – to expose the detail and connectivity associated with each value stream.  Then, once inside a particular model, the reader may again click on the other multi-colored vertical rectangles to understand the integration with other value streams.  Please use Internet Explorer as the navigation and hyperlinks are configured for this browser; other browsers do not support the navigation and hyperlinks.

From just these two examples, the reader can research the ideas presented in this article and scrutinize the case study model as well.   Given the context of the whole enterprise with its supporting architectures and the formal IEEE and TOGAF definitions of architecture, this author closes with the position that the case study model presented in the embedded link above represents the Business Architecture core artifact!  This architectural representation is essential and unifying for the business and defines a set of properties which determine the enterprise’s structure and behavior. Accepting this point of view, then one may design, build, operate and change an enterprise using this descriptive representation of the business as its core artifact.  And hopefully, the reader agrees!

References

• IEEE 1471 website, Frequently Asked Questions (FAQ), http://www.iso-architecture.org/ieee-1471/ieee-1471-faq.html  Just scroll down to the question, “So, what is an architecture?
• The Open Group Architecture Framework (TOGAF) website, http://www.opengroup.org/architecture/togaf9-doc/arch/  Just click on “Definitions” on the left side of the TOGAF web page, and scroll down to the second definition under architecture.
• Whittle, Ralph and Conrad B. Mryick, Enterprise Business Architecture: The Formal Link between Strategy and Results (CRC Press 2004), page 31.
• Martin, James, The Great Transition: Using the Seven Disciplines of Enterprise Engineering to Align People, Technology, and Strategy (American Management Association 1995), page 104.
• Zachman, John, Zachman Institute for Framework Architecture, “Architecture is Architecture is Architecture” http://www.scc.cc/voice/ArtArchitecture%20Is%20Architecture.pdf
• Enterprise Business Architecture web site: Enterprise – Hierarchy; http://www.enterprisebusinessarchitecture.com/model/Enterprise%20-%20Entity/Enterprise%20-%20Hierarchy.htm