References

The References section of the Business Architecture Document presents external documents that provide background information important to understanding the business architecture. If there are a large number of references, structure the section in subsections, for example:

• external documents
• internal documents
• government documents
• nongovernment documents

Architectural Drivers

The business architecture is formed by considering what is needed to improve, or re-engineer, the key business processes. These processes are represented by business use cases, that form a subset of the  Business Use Case Model. Another important input is the business goals, also captured in the  Business Use Case Model. It is not necessary to describe all the business goals here-only the architecturally significant ones. The following are examples of characteristics that may determine whether or not a business goal is architecturally significant:

• It is critical for the long-term success of the enterprise.
• It contributes heavily to the business strategy.
• It cannot be realized with current process, resources, and infrastructure.
• Changing it would have sweeping effects on the business.
• It is influenced by external parties over which the business has no direct control.

However, these are not the only influences that shape the business architecture. There also will be constraints imposed by the environment in which the business must operate, by the need to reuse existing assets, by the imposition of various standards, and so on. These macro-level forces (drivers) are said to shape the business architecture because they have significant influence on what the business does and the way in which it operates.

Architectural drivers is the collective name for architectural goals and constraints. An architectural goal describes a desire or intent of the business architecture, while an architectural constraint imposes a restriction. Clearly defining architectural goals enables the business to take advantage of the forces affecting the business; clearly defining architectural constraints reduces risk by restricting alternatives. Consider, for example, the strategic focus (operational excellence, customer intimacy, or product innovation), the availability of human or other resources, current and expected economic conditions, technology trends, changing customer behavior, competitor movements, the state of the markets in which the business operates, globalization, economic migration, and legislation and regulation.

Also consider key quality dimensions of the business that shape the business architecture. The information presented may include:

• operating performance requirements 
• quality targets, such as "all shipments delivered on-time"
• extensibility targets, such as ability to meet growing customer demands
• portability targets, such as supported countries, languages, and product lines

The Business Process View

The Business Process View, which includes the key business processes, is a subset of the  Artifact: Business Use Case Model. It describes the set of business scenarios and business use cases that:

• represent some significant, central capability of the business 
• have a substantial coverage, meaning that that they exercise many key elements of the organization 
• stress or illustrate a specific, delicate, complex, or risky point of the business architecture

The United States General Accounting Office [GAO97] lists some criteria for prioritizing business process:

• processes with the strongest link to business strategy
• process that have the highest impact on customers
• processes with the biggest potential return on improvement
• processes for which there is strong consensus on the need for change
• processes that can be redesigned with the currently available resources and infrastructure
• less-complex processes that can be improved quickly (quick wins)
• less-complex processes that can be used to gain experience in re-engineering

For each significant business use case, include a subsection containing the following information:

• the name of the Business use case
• a brief description of the business use case, including its purpose
• a description of why the Business use case is considered architecturally significant

The Organization View

The Organization View is initially a subset of the Artifact: Business Analysis Model, including elements that are significant to the business architecture. As the Business Analysis Model is refined into the Artifact: Business Design Model, the Organization View shifts with it, to show how abstract roles in the business are bound to people, software and hardware. This enables quantitative reasoning about business operational performance and costs.

The Organization View describes the most important business workers, business entities and business events, their grouping into business systems, and the organization of these into layers. It also includes the most important business use-case realizations and descriptions of general patterns of behavior.

The scope of this view can be the business itself (the internal organization) or the business and its relationship to its partners (the extended organization).  This last viewpoint is particularly interesting if you want to consider the entire value chain involved in delivering products and services to customers.

The Human Resource View  

The Human Resource view covers all aspects of preparing an organization for change. The results include:

• a recommended infrastructure
• mechanisms for motivating employees to work in the changed organization
• mechanisms for encouraging the necessary skills in the changed organization

