It is my observation that there are no true standards regarding business architecture. Ask any three Business Architects and they will likely agree conceptually on the components that make up business architecture. However, you will get three very different descriptions of how to develop and integrate those components.
There are many techniques available for developing business architecture; and a good Business Architect can adapt just about any set of methods to do so. There are also any numbers of tools on the market that support the available techniques from simple drawing tools, to robust modeling tools, to presentation tools. And you can even find several frameworks that accommodate business architecture. But I have yet to find an agreed upon standard.
That makes business architecture more of an art than a science. In this article I will describe this architect’s approach to bringing some science to the art of business architecture.
Where to begin: With or without the business strategy
To answer the question “Does the business architecture include the business strategy?” we must first agree upon the definition of business architecture. I recently saw a very eloquent definition of business architecture. Unfortunately it does not help answer this question. So for the purposes of this article, let’s agree that “Business architecture is the ‘operationalization’ of the business strategy.” I choose this definition for two reasons: 1) It is short, and 2) It fits my approach. You see, in the absence of standards I can make the definition fit my preferred approach or vice versa. (Perhaps I just made the case for how badly we need business architecture standards.)
So I begin developing a business architecture not by defining the business strategy but rather by understanding the business strategy with its requisite goals and objectives. This gives me a view of the target and the route that the enterprise is willing to take to achieve that target.
After Business Strategy: The Functional Architecture
After I gain a reasonable understanding of the business strategy, I always feel the need to know the core business functions of the enterprise. This is not to say that I’m advocating organizing the enterprise around functional silos. However, I expect that in most cases the enterprises are organization that way and the only way I’m going to break the silos down is to understand them.
I have successfully used different approaches to modeling the core business functions of an enterprise. I list two examples below.
- Bubble Charts – At one time I used a simple bubble chart that contained nothing more the bubbles representing the core business functions with simple associations diagramed between them; nothing more. At this high level, I don’t care who is involved, what systems are involved, or what information passes between them. I simply want to know core business functions and any precedence between them.
- Operations Maps – Later on I did some work in telecommunications where I was introduced to the Telecom Operations Map (TOM) produced by the TeleManagement Forum. The TOM is a layered model that classifies functionality. I adapted the TOM to other industries and it allows me to distinguish between customer-facing functions, internal service development and support, and what I loosely call the network management layer (whereas “network management” in telecommunication refers specifically to the physical telecommunications network, in an industry such as healthcare it might refer to the network of providers and regulatory agencies). I then model the precedence between the customer, service, and network layers and between their respective business functions.
Process Follows Function: The Process Architecture
Once I recognize where the silos exist within the Functional Architecture, I leverage the precedence relations between them to break the silos down. I do this by decomposing the business functions into subsequent levels of specificity. I’ll describe approaches in keeping with the previous examples.
- Bubble Charts – The Functional Architecture is the highest level of decomposition. Decomposing the business function “bubbles” into business events represents the second level of specificity. At the third level of decomposition I define the business processes that result in the completion of the business events replete with business rules, the people and organizations involved in the processes, and the flow of information between the processes. Finally, at the fourth level I concentrate on work flow and processing exceptions.
- Operations Maps – Having defined the various business functions, segregated them into their respective layers, and established any precedence between them, I turn to Use Cases. I create use cases for the set of business processes that exist within each business function. I build use case models that leverage the established precedence to represent end-to-end value streams (of sorts); the established precedence between processes support the pre- and post-conditions of the use cases; the people, organizations, and system involved with each process contribute to the Actor’s Glossary; and alternate courses are a good place to capture additional business rules and process exceptions. I also maintain a model that represents the information owned by and shared between the various processes.
Tools: The nuts and bolts
I have given you just two examples of approaches and techniques that I used to create business architecture in the absence of any standards. As for tools, there are so many on the market that I can not begin to enumerate them here. However, I can tell you the types of tools I used in the above examples.
- Bubble Charts – When I used bubble charts early on, I used a proprietary modeling tool that was based at the time on structured techniques. It did a fine job of capturing all four levels of specificity (i.e., business function, business event, business process, and procedure). It also captured people, organizations, systems, and information involved in each process. It was an integrated modeling tool that supported several architectural views of the enterprise.
- Operations Maps – When I changed my approach to incorporate operations maps, I initially developed the operations maps using either a drawing tool or a presentation tool. After I had a stable, static “picture” of the operations map, I translated it into a UML-based modeling tool. Each layer of the operations map became a “package” in the modeling tool. Business functions within each layer became sub-packages. I then created use case diagrams within each sub-package leveraging the visibility established between packages. As I developed each use case diagram, I maintained class diagrams of the information requirements. As with any UML-based modeling tool, the use case model is easily extended using activity diagrams and swim lanes.
Please notice that I make a distinction between drawing tools, modeling tools, and presentation tools. Drawing tools give you a nice picture but it’s really nothing more than a stake in the ground. Modeling tools give you robust models and enforce constraints that drawing tools do not. And whether you use a drawing tool or a modeling tool, neither of them makes for good presentations. If you must present you models, be sure to translate them into a good presentation tool.
