Introduction

Functional Area Analysis uses a partitioning of the business, such as a CBM Component Model and Heat Map, as a starting point or input. Business domains are identified (for example, from CBM competencies) and further decomposed into sub-domains and ultimately into functional areas (for example, using CBM Components as input). Functional areas also suggest potential subsystem boundaries used for service component identification.

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.

CBM input mapped to Functional Area Description elements

Input from a business analysis activity can save time, and should be used if available. If functional area analysis is being carried out using input from Component Business Modeling (CBM), a 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.

Functional Area Analysis begins by locating and summarizing descriptions of the domains and the activities within domains relevant to the business modeling initiative.  Each of these domains is decomposed into smaller, more discrete, functional areas. Each functional area is concisely described in terms of the functions it is responsible for, as well as functions it depends on from other functional areas.

Where CBM input is used, then the CBM Competencies identified in the CBM Component Map can be treated as domains and CBM Components can be considered as functional areas.  A CBM Heat Map can be used to determine which Competencies and Components should be the focus of this analysis.

Example

We begin with a CBM Component Model that is depicted in the Component Map below. This figure shows the CBM competencies for the Rent-a-car example in the top row of the Component Map table.

Rent-a-car CBM competencies

Descriptions of each competency in the CBM Component Model are shown in Table 6.  These descriptions will save time when we describe the domains that are the focus of Functional Area Analysis.

Rent-a-car CBM heat map

Hot components in the CBM Heat Map indicate competencies that will be the focus of Functional Area Analysis. The figure above shows the four hot components -- the key components for the current SOA initiative in our running example.  The competencies associated with these hot components become the focus domain areas for Functional Area Analysis:

• Marketing and Customer Management (Customer Service is a hot component)
• Products (Promotions Management is a hot component)
• Rentals Management (Rentals and Reservations is a hot component)
• Rental Fleet Logistics (Fleet Management is a hot component)

Descriptions of each CBM component are shown in Table 6. Component descriptions provide insight into the functional responsibilities of domain focus areas and facilitate decomposition of domains into functional areas.

Each domain is analyzed to identify the major functions it is responsible for. Analysis results can be captured in a visual model that groups functional areas by domain as shown below.

Rent-a-car Functional area analysis decomposition

For Rent-a-car, we break the domains into functional areas by identifying major functional responsibilities for each domain in focus: Marketing and Customer management, Products, Rental Fleet Logistics, and Rentals Management.  CBM components of these domains provide the starting point for this analysis:

• A major functional area of the Marketing and Customer Management domain is Customer Service.  Since Customer Service directly pertains to the running example (it plays a direct role in rental-related activities), it will be further analyzed.  Other functional areas of this domain may be of interest to a different initiative, but since they do not play direct roles in this specific example, they will not be analyzed in detail at this time.
• For the Products domain, Promotions Management is a major functional area identified for further analysis since promotions affect rental pricing.  Once again, although there are other functional areas that fall within this domain, the focus area for Functional Area Analysis will be on the functional areas that are directly relevant to this SOA initiative.
• Fleet Management is a major functional area for the Rental Fleet Logistics domain that plays a role in the reservation process, for example where vehicle availability information is important.
• Rentals Management has been decomposed into three major functional areas: Rental, Reservations, and Pricing.  In this case the hot component Rentals and Reservations does not map one to one to functional areas as was the case for the other domains.  The Reservation and Rental functional areas provide the most customer visible aspects of the car rental experience.  Pricing is a key function for completing a reservation, as well as for completion of the vehicle rental at check-in (note that the function being referred to here is not the same as Pricing Management – Pricing in this domain involves setting a price for a specific reservation or rental based on a number of factors such as type of vehicle, type of customer, etc.). 

These will be the core functional areas for the next steps in this example.

The decision to designate three functional areas instead of one is a result of anticipating that these functional areas will be used in other SOMA steps, such as categories in the service hierarchy and subsystem boundaries to group functionally related components.  At this early stage of the SOMA process, Rentals and Reservations looks like such a large functional area (i.e. encompassing many functions) that it could have become unwieldy to use in later steps.  As is the case with other modeling techniques, we may find out later in the process, when more is known, that representing these three as a single subsystem will work fine (this in fact will be the case as we will see later in the paper).

