Service Level Agreements: The Chicken and The Egg
Service Level Agreements, or service contracts, have been a hotly contested item in the SOA world. Generally, the business needs drive the creation of service level agreements. While I do understand that business drivers and the business analysts should drive technology, in the world of SOA there are many reasons pushing the direct opposite.
Many unknown factors in a SOA environment can ruin an SLA in a heartbeat. These factors might include network, system, application server and database failures. SOA applications are not always transparent, meaning the interdependency and relationships across many different systems and networks might hide from business analysts the true service scope. A composite service, or chain of services, might look to the business analyst as a single request/response transaction-giving him or her a false sense of security.
Do the business analysts really understand the technology underneath well enough to create performance metrics that bind their organizations financially and legally? From experience, I would tend to say no. If I was a business analyst, (and this is pulling directly from my Type A, INTJ and Engineering background) I would want to have the performance of metrics known over a period of time before I created an SLA.
This means I would want to set up my services, evaluate them over a period of time, and then base my Service Level Agreements on those proven and evaluated metrics. I guess it requires an opposite way of thinking-hence the chicken and the egg in the title.
Testing and evaluating these metrics beforehand will actually allow service developers and business analysts to play out what-ifs with regard to increasing scalability and performance of the services in question.
When business analysts go back to their customers to say, for example, “We can offer you a response time of 50 ms for this service for $10,000 per month; or we can offer you a response time of 25 ms for this service for $15,000 per month.”-the business analyst walks in to that meeting knowing what their organization is capable of doing. Talk about a strong position!
While I am not saying that the normal way SLAs are created is done incorrectly, I do strongly believe that business analysts and service developers can create a synergistic way of developing SLAs. From this perspective, the egg can come before the chicken.