The Business Architecture Core Artifact

Comments: 1
Rate this:
Total votes: 0

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.           

Enterprise Architecture Component Component Organizing Principle
Business Architecture Value Streams including the Inputs/Outputs, Results and Outcomes
Data/Information Architecture Logical Tables, Entities and Relationships
Application Architecture Services, Service Composition (into applications) and Service Usages (by other applications)
Technology Architecture Servers, Computing and Communication Technology Elements
Security Architecture Authentication and Authorization
Organizational Architecture Roles and Responsibilities including Expectations

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! 



Ankit Tara
posted 6 years 23 weeks ago

I agree with the spirit of

I agree with the spirit of the definition of architecture from the IEEE 1471; however think it is a bit weak for the approach based on the System Thinking. I define an architecture of a system as a sub-structure of the system's elements that simultaneously possess three characteristics - being fundamental, self-sufficient and cohesive - and share the common principles governing its relationships to each other and the environment as well as its design and evolution. Architectural elements of a system are those that the system cannot exist without (fundamental), that are independent from other elements of the system (self-sufficient) and form a united structure (cohesive). Challenging many elements of a organisation of business, I have found (so far) only two elements meeting the requirements to the architectural elements. These elements are: business functionality and business information (semantics and ontology). There are other fundamental elements in the organisational systems but they either not cohesive or not self-sufficient. Thus, Business Architecture is the architecture that comprises business functionality and business informational models, positions itself across the business administrative and organizational enterprise structures, and that transforms goals and objectives described in the Business Enterprise Model and refined in the Strategic Business Plans into the functional and informational definition of the corporate business. I do distinguish the abstract architecture from its actual implementation. With this regard, I relate infrastructure, application, security and other technology architectures to the implementation of Business Architecture. The Organizational Architecture, IMO, is not an architecture and the organisational structure is one of the major implementation elements that have to meet the requirements of business architectural solutions for particular strategy. John Zachman's statement: “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)" - does not make much sense to me because a system's architecture is a particular thing with its definition; the IEEE 1471 pointed on that no description of the things (=views on the thing) cannot fully replace the definition of the thing. I do not understand what object may be required to create and why a change in whatever object relates to the system's architecture.

Join the Discussion

Remind me later

What are your professional development goals for 2022?

Take our Professional Development Survey
Take the survey now for an opportunity to win an online course worth up to $795!

The survey is just five questions long and only takes a few minutes.