Activity: Define the Business Architecture

This activity adds value only if you are doing business modeling in order to engineer your business. If you are merely building a chart of an existing organization in order to derive system requirements, architecting the business is not necessary. See also Concepts: Scope of Business Modeling. 

Develop an Overview of the Business Architecture

The business architecture overview is created early in the lifecycle of a project, possibly as early as the development of the proposal. It is often depicted in graphical form, using some informal notation or storyboarding technique. It represents the intent and idea behind a business modeling effort. The lead business-process analyst produces the business architecture overview, often in collaboration with the project sponsor.

The overview graph must indicate major elements of the business and its environment, such as teams, business tools, and external sources of influence (for example, regulatory bodies, partners, and market segments). The overview graph most often does not focus on the entire business architecture as described here. However, a large effort, such as a business process re-engineering (BPR) project, would consider the entire business architecture. The notion of business architecture is described in Concepts: Business Architecture.

It is useful to consider the purpose of business architecture and its intended audience. This ensures that the manner in which the business architecture is described and presented will be appropriate for those who must understand it. The intended audience can be categorized into different groups with various concerns. Each of these groups will be interested in different architectural views of the Artifact: Business Architecture Document.

At this point, the business architecture overview is a provisional first pass. No commitments should be based on this overview diagram. The initial overview graph may or may not be included as part of the Artifact: Business Architecture Document, depending on what value it adds to the content.

Describe the Forces Affecting the Business Architecture

Identify the constraints and trends within the business and its environment that could have a significant effect on the structure of the business or the way in which it works. When defining the business architecture, these forces must be analyzed to ensure that the business can adapt to possible changes within a reasonable time and withstand other kinds of impact.  Forces that are worth considering include the business strategy and trends, as well as possible future events that would affect every part of the organization or radically change some significant central part of it. In addition, it is important to consider changes that might have to be made very rapidly, along with constraints that might be imposed or lifted in future that may alter the way business is done or open new opportunities.

Consider the probability of these events or changes occurring, and try to visualize their effects on the business. Once you understand the probabilities and effects, you can prioritize these forces and make decisions regarding how to deal with the highest-priority issues. The options available for dealing with each change are:

• Prepare for rapid response to the change.
• Act is if the change has already occurred.
• Minimize the possible effects of the change.
• Ignore the possibility of the change occurring.

Document your results in the Artifact: Business Architecture Document, the section on architectural drivers and constraints.

Prioritize Business Use Cases

Determine which business processes are most critical to explore in order to achieve the goals presented in the Artifact: Business Vision Document. Consider the highest-priority and highest-risk business goals, and then look for the business processes that support them. Be sure to look for business use cases or business scenarios from the outlined Business Use-Case Model (in Activity: Find Business Actors and Use Cases) that represent some significant, central capability of the of the target organization or have large architectural coverage. Also consider use cases that employ many architectural elements or illustrate a specific, delicate point of the business architecture.

The selection of business processes (or scenarios, which are parts of business processes) must reflect both coverage and criticality.  Coverage is necessary to ensure that enough of the business systems are being considered. Business architecture concerns breadth, and coverage ensures a sufficient amount of it.  A few core business processes usually touch the breadth of the organization. Criticality, on the other hand, characterizes the business processes with the highest priority. Priority is derived from important or risky business goals, difficult or complex business processes, and new or vague business processes. Be especially attentive to vague business processes-they might be vague for a reason. Investigating a vague business process often clears up much uncertainty about the way different parts of the organization work together.

Also consider the business goals supported by the business use cases. Business goals that can be relatively easily achieved or offer high returns (that is, most strongly support the business strategy) are a good place to start. The business use cases supporting these business goals may have high priority.

The prioritized business processes or business scenarios should be documented in the business use-case view of the Business Architecture Document. See also Guidelines: Business Architecture Document, the section on business process view.

Outline the High-Level Organization

Identify the high-level groupings that will constitute the organization. These can be departments, divisions, or business units, depending on what terminology your organization uses. These high-level groupings can be used as input when identifying your initial set of business systems in the Business Analysis Model (if you have a very large and complex business model). 

For key interfaces to customers and (where appropriate) between business systems, the primary business workers and business entities must be identified. It may also help to define the purpose of each business system and its capabilities. Clear definitions of purpose and capabilities provide a better understanding of the role that the business system must play in business use-case realizations. Such definitions also help reveal the manner in which the business system must interact with other ones.

