The Business Architecture is an integrated component of any Enterprise Architecture (EA) framework. For example, The Open Group Architecture Framework (TOGAF) has defined a Business Architecture component1. As an architecture representing some key elements of the enterprise, it has to fit into the overall design of that enterprise. The Business Architecture is not a stand alone nor isolated component, but a fully integrated one in the context of EA. Viewing the Business Architecture as some autonomous, monolithic structure of the enterprise, reveals motivations contrary to systems thinking. If you consider the IT Architectures1; Data, Application and Technology, then how does the Business Architecture integrate with them?
During the past several years, many companies have undertaken numerous Business Process Modeling (BPM) initiatives. One way to begin Business Architecture development is to start integrating the core cross-functional processes from these previous BPM initiatives. This is relatively easy to do, providing the BPM approach called for the precise graphical modeling of the inputs and outputs of the various processes. Many of these inputs and outputs are technology related items; for example, they are repositories of data, messages between internal or external systems, or extractions of data for reporting. It is obvious that these inputs and outputs are commonly shared between the Business Architecture and the IT Architectures. So, how do you integrate them between the two different domains of Business and IT?
The first suggestion is to have the BPM tool graphically portray and differentiate between inputs and outputs that are technology related and physical in nature. For example, a web order is a technology related item and a laptop computer is physical in nature. Their renderings in a model as square or round shapes are not as important as the ability to differentiate between the two in the process and architecture models. This distinction in appearance aids pattern recognition when searching for technology related inputs and outputs or when scrutinizing the models for improvements. Considering this point of view, anytime you look at a process model and find a shape representing a technology related item, then you know that you must also find that same item in the IT domain. Then, how do you characterize a technology related item in the business model?
Figure 1 provides an example of how to represent a technology related item in a BPM or Business Architecture model. In this example, the technology related item is the Order repository for a manufacturing company which contains all of the Orders from its customers. This means that the Order initially defined in the business domain must also exist in the IT domain. In the center of this figure, the technology related item appears as a slanted rectangle with a clear shadowed border. The clear shadowed border represents an aggregation of orders. The choice of a slanted rectangle versus another shape is certainly optional, but a standard is required for the enterprise!
Figure 1.
Continuing with a review of Figure 1, the aggregated Order has three types; Product, Replacement Part and Service. And you would expect to find in the process models, some identical processing for each Order type and also some unique processing for each Order type. Meticulous design of Order processing in the BPM initiative most likely resulted in high reuse of standardized processing steps. If the BPM initiatives are properly integrated in a Business Architecture, then you have a model illustrating all of the processes that access the Order repository.
Figure 2 represents an Entity Relationship Diagrams (ERD) of the Order repository built in the Data Architecture, using information defined in the BPM and BA models. You can easily see the relationships between the information provided regarding the Order in the business domain and the resulting analysis and design of the Order in the IT domain. The two figures represent a formal and precise integration between the domains of business and IT, not the juxtaposition or casual association of two interesting elements in different domains. Architectures represent relationships, connectivity and integration; a rigorous and formal discipline.
Figure 2.
Continuing the review of Figure 1, the right side elements, Order Number, Customer Number and Item Number, represent additional information contained in the Order. Many like to include the key to the repository once it is defined. The left slide elements, Entered, Released, Scheduled, Work in Process, Built, Shipped, Invoiced and Paid in full, represent the various states of the Order during its life cycle. The information in Figure 1 is captured in the business domain during business analysis and used by software developers when building, for example, the UML state transition diagrams. Here again, another architectural relationship between the BPM and BA models, and the IT. It is not necessary to duplicate all of the information regarding the Order in both domains, but capture just enough in the business domain to insure clarity and a direct association with the Order in the IT domain. This approach creates a nexus between the domains of business and IT; an enabling capability afforded by applying architectural disciplines defined in most every EA framework.
This is one relatively simple example of how to integrate the Business Architecture with the IT Architecture in the context of an Enterprise Architecture. As you can see, it all comes together; by design; with forethought and planning; most likely just like the architects of the various EA frameworks envisioned.
1. Andrew Josey, The Open Group, “TOGAFTM Version 9 Enterprise Edition – An Introduction” January 2009.
