Many companies are beginning or at least seriously considering a Business Architecture (BA) initiative. Even though the Business Architecture has always existed, its structure, nature and appearance have remained hidden from view. The ability to express the complexity of an enterprise in a commonly understood and graphical format, for purposes of analysis and design is severely limited without the Business Architecture. And of course, one will need a rich graphical modeling notation or language in order to develop the BA.
Most likely at the beginning of a typical BA initiative, several business and IT managers are ask to provide their current models of the enterprise. Many times a model of classified processes listed in functional columns is innocently, but incorrectly assumed to represent the BA model itself. If some models are available, they are usually out of date or really just classifications of interesting things about the enterprise. Sometimes, the response is “nothing formal is available but I can draw one on the grease board!” In most cases, these representations are not models at all, but simply sketches or casual drawings lacking any formal modeling disciplines. These drawings merely represent the thoughts in an individual’s mind and do not possess the rigor or structure to be easily understood by others or shared throughout the enterprise without extensive explanation.
Some may have tried to adapt the Unified Modeling Language (UML) notation and artifacts as perhaps providing a “first look” at the Business Architecture. Even though the UML was neither designed nor intended for use as the language of BA, these first models may have at least launched some creative and focused thinking about the BA model itself. And yet, others may have also tried to use the Business Process Modeling Notation (BPMN) in a similar fashion. While these first attempts certainly had noble intentions, most likely, these “early drafts” using the UML and/or the BPMN were disappointing, both in the ability to represent enterprise complexity and to create a shared understanding about the enterprise. At the minimum, one would need to significantly expand the UML or BPMN in order to represent the Business Architecture. After all, neither the UML nor the BPMN comprehend Business Architecture needs! Ironically, it is interesting to note that the BA must integrate all of the enterprise’s business processes, probably modeled using the BPMN, and the business processes must link to UML or code development/generation artifacts.
Without delving into the full blown development of a modeling language for Business Architecture, perhaps one can at least begin the discussion and analysis by first looking at some of the most basic needs for Business Architectural modeling.
In the core BA model, one will find the integration of processes, capabilities, functions, activities and other similar things represented as an essential component. Most likely, this essential component will represent an end-to-end collection of activities that deliver a result to a customer (or end user) and it has a clear goal: to delight the customer(1). This high level component integrates several enterprise elements and represents a singular but unique encapsulation of significantly important information. Some of these encapsulations may focus directly on the profit generating customer while others may benefit and deliver results to corporate executives, stakeholders, employees and the people who run the enterprise. However, its integration with other similarly encapsulated enterprise entities and external entities stands at the foundation of the BA. The organizing principle and purposeful reason for integration of the BA requires a clear definition, understanding and acceptance by the enterprise; and that principle and purposeful integration demands a customer-centric focus.
One can call this singular encapsulation many names, for example, a value stream or a customer-centric cross-functional process. And of course, the focus on a client, consumer, guest, passenger, patron, citizen, end user, stakeholder and other similar terms are just as valid as customer. Value streams will suffice for purposes of continuity in this article. After all, value streams are frequently used in Lean Manufacturing, Six Sigma, BPM and other enterprise disciplines.
In the language of BA, the value stream needs a representation, graphical icon or construct that sets it apart from other decomposed or aggregated processes. The value stream is at the highest level of a set of logically related and integrated elements, and sometimes stands alone for analysis, design and expectations for success as defined in the corporate strategy. However, one can harness even greater potential by integrating the value streams by having one drive, influence, respond to and/or initiate another! One can decompose the value stream for detailed analysis of its complexity, seeking performance improvement and then aggregate it back up to discuss its contribution to strategic objectives. After all, a value stream will include all of the people, processes and technologies required to deliver the expected results and outcomes.
Many process models begin in the swim lane format and these are very well recognized and understood. These models usually represent the lowest level process descriptions from which the transition to creating UML artifacts begins or to configuring packaged software begins or if using a BPM tool, the transition to eventually code generation begins.
Some of these swim lane models run for many pages, contain off page connectors and are occasionally hard to follow in this multi-page format. It is rather easy to aggregate a swim lane model up to a single box representation or maybe to a single page representation with a modest number of aggregated processes. While this does add an additional level to the model, it makes it more comprehensible and less intimidating to other reviewers.
From the multi-page swim lane model, some logically related group of sequential steps are consolidated into a single box along with its net external inputs and outputs. For example, perhaps a ten page swim lane model might aggregate up to a single page model with six or seven boxes containing their corresponding external inputs and outputs. Then by “clicking on” or decomposing any of the six or seven aggregated boxes, one exposes the very same detail and complexity of the logically related group of sequential steps as found in the ten page swim lane model. Some consider aggregation as the creation of “process black boxes” and this characterization is valid. These “process black boxes” also encourage reuse of formerly designed processes which have been optimized for performance. This is quite easy to use if properly aggregated, but rather hard to reuse if forced to model exclusively in the swim lane format. As long as the normal rules of balancing inputs and outputs between levels of a model are strictly followed, aggregation and decomposition become not only a useful technique, but a necessary one as well.
In the language of BA, the decomposed (lower level detail) and aggregated (higher level summary) processes need a different representation, graphical icon or construct, and most every modeling notation satisfies this requirement fairly well.
Process aggregation and process decomposition are very useful tools and this technique has been around for quite some time. By applying the very same thinking to “inputs and outputs” of processes, one can realize a similar benefit. Inputs and outputs can be aggregated and decomposed as well; aggregated in higher level models and decomposed in lower level models. For example, if a company manufactures one hundred different products, representing all one hundred products in a single high level model would exhaust the modeling page’s landscape and overwhelm the reviewer. The one hundred products might be aggregated, say for example, by customer type, by line of business or by product family; it just depends on what is best for the enterprise, but not based on some arbitrary modeling rule.
At least three kinds of input/output aggregations should be considered: whole/parts, shared relationships and containers. For whole/parts, these inputs/outputs must have all of the parts to have the whole; for shared relationships, these inputs/outputs share something in common or may inherit some shared properties; for containers, these inputs/outputs are broadly defined, and are sometimes composed of several dissimilar but logically related elements.
In the language of BA, representations of aggregated or decomposed inputs/outputs must be clear in the model. Therefore, the representations of any aggregated inputs/outputs must appear differently from those decomposed inputs/outputs at their most elementary or lowest level. And to further enhance the ease of communication and differentiation in graphical models, “physical” inputs/outputs (e.g., a fulfilled order packaged in a shipping container) must appear differently than “technology related” inputs/outputs (e.g., a web transaction). All of these distinctions in a rich graphical modeling language improve its readability and ability to instantly communicate something of relevance just by its appearance.
Balance inputs and outputs between levels of a model: A model is in “balance” when all external inputs and outputs in a “high level” (parent) model are represented in a “lower level” (child) model. The two “levels” of models are then defined as “in balance.” This is a formal rule that requires strict adherence. “Level” refers to a position in a scale or rank, for example, parent model and child model, and most everyone is familiar with this term in this context. This formal definition of “balance and level” was explained in a book by Tom DeMarco titled Structured Analysis and System Specification(2).
In the language of BA, the balancing of inputs and outputs between levels of a model is a rule rather than a single construct in a modeling language. The manifestation of this rule is found in the appearance and relationships between parent (high level) and child (low level) models.
These few recommendations and suggestions are merely intended to initiate the thinking about the language of Business Architecture. Anyone trying to build a Business Architecture model will quickly realize the futility of using the UML and/or BPMN and will begin to understand the ideas presented here as a starting point for developing a modeling language or notation specifically fulfilling the needs of the Business Architecture. A modeling notation which maps its constructs to those of a real language, coupled with a rich syntax and semantics for all constructs, will lead to a very effective and efficient way in which to communicate important ideas within the Business Architecture; after all, a picture is worth a thousand words!
For those wishing to see an example of a Business Architecture model that supports the ideas presented in this article, just review the web site listed below. Please use Internet Explorer as the links are configured for this browser. Just click on any colored vertical rectangle, representing a value stream (or an aggregation of value streams) in order to navigate through the models.
There are no products in your shopping cart.
| 0 Items |
Membership at BAInstitute.org includes access to our other communities.
