About Business Processes, Use Cases & SOA (2)

This posting is a follow-up on a previous posting in which I explained how business process models and use cases can be used to capture requirements. It especially highlighted how use cases can be used for aspects that might not that easily be captured using business processes alone.

In this second posting, I will give an example how the business process model of the previous example is drilled down to ensure that all nodes in that model are of the level of user-goals, and what the benefit of that is. I will also discuss a way to discover services from the business process model.


Drilling Down Business Process Models

When looking at the business process of the previous posting, you might notice that each activity actually is a use case of its own, most of them being at the level of user-goal use cases (which is a use case for which the user can execute it in one session and walk away happily after that). The only exception might be the Validate Parking Permit use case, that for that reason has been drilled down further to investigate if this really is at a level of a user-goal.

The result is the following Validate Parking Permit Application business process model:



As illustrated in this model, a couple of other organizations are involved in the validation, possibly making it a lengthy process, and initially suggesting that the upper level activity indeed is not a user goal level use case. But what if the other organizations have automated services available that respond within seconds? What this shows is that the level of a use case in some cases depends on the options for implementing it. This certainly is true in case of a Service Oriented Architecture.

For the following it will be assumed that such services do exist, making the Validate Parking Permit Application activity indeed an activity at the level of user-goal use cases. In the context of the Oracle Unified Method this automatically classifies the diagram above part of the use case details rather than a business process.

However, the question if it is a business process model or just use case details, is just an academic one. What is important is that you have a clear idea of when a business process needs to be further detailed. It is advisable to drill them down to the level of user-goals, for the following reasons:

• User goals provide the most effective level to start from and create system use cases from business use cases to describe what the system should do (*). For example, it is at the level of user-goal business use cases that you will decide whether a goal will be kept manual or supported by a system.
• You typically either implement a user-goal level use case or you do not implement it at all, making it the optimal unit to estimate and trace requirements from there.
  

(*) Business use cases have the business as subject and are written by business analysts to document business processes. System use cases have the system as subject and are written by system developers to document how actors communicate with the system to achieve their goals.


Service Discovery

Assuming that the requirements so far point to a solution using a Service Oriented Architecture, it is imperative to discover the services in the requirements. This is not only important for creating the application architecture but also provides important input to the estimating process.

One of the reasons to do business process modeling in the first place is that it relates very well to a Service Oriented Architecture, which makes implementation of the business process itself possible. You can imagine that the Parking Permit process is implemented as a longer running process that may take weeks to complete. But that will not be the only service involved, as the Parking Permit process itself needs other services to complete.

There are several approaches to discover services. One of them being by reviewing a business process and identify where the transitions are from an activity of one actor (swimlane) to that of another. In general this indicates a candidate service. In the example the candidate services are in the activities:

• Apply for Parking Permit
• Notify Resident of Waiting List
• Notify Parking Service of decision
• Notify Resident Permit Ready for Collection
• Collect Parking Permit
• Verify Vehicle Ownership
• Verify Electoral Register
• Verify Residence
  

The Apply for Parking Permit candidate service obviously is the starting point for the Parking Permit process itself. You can imagine that the web site of the municipality provides some form that the resident can fill out and on submit calls the Parking Permit process.

The Notify Resident of Rejection, Notify Resident of Waiting List and Notify Resident Permit Ready for Collection (from Parking Services to the Resident) are candidate services whereby the Parking Service process needs to call out some provider that handles multi-channel notifications to third parties. Whether this will be one service that can handle some generic notification, or three different services that each handle a specific notification type, or any other combination, is a design decision and at this stage is yet to be determined. Mind you, we are analyzing the business and capturing requirements, not yet defining the solution!

The Notify Parking Services of Decision points to yet another candidate service that the Resident can call to get the application removed from the waiting list.

The Verify Vehicle Ownership, Verify Electoral Register and Verify Residence already have been indicated as existing services. However, if they were not, creating them would have been outside the scope of the Parking Permit process, as those services would then have to be created by third parties not involved in the project.

From the last example above, we can conclude that transitions to activities within the scope of secondary actors that are not within the scope of the project, only indicate calls to external services.


Prototyping the User Interface

Any use case that has a user interface associated with it, might be detailed with a conceptual screen layout. Note that a conceptual screen layout is not a design, as it does not specify an actual screen layout, let alone aspects like styling. It’s main purpose is to specify which data should be shown, and should be validated during the review.

Depending on if and when you start creating a Domain Model to identify the business entities involved, conceptual prototypes provide input to or can be use to validate that model.

For example the use case Apply For Parking Permit could be detailed with a screen layout as follows:


Other use cases that may require some conceptual layout are the following:

• Notify Resident of Rejection (mail/email/SMS)
• Notify Resident of Waiting List (mail/email/SMS)
• Notify Parking Services of Decision (mail, screen)
• Notify Resident Permit Ready for Collection (mail/email/SMS)

When analyzing the Validate Parking Permit Application use case, you may find that Parking Services wants to be able to override the decision that comes out of the verification, for example by blocking a parking permit for someone that appears to hire a garage box (which none of the external organizations would note). In that case that use case also would require a conceptual screen layout.


To be continued ....