Consider the scope of the project as defined in the Artifact: Business Vision. There is no point in exploring details of parts of the organization that are out of scope. See also Concepts: Modeling Large Organizations. 

Sketches to a high-level organization should be included in the organization structure view of the Business Architecture Document. See also Guidelines: Business Architecture Document, the section on organization structure view.

Identify Business Systems

Identify and briefly describe business systems within the business being modeled. Business systems are really only useful for large, complex business models. Depending on the business-modeling scenario and the scope of your efforts, you might decide against using business systems at all.

A business system represents a relatively independent capability within the organization. It defines a set of responsibilities as well as the business workers, business entities, and business events that undertake these responsibilities. In this way, a business system is a structural part of the organization, like a department, except that the only interactions allowed within a business system are through the predefined responsibilities. Consider, for example, a serving window in a restaurant or an IT support department with a services catalog. In both these examples, there are predefined interactions. What, for example, would happen if you went around to the back of the restaurant to try to get a meal from somebody in the kitchen? Similarly, what would happen if you asked the computer support technician to book you an airline flight? We use business systems to disallow any interactions with the business workers and business entities within it, other than the specified interactions. This allows us to partition large, complex business models so that we can focus on detailing one part of the model without losing sight of where it fits into the whole.

Discuss and obtain agreement regarding which (if any) business systems should be included in your model. Some business systems may be described in only limited detail in the context of the business use-case realizations. Others may provide important input or receive output, in which cases they should be modeled as business actors. This means they are external to the business being modeled.

You may want to indicate how a business system participates in a business use case without showing the internal interactions between business workers and business entities within that business system. Where necessary, you can "zoom into" the business system to show internal collaborations as part of the business use case.

For more information on business systems, see Guidelines: Business System.

Outline Prioritized Business Use Case Realizations

Identify which business workers and business entities participate in the execution of each prioritized business use case. They form the business use-case realization of the business use case. For large, complex business models, business use case realizations can be expressed in terms of interactions between business systems.

The sketches to process realizations must be included in the organization view of the Business Architecture Document. See also the section on organization structure in the Guidelines: Business Architecture Document.

Define Geographic View

This view describes the geographic locations in which the business is deployed, along with the distribution of organizational structure and function across these locations. The locality view is useful for assessing the impact of time and distance on the business processes. Processes may be streamlined, or the organization itself may be restructured to eliminate the overhead of coordinating distributed activities.  Furthermore, unique characteristics of each location (such as legislation, resources, accessibility, or image) may affect the decision to deploy certain business activities there. Ships may also be regarded as locations. The process of defining the Geographic View consists of the following activities:

• Identify the major locations (countries or cities) in which business activities are performed.
• Identify the dependencies and paths of communication between these locations.
• Map the business systems (from the Organization View) to these locations.
• Assess the positive and negative qualities of each location regarding the business activities performed there.
• Assess the overall effects of distribution on the business use cases.
• Explore the effects of streamlining business use cases or restructuring the organization to eliminate overhead.

Define Human Resource and Cultural View

The process of defining the human resource aspects of the business includes the following activities:

• Consider the competence profiles that exist within the organization. Define competence profiles that will be required in the future, or define the necessary changes to the existing profiles. Will the future business require employees to be more or less independent? Will they need higher or lower education requirements?
• Discuss education needs. Define both long-term training programs to overcome the differences between current and desired competence profiles, as well as any initial training needs associated with the introduction of new business processes. 
• Define any mechanisms (reward structures, trainee programs, mentor programs, or other incentives) that exist or need to be put in place to enhance skill levels. Discuss the advantages and disadvantages of each.
• Explore the possibility of relocating individuals in the organization due to changes in responsibilities or the need to enhance communication.

The process of describing cultural aspects of the business includes the following activities:

• Determine the characteristics of the culture. 
• Determine which of these characteristics are key to the organization and must be left undisturbed. 
• Discuss which characteristics must change.
• Determine what mechanisms are in place to maintain and encourage the culture. Discuss ideas for new or changed mechanisms.
• Define a path to be taken to introduce any changes that you deem necessary. 

The results of this step should be documented in the Human Resource View of the Business Architecture Document. See also Guidelines: Business Architecture Document, the section on human resource view. 

Evaluate Your Results

Check the Business Architecture Document verify that your work is on track. See Checkpoints: Business Architecture Document.

This content developed or partially developed by Empulsys BV.

Rational Unified Process