Task: Business Operation Analysis
This task defines how to perform the transformation of a behavioral description at the Business System Level, into coarse-grained system structure.
  • To elaborate the black-box flow-of-events text for each Business Operation in each architecturally significant business use case into sequences of white-box steps, speaking in terms of subsystem actions and collaborations.
  • To augment  these white-box descriptions with decisions regarding the relevant architectural views, and white-box budget requirements.
  • To create subsystem interactions in sequence or collaboration diagrams (in the Business Analysis Model), based on the white-box steps.
Main Description
In this task, the Business Designer begins the transformation of a behavioral description at the Business System Level, intocoarse-grained system structure (and associated interactions) and behavior at the Business Subsystem Level.
Elaborate black-box text into subsystem white-box steps

In this step, you take the Business Use-Case Model and elaborate the black-box flow-of-events text (which is a property of each business use case) into sequences of white-box steps (which speak in terms of subsystem actions and interactions, using the subsystems and outlined collaborations from Business Architectural Analysis). If this task is performed for a subsystem for which the operations have been already specified, then the starting point are the operations and you can proceed directly to the Initial White-Box Step Expansion.

Next, a Business System Operation (black-box step) is expanded into one or more white-box steps, each of which is performed by a named subsystem. The Designer is guided by the work done by the Architect (during Architectural Analysis) in the selection of subsystems and interactions which are used to describe the white-box steps. Note that the analysis now proceeds driven by Business System Operation; that is, treat the next realization step as the realization of each Business System Operation (rather than the more abstract notion of business use case black-box step). 

Initial white-box step expansion

The white-box steps for each Business System Operation are captured (initially) in the Business Analysis Model, associated with the corresponding Business System Operation as its realization. The white-box steps are not stored with the Business Use-Case (they are shown that way here simply as an illustration), but can be traced from the Business Use Case through the Business System Operation

Augment white-box steps with locality, process and worker decisions

The description is then further augmented with locality decisions, process decisions, and worker decisions. The locality decision places, with some latitude (given the level of abstraction of locality) where the subsystem white-box step are performed. The process decision is necessary only when it is decided that (for this step at least), the subsystem is "passive," that is, its operations are invoked by processes external to the subsystem. An "active" subsystem is able to respond autonomously, using processes internal to the subsystem. The business designer is again guided by the work of the business architect (in producing the Locality Model and Process Model). In worker decisions, appropriate when you make allocations to human resources, you start to identify the organizational entities and then system worker resources needed for a Business System Operation.

If the analysis shows that a white-box step requires more than one locality (or process), then decompose it into smaller steps, so that each can be associated with a single locality (and process, where appropriate). This decomposition might have important architectural ramifications (it might need the subsystem to be refactored) and needs to be canvassed with the team or person playing the Business Architect role.

Allocate white-box budgeted requirements
Next, apportion black-box step budgeted requirements to white-box steps. This allocation helps determine the performance requirements for both the subsystem and the associated locality. In the case of a passive subsystem, it is an input into latency analysis of the invoking process (which might have other responsibilities).
Sort white-box steps by subsystem

In this step, you collect together all white-box steps for each subsystem (that is, the white-box steps that belong to that subsystem). This is done in preparation for the identification of Subsystem Operations (which are to the subsystem what Business System Operations are to the business system), by examination of the subsystem white-box step descriptions. As with the identification of business system operations, there might not be a unique subsystem operation for each white-box step. Also note that the white-box steps are grouped by business system operation. For example, this might be done in tabular form as well, grouped by subsystem:

Refine outlined collaborations for each system operation

Based on the white-box steps, subsystem interactions are created in sequence or collaboration diagrams (in the Business Analysis Model). This refines the work done previously by the Business Architect. At this stage, the collaborations might still be abstract, perhaps only links are identified, or messages at an abstract level. This work, nevertheless, gives an insight into the coupling and cohesion of the subsystems. This refines the white-box step expansion performed previously (see Initial White-Box Step Expansion).

Evaluate the analysis
The Business Designer needs to call for an informal review at the conclusion of this task, and thus ensure that all emergent issues are recorded and scheduled for resolution.
Multiple Occurrences
Event Driven
More Information