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 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 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.
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 Artifact: 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 Artifact: 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
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 Guideline: Business System.
Identify Key Abstractions - Business Workers and Entities
For key interfaces to customers and (where appropriate) between business systems, the primary Artifact: Business Worker(s) and Artifact: 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.
Outline Prioritized Business Use-Case Realizations
Define Distribution (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 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.
Define Human Resources (Worker) and Cultural Views
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
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
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.
Evaluate your Results