In order to quickly arrive at a well-functioning organization, this work can be started long before the final business design has been found. Early in a project, in the initial iterations before the objectives for the effort are stable, the work focuses on generally preparing the staff for change. Later in the project, the work instead focuses on educating the employees in their new tasks and investigating the needs for infrastructure changes; for example, where people are located and what equipment they need. If the business-modeling effort results in massive changes, such as in business re-engineering, preparing for change might be such a complex and costly task that it is treated as a separate project.

Kotter's change model [KOT96], which has been successfully used by a number of organizations, defines the following steps for leading an organization through change:

• Establish a sense of urgency.
• Create a guiding coalition.
• Develop a vision and strategy.
• Communicate the vision.
• Empower broad-based action.
• Generate quick wins.
• Consolidate gains and produce more change.
• Institutionalize new approaches.

More specifically, you need to consider the following aspects of change: 

• understanding organizational culture
• managing concerns and attitudes
• changing and improving skills
• defining incentives

Understanding Organizational Culture

To succeed with a change and make it permanent, you must also understand, and possibly change, the culture of the target organization. If you fail to understand the culture of the target organization, any business engineering effort will fail. 

Even if your business-modeling effort is not aimed at any radical change, the culture is important to understand-enough so that you can avoid introducing elements to the organization that disturb it in an unexpected way. 

Culture is not something you can touch or describe with a simple formula. 

Champy [CHM95] characterizes the culture of a healthy business as a culture of "willingness." Specifically, Champy suggests that employees in a new business must be willing to do the following:

• always perform to the highest measure of competence
• take initiatives and risks
• adapt to change
• make decisions
• work cooperatively as a team
• be open, especially with information, knowledge, and news of forthcoming or actual "problems"
• trust and be trustworthy.
• respect others, including customers, suppliers, colleagues, and themselves
• answer for their actions and accept responsibility
• judge and be judged, to reward and be rewarded, on the basis of performance

It is not easy to change a business' culture, or any culture for that matter. This alone is the subject of entire books. Again, Champy [CHM95] provides the inspiration for a brief description of the recommended procedure:

• Determine the shared values of the people in the existing business.
• Identify and weed out bad behavior.
• Articulate what values and behaviors you want.
• Determine if your management use cases support your aspirations for certain values and behaviors. If they do not, it is impossible to change the culture.
• Install new values by teaching, doing, and living according to them.

The path to a changed culture is full of traps. Repeated here are four of the "don'ts" that Champy [CHM95] warns against:

• Don't tolerate people who refuse to change their behavior, especially if their work is important to achieving your engineering goals. When you tolerate old behaviors, it signals that you are not serious about change. This applies to everyone-managers and team members alike.
• Don't expect people to change how they behave unless you arrange their work to allow them to act differently.
• Don't expect immediate cultural change. A complete cultural change takes a few years, not a few months.
• Don't delay engineering the management use cases to support the new set of values.

Managing Concerns and Attitudes 

Areas to consider are: 

• Business idea and strategies-are they explained well and understood by everyone? 
• Functionally oriented versus process-oriented organization-are you changing to a process oriented organization, and, in that case, are the benefits explained and understood?
• The coming change-change is less threatening if you explain what it entails, and also what is motivating it. The change should be motivated not just from the perspective of the members of the business, but also from the perspective the customers. 
• Business culture-does the culture support the proposed changes? 

Changing and Improving Skills

There are needs for education at several levels and we have chosen to show three categories. For general skills and for some domain-specific skills, you may find externally available programs. For skills that are more specific to your organization, you need to develop and plan for presentations, workshops, and, in some cases, more extensive training programs. 

General skills: 

• A process-oriented organization is focused on the customer. You may need to build an awareness of the difference between delivering value to the customer and just following procedures. 
• Responsibilities are distributed to the individuals working in the processes, which might require that you make sure everyone clearly understands enough of the business rules to make the right decisions. 

Domain-specific skills: 

• Do you have a general understanding of the business, including products and services?
• What business actors (customers, partners, vendors) are involved?
• What results are produced and what services are delivered?
• How is this related to your work responsibilities within the processes?

Business-process specific skills: 

