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
Roles | Primary Performer:
| Additional Performers:
|
Inputs | Mandatory:
| Optional:
|
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
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|