In the context of the information system/information technology (IS/IT) environment, the first problem to be solved has an even broader context than we described in Chapter 4. In this environment, business 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, management systems, 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 the IS/IT context, it would be helpful to have a technique by which we could determine the answers to the following questions:
Why build a system at all?
Where should it be located?
How can we determine what functionality is optimum to locate on a particular 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 ideally suited to addressing this particular problem, and that technique is 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 software development or manufacturing welding robots, or you may wish to model a not-for-profit business or service organization or an intradepartmental process or internal work flow.
In any case, the purpose of business modeling is twofold:
To understand the structure and dynamics of the organization
To ensure that customers, end users, and developers have a common understanding of the organization
This approach gives the team a logical approach to defining where software applications can improve the productivity of the business and to assist in determining requirements for those applications.
Of course, a variety of techniques can be applied to business modeling. However, it's rather convenient that, as software developers, we have at our disposal a rich set of tools and techniques that 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.
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—payroll withholding record, for example. If we can be fortunate enough to use the same techniques or very similar techniques for both problem analysis and solution design, the two activities can share these same work products.
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 (1994) 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, or UML—for modeling software-intensive systems.
In late 1997, a 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). The Unified Modeling Language[2] 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 applications, such as system modeling and business modeling. A tutorial on UML is outside the scope of this book. (For this, refer to the three companion books on the UML: Booch, Rumbaugh, and Jackson (1999), The United Modeling Language User Guide; Jacobson, Booch, and Rumbaugh (1999), The Unified Software Development Process; and Rumbaugh, Booch, and Jacobson (1998), The Unified Modeling Language Reference Manual.) However, we will use some key concepts from the UML in this section and will build on this foundation in succeeding sections of this book.
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 by which the actors interact with the business elements to get their job done. Together, the actors and the use cases describe who is involved in the business activities and how these activities take place. Figure 5-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.[3]
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 might include
"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 5-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 represents a business entity or something that business workers produce, such as a paycheck or a ball bearing or a source file.[4]
A business object model also includes 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 to understand what changes will have to take place within the business processes themselves in order for the new system to be effectively implemented.
One advantage of this approach to business modeling is the clear and concise way of showing dependencies between models of the business and models of the system. This clarity improves the productivity of the software development process and also helps ensure that the system being developed solves the real business need. See Figure 5-3.
The translation between the two can briefly be summarized as follows.
Business workers will become actors to the system we are developing.
Behaviors described for business workers are things that can be automated, so they help us find system use cases and define needed functionality.
Business entities are things we may want the system to help us maintain, so they help us find entity classes in the analysis model of the system.
In performing the translation, business modeling facilitates the process of moving from an understanding of the business and problems within the business to the potential applications that may be implemented to deliver solutions to the problems identified.
Business modeling is not something that we recommend for every software engineering effort. Business models add most value when the application environment is complex and multidimensional, and when many people are directly involved in using the system. For example, if you were building an additional feature to an existing telecommunication switch, you would not consider business modeling. On the other hand, if you were building the order entry system for GoodsAreUs, we could have used business modeling to good advantage to support problem analysis.
In this chapter, we discussed a specific problem analysis technique, business modeling. In so doing, we defined
Why you might need to model the business
How, using the UML, we transpose techniques developed for software engineering and use them for business modeling
The primary artifacts of business modeling, the business use-case model, and the business object model
How you can define software applications and derive software requirements from models of the business.
In the next chapter, we'll look at systems engineering of software systems, another problem analysis technique, that will help give a shape to applications of the embedded-systems type.
[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.
[2] UML v1.1 was adopted by the international Object Management Group (OMG) in 1997 after the original creators at Rational Software (Booch, Jacobson, and Rumbaugh) built a broad-based industry consortium and included concepts from other methods, as well as a public feedback and revision process.
[3] The icon is one of many standard UML stereotypes. For further discussion of the modeling icons, see Rational Software Corporation (1999).
[4] Ibid.