WPD: Business Object Model

IBM Global Services

Business Object Model

Work Product Description (WPD)
Unique ID: APP 302
© Copyright International Business Machines Corporation 1998, 2000
Version 3.0, January 2000

1 Description
The Business Object Model work product identifies objects of importance to a business and documents
the relationships between them in terms of responsibilities and behavior. Its emphasizes the roles
performed in the business area and their active responsibilities. It uses a subset of notation from the
Unified Modeling Language (UML).

The Business Object Model brings the notions of structure and behavior together. It is a bridging work
product that articulates business concerns in a way that is similar to methods of software development
while retaining a purely business content. It is a consolidation of what is known about the area of
business concern expressed in terms of objects, attributes, and responsibilities.

A Business Object Model is not a “model of business objects.” It is an “object model of the business.”
The difference is a matter of perspective. The term “business objects” connotes the part of a software
solution that directly represents items of interest to business. The software domain is associated with the
scope of a planned implementation. This implementation-free view of the software space is the subject of
an analysis object model.

2 Purpose
The Business Object Model is positioned firmly on the bridge between the world of business and the
world of information systems development. It explores the essence of business area knowledge in a way
that provides a transition from thinking about business issues to thinking about software applications. Its
creation is a way of verifying requirements to be enabled or supported by the information system to be
built. Agreement between business object definitions and relationships, and the names for the objects
and relationships permits business area knowledge to be represented in a precise manner that can be
understood and validated by business area experts.

In addition, the Business Object Model:

• Helps to scope what is inside and outside the specific application being developed. The boundaries
of the application are explored through an object view of the business area.
• Can be reused by many development projects. To the extent that it is it free of design details and is
also free of application boundaries, a good Business Object Model is a key asset that a company can
build, maintain, and reuse in many applications within the business area.

Work Product Description Page 1 of 7

WPD: Business Object Model

2.1 Impact of Not Having This Work Product

Creation of the Business Object Model forces developers to examine other business modeling work
products and reformulate them in terms of objects and collaborative behavior. Failure to perform this step
means the risk that developers will only give superficial attention to the business model. This is a waste
of costly business modeling effort and of the advantages of be gained therein. In this way, systems get
built that do not support the true needs of the business.

2.2 Reasons for Not Needing This Work Product

If developers have participated in the business modeling efforts to produce classified business terms,
business process models, business event lists, etc., they may be well grounded in the concepts of the
business domain for the application. In this event, it may be reasonable to proceed directly into use case
modeling and analysis object modeling.

3 Notation
The notation for the Business Object Model is a simple subset of UML, with an emphasis on static
structure diagrams and collaboration diagrams.

The primary focus is on object types and their collaborations. Occasionally it is helpful to explore
instance-level associations. The distinction between types and instances of objects is shown below.
There is a “Type,” with attributes and behaviors, and an instance “T1,” where it is shown as an instance of
Type with its name underlined.

Type
Attribute1 T1:Type
Attribute2 Attribute1 = x
Behavior1 Attribute2 = y
Behavior2

A useful portrayal of business objects is the class diagram, which is a static structure diagram. The three
primary ways of relating types in UML are associations, compositions, and generalizations. Associations
show multiplicity of the numbers of each type that can be validly related to each other. For example, any
number of Type 1s can be associated with at least one Type 2.

Type1 Type2
* 1..*

A variation on the association has an arrow point on one or both ends of the association path. This
indicates that navigation is supported toward the class that is attached to the arrow.
1..*
Type1 Type2
*

Compositions show how types can be used to create other, more complicated types.

Type

Component1 Component2

Work Product Description Page 2 of 7

WPD: Business Object Model

Generalizations show levels of abstraction among types, where there is a type/subtype hierarchy.

Type

Subtype1 Subtype2

4 Example
The following example is based on a business process model from a retail store gift registry process.
This is a view on a more comprehensive model of the retail store operation. There are various roles that
have been defined in the gift registry process, and these are reflected in the model below as active object
types, such as EventCoordinator, WishLister, CustomerDefiner, and ProductSelector. These are shown
at the center of the view, collaborating to ensure that the customer is defined, the WishList is created,
Products are selected and associated with WishListItems, etc.

