Guidelines: Going from Business Models to

Systems
Topics

• Introduction
• Business Models and System Architecture
• Business Models and Actors to the System
• Automated Business Workers
• Business Models and Entity Classes in the Analysis Model
• Interaction between Business Workers Translated to System Requirements
• Using the Business Object Model for Resource Planning
• Summary Table

Introduction
The approach to business modeling presented in the Rational Unified Process includes a
concise and straightforward way to generate requirements for supporting business tools or
systems. A good understanding of business processes is important for building the right
systems. Even more value is added if you use people's roles and responsibilities, as well as
definitions of what "things" are handled by the business as a basis for building the system.
It’s from this more internal view of the business, captured in a business object model, that
you can see the tightest link to what the models of the system needs to look like.

The relation between models of the business and models of a supporting

information system

Business Models and System Architecture

From an architectural perspective, having business models in place is particularly useful if
your intent is to build one of the following kinds of systems:

• Customized systems for one or more companies in a particular type of industry,

such as banks and insurance companies.
• A family of applications for the open market, such as order handling systems,
billing systems, and air-traffic control systems.

The business models give input to the use-case view and the logical view as presented in
the analysis model. You can also find key mechanisms at the analysis level, which are
referred to as analysis mechanisms.

The following should be considered:

• For each business use case that will be supported by the system, identify a
subsystem in the analysis model. This subsystem is in the application layer and is
considered a first prototype iteration. For example, if you have an Order process and a
Billing process in your business use-case model, identify an Order subsystem and a
Billing subsystem in the application layer of your analysis model. You may argue that
Order and Billing are separate systems. Well, that’s a matter of scope. If you’re
considering all of your business tools as one system with several applications that share
architecture, Order and Billing would be application subsystems. If your scope is to
build an Order Management application only, then Order Management would be your
system and the recommendation above would not make sense. It only makes sense if
your scope is such that you consider all business tools in your organization as one
system.
• For each business worker supported by the system, identify use cases that represent
what is to be automated.
• For each business entity supported by the system, identify entity classes in the
analysis model. Some of these are candidates for being considered as key mechanisms,
the component entities, in the system.
• For clusters of business entities—a group of business entities that are used solely
within one business use case or a group of otherwise closely related business entities—
create a subsystem in the business specific layer.
 In a four-layered system architecture, business models give input to the top two
layers

Business Models and Actors to the System

For each business worker, identify a candidate system actor. For each business
use case the business actor participates in, create a candidate system use case.

To identify information-system use cases, begin with the business workers in the business
object model. For each business worker, perform the following steps:

• Decide if the business worker will use the information system.

• If so, identify an actor for the information system in the information system’s use-
case model. Give the actor the same name as the business worker.
• For each business use case in which the business worker participates, create a
system use case.
• Repeat these steps for all business workers.

Example:

Based on business models of a bank, you can derive candidate system actors and
system use cases.

Automated Business Workers

If you are aiming at building a system that completely automates a set of business
processes—which is the case if you are building an e-commerce application—for example,
it’s no longer the business worker who will become the system actor. Instead, it’s the
business actor who will directly communicate with the system and act as a system actor.

You are, in effect, changing the way business is performed when building an application of
this kind. Responsibilities of the business worker will be moved to the business actor.

Example:

When building an e-commerce site for a bank, you will be modifying the way
the process is realized.

• Responsibilities of the Clerk will be moved to the Customer.

• Create a system actor Customer corresponding to the business actor
Customer.
• Remove the system actor Clerk.
• Modify the system use case Money Transaction 1 to work with the system
actor Customer, instead of Clerk.
 Completely automating business workers changes the way the business process
is realized, as well as how you find system actors and use cases

Business Models and Entity Classes in the Analysis Model

For each business entity, create a class in the system's analysis model

A business entity to be managed by an information system will correspond to an entity in

the analysis model of the information system. In some cases, however, it might be suitable
to let attributes of the business entity correspond to entities in the information-system
model. Several business workers can access a business entity. Consequently, the
corresponding entities in the system can participate in several information-system use
cases.

Example:
 The business entities Customer Profile, Account, and Loan are all candidates for
automation.

Interaction between Business Workers Translated to System

Requirements
How should you interpret a link between workers in the business model? You must find out
how the information systems can support the communicating workers. An information
system can eliminate the need to transport information between workers by making the
information available in the information system.

Using the Business Object Model for Resource Planning

If you intend to use the business object model for resource planning or as a basis for
simulation, you will need to update it to reflect what types of resources are used. You need
to modify it so that each business worker and business entity is implemented by only one
type of resource. If your aim is to re-engineer the business process, in the first iteration of
your business object model, you should not consider resources. Doing so tends to make you
focus on the already existing solutions, rather than on identifying problems that can be
solved with new kinds of solutions. Here's an example of a procedure to consider:
• In a first iteration of the business object model, work without considering the
resources or the systems that will be used to implement the business.
• Discuss what can be automated.
• Discuss how automation can change the business process and start sketching out a
system use-case model and system requirements.
• In a second iteration to the business object model, update it to reflect resources used
and what is to be automated.
o Some business workers will be tagged as automated workers.
o Some business workers will be split into two—one automated, the other one
not.
o Parts of two business workers may be partitioned out to a new automated
worker.
o Parts of a business worker’s responsibility may be moved outside of the
organization to become the responsibility of a business actor.

Example:

In the banking example, we decided to update the business object model in

order to use it for resource planning.

• The Clerk business worker is completely automated and becomes an

Automated Clerk. The bank will only do on-line banking.
• The Loan Specialist is partly automated, and is split into an Automated Loan
Specialist and a Loan Specialist.

The business workers are modified to reflect automation

Summary Table
The following table summarizes the relationship between the business models and the
system models.

System Models How to find candidates, using Business

information in the business models Models
Actor Actor candidates are found among Business worker
business workers.
Actor Other actor candidates are found among Business actor
the different business actors (customers,
vendors) that will directly use the
system.
Use case Use-case candidates are found among Business
business-workers’ operations. Look for workers’
operations, and areas of responsibility, operations
that involve interactions with the
information system. Ideally one
information system use case supports all
the business worker’s operations within
one business model use-case realization.
Entity class Entity class candidates are found among Business entity
business entities. Look for business
entities that should be maintained or
represented in the information system.
Entity class Entity class candidates are found among Attributes
attributes in the business object model.
Look for attributes that should be
maintained or represented in the
information system.
Relationships Relationships between business entities Relationships
between entity often indicate a corresponding between
classes relationship between the classes in the business entities
information system model.