Chapter 6. Business Modeling

Key Points

Business modeling is a problem analysis technique especially suitable for the IS/IT environment.
The business model is used to help define systems and their applications.
A business use-case model, consisting of actors and use cases, is a model of the intended functions of the business.
A business object model describes the entities that deliver the functionality to realize the business use cases and how these entities interact.

In the context of the IS/IT environment, and in the context of ISV applications that work with disparate systems and other applications, the first problem to be solved has an even broader context than we described in Chapter 5. In this environment business, system, and organizational complexity abounds, and one typically needs to understand some of this complexity before even attempting to define a specific problem worth solving. This environment consists not simply of a user or two and their interface to a computer but rather of organizations, business units, departments, functions, wide area networks, the corporate intranet and extranet, customers, users, human resources, material requirement planning (MRP) systems, inventory, existing applications, and more.

In addition, even when we are focused on a specific application to be implemented, we must continually remind ourselves of the broader context in which the application operates. Perhaps this can be accomplished successfully by asking the right questions, but as with any technique, there's more that can be done in a specific context than in the more generic case.

In these contexts, it would be helpful to have a technique to determine answers to an even broader set of questions such as the following.

Why build a system at all?
Where should it be located?
How can we determine what functionality is optimum to locate on a particular node in the system?
When should we use manual-processing steps or workarounds?
When should we consider restructuring the organization itself in order to solve the problem?

Fortunately, there is a technique that's well suited to addressing this particular problem, and that technique is business modeling .

The Purpose of Business Modeling

Within the context of this book, we can think of the terms business and business modeling in the broadest possible context. For example, your business may be the business of developing software or manufacturing welding robots, or you may wish to model a not-for-profit business or service organization or an intradepartmental process or internal workflow.

In any case, the purpose of business modeling is threefold:

To understand the structure and dynamics of the existing organization
To ensure that customers, end users, and developers have a common understanding of the organization
To understand how to deploy new systems to facilitate productivity and which existing systems may be affected by that new system

Business modeling gives the team a logical approach to defining where software applications can improve the productivity of the business and helps determine requirements for those applications.

Using Software Engineering Techniques for Business Modeling

Of course, a variety of techniques can be applied to business modeling. However, it's convenient that, as software developers, we have at our disposal a rich set of tools and techniques we already use to model our software. Indeed, we already know how to model entities (objects and classes), relationships (dependencies, associations, and so on), complex processes (sequences of activities, state transitions, events, conditionality , and so on), and other constructs that occur naturally in the context of designing our software applications.

With the right choice of business modeling technique, some of the work products, such as use cases and object models, will be useful in the solution activity.

If we could apply these same techniques to business modeling, we would be speaking the same language in both contexts. For example, a "thing," such as a payroll withholding stub, described in the business domain might relate to a "thing" that appears again in the software domain ”a payroll withholding record, for example. If we can be fortunate enough to use the same (or very similar) techniques for both problem analysis and solution design, the two activities can share these same work products.

Choosing the Right Technique

Historically, we have seen that modeling techniques that were developed and matured in the software domain inspire new ways of visualizing an organization. Since object-oriented visual modeling techniques have become common for new software projects, using similar techniques in the business domain comes naturally. This methodology has been well developed by Jacobson, Ericsson, and Jacobson [1995] and others.

The 1980s and 1990s saw a rapid proliferation of both business modeling techniques and software development methodologies. However, they were all different! At the center of this activity were the various object-oriented (OO) methods and notations developed by various software engineering experts and methodologists. ^[1] Fortunately, these methodology "wars" are over, and the industry has settled on an industry standard ”the Unified Modeling Language (UML) ”for modeling software- intensive systems.

^[1] Various OO methods included the Booch method by Grady Booch from Rational Software; the Object Modeling Technique by James Rumbaugh, then at GE; Responsibility-Driven Design by Rebecca Wirfs-Brock at Tektronix; Object Oriented Software Engineering by Ivar Jacobson, then at Objectory in Sweden; the Coad-Yourdon method by Peter Coad and Ed Yourdon; and a half dozen more.

The Unified Modeling Language

In late 1997, this graphical language "for visualizing, specifying, constructing, and documenting the artifacts of a software intensive system" was adopted as an industry standard [Booch, Jacobson, and Rumbaugh 1999]. The UML provides a set of modeling elements, notations, relationships, and rules for use that could be applied to a software development activity. However, the UML can also be used to model other domains, such as systems modeling and business modeling. A tutorial on the UML is outside the scope of this book. (For this, refer to the three companion books on the UML: Booch, Jacobson, and Rumbaugh [1999], The Unified Modeling Language User Guide ; Jacobson, Booch, and Rumbaugh [1999], The Unified Software Development Process ; and Rumbaugh, Jacobson, and Booch [1998], The Unified Modeling Language Reference Manual .) Nonetheless, we will use some key concepts from the UML in this section and will build on this foundation in succeeding sections of this book.

Business Modeling Using UML Concepts

One of the goals of business models is to develop a model of the business that can be used to drive application development. Two key modeling constructs that can be used for this purpose are a business use-case model and a business object model .

A business use-case model is a model of the intended functions of the business and is used as an essential input to identify roles and deliverables in the organization. As such, the business use-case model consists of the actors (users and systems that interact with the business) and the use cases (sequences of events through which the actors interact with the business elements to get their jobs done). Together, the actors and the use cases describe who is involved in the business activities and how these activities take place. Figure 6-1 shows the business use-case model. Note that the oval icon used to represent the business use case has a slash, indicating a business-level use case rather than a system-level use case. ^[2]

^[2] The icon is one of many standard UML stereotypes. For further discussion of the modeling icons, see Rational Software Corporation [2002].

Figure 6-1. Business use-case model

graphics/06fig01.gif

A business use-case model, then, consists of business actors and business use cases, with the actors representing roles external to the business (for example, employees and customers) and the business use cases representing processes. Examples of a business use-case model might be

"Deliver electronic pay stub to employee."
"Meet with customer to negotiate contract terms."

Examples of business actors are

"Customer"
"Employee"
"Software developer"

The business object model describes the entities ”departments, paychecks , systems ”and how they interact to deliver the functionality necessary to realize the business use cases. Figure 6-2 represents the business object model. The actor-circle icon represents a worker who appears within the business process, such as a payroll clerk or a system administrator. The slashed circle without an actor represents a business entity or something that business workers produce, such as a paycheck or a ball bearing or a source file. ^[3]

^[3] Ibid.

Figure 6-2. Business object model

graphics/06fig02.gif

A business object model may also include business use-case realizations that show how the business use cases are "performed" in terms of interacting business workers and business entities. To reflect groups or departments in an organization, business workers and business entities may be grouped into organizational units.

Taken together, the two models provide a comprehensive overview of how the business works and allow the development team to focus on the areas in which systems can be provided that will improve the overall efficiency of the business. The models also help the team understand what changes will have to take place within the business processes themselves in order for the new system to be effectively implemented.

Buy on amazon.com >>

Leffingwell D., Widrig D.

<< Previous page

Table of contents

Next page >>