Gift Registry - Business Object Model

RegistersGifts

Customer GathersToTransmit InterStore BroadcastsTo

GuestLocation Communicator Store

*
ProvidesShippingRadius AccessesToTransmit
RequestsBroadcast

1
1 Establishes Creates 1..*
Event EventCoordinator RequestsCreation
WishLister WishList

1 1 EnsuresCompleteness

Adds
WishListItem
ShipToBefore ShipToAfter RequestsAuthentication ProvidesRequirements ConveysSelection
*

1 0..1 1 * IsAlternativeFor

BeforeEvent AfterEvent MatchesRequirement *

CustomerDefiner ProductSelector Product
Address Address *
* Complements

Establishes Authenticates

Customer CommunicatesAt ProductOption Clothing Housewares

Address CustomerRecord
* *

ClothingSizes ClothingColors

This is a simplified drawing as it is intended to convey business information in a way that is conducive to
thoughts of objects collaborating in a software space. There are some structural relationships, but the
thrust of the drawing is to convey behavior between the role objects and others.

Work Product Description Page 3 of 7

WPD: Business Object Model

5 Development Approach
The Business Object Model is based on the object-oriented paradigm, which has become a dominant way
of designing software. This approach stresses modularity, where modules are thought of as objects.
These objects know their own state and collaborate to accomplish various forms of behavior by sending
messages that request services from each other.

Certain items in the business world have characteristics that closely parallel this object paradigm. These
business items receive information, transmit information, transform information, and embody and execute
rules. They have characteristics, such as classification, composition, and interaction, based on defined
protocols. In business, things that most closely match object characteristics are people serving roles and
organizations serving roles. People and organizations in roles receive, transform, and transmit
information, often based on definable rules and protocol. These roles are susceptible to interesting
classification as well as combinations.

Other clearly information-bearing things, such as products, locations, and information constructs (e.g.,
agreements, lists, histories, monetary accounts etc.) also become candidates for objects in the Business
Object Model. These generally cooperate with business role objects to calculate inventory levels, price
themselves, trigger future actions, and store the results of business actions.

There are three approaches to business object modeling:

1. The Business Object Model may be produced as part of a Joint Application Development (JAD)
session. JAD techniques can be used to elicit agreement on business area details and on application
requirements. An object model, and possibly scenarios, may be used to express the information
discussed during the JAD sessions.
2. Begin from a generic reference model that is customized and expanded to articulate the specifics
found in a particular business environment. A source on the refinements needed can be found in the
business language of the specific business domain. This will help facilitate the customization of a
generic solution for a particular IBM customer.
3. Start from other business model work products and mine them for information to produce the
Business Object Model. Sources for information that can be expressed as business objects are the
Classified Business Terms and Business Rules work products, and any business process models that
may exist. When starting from the business process model, examine each type of role based on its
responsibilities and interactions with other roles.

No matter how the information is discovered, in building the Business Object Model business items that
receive information, transmit information, transform information, embody business rules, execute rules,
can be classified, can be composed into more complex structures, and can interact based on defined
protocols are sought out. Also sought are persons in roles and organizations in roles as well as other
information-bearing things such as products, locations, and information constructs such as agreements,
lists, histories, and monetary accounts.

As business objects are gathered and refined, their behaviors are articulated. The individual and
organizational role objects cooperate with each other to perceive business events, capture information,
and make decisions based on well-defined business rules. They work with other business objects that
are able to calculate inventory levels, price themselves, trigger future actions, and store the results of
business actions.

A general rule for Business Object Models is to express as many object names as possible in terms of
roles. Make the names denote performers of actions (e.g., CustomerDefiner and WishLister). This puts
the modelers in a behavior-oriented mindset, which helps to avoid a problem where Business Object
Models are simply entity relationship models. Instead the Business Object Model should depict

Work Product Description Page 4 of 7

WPD: Business Object Model

responsibility partitioning. Someone (or some thing) is responsible to perform certain actions. Modelers
should be concerned with whether a division of labor is, at least conceptually, possible.

