Guidelines:
Business Architecture Document
Topics
The References section 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
- non-government documents
- and so on
The business architecture is formed by considering what mechanisms are needed
to in the best possible way improve, or re-engineer, the key business processes.
These key business process are a subset of the business
use-case model. Another important input are the objectives of the business,
captured in the Business Vision.
However, these are not the only influences that shape the business
architecture—there 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.
The business process view includes the key business processes, and it is a
subset of the Artifact: Business Use-Case
Model. It describes the set of business scenarios and/or 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 point of the business
architecture.
For each significant business use case, include a subsection with the
following information:
- The name of the business use case.
- A brief description of the business use case, including its purpose.
- Significant descriptions of the workflow of the business
use case. This can be the whole workflow description, or subsections of it
that describe significant flows or scenarios of the business use case. The
workflow may be described textually, with or without activity
diagrams.
- Significant descriptions of relationships involving the business use case,
such as include-relationships and extend-relationships, or
communicates-associations.
- An enumeration of the significant use-case diagrams related to the
business use case.
- Significant descriptions of any special requirements of
the business use case. This can be the whole special requirements
description or subsections of it that describe significant requirements.
- The realizations of these business use cases should be found in the
organization structure view.
The organization structure view is a subset of the Artifact:
Business Object Model, including elements that are significant to the
business architecture. It describes the most important business workers and
business entities, their grouping into organization units, and the organization
of these into layers. It also includes the most important business use-case
realizations.
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 in the organization that disturbs it in an unexpected way.
Culture isn't 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 yourself.
- Answer for their actions and accept responsibility.
- Judge and be judged, to reward and be rewarded, on the basis of
performance.
It isn’t 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 don't, 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.
The human resource aspects view should cover 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
reengineering, preparing for change might be such a complex and costly task
that it is treated as a separate project.
More specifically, you need to consider the following aspects of
change:
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’ve 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:
- 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:
- A good knowledge of the process or processes in which you will be.
- A good knowledge of the responsibilities defined for the business workers
you will act as and an ability to perform the activities of the business
worker.
- An understanding of your colleagues’ responsibilities and activities.
- Knowledge of how to use the business tools.
Achieving the right skills within the organization may be a combination of
training existing employees and hiring new people.
Define a reward system that encourages employees to work in the direction of
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 is, however,
essential for the acceptance of changes among the employees.
As a prerequisite for success, the staff must have the right equipment and
that equipment must be optimally located in relation to their tasks.
In a service industry, this 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 process 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 processes, and
consider:
- Which business workers participate in several processes?
- 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?
- Estimate the cost per business process 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 describes volumetric and responsiveness characteristics of the
business. The information presented may include:
- The number of key elements the system will have to handle.
- The key performance measures of the system, such as average response time
for key events; average, maximum, and minimum throughput rates, and so on.
Most of these qualities are captured as performance goals of the business use
cases. They are presented here because they shape the business architecture in
significant ways and warrant special focus.
In this section, list the 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.
For each dimension, discuss how the business architecture can support it. You
can organize the section by the different views or by qualities.
Copyright
© 1987 - 2001 Rational Software Corporation
| |
|
Artifacts >
Business Modeling Artifact Set >
Business Architecture Document >
Guidelines
