The business model is intended to capture the business vision in a modeling format. It describes:

· the stakeholder requests in terms functionality of the business as captured by use cases.

The business model is implementation independent. That is; it does not describe the business in terms of systems and technology currently used to perform the job of the business. The business model should be accurate when all technology is removed and all that is left is the people and basic tools. [Another way like to describe the business model is to think of it in terms of there being no electricity available to the organization. Ask yourself; with no power available to the workers does the model accurately describe their work environment and processes?]

When the existing business processes are changing as a result of automating the business then we may include a gap analysis that describes the cost to the business as a result of the change.

11.1Business Architecture

Used by the analyst to define the scope of the analysis effort, supported by a business architecture diagram, showing what business areas are in scope for the project. A typical business architecture diagram might look like that in Figure 1:

Figure 1: shows the possible architecture of a restaurant business. Shaded nodes are the business areas within the scope of the restaurant business. Non-shaded nodes are restaurant interfaces. Figure 1: shows the major business areas of the restaurant. these are:

Restaurant[1] - The business area responsible for serving customers. This includes seating customers, showing them the menu, taking their orders, handling their bill and storing their belongings whilst in the restaurant.

Kitchen - The business area that handles food served in the restaurant. This includes, preparing ingredients, cooking, cleaning and serving meals. The kitchen interfaces with the restaurant in order to take orders and serve food.

Administration - This area of the business is responsible for handling restaurant finances. That includes, paying bills, maintaining records for tax purposes and banking functions. The administration business receives the days takings from the restaurant, monitors goods as they are received from shipping and receiving in response to orders from stock keeping, pays the suppliers of goods and maintains the restaurant financial balance with the bank.

Stock Keeping - This business area is responsible for maintaining stock levels within the restaurant. This includes monitoring stock levels and ordering items at the appropriate time. Stock keeping is informed when goods are required by the kitchen and is informed when ordered goods arrive at shipping and receiving.

Shipping and Receiving - Is responsible for receiving ordered goods and sending out restaurant goods. Shipping and receiving delivers received goods to the kitchen and informs stock keeping when goods are received.

Bank - The bank is the interface to the administration function of the restaurant where funds are maintained and bills are paid.

Supplier - The interface to the shipping and receiving and administration business areas. Supplies are ordered by the administrator and received through the shipping and receiving area.

Note that although transactions between certain departments may be carried out electronically (the Administration and the Bank, for example), no technology is implied by the architecture diagram.

11.2Business Use Cases

The Business Use Cases (BUC) capture the functionality under discussion for the project. They describe the business processes in terms of actors that are external to the business. Primary business actors are the people that gain benefit from the use case.

Remember that the primary actors are the people gaining benefit from the use case and not the people involved in doing the work of the use case. (Who 'gains benefit' is a judgment call and not necessarily a definite actor role. It is however, not anyone involved with working the use case.)

· Receive Goods - The supplier gains benefit because they get paid for goods received by the restaurant.

· Maintain Stock Levels - The kitchen is the benefactor by ensuring that a supply of ingredients is always maintained.

· Balance Books - By ensuring that the restaurant remains profitable is of benefit to the bank. (One could also make arguments for the Restaurant Owner to be the primary Actor, and the Bank being a secondary actor of the use case.)

· Eat Lunch - Is ensuring that the customer is leaving the restaurant satisfied.

· Handle Customer Question - This use case is also of benefit to the customer, by helping to ensure that the customer leaves satisfied.

Each BUC is detailed as a textual document by completing the BUC template. The process steps of the BUC are shown below. For iteration 1 of the development process we are only detailing the Customer Eat Lunch use case.

11.2.1 Eat Lunch BUC

The activity diagram in Figure 7: captures the BUC basic flow steps graphically.

11.3Business Processes

The business processes detail the interactions between the restaurant business areas in satisfying the needs of the business as a whole. Whereas the BUC steps are concerned with the interactions between the actors and the restaurant, the business processes detail the internal interactions of the restaurant’s business workers. These may be captured by adding swimlanes to the activity diagram, or by sequence diagrams[2], as shown in Figure 8:.

The internal processes involved with serving a customer are a lot more complicated than shown in the BUC activity diagram. The sequence diagram in Figure 8: shows the basic flow of the BUC. Each alternate flow will be described by its own sequence diagram.

The detailed process diagrams allow the business to assess the workload involved by each worker involved in a BUC.

