Task: Functional Area Analysis
This task takes initial ideas about partitioning of the business (for example, from a component business modeling approach) and refines them, based on the identification of sets of cohesive business functions for the business domain, into functional areas - aggregates of functionality that are assigned to business systems.
Disciplines: Business Modeling
Purpose

The purpose of functional area analysis is to validate initial ideas about the partitioning of the business, firstly into business domains (which will logically enclose a set of business systems that are of interest for the business modeling effort) -- noting that this may require an intermediate step of identifying sub-domains to delineate the part of the business to be studied -- and then by discovering functional areas, that is, aggregates of functionality that can be assigned to business systems. It is a complementary approach to Business Architectural Analysis and can be used in concert with that task.

Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
    • None
    Outputs
      Main Description

      Functional area analysis can begin with a component business model (see Concept: Component Business Modeling) and use the identified CBM competencies as a starting point for the set of Artifact: Business Domains. The business modeling effort is scoped by the business domain(s) under study, so functional area analysis may select from the initial set of business domains and further decompose these into sub-domains, and ultimately into functional areas -- CBM components from the initial model should give good guidance here.

      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 - the functions themselves may also suggest automation -- the IT subsystems within the Business Systems that will realize some or all of the services.

      Steps
      Decomposing Domains into Functional Areas

      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.

      Mapping Functional Areas to (IT) Subsystems

      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.

      More Information