Knowledge Repository Service Identification

Service Identification

The Enterprise Service Specification Process (ESSP) describes a process and artifacts that are required to specify a set of services. It is not a methodology for identifying the services themselves. In this page, we provide artifacts that used to identify services, components, and flows (interactions) based on the SOMA methodlology. The techniques that are used to produce these artifacts ensure that services are aligned both with business goals (top-down) and existing assets (bottom-up). These artifacts fit into the ESSP in that they are inputs to the Service Scope and Description document, which is the outcome of the Inception phase of the Enterprise Service Specification Process (as depicted in Figure 1).

Figure 1: Enterprise Service Specification Process

Overview

We use the techniques of goal-service modeling (GSM), domain decomposition, existing asset analysis, and service refactoring and analysis to develop an initial service portfolio. The techniques are complimentary and ensure that the services are aligned with business goals, existing resources, and can be specified at the appropriate level of granularity.

Goal-Service Model (GSM)

GSM ensures that services are aligned with important business goals. The process involves starting with high-level statements of business goals, and then refining them into sub goals until those goals become actionable (i.e. something that we can address with software). At that point, we begin to define Key Performance Indicators (KPI), which are declarative statements about the value that these goals provide to the enterprise. Each KPI may have an associated Metric, which describes how we intend to measure the value. Finally, low-level goals that have both KPIs an Metrics become candidate services. These candidate services are added to the evolving Service Portfolio.

Domain Decomposition

Domain Decomposition provides a top-down analysis of the enterprise domains and processes in order to identify services, components, and flows. This analysis includes functional area analysis, business process modeling, variation analysis. Outputs include candidate services, components, and business entities.

Functional Area Analysis

Functional Area Analysis is used to identify the static structure of the enterprise by partitioning it into coarse-grained functional areas. Functional areas are partitioned into loosely-coupled sub systems. For each functional area, the responsibilities, business entities, and any associated policies & rules are identified. Here, only high-level business entities are identified. There variations are elaborated in the Variation Analysis, and ultimately included in the Business Entity catalog in the Information Analysis.

The table below provides a starting point for functional area analysis. High-level functionality from the requirements elicitation project should be grouped into Domains and Functional Areas. Each Functional Area is partitioned into Sub Systems that have a cohesive set of Responsibilities. The Responsibility descriptions identify Business Entities needed to fulfill the Sub System's function. Business Entities are linked to more detailed descriptions in the evolving Business Entity Catalog.

Business Process Modeling

Business Process Modeling is used define the to-be, dynamic model of the enterprise, given the as-is model.

Existing Asset Analysis

—

Outputs

Information Analysis

Business Entities
Relevant Standards
Existing Data Sources

Service Portfolio

—

Rules & Policies

—