Service Orientated Architecture
I attended the PDC and listened to both the Indigo sessions and the Panel discussion at the end of the Architecture Symposium. I found it very interesting that the Panel had some difficulty in defining exactly what they meant be Service Orientated Architecture and why a new approach was required to complement Object Orientated design and analysis. The definition of a service seemed to a component that communicated with other components using messages.
Since I have been involved in outsourcing projects I thought I would look at it from another approach. When you offer to be a “service provider” for a company you agree to provide to the customer a set of “services”. For each of the services you agree a “Service Level Agreement” (SLA). The SLA defines the contract for the service: who provides the service, the guaranteed availability of the service, the escalation process and the penalties if the service level is not met. So here we have a defined service provider, a clearly defined service and a contract. But what do we mean by a service?
A good example of a service is email. The service level agreement would define that email is mission critical, must be available 99% of working year and that old emails must be archived for 5 years to meet regulatory requirements. But the email service consists of different components: e.g. the email server (Microsoft Exchange) software, the hardware where the email server runs and the process by which the email server is managed. In addition subsidiary services are required such as the backup, restore and disaster recovery services. These are often grouped together under the title business continuity.
It is clear that a service according to this definition has a defined provider and consists of an application, hardware and a process and that is regulated through a contract. This is where the service-orientated architecture differs from the object-orientated approach as the application or the set of applications are only one part of the defined service. Also there are service dependencies and those services may not be under be directly under your controlled but are regulated according to service level agreements.
However, experience has shown it is very difficult to write clear and unambiguous service level agreements.