Case Study
The case study examples we've been exploring so far in this chapter have focused on how RailCo is transitioning toward an SOA. Let's take the time to look at another service modeling example, this time turning our attention to some new business requirements confronting TLS.
We take advantage of the fact that this scenario takes place in a different organization by altering the parameters of the service modeling exercise. Specifically, this TLS example differs from the previous RailCo examples as follows:
- TLS contrasts three separate approaches to modeling their service candidates.
- Two of the approaches considered involve establishing an orchestration layer by introducing a new process service candidate.
- One of the approaches is based on the creation of entity-centric service candidates.
- TLS employs the use of the classification system we explained in the previous section. As a result, the terms used in this example differ from the RailCo example.
Let's now take a look at how TLS attempts to address a problem with their current Timesheet Submission Process by modeling service candidates.
The problem
TLS outsources a number of its employees on a contract basis to perform various types of specialized maintenance jobs. When these employees fill out their weekly timesheets, they are required to identify what portions of their time were spent at customer sites. Currently, the amount of time for which a customer is billed is determined by an A/R clerk manually entering hours from an appointment schedule (published prior to the submission of timesheets).
Discrepancies arise when employee timesheet entries do not match the hours billed on customer invoices. To address this problem and to streamline the overall process, TLS has decided to integrate their third-party time tracking system with their large, distributed accounting solution.
The initial TLS Timesheet Submission Process
Subsequent to a business requirements analysis, TLS analysts document a simple Timesheet Submission Process. Essentially, every timesheet TLS receives from workers outsourced to clients is required to undergo a series of verification steps. If the timesheet is verified successfully, the process ends and the timesheet is accepted; whereas, a timesheet that fails verification is submitted to a separate rejection step prior to the process ending.
Here is a breakdown of the current process steps, as illustrated in Figure 12.14:
- Receive timesheet.
- Verify timesheet.
- If timesheet is verified, accept timesheet submission and proceed to Step 5.
- Reject timesheet submission.
- Terminate process.
Figure 12.14. The TLS Timesheet Submission Process.
This process is self-contained and has no dependencies on any other processes. Within TLS's service-oriented environment, it therefore is considered a primitive business process.
Expanding the TLS Timesheet Submission Process
Though it only consists of five steps at this point, there is more to this process. The details are revealed as we decompose the process logic using our building blocks.
We begin with the "Verify timesheet" step, which is actually a sub-process in its own right. It therefore can be broken down into the following more granular steps:
|
2a.
|
Compare hours recorded on timesheet to hours billed to clients.
|
|
2b.
|
Confirm that authorization was given for any recorded overtime hours.
|
|
2c.
|
Confirm that hours recorded for any particular project do not exceed a predefined limit for that project.
|
|
2d.
|
Confirm that total hours recorded for one week do not exceed a predefined maximum for that worker.
|
Each of these steps is a simple action that is considered a primitive business activity. Further, upon subsequent analysis we discover that the "Reject timesheet submission" process activity can be decomposed into the following primitive business activities:
|
4a.
|
Update the worker's profile record to keep track of rejected timesheets.
|
|
4b.
|
Issue a timesheet rejection notification message to the worker.
|
|
4c.
|
Issue a notification to the worker's manager.
|
Having drilled-down the original process activities, we now have a larger amount of primitive business activities. To represent our revised and more detailed process we need to show all 11 possible process activities (Figure 12.15).
|
1.
|
Receive timesheet.
|
|
2.
|
Compare hours recorded on timesheet to hours billed to clients.
|
|
3.
|
Confirm that authorization was given for any recorded overtime hours.
|
|
4.
|
Confirm that hours recorded for any particular project do not exceed a predefined limit for that project.
|
|
5.
|
Confirm that total hours recorded for one week do not exceed a predefined maximum for that worker.
|
|
6.
|
If timesheet is verified, accept timesheet submission and proceed to Step 11.
|
|
7.
|
Reject timesheet submission.
|
|
8.
|
Generate a message explaining the reasons for the rejection.
|
|
9.
|
Issue a timesheet rejection notification message to the worker.
|
|
10.
|
Issue a notification to the worker's manager.
|
|
11.
|
Terminate the process.
|
Figure 12.15. The TLS Timesheet Submission Process, where each process activity is also a primitive business activity.
As we mentioned earlier, although the initial service-oriented solution built by TLS was successful in its implementation, it has been criticized for the amount of up-front analysis effort it required. TLS therefore intends to explore alternative approaches before proceeding with larger scaled SOAs. To accomplish this, TLS analysts want to use this project to compare different service candidate configurations before proceeding to the design stage.
Approach #1: Deriving hybrid services
TLS analysts first look at how service candidates could be derived using the most cost and time-efficient approach possible: creating hybrid, task-centric services. They are fully aware that this would not lead to a quality SOA, but they need to take practical considerations into account and therefore want to explore extremes. They begin by grouping the primitive business activities defined in their primitive business process into two categories (shown in Figure 12.16).
Figure 12.16. An ad-hoc grouping of primitive business activities.
These two groups seem to adequately represent the collective business process logic and are therefore used as the source from which two corresponding service candidates are derived:
- Verify Timesheet Service
- Reject Timesheet Service
As part of this process, each of the previously listed service candidates undergoes some analysis to determine exactly what would be involved with its execution. The result is a set of more granular service operation candidates, as shown in Figures 12.17 and 12.18.
Figure 12.17. The Verify Timesheet Service candidate.
Figure 12.18. The Reject Timesheet Service candidate.
The resulting service composition (Figure 12.19) is quite simple. The Verify Timesheet Service candidate acts as a quasi-process service in that it contains the bulk of the primitive business process logic, as well as the composition logic for involving the Reject Timesheet Service, should an invalid timesheet be encountered.
Figure 12.19. A simple service composition consisting of two hybrid, task-centric service candidates.
Well, this analysis didn't take too long, and that is something that appealed to the analysts. However, upon a review of their modeling efforts, some significant drawbacks are identified with this approach. Below is a collection of pros and cons identified with creating hybrid, task-centric services.
Pros
- Minimal analysis and modeling effort.
- Results in the creation of simple and easy-to-understand service candidates.
Cons
- No specialized service layers were created, therefore eliminating the benefit potential of service layer abstraction.
- No real reuse benefit is achieved, as services are very specific to a single process.
- No agility is achieved, as service logic is tightly coupled to process logic.
Note
This approach corresponds to the first of the eight scenarios covered in the Service layer configuration scenarios section of Chapter 9.
Approach #2: Deriving entity-centric services
Next, TLS analysts revisit the familiar concept of deriving entity-centric business services. Their goal is to establish a layer of entity-centric candidates, along with a parent orchestration layer consisting of a single process service candidate.
They begin by reviewing an existing entity model relevant to the Timesheet Submission Process.
Figure 12.20. A TLS entity-model displaying entities pertinent to the Timesheet Submission Process.
TLS analysts study this model, along with the following list of granular service operation candidates identified during the previous analysis:
- get recorded hours for customer and date range
- get billed hours for customer and date range
- compare recorded hours with billed hours
- get overtime hours for date range
- get authorization
- confirm authorization
- get weekly hours limit
- compare weekly hours limit with hours recorded
- update employee history
- send message to employee
- send message to manager
Before actually putting together entity-centric business service candidates, analysts first define a preliminary process service candidate called the Timesheet Submission Process Service. They accomplish this by retrieving operation candidate descriptions that contain business rules and conditional logic, as shown in Figure 12.21.
Figure 12.21. The Timesheet Submission Process Service candidate.
Next, the Timesheet entity is reviewed. It is decided that this entity warrants a corresponding entity-centric business service candidate simply called "Timesheet." Further, by analyzing its attributes, TLS determines that of the listed service operation candidates, the following should be grouped with this service candidate:
- get recorded hours for customer and date range
- get overtime hours for date range
- get authorization
However, upon subsequent analysis, it is determined that the first two operation candidates could be made more reusable by removing the requirement that a date range be the only query criteria. Although this particular business process will always provide a date range, other processes may want to request recorded or overtime hours based on other parameters. The result is a revised set of operation candidates, as shown in Figure 12.22.
Figure 12.22. The Timesheet Service candidate.
Analysts then take a look at the Invoice entity. They again agree that this entity deserves representation as a standalone entity-centric service candidate. They name this service "Invoice" and assign it the following operation candidate:
- get billed hours for customer and date range
When the service-orientation principle of reuse is again considered, analysts decide to expand the scope of this service candidate by altering the function of the chosen operation candidate and then by adding a new one, as shown in Figure 12.23. Now service requestors can retrieve customer and billed hours information separately.
Figure 12.23. The Invoice Service candidate.
The Employee and Employee History entities are reviewed next. Because they are closely related to each other, it is decided that they can be jointly represented by a single entity-centric business service candidate, called "Employee." Two service operation candidates are assigned, resulting in the service candidate definition displayed in Figure 12.24.
Figure 12.24. The Employee Service candidate.
Finally, the remaining operation candidates are grouped into a reusable application service, simply called "Notification."
- send message to employee
- send message to manager
To make the service candidate more reusable, the two operation candidates are consolidated into one, as shown in Figure 12.25.
Figure 12.25. The Notification Service candidate.
Note that when normally modeling entity-centric business services, reuse would be a larger concern and many more operation candidates would be added to arrive at a series of services candidates fully equipped to manage a range of common processing requirements. In this example, most of the operation candidates we created were only related to our immediate requirements.
Figure 12.26 displays the resulting service composition, which illustrates three distinct service sub-layers: orchestration, business, and application.
Figure 12.26. A service composition controlled by an orchestration layer.
TLS analysts conclude this modeling exercise by listing the pros and cons of their results.
Pros
- Allows for the creation of reusable service candidates.
- Establishes an extra level of abstraction via the orchestration layer.
- Highly extensible and agile.
Cons
- Requires more analysis effort.
- Results in a more complex service composition.
- Requires the creation of additional services not yet identified (application services needed to carry out processing tasks for the Employee, Timesheet, and Invoice services).
Note
This second approach corresponds to service layer configuration Scenario #8 of those discussed at the end of Chapter 9.
Approach #3: Mixing task-centric and entity-centric services
Before TLS makes a final decision, they choose to explore one more option. It has been discovered that there is reuse potential for the collection of verification tasks associated with the Timesheet Submission Process. Therefore, analysts speculate that by adding a task-centric service candidate to the set of entity-centric service candidates they just defined, they may be able to derive a reusable composition. This composition would represent a sub-process that could be reused by other master processes.
Because most of the work already has been done, this extra bit of modeling effort does not take them long. First, they identify and group the verification tasks into a new service candidate called Verify Timesheet (Figure 12.27).
Figure 12.27. The Verify Timesheet Service candidate.
This reallocation of operation candidates does not affect any of the previously defined entity-centric candidates. It only removes some of the process workflow logic from the parent Timesheet Submission Process Service candidate. It also results in a new composition configuration (displayed in Figure 12.28) in which the task-centric service candidate adds a layer to the composition hierarchy.
Figure 12.28. The revised service composition incorporating a task-centric service.
Pros
- Similar benefits of agility and extensibility to the entity-centric only approach.
- If the Verify Timesheet sub-process is truly reusable, there may be a benefit to abstracting it from larger process workflow logic.
Cons
- Results in an even more complex composition that introduces an additional layer of processing.
- Removal of workflow logic from the process service decentralizes control of the overall Timesheet Submission Process.
Note
This last approach is an implementation of service layer configuration Scenario #7, as explained in the last section of Chapter 9.
At the end of the day, the three approaches are compared and contrasted. Analysts review the pros and cons of each and balance these with short and long-term TLS goals. Their final decision is to continue with the pure entity-centric configuration (the second of the three we covered in this example).
However, as stated earlier, they will not be relying on the top-down approach any more. Pressing requirements and time constraints have motivated them to adopt the agile delivery strategy.
|
