Concepts: Going from Business Models to Systems

• Introduction
• Business Models and System Architecture
• Business Models and Actors to the System
• Business Models and Entity Classes in the Analysis Model
• Interaction between Business Workers Translated to System Requirements
• Different Contexts for Business Modeling
• Other Sources of Requirements on Systems
• Summary Table

Introduction

The approach to business modeling presented in the Rational Unified Process includes a concise and straightforward way to generate requirements on supporting information systems. A good understanding of business processes is important to be able to build the right systems. Even more value is added if you also 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 is 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 should 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 kind of systems:

• Customized systems for one or more companies in a particular type of industry (banks, insurance companies).
• A family of applications for the open market (order handling systems, billing systems, air-traffic control systems).

The business models would give input to the use-case view, and the logical view as presented in the analysis model. You would also be able to find key mechanism at the analysis level (analysis mechanisms).

The following should be considered:

• For each business use case that is to be supported by the system, identify a subsystem in the analysis model. This subsystem is in the application layer and is to be considered a first prototype iteration. For example, if you have an Order process and a Billing process in your business use-case model, you would identify an Order subsystem and a Billing subsystem in the application layer of your analysis model. But, you may argue, to me Order and Billing are separate systems. Well, that is a matter of scope. If you are considering all your information-system support 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. So, the recommendation given above only makes sense if your scope is such that you consider all information-system support in the organization as one system.
• For each business worker that is to be supported by the system, identify use cases that represent what is to be automated.
• For each business entity that is to be supported by the system, identify entity classes in the analysis model. Some of these are candidates of being considered key mechanisms ("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 will give input to the two top layers.

Business Models and Actors to the System

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.
• If the business worker has a responsibility within a business use case (one or several operations) that involves the use of the information system, identify an information-system use case for each such responsibility. Give the information-system use case a name that reflects the identity of the responsibility it supports.
• If the responsibility within the business-system use case is fragmented, you may identify several information-system use cases for it. A "fragmented" responsibility is one that encompasses many kinds of activities performed at different times that have no direct causal connection.
• Repeat these steps for all business workers.

In the same way, you should look at each business actor. If the business actor will use the system directly, you should identify an information-system actor corresponding to the business actor.

Business Models and Entity Classes in the Analysis Model

A business entity that is to be represented in 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. A business entity can be accessed by several business workers. Consequently, the corresponding entities in the system can participate in several information-system use cases.

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.

Different Contexts for Business Modeling

We have seen three main types of situations:

• You perform business modeling to help find requirements on one specific application, to be built from scratch. There are other applications supporting the business that we need to be aware of (legacy systems). Decisions need to be made on whether the new application should replace some functionality in the old legacy systems, or whether it should complement the legacy systems.
• You perform business modeling to help find requirements for improving an already existing application.
• You perform business modeling to help find requirements on information systems in a completely new line of business. The goal of the work is not necessarily to build new applications, but to determine if existing applications in other lines of business can be used (with or without modifications) in the new line of business.

What all these "typical situations" have in common is that the goal is to define a subset of the requirements on automation, not all requirements. This means that before you can define which business workers become system actors to the application you are building, you need to identify what situation you are trying to resolve, and also obtain information on any already existing applications that will co-exist with the one you are building.

Other Sources of Requirements on Systems

There are many sources of knowledge about—and requirements for—the information system outside the business model. Examples of sources are:

• Users of the information systems that you have not modeled in the business model. For example, the system administrator is a user of the information system that is (usually) not represented in the business model.
• Strategies that the business as whole has decided on. For example, regarding IT, reuse, compatibility and quality.
• Corporate databases that must be used.
• Other information systems with which the new system(s) must work.
• Timing and coordination with other projects.
• Trends within the business’s own industry and within the IT industry.

See the Requirements Workflow for more details.

Summary Table

The following table summarizes the relationship between the business models and the information-system models.