To understand the relationship between Business Architecture and SOA, we first need to ask the question what are these two types of architecture? For a description of SOA, see my July SOAInstitute article “Key Components of SOA” at http://www.soainstitute.org/articles/article/article/key-components-of-soa.html. So the next question is “What is Business Architecture”? While there are many available definitions, here are a few that I found useful.
A rather wordy, but descriptive definition comes from the USDA. “The business architecture represents the functions and processes that support the business, the organizations that perform the business, the locations where the business is performed, and the factors that could cause the business to change. In other words, the business architecture addresses how the mission-critical functions of the organization are accomplished. It is a portrayal of how the organization actually accomplishes its mission rather than how it is organizationally structured to manage its mission. The business architecture also encompasses a strategic direction that an organization strives to attain. Major influences on the business architecture are laws and regulations, external and internal policies, organizational structures, organizational culture, business change, people, budgets, and technology drivers. This layer ignores any physical constraints and contains no element of system design”
The Open Group describes the Business Architecture View as: “Addressing the concerns of the users including consideration of the following:
- People – the human resource aspects of the system. It examines the human actors involved in the system.
- Process – deals with the user processes involved in the system.
- Function – deals with the functions required to support the processes.
- Business Information – deals with the information required to flow in support of the processes.
- Usability – considers the usability aspects of the system and its environment.
- Performance – considers the performance aspects of the system and its environment”
The business architecture view is derived from Business Scenarios, where each scenario is defined by describing the problem, environment, objective, human actors, system actors, and roles and responsibilities.
Finally, for a more succinct definition we can turn to the recent article “Business Architecture: Aligning Strategy and Deployment” https://www.bpminstitute.org/articles/article/article/business-architecture-moving.html by William Ulrich, co-chair of the Brainstrom Group Business Architecture Conference which described Business Architecture as “Conceptual views & physical instantiations of business strategy, governance structures and processes – across the extended value chain”.
What all of these definitions have in common are the concepts of strategy, organization, and business processes. In other words, the business architecture translates the business strategy into actionable processes, what Brainstorm Group Business Architecture co-chair Ken Orr called “the missing link” in the architectural puzzle. When we look into some details of this, we see that it involves people and systems (the actors and their organizations), information and information flow, and business processes and activities.
Not surprisingly, we see these same elements if we examine some of the standard ways of representing business architecture. For example, a Business Context diagram illustrates users, organizations, boundaries and information flows between them. A value chain diagram shows organizations and the chain of processes and information that provide business value. A business process diagram shows the sequence of processes executed by different organizational units, and the information flow between them.
So how does this relate to SOA? In my article, I identify the ‘business model’ and the ‘common information model’ as key components of SOA. These two components are critical to moving an enterprise from simply building services (which at best may incidentally work together), to having an architectural approach that systematically leads to an organized collection of related, non-overlapping and composable services.
The SOA business and information models are directly related to the business architecture. They intersect at the business process, as defined in the business architecture, and translated into service concepts in the service model where they are extended to the next level of detail. The information flow of the business processes becomes the basis of the shared information model for the services and the document definitions at the service model. These relationships are illustrated in the figure below.
The business process is made up of actors, activities and flows, where flows can be adorned with details about the specific information that is passed. Each activity in the business process is represented by a business service in the service model. Business services will be composed of other, (smaller) domain and utility services. Each information flow in the process is represented by a document in the information model. Documents are composed of classes from the shared information model.
We have described the relationship for a single process, but of course the business architecture and the service model are concerned with the totality of processes, services and information. They are concerned with the present, the near term and the long term. Thus, the business model must identify all of the processes and information that exist today, those that are currently planned or being implemented, and the processes and information that are needed over time to realize the business strategy and goals.
Likewise, the SOA Business Model must describe today’s services, documents and information, those currently being implemented, and future services and information, those which will provide the business capabilities required of the future business processes. In other words, the SOA service model is directly influenced by the business strategy and must identify services to provide all the capabilities required of that strategy. And, the SOA information model is directly influenced by the business information and must identify all of the information required for the future processes.
The SOA Business Model has some other important goals. It has to manage the sharing of services and information across processes. In other words, it needs to eliminate redundancy, overlap, and gaps between services so that each business capability is implemented once, by the organizational unit that is responsible for that capability. And that those services are used by all the different processes needing those capabilities. In addition, all of the information shared between services must be identified in the common information model. In other words, all services that are related to the same business concepts must use the same information to describe those concepts. Finally, the SOA Business Model must ensure that all of the information passed into and out of the business services (mostly in the form of documents) is defined in the common information model.
We looked at several different definitions of business architecture and identified some common components of strategy, processes and information. Then, we looked at how these aspects of the business architecture are related to SOA, and specifically to the SOA business model. At the business architecture level, we need to ensure that our business architecture is internally consistent. That strategy, goals, organization, etc. are realized as processes and information. Then, we need to make sure that the business architecture is consistent externally with the SOA Business Model, that it drives the long term vision, and that we have complete and consistent traceability from strategy to process to implementation as a business service.
