The purpose of this activity is to identify for each subsystem the main set of operations, group them into interfaces and recursively define their realizations in terms of the operations supported by the next level subsystems.

This activity describes a top-down approach of logically decomposing the business sytems across multiple aspects driven by the chosen architectural viewpoints and views (see the Use Case Flowdown and Supplementary Requirements Flowdown concepts).

Although in most of the cases the starting point will be the top-level business use cases, this is not a pre-requisite. If the use-case techniques are not employed by the modeling team, this operation-based approach could still be used as long as you can define the operations for the top-level business system. This is also true when this activity is performed for a business subsystem for which only the operations have been defined.

There are two other main characteristics of this approach. One, this is a play around two perspectives on the business (sub)systems: black box and white box. You start with the black box perspective and define the externally visible properties of the system(s), mostly in terms of operations. Then you open up the black box, define or identify its elements and describe how each system operation is realized by the elements' operations. The second characteristic of this approach is the fact that is recursive. You are applying the same general method at lower, more detailed levels, for finer-grained subsystems.

A simplified workflow through this activity is presented below:

• Task: Define Business System Context: start with the business use cases and define the top-level business system operations (black-box perspective).
• Task: Business Architectural Analysis: define the structural organization of the subsystems (white-box perspective).
• Task: Business Operation Analysis: realize the top-level operations by collaborations of the subsystems' operations
• Task: Business Operation Design: refine and refactor the operations defined during analysis and expand the realizations over the previously chosen architectural viewpoints/views.

A person acting as a business architect and/or business process analyst needs to have strong modeling and writing skills. Although knowledge of the business is useful, it can be obtained by involving domain experts as reviewers. To perform this activity effectively, you also need people who are familiar with the current set of software systems used in the organization, from both functional and support points of view.

Perform this activity if you need to increase the rigor and precision of your modeling outputs. This activity will usually be a building block part of larger activity which will address all the aspects of defining either the as-is business or the to-be one.