Introduction

We define business architecture as an organized set of elements with clear relationships to one another, which together form a whole defined by its functionality. The elements represent the organizational and behavioral structure of a business system and show abstractions of the key processes and structures of the business [NDL97], [ERI00].

Context of Business Architecture

Different people have different backgrounds and perspectives. When attempting to achieve a common understanding on something as complex as the organization-including its processes, structure, and strategy-we need a way to describe architecture and architecturally significant issues in a way that will be understood by each impacted group. This is done by describing three different-yet-related architectures as shown and described later in this document.

Business architecture is a description of the significant aspects of the organization. Application architecture is a description of the software applications that support the business, including how those applications are used and how they interact with each other. Technical architecture is a description of the hardware infrastructure that supports the software applications.

The business architecture must govern the application architecture, which in turn must govern the technical architecture. This does not imply a hierarchical relationship wherein the business architecture prescribes to the application architecture, and the application architecture prescribes to technical architecture. Rather, it means that goals and constraints (called drivers) are communicated in one direction, and any architectural decisions (called tradeoffs) that affect the governing architecture must be made at the level of the governing architecture. An architectural goal implies a desired condition, while an architectural constraint implies mandatory compliance. However, even constraints can be intentionally ignored. For example, a constraint that requires the business to comply with certain legislation might be ignored because the cost of making the changes necessary to comply far exceed the penalties incurred by noncompliance.

Architecting is about balancing forces and making tradeoffs to create a solution that optimally satisfies conflicting requirements. This means that the business architecture defines goals and constraints that describe the support that it requires from application architecture. The same applies to the application and the technical architecture. Where conflicts arise, as they always do, localized sub-optimal solutions must be found in order to ensure an optimum overall solution. When these decisions have a broad impact, they are termed architectural issues and must be formally agreed to by stakeholders represented by an architecture board.

These different architectures must always be considered when communicating with stakeholders. Discussing only one of them with an individual who does not understand its form, application, or notation results in ineffective communication. Furthermore, it can cause that individual to misunderstand the consequences of his or her decisions regarding the other architectures. The impact of decisions in one of the architectures must be translated to the other ones. This helps stakeholders understand the benefits and disadvantages of tradeoffs, which leads to architectural alignment. Architectural alignment helps us understand the consequences of decisions.

Business Architecture as a Framework for Change

The business architecture is what we use to communicate with different stakeholders about the business to ensure a common, consistent understanding. We can describe the business architecture as the framework within which we make changes to the organization to enable the business to ultimately realize the business idea, as shown in the figure.

Business Architectural Views

Because business architecture is complex and difficult to measure, we divide it into a number of different views. Much as the software architecture is defined in Concept: Software Architecture, the architectural views of the business will be defined here.

Each view describes one aspect of the entire business. It therefore contains an architecturally significant subset of what would be a complete definition. In other words, an architectural view contains the 20% that really matters to that aspect of the business [ROY98].

The architectural views are helpful in discussing the business architecture with different stakeholders. Because each stakeholder has one or several views that are of particular interest, he or she can focus on those aspects of the organization that are associated with those views without having to understand everything else as well.

Note that not all views apply to all situations. Some views can be ignored when they add no value, and sometimes it might be necessary to define new views. Here are some typical business architectural views:

• Market View describes the markets in which the business operates, customer profiles and offerings, or the products and services that the business offers to customers in the target markets.
• Business Process View describes the significant goals of the business and outlines the key business use cases that support these goals. When business use cases are used to document business processes, this view is called the Business Use Case View.
• Organization View describes the groupings of roles and responsibilities within the business and the realization of business use cases.
• Human Resource View describes remuneration profiles and incentive mechanisms, key cultural characteristics and mechanisms, competence profiles, and education and training mechanisms.
• Domain View describes the major business concepts and information structures used by the business.
• Geographic View describes the distribution of organizational structure, function and resources across physical locations such as cities and countries.
• Communication View describes the communication pathways within the business.

Mapping of the Business Architectural Views to RUP Viewpoints 

RUP Viewpoints are described in  Concept: System Architecture. These viewpoints are applicable to system development generally. When the 'system' under consideration is a business, the Business Architectural Views form a more pertinent specialization of the generic viewpoints. The following table shows how they are related. Note that the Business Architectural Views, by the definitions offered in  Concept: System Architecture, in some cases cover multiple views (where a view is the intersection of viewpoint and abstraction level).