Designing the case hierarchy
Archived
2 Tasks
10 mins
Scenario
Front Stage has analyzed their requirements regarding hosting outdoor events, also known as weather prep, as well as the need to issue requests to different hotels to have a block of rooms reserved for that event. Weather monitoring is included in the price of an event. Hotel booking and parking are offered as optional services at additional charges.
Analyze the key requirements for this application . The key requirements to consider are:
Processes – The weather prep, hotel rooms request, and parking services functionality must be able to execute independently .
Extensibility – It must be possible to extend the booking application to support different types of venues.
Reporting – Reports for events should be defined that display revenue, cost, and profit (profit by event type)
Data – Facilities users must not be able to see financial information.
UI – Customer quotation, event manager review, and hotel booking screens.
Review any viable alternative designs listing the pros and cons of each to produce a recommendation on the most appropriate case structure for the application. Make a list of questions to ask Front Stage. This may help produce a design that satisfies the current requirements and accommodate future requirements with minimal refactoring.
Detailed Tasks
1 Solution detail
An Event case with subcases is preferred because it:
- Fully satisfies the application locking requirements
- Make it easier to satisfy the UI requirement
- Helps make the application more accommodating to future requirements because subcases offer more specialization options
2 Alternative approaches
Single Case with subprocesses (subflows)
A single Event Case does not satisfy the processes requirements due to locking issues. The extensibility and reporting requirements are easily satisfied, and the UI requirement may be satisfied with independent data objects tracking each hotel. However, extra work is required to update the status of each hotel.
The data requirement could be satisfied by obfuscating the data for the facilities users, but this is not an optimum solution for securing data.
The processes requirement, however, could not be fully satisfied due to case locking since this prevents two users from updating the cases at the same time. Optimistic locking could be implemented in order to remedy the problem, but this may not be an optimum solution since it may detract from the user experience during case processing. This problem may be exacerbated if additional services are added.
Single Case with child cases (subcases)
A viable alternative is an Event top level case with subcases for services (currently Weather, Hotel, and Parking). Modifying the default locking scheme to lock subcases independently of their parent would solve the locking problem and allow parallel processing without interruption. This also lends extensibility of the design as it may be easy to handle additional services. Consider handling the coordination of the subcase resolution with the main case using this solution. Hotel subcases should complete prior to the event starting, and the Parking case is active during the actual event and possibly after. Also consider the effect of adding additional services in the future.
Multiple cases (with subflows/processes)
An alternative to the single top level event case is having a separate quote case provide the initial quote. If approved, a peer Event case is created. This provides the possibility of only creating an event case if the event is approved by the customer and executives.
Conditionally creating top level case (with subflows/processes)
Another alternative is providing a quote to the customer on the first screen using the New harness. If the customer approves the quote, a top level case is created and is routed for approval. If the quote is not approved, the quote dies and is never persisted.
Pros/cons of each approach
| Design | Pros | Cons |
|---|---|---|
| Single case with subprocesses |
|
|
| Single case with child cases |
|
|
| Multiple cases |
|
|
| Conditionally creating top level case |
|
|