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
I seriously doubt if there are any successful SOA projects. There are certainly projects that have built new software and have built it out of services, but that is just modular software. For instance, to build the middle office of a brokerage you pretty much have to divide the problem into an interface to the front office, a transaction manager (to manage the state of the orders), a broker for the messages, a position keeper, a risk manager, a transaction execution capability (possibly for each exchange you might trade on) and an interface to the back office. If you call that SOA fine, but the solution has very few of the characteristics people claim for SOA. There is no stateful broker, there are no interpreted workflows, there is no service composition and everything is run asynchronously and autonomously using events.
At the heart of the misunderstanding is the idea that a transaction can call out to another service to complete its work. This, in one stroke, destroys latency, reliability and throughput. It can also destroy transactionality if the call out makes a state change.
John