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 Concept: 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 Work Product: 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 Work Product: Business Architecture Document, depending on what value it adds to the content.

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 Work Product: Business Architecture Document, the section on architectural drivers and constraints.

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 Work Product: Business System(s) in the Business Analysis Model (if you have a very large and complex business model). 

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

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

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 Guideline: Business System.

For key interfaces to customers and (where appropriate) between business systems, the primary Work Product: Business Worker(s) and Work Product: Business Entity(s) 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.

Identify which Work Product: Business Worker(s) and Work Product: Business Entity(s) 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 Guideline: Business Architecture Document.

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 tasks.  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 tasks:

• 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.

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

• 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 tasks:

• 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 Guideline: Business Architecture Document, the section on human resource view. 

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