11.4Business Rules

Business rules are captured as a result of detailing the business functionality.

Business rules that are derived from the Eat Lunch BUC are shown in Table 1: Eat Lunch Business Rules.

· Seating Priority - Customers will be seated on a first come first served basis, unless every restaurant table is occupied, in which case the largest party that may be seated at the next free table will be seated first.

· Menu Items - Items on the menu are ordered: 'Starters', 'Main Meal', 'Dessert', 'Wine and Cheese', 'Aperitifs', alcoholic drinks, all other drinks. Items for each category are selected from those available in the kitchen for that day.

The business rules are maintained in a business rules repository and referenced from the BUC. The steps impacted by the rules are referenced by the business rule.

11.5Business Objects

Business objects are the items (or artifacts), whether physical or conceptual, that are used to satisfy the business process needs. Normally, I see the business objects added to the BUC worker details activity diagrams. Since we used a sequence diagram to describe the worker details (instead of an activity diagram with swimlanes), we need a new diagram notation to support the objects. We could add objects to the sequence diagram, but this diagram is already very busy, and adding objects may make it almost unmanageable. Instead I am going to use the collaboration diagram. (Many tools support automatic conversion of sequence diagrams into collaboration diagrams.) In Figure 9:, the sequence diagram has been converted into a collaboration diagram, and objects have been added to messages between actors, where needed.

When converting from a sequence to collaboration diagram, the actors are identical to those on the sequence diagram, and messages between actors are replaced with data flows. The collaboration diagram is a sequence diagram with the timing removed.

To discover the objects, we add an object to each message connection between actors and workers, describing the data passed between them.

Notice that some actors and objects have been placed on the diagram twice, for readability.

The objects in Figure 9: may be collected onto a class diagram and relationships between the objects described as class relationships, as shown in Figure 10:.

The objects have been converted to classes and relationships and their cardinality have been added. See Chapter 13 for an explanation of the class diagram notation.

Finally the object descriptions are added to the glossary, given definitions and assigned to the appropriate business area.

11.6Automation

With the BUC details defined, the business analyst may assist the IT organization with identifying areas of automation in order to satisfy the project vision.

The steps of the BUC that are candidates for automation are listed along with a description of how the automation benefits the business vision and the impacted objects.

The step numbers are references back to the use case details. In this manner, when a step changes the table may be updated automatically.

The impacted objects are derived from the steps in Figure 9: and their relationship to the objects show in Figure 10:.

11.7Gap analysis

The purpose of a gap analysis is to identify the work involved with a changing business process. The gap analysis is not intended to identify the costs of automating an existing process. (The following chapters deal with the analysis effort involved with automating the process.)

By detailing an ‘as-is’ business model and a ‘to-be’ business model, the two may be compared and the differences identified.

For example, suppose that the restaurant decides to cut costs by removing the need for a cloakroom attendant during lunch hours. Then the difference to the ‘as-is’ model is as follows.

The items in ‘red’ are removed from the business worker interaction diagram[3].

Figure 11: shows the savings in business activity, and Figure 12: the savings in business objects, due to the cloakroom being removed from the business process.

11.8Summary

Business Workers – the roles performing the business processes in order to deliver benefit to the business actor.

Business Use Cases – A detailed description of a business process delivering benefit to a business actor.

Business Activity Diagram – A visual breakdown of the activities performed by the business workers in satisfying the business use case.

Business Object Diagram- Captures the artifacts that are used by the business workers to satisfy the business use case.

Remember that prior to tackling the task of creating a business modeling artifact, you should identify the stakeholder who is going to use the artifact and what they intend to do with it.

It is always useful to identify the BUCs, in order to be able to scope the project. Any BUCs outside of the scope of the project may be filed for use on other projects.

If intending to automate part of the business, then the BUCs that are within scope of the project vision should be detailed.

If the business is changing and a gap analysis is required, then detailing the business activities and the business objects is a useful activity.

If the reason for the business model is to document the customer experience, then detailing the business worker activities and objects is probably unnecessary.

The following chapters assume that the business model is going to be partially automated.

[1] Restaurant has become an overloaded term that could be open to confusion dependent upon the context that it is used in. When using the term Restaurant it will need to be clear whether the term refers to the restaurant business area or the restaurant as an organization.

[2] Since I am allergic to swimlanes .. they make my hair fall out.

[3] Sequence and collaboration are both types of interaction diagram.