There is actually an overlap across several domains regarding pricing, but we have chosen to emphasize just the pricing aspect of Rentals Management since that this is the aspect of pricing that is most directly related to the example.  The Products domain establishes baseline pricing guidelines that account for standard cost and profit policies.  Marketing and Customer Management information combined with information from Rental Fleet Logistics information and other marketplace related criteria supports special promotional pricing by the Products domain.  Marketing and Customer Management influences the criteria by which pricing schedules are applied to various customer types.

Nevertheless, whatever led to the establishment of pricing schedules, in this specific running example, it is Rentals Management where the prices are actually used during the reservation and rental.  In a different scenario, other aspects of pricing could be the focus area.  This is the type of insight that CBM and SOMA can bring to the customer, potentially leading to future initiatives and greater business value.

Further analysis will consider the interdependencies that begin to emerge as analysis delves deeper into these functions.  For example, as part of Reservations, it would be advantageous to adjust pricing due to oversupply of vehicles of a particular class at a particular location that Fleet Management is aware of.

Each functional area is described with a concise textual explanation as shown in the Rent-a-Car Functional Area Description Table example.  Input from a business analysis technique like CBM can save time: CBM Component descriptions that helped to identify functional areas also provide details that can be used to describe each functional area and its associated functions.

Functional Area Interactions and Dependencies

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 (i.e. the interactions and collaborations among functional areas) are identified.  This information will be used later as an input to subsystem analysis, which considers, among other things, the interactions among subsystems (which Functional Areas are used to identify) and Service Components within the subsystems.

The partitioning of the business domain results in a set of functional areas.  These functional areas will contain aggregates of cohesive functionality called subsystems.  Each subsystem is a conceptual mechanism by which the boundaries of the potentially cohesive set of service components are defined.

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

Subsystems bridge the gap between business (as defined by functional areas) and IT (as realized by service components).

A final step is to identify a candidate subsystem for each functional area.  In many cases there will be a one-to-one relationship between functional areas and subsystems.  If it appears that multiple subsystems could be required, this is an indication that the functional area may need to be reassessed, split into one or more additional functional areas, each taking on a subset of the original functional area's functions.

Functional Areas

Functional areas form the basis for defining the boundaries of IT subsystems, and provide a means to classify candidate services.  Functional areas are used as a starting point for subsystems and Service Component identification.  Functional areas are the lowest level of granularity to which a domain is decomposed.  In this work product, each functional area is concisely described in terms of the functions it is responsible for, as well as functions it depends on from other functional areas.  Functional areas provide sets of cohesive business functions for the domain (i.e. are subsets of the overall domain functionality).  The identification of clearly defined functional areas is important for the success of business modeling initiatives because functional areas are a key to establishing cohesive business aligned groups of services and the subsystems that will be used to realize those services.

Candidate subsystems identified in this work product are further analyzed leading to the identification of the Service Components that will be used to realize (implement) the services associated with the subsystem.

A service component is a realization of a subsystem, a logical grouping of functionally-cohesive business-aligned services, which is important enough to the enterprise to be managed and governed as an enterprise asset.  These business-aligned services can be exposed at a variety of boundaries, including the edge of the enterprise or a business unit.

Any business is composed of business domains, a logical grouping of business capabilities (functionalities) that provide related business functions and require similar skills and expertise. To explain the concept of business domain, consider the following simplified example:

• What the Business is selling? -- Products Domain
• To whom the Business is selling and how to improve it? -- Customer Relationship Management and Marketing Domain
• When and how to sell? -- Sales Management Domain
• How to Manage the Business? -- Business Administration Domain

Domains can be broken down (decomposed) into Functional Areas.  Functional areas provide a set of cohesive business functions for the domain.  For example, a functional area in the Products Domain could be Product Development, whose main function is to develop and enhance the products.