There seems to be a general feeling that SOA services will somehow just exist out there in a cloud. The nitty gritty of their implementation, of who is actually responsible for them and how they are managed is hidden behind the service interface and the consumer doesn't have to worry about it.
If you had that point of view and you'd been using Amazon's S3 services you would have been hit when the S3 service went down last week. If you boil down Amazon's explanation to it's essence it seems that the number of "consumers" increased unexpectedly and overloaded the security system. Now Amazon's up-time statistics are maybe very good, but systems still go down.
Now say that you're implementing a SOA in your company. The services provided are going to be mission critical (just like your applications are). But one day, they will go down. And when they do you better make sure that you know who is responsible for them, what the implementation is so that you can fix things and that the management is so set up that the right people are brought to the problem as soon as possible (and while you're at make sure that you've defined the SLAs for the services, governance processes are in place to ensure that usage profiles are known in advance and that the services are monitored so that you can spot possible problems before they become serious).
1 comment:
I agree - people seem to forget that a service revolves around the 'Service Contract' which is more than just the WSDL.
e.g. as with any contract, you need to ensure you have the technical and people resources available to meet any SLAs (that should be defined in the Service Contract). In a multi-sourcing world, this can be particularly painful as you are likely to have many organisations that need to be involved to return a particular service back to action.
Post a Comment