Designing the case hierarchy
3 Tasks
2 hrs
Scenario
Front Stage has finalized its requirements regarding hosting outdoor events, including weather preparation, hotel room reservations, and parking. 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 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 all viable design options and list the pros and cons of each to produce a recommendation on the most appropriate case structure for the application.
Optional: Generate a list of additional questions to ask Front Stage, which may help produce a design that satisfies the current requirements and accommodate future requirements with minimal refactoring.
Detailed Tasks
1 Identify design options
Single case with subprocesses (subflows)
A single Event case does not satisfy the process requirements due to locking issues. The extensibility and reporting requirements are easily met, 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 can be satisfied by obfuscating the facility's users' data, but this is not an optimal solution for securing data.
However, the processes requirement cannot be fully satisfied due to case locking because this prevents two users from updating the case simultaneously. Optimistic locking can remedy the problem, but this may not be optimal because it may detract from the user experience during case processing. Adding more services might exacerbate this problem.
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 solves the locking problem and allows parallel processing without interruption. This approach also lends extensibility to 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 possible design option. Hotel subcases should complete before the event start, 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 approach provides the possibility of creating an event case only if the customer and executives approve the event.
Circumstanced top-level case (with subflows/processes)
Another alternative is providing customer self-service quote capability through a Mashup channel Event case circumstance. If the customer likes the quote generated within the Create stage, on submit, the Event case would move forward to the Quotation stage to which the customer does not have access. If the customer does not want to go forward, they can cancel within the Create stage which resolves the Event case. In the Quotation stage a Sale Executive can reject or approve a customer-submitted quote. If not speaking with the customer directly when a Sales Executive approves a customer-submitted quote, the customer could be asked to confirm their decision, also through a Mashup interface.
2 Evaluate design options
Pros and cons of each design option
| Design | Pros | Cons |
|---|---|---|
| Single case with subprocesses |
|
|
| Single case with child cases |
|
|
| Multiple cases |
|
|
| Single case with child cases, circumstance the singe case for Mashup |
|
|
3 Recommend the best design option
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 option
Customer self-service being added to the top-level case does not affect the decision to spin off subcases once past the Quotation stage. Care needs to be taken not to display information to the customer, such as costs and profit, that only a Sales Executive should see.
Available in the following mission:
Want to help us improve this content?