Many business and IT professionals have realized that one simple and easy way to describe the Business Architecture (BA) is to say that it represents the “sum of all business processes” for an enterprise (or business unit). In fact some refer to this sum or integration as the “Business Process Architecture.” While this comment is basically correct, it does require a broader perspective and more detailed description.
To achieve this integration or summing, one must understand how the various business processes are organized for their particular enterprise (or business unit). Perhaps the processes are organized in a typical Business Function/Process model or perhaps they are classified by owning organization. These types of lists and groupings are sometimes useful as they may represent the inventory of business processes according to some specific organizing criteria, but no list or grouping of interesting things can represent any kind of architecture. Even so, this organized inventory of processes can provide a starting point for building the primary artifact of the BA.
One must next consider what information is maintained in the business process models. If the “inputs” to the processes, the “transformation” of these inputs into outputs, and the “outputs” themselves are all clearly defined, then integration of the models is possible and precise representation in a graphical model is quite feasible. If the inputs/outputs are obscured, poorly defined or buried in some supporting text, then this graphical information deficiency must be promptly rectified. The presence of the inputs/outputs is required for integrating in a graphical model and uploading in the modeling tool’s repository. Without the inputs/outputs, there is no way to integrate, connect or link the models. Lacking the inputs/outputs all one can do is juxtapose the models! Even with the inputs/outputs, what does one do if some of the models are represented in the lowest level swim lane format, or if some are aggregated to a higher level, or if others are aggregated all the way up to a value stream level? In this situation, it is necessary to define a purposeful organizing principle upon which to base integration and development of the Business Architecture.
From the inventory of processes, one can build an architecture of the business after agreeing to arrange and aggregate the business processes by a purposeful organizing principle. Essentially, two kinds of organizing principles are available for consideration, one based on an internal focus (inside-out) of the enterprise or one based on an external focus (outside-in) of the enterprise. The internal focus on functions or organizations will enable development of the Business Process Architecture, but this internal focus is flawed in that it represents a “weak” and sometimes even a “troublesome” organizing principle! Everyone understands the consequences of functional thinking and the controversies surrounding “silo based thinking.” Besides, this kind of thinking is so last century! So why carry forward this “inherent design flaw” when building a Business Architecture in the 21st Century? Why not choose an external focus – a customer centric focus – as the organizing principle for the BA? The manifestation of this customer centric focus is found in the oft familiar value stream[1] which is used in Six Sigma, Lean Manufacturing and strategic BPM initiatives. The value stream used as the organizing principle represents a much stronger choice and results in the development of an architecture of value streams focused on the customer rather than of a Business Process Architecture focused on functions or organizations. Therefore, one can eliminate the “inherent design flaw” as well as the controversies associated with the functional silos.
The integration of business processes into an architecture of value streams requires one to understand that workflow models are dynamic in nature; that is they transform inputs to create outputs. In typical workflow models, the dynamics of this transformation are clearly illustrated as well as, for example, the proper sequencing of activities necessary to complete the process. As for architectural models, they are static in nature, illustrating the many and varied relationships, linkages, connectivity and associations for a structure. In simple terms, Ivar Jocobson in The Object Advantage described architectures as static structures, with one element linked to other elements to form, collectively, a structure[2].
One can summarize the dynamics of a multi-step workflow model (a child model) up to a higher level single aggregated business process model (a parent model). This creates an architectural representation that is static in nature. The dynamic information, including the sequencing of activities and flow of control, may be encapsulated or aggregated all the way up to a value stream model. This aggregation is quite simple to perform as long as the parent and child models are properly “balanced between levels” with regard to the inputs/outputs. When all external inputs and external outputs in a higher level (parent) model are represented in a lower level (child) model, the two levels of models are then defined as in balance[3]. The aggregation of a workflow model up to a higher level architectural representation and its integration with other business processes is illustrated in the following series of four figures. On the descriptive connecting lines between processes and their respective inputs/outputs, a create line uses the “plus sign”, an update line uses the “clear delta” symbol and a retrieve line uses a “darkened arrow” symbol.
Figure 1 represents the dynamic nature of a typical workflow model. This example is for a build-to-order manufacturer representing the sequence of business processes and flow of control for fulfilling an order. This figure represents the highest level representation of a workflow model with the traditional swim lane models found in the lower levels of decomposition. For example, the business process “Place Order” (the third double box from the left) will get decomposed into a swim lane model as will all of the other business processes in the figure.
Figure 1: Fulfill Order – Highest Level Workflow Model: The aggregation of the workflow model in Figure 1 is represented by a single aggregated business process with its corresponding inputs/outputs balanced between levels as illustrated in Figure 2. With the information in the workflow model aggregated in this manner, the model’s content has transitioned from a dynamic representation to a static representation, and it is now available for integration with other similarly aggregated models. One could say that this figure has converted the workflow model into a proverbial “black box” model and that is accurate. In Figure 2, one can see the inputs/outputs, but the dynamics of the workflow are hidden from view represented by a single aggregated business process, the “black box” called “Fulfill Order” in this figure.
Figure 2: An Aggregated Workflow Model (the black box model) In a similar fashion, other related workflows – Change Order, Return Order and Review Order – are aggregated up as well. Now one can integrate all four of these aggregated business processes with one another creating Figure 3, the lowest level of a static architectural model for the Order to Cash Value Stream. Notice how the shared inputs/outputs between the four aggregated business processes are revealed for analysis in this figure. One could take all of the enterprise’s business processes and integrate them into an architectural type model by connecting one aggregated business process to another through their respective inputs/outputs as illustrated in Figure 3.
Figure 3: Integrated or Sum of Business Processes – Lowest Level Architecture Model: Continuing with this aggregation approach, the four aggregated business processes integrated in Figure 3 are in a likewise fashion, aggregated up to the Order to Cash Value Stream level as presented in Figure 4. With the addition of the sources and destinations for all inputs/outputs even more information is revealed for analysis in this figure. These sources and destinations may be external entries (e.g. Customer) or internal entities (e.g. other value streams such as Manufacturing to Distribution).
Figure 4: Order to Cash – Value Stream: Next one can integrate the Order to Cash Value Stream with the Manufacturing to Distribution Value Stream and/or with the Prospect to Customer Value Stream and so on, and so on until all value streams are integrated. As one can see the architecture of value streams represents the integration of all aggregated business processes, connecting one element to another element to form, collectively, a structure.
This aggregated approach was presented from a bottom-up prospective, but it will begin with the design of some candidate value streams and then follow with the aggregation and integration of the logically related business processes. This sum and integration of all enterprise (or business unit) processes results in the first release of the Business Architecture, reasonably complete and ready for analysis and scrutiny with strategic initiatives. Readers wishing to examine the BA case study example from which these figures were built are encouraged to review the one found within the embedded link. Please use Internet Explorer as the navigation and hyperlinks are configured for this browser; other browsers do not support the navigation and hyperlinks. Just click on the colored vertical rectangles.
References
- Martin, James, The Great Transition: Using the Seven Disciplines of Enterprise Engineering to Align People, Technology, and Strategy (American Management Association 1995), page 104.
- Jocabson, Ivar, Maria Ericsson and Agneta Jacobson, The Object Advantage: Business Process Reengineering with Object Technology (ACM Press 1995), page 97.
- Tom Demarco, foreword by P. J. Plauger, Structured Analysis and System Specification (Prentice-Hall 1979), page 341.