As the Business Object Model develops, it is useful to create various views on the objects that have been
modeled. One of these views is the static structure diagram. This shows a number of objects and how
they relate to each other in arrangements such as composition and classification hierarchies.

Collaboration diagrams are more behavior oriented and show how a number of objects work together to
perform certain functions within the business. A particularly useful collaboration diagram is one that has a
single business role object as its focal point. Based on all the actions that this role performs, wherever it
appears in business process models, we create responsibilities and collaborations with other objects.
This is a powerful mechanism for exploring the partitioning of behavior within the business domain.

6 Validation and Verification

Walkthroughs with “arms-length” reviewers are a useful way of validating this work product for
completeness and quality. Bring in peer experts to review the model. Ideally, a team composed of
Information Technology personnel and, most importantly, key business personnel perform this validation.
During such reviews, the leader should interpret the model for the attendees and invite their feedback.
Another member of the modeling team should look for and record issues that arise during the session.

A Business Object Model is complete when it reflects all important business concepts within the intended
scope as specified by the classified business terms.

A quality Business Object Model is one in which:

• The names of object types accurately reflect either concepts in the business area or abstractions that
structure the model.
• Class names are appropriate. Names should convey intent. Be suspicious of names such as
Controller and Manager as these often indicate a centralization of control.
• No design artifacts are present.

7 Advice and Guidance

The following guidance is suggested:

• Focus the area of coverage on a well-defined business area, activity, function, or problem.
• Keep instances in the Business Object Model work product few and simple.
• Keep syntax to a minimum to enable customers and end users to participate fully.
• Use the modeling notations informally as a way of sketching business area knowledge as business
area experts reveal it.
• Continually ask business area experts to validate the analysis. Conduct reviews with different
experts.
• Define the aim of the Business Object Model as precisely as possible; formulate it as a question to be
answered by the analysis. An example of an aim might be: “Where are the boundaries of the
application?” or “How is this application related to the existing another application?” Use this question
whenever there is doubt about what should be analyzed and how deeply.
• Use open questions to elicit stories. Focusing on specific historical incidents can be very powerful
here.

Work Product Description Page 5 of 7

WPD: Business Object Model

8 References
Ballard, C., and Hodgson, R. (April, 1996). OTCN White Paper: Developing a Business Object Model
Using Scenario-Based Responsibility Partitioning. IBM Object Technology Practice.

Kurt, W. D. (1995). Applying OMT - A Practical Step-by-Step Guide to Using the Object Modeling
Technique. Upper Saddle River, NJ: Prentice-Hall. New York: SIGS Books. ISBN 0-13-231390-1.

Thornton G. and Eldred, J. (1996). Getting Results with the Object-Oriented Enterprise Model. New York:
SIGS Books.

Reenskaug, T., et al. (1996). Working with Objects. Greenwich, CT: Manning.

Taylor, D. (1995). Business Engineering with Object Technology. New York: John Wiley & Sons.

UML Notation Guide, Ver. 1.1, September, 1997.

9 Estimating Considerations
The time spent creating a Business Object Model depends primarily on the complexity of the business
area being modeled. Assuming the existence of a set of process models and classified terms, an object
model can be put together in a period of 2 to 4 weeks. The basic model can be subjected to various
views, in the proper tool, and these views will be revisited and refined during the course of the project.

Questions to be considered when making estimations of effort required to produce Business Object
Models include:

• What reference models exist from similar business situations that can be reused?
• What models already exist in the client environment?
• What is the scope of the effort?
• How large and diverse is the user community being modeled?
• How complex is the business area in general?

Work Product Description Page 6 of 7

WPD: Business Object Model

10 Revision History

Date of this release: Date of next revision:

Revision Revision Summary of Changes Changes

Number Date Marked?
Version January MIFP published version – no changes.
3.0 2000
Version December Removed context information in Estimating Considerations. No
1.3 1999
Version September Updated template, editorial changes, and inserted estimating
1.2 1999 considerations

Version February A standard format template was applied, and the document
1.1 1999 was edited for grammatical errors.

Version September Base version.

1.0 1998

Work Product Description Page 7 of 7