Task: Business Operation Design
Refines the results of Operation Analysis.
Purpose
  • To refine the preliminary subsystem interactions into Operation Realizations in the Business Design Model.
  • To refine and specify the Subsystem Operations.
Relationships
Steps
Create Operation Realizations

In Task: Business Operation Analysis, the Business Designer created subsystem interactions (without much detail) in the Business Analysis Model. Recall that you had organized the granularity of these interactions so that they were grouped by Business System Operation, that is, you captured the interactions that realize each Business System Operation. Now, working with the expanded (white-box) business use-case descriptions, the detail of messages, entities exchanged, sequencing, control flow, and associated data is added and the resulting Operation Realizations are captured in the Business Design Model, again organized by Business System Operation. As this detail is added, the Business Designer evaluates the quality of the emergent collaborations, looking for opportunities to refactor the design. Annotate the Operation Realizations with descriptions of what the subsystem does when processing a message (drawn from the white-box step description and refined if necessary). These descriptions help with the next step, to develop specifications for each Subsystem Operation.

Aggregate similar subsystem white-box steps and specify Subsystem Operations

The Business Designer produced the initial Subsystem Operation Survey placeholder during the Operation Analysis task. Next, working from the white-box steps and the Operation Realizations, the Subsystem Operations are identified and their behavior specified. As with the identification of business system operations, there might not be a unique subsystem operation for each white-box step; that is, as you examine the set of white-box steps and their associated exchange of messages, input-output entities, and so forth., you might find that it is possible to define a smaller set of Subsystem Operations to fulfill their needs.

The operations can also be resorted by locality or by process, thus showing the association of a set of Subsystem Operations with each locality or with each process. The locality sort gives an indication of the load at a locality (and so is useful for reasoning about the capacity of the components that support the locality). In this form, the survey sorted by locality becomes a property of the Business Deployment Model.

When a Subsystem Operation is hosted at multiple localities, this indicates that at least part of the subsystem is replicated. There is no implication that these replicated portions necessarily share data or are kept in synchronization. These are design choices which depend on the application and reason for replication; for example, the processing required might be identical, but occur for a different business segment. In the extreme, all of a subsystem's operations can be hosted at multiple localities, meaning that, effectively, the subsystem itself is replicated. The need to identify replicated instances uniquely also depends on the reasons for replication.

The process sort allows the Business Designer to reason about concurrency issues: if you were to view a Subsystem Operation as a discrete piece of functionality available to business actors, then, as a first approximation, operations associated with the same process cannot be performed in parallel. This might lead the Business Designer to reconsider the process allocation, or consider process replication, or to examine the perceived latency problem at a lower level of detail, for example, through examination of time-slicing options, and process sharing when an operation blocks (to do input-output, for example). These techniques can give acceptable responsiveness, whereas a delaying of the start of an operation (strictly serializing operations) might be intolerable. In this form, the survey sorted by process becomes a property of the Business Design Model.

Footnote What have you achieved

For each subsystem, you have:

  • defined its operations
  • defined the interfaces you expect the subsystem to support
  • described how the subsystem collaborates with other subsystems to realize the business use cases
  • defined the subsystem's context: its actors, interfaces and I/O business entities

You are thus well positioned to be able to hand-off this set of work products for or to perform further decomposition in a recursive fashion.

Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
More Information