Guidelines: Business Architecture Document
Topics
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
The business architecture is formed by considering what is needed to optimally
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, 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 is a subset of the Artifact:
Business Analysis Model, including elements that are significant to the
business architecture. It 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 Aspects 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:
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:
- 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.
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?
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 activities
of the business worker.
- You need an understanding of your colleagues' responsibilities and activities.
- 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.
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.
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
telesales 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.
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 of the 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 content developed or partially developed by Empulsys BV.
|
| |
|