Artifacts > Business Modeling Artifact Set > Business Architecture Document > Guidelines

SWEN 5135 Configuration Management

Topics

References

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

Architectural Goals and Constraints To top of page

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 To top of page

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 To top of page

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.

Culture View To top of page

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.

Human Resources Aspects View To top of page 

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: 

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’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. 

Defining Incentives 

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.

Location

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.

Size and Performance To top of page

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. 

Quality To top of page

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


Display Rational Unified Process using frames

Rational Unified Process