• You need a good knowledge of the process or processes of the business.
• You need a good knowledge of the responsibilities defined for the business workers that you will act as, along with an ability to perform the tasks of the business worker.
• You need an understanding of your colleagues' responsibilities and tasks.
• You need a knowledge of how to use the business tools.

Achieving the right skills within the organization may be the result of a combination of training existing employees and hiring new people. 

Defining Incentives 

Define a reward system that encourages employees to work in the direction of the business idea and business strategy to satisfy the needs of the served actors. With the goals of the individual business processes, which as a starting point should be based on business ideas and strategies, define rewards related to:

• overall performance of the business
• overall performance of the business process
• results of the individual execution (instance) of a business process
• contributions of each individual 

Investigate existing incentives for all kinds of employees in the target organization. Rewards in a functionally oriented organization are often related to the individual functional organization unit, which fails to capture that it is the overall result of the business and its business processes that are the essential aspects. Such incentives need to be replaced as soon as possible.

A smooth transfer from the old to the new reward system, however, is essential for the acceptance of changes among the employees.

As a prerequisite for success, the staff members must have the right equipment, and that equipment must be optimally located in relation to their tasks. 

The Geographic View

In a service industry, optimal location is often relatively easy to arrange, whereas in a manufacturing company, the changes in a business process might become both expensive and extensive. The budget and the available time frame often limit what is possible to achieve on a single project.

The importance of the location varies between different kinds of processes. A tele-sales process, a field sales process, and a manufacturing process significantly differ in this respect. The possibility for a business-engineering effort to affect where and how the organization will be located in the future also differs significantly between projects.

The following procedure helps determine a realistic approach:

• Look at each business use case to see how the involved business workers should be physically located in order to optimally perform the tasks.
• Look at the use-case realizations, one by one, to identify the needs of equipment and premises for each business worker.
• Look at the whole business, or a group of related business use cases, and consider:
  • Which business workers participate in several business use cases?
  • Which processes make use of each other's results?
• With this as a basis, identify the optimal location of each business worker.
• Compare this with the current situation and ask yourself:
  • What is a realistic change within the mandate of the project?
  • What is the most cost-effective location?
  • What is mandatory? What can the organization live without?
  • What can be compensated for by having the right equipment?
  • What can be compensated for by having the right location?
• Consider the effect of relocating an entire business system on the business use cases.
• Estimate the cost per business use case to change the location according to what you have discovered. Determine whether the investment is realistic.

For example, a mobile data solution must be considered for a sales person who needs direct access to company databases while at the customer's offices. Having video-conferencing equipment installed sometimes compensates for the disadvantage of having the members of a development team located at different sites.

Architectural Tradeoffs

This section of the Business Architecture Document describes the how the business architecture realizes the architectural goals and constraints (architectural drivers) described near the beginning of this document. It is a discussion for preserving the rationale underlying architectural decisions. Most, or at least many, architectural drivers are conflicting, and the business architecture must therefore provide an optimal solution that satisfies the greatest number of conflicting drivers to the greatest possible extent. This implies that tradeoffs and decisions will have to be made. It is these decisions and tradeoffs that are described here.

As an example, one architectural goal may be the ability to rapidly deploy new products, while another architectural goal may be the ability to deliver products via partners with complementary offerings. These two goals are conflicting, because delivering product via external partners implies a longer time-to-market. In such a case, this section would describe the tradeoffs made within the business architecture to achieve the maximum of both these goals.  In this example, a partner product management team might be created, and certain restrictions might be applied to the selection of candidate partners.

Many conflicts and tradeoffs will surface only after the application architecture or technical architecture is considered (see Concept: Business Architecture). It is essential that the consequences of these decisions be clearly understood.

This section presents both the rationale for the overall architectural shape of the business (as captured initially in Artifact: Business Analysis Model and Artifact: Business Deployment Model), and the rationale for the later realization choices in terms of people, software and hardware (presented in the Artifact: Business Design Model) - if these are thought to be architecturally significant.