Frankly speaking, I am a bit confused.
Gartner is saying that 75% of SOA projects are failing, whereas others (especially those who work on SOA projects) are claiming that they have delivered successful SOA projects.
What are we trying to do?
From previous articles you might remember that I am a believer in context: Are we using SOA for Application Integration? Are we writing new applications? Or is our goal to Integrate an Enterprise?
However, in this case the different contexts have a lot in common if it comes to quantifying and qualifying the success of SOA.
The following questions should help you to examine whether a SOA rollout is successful or not:
- How many Services are there in total (provider and canonical form)?
- Are there enough services to actually call it a SOA based solution?
- What was the total build time per service?
Maintaining the current speed, is it a good enough TTM? - How many of those services are re-used across Enterprise/Domain?
If the solutions are just departmental, why are you calling it ESB then and where is the benefit of re-usability gone? - Do Services exist in an original and canonical form?
If there is no canonical representation of a service you are tightly coupling domains and their systems. - How is the Service lifecycle governed?
IBM has found that SOA Governance is necessary for a successful project; you might want to stop and (re-)define your governance first. - Who owns those services and how is a change governed?
Who is paying for the services? And what happens if composite services have different SLAs in place? You will pay for the SLA upgrade? - Who owns orchestrated services which use services from different owners?
(see above) - How many versions per service are there?
Has version hell already begun to manifest itself? - How is transactionality handled across services (WS-AT, No Tx)?
Do scalability tests and find out whether the current approach is scalable enought – the sooner the better! - How is compensation handled? How complex is it?
Often compensation handling is more complex than the services itself. If that is the case you need to stop and ask whether the current SOA approach will be working for you in the future. - What do those services do? Execute functionality (Write) or query information (Read-only)?
Information/Query services are ok for representational gateways, not if they increase system inter-dependencies. If service calls change state, check out the point on scalability and transactions (above). - How is determined what the max usage load will be during peak?
You will need that to determine whether your approach is future proof. - How many service consumers are there per service?
If there are only 1 or 2 consumers per service, ask yourself Why? Are there too many versions, is it not re-usable or not mature enough yet?
If we get answers to above questions, then we have a pretty good understanding where the SOA rollout is at:
- Are there only 3 read-only services (too early to make a call)
- Do we have 10 different versions per service (version Hell is already on it’s way)
- There are no clear ownership boundaries and contracts in place (Governance issue)
- Etc.
Hope all is well!
Andy