|
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 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 Work Product: 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 initially a subset of the Work Product: Business Analysis Model, including elements that are
significant to the business architecture. As the Business Analysis Model is refined into the Work Product: 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 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 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.
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 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.
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 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.
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
Work Product: Business Analysis Model and Work Product: Business Deployment Model), and the rationale for the later
realization choices in terms of people, software and hardware (presented in the Work
Product: Business Design Model) - if these are thought to be architecturally significant.
|
