10 Key Measures of SOA Successful SOA Implementation

• Financial

– Revenue per service (currency/service)
– Service vitality index (amount of revenue from new services over the last 12 months compared to all service revenue) (%)

• Management

– Number of new services generated and used as a percentage of total services (%)
– Mean time to Service Development (MTTSD) (time)
– Mean time to Service Change (MTTSC) (time)
– Service Availability (%)

•  Project

– Service reuse (%)
– Cost of not using or stopping a service (currency, time)

• Service

– Service complexity, as measured through cyclomatic complexity (unit-less)
– Service quality assurance confidence, derived through service code coverage (%)

Service Design Principles

As we all know SOA is an architectural style to building systems from autonomous services. So what are services? Services are software programs that interact with well defined messages over network.

Keeping these propositions in sight, SOA ecosystem robustness and architectural value is greatly influenced by how Services are designed as consumer and provider.

While designing a service one should consider following perspectives:

1. Provider perspective
2. Consumer perspective
3. Implementation perspective
4. Administration perspective

The design goal service should be similar to any software system. These are:

1. Loose coupling: Basic objective of SOA
2. Encapsulation: Basic objective of Object Orientation
3. Polymorphism: Basic objective of Object Orientation
4. Autonomy: Basic objective of SOA and distributed computing
5. Orthogonality: Basic objective concept of layered architecture and Object Orientation
6. Idempotency: Basic concept of distributed computing
7. Cohesion: Division of labour and specialization

So partial list of design and building principles of services:

1. Services should be designed for availability and stability.
a. Once services are deployed in production environment change in their availability & scalability is undesirable
b. Infrastructure support for service should be continually evaluated and updated to cater increased load and stress.
2. Service configurations are designed and built for change
a. With the passage of time and changing business needs, service configurations changes with respect to functional and non functional aspects.
b. Service’s deployment options with respect to physical location, policy, topology changes
3. Service invocations are subject to famous EIGHT fallacies of distributed computing.
4. Use Object based ( programming language - Java objects or XML documents à object/document may represent business event not actual business documents) operation/method parameters and return type
5. Keep service surface area minimum. The more operations/methods a service exposes the more difficult to manage them.
6. Avoid Service Hell
a. Service granularity must be managed. Too coarse grained service hinders re-usability. Too fine grained services create a jungle of services.
b. Service versioning should be managed
7. Adopt pessimistic view while designing a service (consider both views: Provider & Consumer)
a. Design and build services with extensive exception and error framework in foundation.
b. When service acts as provider validate one and all inputs
c. When service acts as consumer design for unreliable provider with respect to availability and performance
8. Services contract should be deployed & versioned independent of:
a. The system they are deployed
b. The inter implementation
9. Idempotency (Repeatability): Service must be idempotent with respect to one and multiple consumers.
10. Service nomenclature should be in sync with business not with development team. This especially true for business services.
11. Services must be stateless.
12. Services should have multiple interfaces either using ESB or without it.
13. Service should support patch like mechanism to facilitate upgrade.
14. Service operations/methods should be designed for concurrency.
15. Carefully decide (use both business and technical perspectives) which service should have compensatory service
16. Avoid transactions
17. To track state during long running service use track identifier at each milestone of process.

Inter Service Dependency Model

In any SOA ecosystem, there are bound to be numerous services. Some of the services in will be core services which will be used by most of the services. If this interdependency is not maintained, it may result in spaghettiof services. To have an ordered SOA architecture, one must rely on proven layered architecture which ensures robustness and independence of non adjacent layers.

To measure inter dependence of services, I have developed a simple but effective model, which I call Inter Service Dependency Model. This model is inspired by DSM (Design Structured Matrix.

In this model, services are viewed from provider and consumer perspective and emphasis is on maintaining layered based architecture principles in SOA ecosystem.



The matrix is divided into three distinct areas. The Solid BLACK region is the demarcation between RED and GREEN. One should fill value in GREEN and RED region cells to illustrate inter dependency of services. This dependency strength generically can be defined as



In a well designed SOA eco system following conditions should exist:

1. Matrix is populated only with Zero and Positive numbers
2. RED region is populated with Zero
3. Black region must not be populated ( pretty obvious)
4. GREEN region should be populated with positive numbers.

Above mentioned conditions still not address adjacent layer dependency only. To address that one should be able to figure out structure of GREENs and may also club services into layers.

Reference:

1. http://www.dsmweb.org/
2. http://ausweb.scu.edu.au/aw08/papers/edited/mehboob/paper.html
3. http://www.stsc.hill.af.mil/crosstalk/2005/11/0511SangalWaldman.html
4. http://www.lattix.com/technology/whatisdsm.php
5. http://en.wikipedia.org/wiki/Dependency_Structure_Matrix

Composite Services Complexity Measure

While evaluating a service complexity, I developed few of the measure. One of the measures is Complexity Measure which considers depth of service or we can say composition depth of service.

For this measure composite services were divided into four types:

1. Sequential Composite Services
2. Co-ordination Composite Services
3. Recursive Composite Services
4. Complex Composite Service



So Complexity Measure for:

Sequential Composite Service:

Composite Service Depth, CSD = Distance to the farthest service in sequence

Co-ordination Composite Service:

Composite Service Depth, CSD = Arm Count

Recursive Composite Service:

Composite Service Depth, CSD = (Optimistic recursion count + Pessimist recursion count)/2

Complex Composite Service:

Composite Service Depth, CSD = Sum of (Composite Service Depth in terms of Sequential, Recursion and Co-ordination manner)

For a good implementation CSD should not be more than 3 to 5. But in reality, most of the time consumer of a service is not aware of complete service tree.

Recursive composite service must be avoided.

As a good practice, each service should publish its CSD count.