SOA Governance Technical Standard : SOA Governance Metrics Example

 

A common question about SOA governance monitoring is: “Should we be monitoring the efficacy of SOA governance or both SOA governance and the SOA journey itself?” Different people come out on opposite sides of this question, but the preponderance of opinion is that it makes sense for SOA governance monitoring to be considering both. After all, the purpose of SOA governance is to ensure quality of services, and without information about the holistic SOA journey, it will be difficult to properly adjust the corresponding SOA governance.

Examples of some metrics that might be used to measure the SOA are as follows:

METRIC

Percentage of Customer Service Representative (CSR) phone calls handled by automation (interactive voice response) increases by 5% each year

Definition

Percentage of CSR contacts handled without human intervention (automated handling)

Goal

5% automated handling increase by end of year allows increased CSR focus on revenue enhancement (estimated $12M increased revenue)

Sub-goal

8% increase for current customers

Sub-goal

2% increase for new customers

 

METRIC

Percentage of repairs that can be performed remotely

Definition

Percentage of repair requests that can be performed without a repairman by using remote and automated capabilities to resolve customer trouble tickets

Goal

25% automated remote repair by end of year ($39M savings)

Examples of some metrics that might be used to measure the SOA governance itself include:

METRIC

Percentage of development trouble tickets caused by inadequate design

Definition

Development trouble tickets are assigned a root cause with “inadequate design” being one of the root causes. To test the efficacy of the governance control point for quality service design, measure the percentage of all tickets caused by inadequate design.

Goal

After establishment of a six-month baseline, expect this percentage to continually decrease.

Vitality

Further analyze the causes of poor design and inadequate requirements. Make and implement changes to the governance control point for quality service design.

 

METRIC

Number of violations of architecture policies during the development process

Definition

The development process will have control points that will check adherence to the specific architecture policies that have been selected. In the review, the number of violations will be tracked.

Goal

After establishment of a six-month baseline, expect this percentage to continually decrease.

Vitality

Further analyze the causes of violation and decide whether the policies are inadequate or further training needs to take place to make the developers more conversant with them.

 

 

 

 

The Open Group
Platinum Members
HP IBM Oracle Philips