Functional area analysis begins by creating summary descriptions that identify the major high level functional responsibilities of each domain.  Next, each domain is decomposed into smaller, more discrete, functional areas. Each functional area is described in terms of the specific functions it is responsible for, as well as functions it depends on during collaborations with other functional areas. See Concept: Functional Area Analysis. If functional area analysis is being carried out using input from a CBM effort, a business domain will typically map to a CBM competency, CBM business components are a good starting point for the identification of functional areas, and CBM component services and activities are a good way to identify functions.  CBM components often map one-to-one to functional areas, although in some cases a CBM component may be too coarse grained, encompassing too many types of functions. In that case it would need to be further decomposed into multiple functional areas. The functional areas will be assigned to Artifact: Business Systems, which will support services to deliver these functions.

As each functional area is being analyzed and described in terms of its functions, it is also analyzed in the larger context of its relationships to other functional areas (that is, the interactions and collaborations among functional areas) are identified.  This will help determine how the Business Systems owning the functional areas will collaborate.

The partitioning of the business domain results in a set of functional areas.  These functional areas should suggest aggregates of cohesive functionality that can be assigned to subsystems, which will deliver that capability.  Each subsystem is a conceptual mechanism to help define the encapsulation of services to deliver that capability -- and which may ultimately be automated by IT systems within the Business System. Subsystems collaborate to deliver the services provided by the Business System that owns the functional area.

The identification of subsystems as a result of functional area analysis allows the seamless transition from business identification of functional areas, their mapping to Business Systems to the determination of which subsystems are actually involved in the implementation of a given functional area. The subsystems become a blueprint for reuse. This approach provides us not only with an abstract specification of behavior of a subsystem, but also contracts by which subsystems collaborate and depend upon one another.

It may not be necessary to further refine the functionality assigned to a Business System, in which case there is a one-to-one mapping between the functional area and a subsystem, that is the Business System supporting the functional area has a single IT subsystem analog which yields its behavior. A proliferation of subsystems, on the other hand, may be an indication that the functional area is too coarse-grained to be assigned to a single Business System, and needs to be further divided.

Note, additional details on Subsystem Identification are available in the Guideline: Design Subsystem.