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

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

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.