Once upon a time, maintaining service levels was a simple yet difficult matter. At least you knew who was responsible for tuning databases, monitoring infrastructure, and safeguarding access control. The hard part of course was getting everything working as promised.

Service-related issues have been traditionally been dealt with piecemeal, at the perimeter, data center, and inside application and database silos. Even after web applications exposed databases to the outside world, the action that mattered was confined (1) to the application inside the firewall, as the domain of security specialists or DBAs, or (2) out there in the cloud, where it was the service provider's problem.

You had, in effect, a barrier between the circulatory and nervous systems where interaction, and responsibility for it, was carefully proscribed.

Life isn't as simple anymore. With services eroding the silos demarcating internal applications from one another, not to mention the outside world, it's growing difficult to delineate where the system admin's responsibility leaves off and the software developer or process owner kicks in. In a Services-Oriented Architecture (SOA), key aspects of business logic are often intertwined with service level.

Consider an order fulfillment process. The customer's procurement system triggers a series of events, culminating in a requirement to receive confirmation from you, the supplier. In so doing, the customer system fires a request to your order processing system, which in turn triggers an orchestrated process involving inventory checks, approval workflows (where warranted), queries to logistics providers, followed by final
acknowledgment. When you guarantee a platinum-level partner or customer priority service, you are implicitly promising that your infrastructure will deliver at a specified performance level.

In such a scenario, who's responsible for ensuring that the request is genuine, comes from an approved customer or partner, and requires response within a given timeframe?

We'll understand if you're drawing a blank.

When silos of functionality break down, so does division of labor. System admins, charged with infrastructure health and perimeter protection, are over their head when considering the subtleties of contractual service guarantees. Likewise, the software and process folks are understandably edgy when it comes to banking on infrastructure issues outside their control.

Not surprisingly, the market for governance solutions reflects the current organizational disconnect. Systems management providers like BMC, CA, HP and IBM are accustomed to calling on systems admins or operations, while SOA run-time governance upstarts like Actional (now part of Sonic), AmberPoint, and SOA Software speak to software shops.

There's been a bit of consolidation. HP's acquisition of Talking Blocks a couple years back and IBM's more recent acquisition of Cyanea, provide hints that the artificial boundaries between infrastructure and service management markets may eventually dissolve.

But that won't happen before customer organizations overcome cultural inertia.

When you first deploy a handful of services in an SOA pilot, you can readily babysit them yourself. When you ramp up to dozen services or more, you need a mechanism to enforce policy at run time. And once you really get serious about SOA deployment, that's when you need better-coupled infrastructure management.

Nope, you won't want to breach the blood-brain barrier outright because your perimeter must remain sacrosanct. But you'll need some way to improve circulation.

Tony Baer is principal of onStrategies and a well-published IT analyst with over 15 years background studying implementation issues in enterprise systems, application development, data management, and business intelligence. The author of books covering .NET and J2EE, Baer's writings also appear in Application Development Trends, Computerworld, Computergram, and Manufacturing Business Technology. Baer's commentaries and rants on the state of the IT market are available here.