Service Guarantees

There is plenty of current discussion about SOA, or Service Oriented Architecture. Besides the invevitable mention in nearly every conference proceeding (or perhaps because of it) HP recently spent $4.5 billion to acquire Mercury Interactive, a "business technology optimization provider" according to Forbes.

In the midst of this kind of hype, it is refreshing to find a quote like the following:

SOA seems like another invention intended to tame the software beast. It has a lot of superficial appeal  to high-level management, which is struggling to bring discipline, order, predictability, and direction to their jobs. But it's part of a long history of terms and fads that never quite did the job. In the end, only time-tested basics give you results.
--Consultant Jeffrey Travis Atwood from Talking Tech, Wall Street Journal, 7/25/06

While SOA has broad implications to software development strategies, I think the relevant word is service. Or as Atwood suggests, discipline, order, and predictability.

Providing a service requires:
    1. defining the functionality
    2. identifying development time and resources
    3. understanding service level guarantees for both availability and performance

Architecting and deploying a new software strategy based on SOA sounds to me like a lot of high-level planning, discussing, and implementing. This will inevitably include modifying existing or writing new software to meet changing requirements resulting in significant time and resource expenditures. A big part of the effort will require service level definitions for each application.

Alternatively, we could focus on an approach to service guarantees that spans multiple applications and software services without having to re-architect any systems or deploy new 3-letter acronyms. Tackling service issues with one fell swoop involves setting the underlying foundation in the data center to provide guaranteed response times, and closing the Server-Storage Performance Gap.