All too often, when I come across one of Todd Biske’s writings, my conclusion is, “Why didn’t I ever think of that?” As a former colleague on the weekly BriefingsDirect podcasts, you could always count on Biske to come up with common sense insights that were so basic that they never occurred to you. In his latest post, The Future of ESBs, he reiterates a conclusion he came to some time ago, that “the capabilities associated with the [ESB] space really belong in the hands of operations rather than the hands of developers.” That’s because when you eliminate all the extraneous embellishments of the definition of what ESBs are, at the end of the day, they are all about connecting services. Nothing more, nothing less. He adds that when you really compare costs (and we presume, benefits) of ESBs, it should be with that of other network intermediaries, such as switches, load balancers, and proxying appliances – rather than the software-based offerings of middleware providers who dominate the ESB market.
The dilemma of course is that the network folks have had difficulty navigating up the stack. Recall Cisco’s Application-Oriented Networking (AON), where routers were supposed to get a lot smarter about prioritizing SAP traffic? The notion of attaining telco-like Five 9’s availability and service levels out of the basic plumbing of service, process, or (forbid the thought) application-level integration has long been a holy grail. Haven’t heard much from Cisco about AON lately.
The problem is mindset, not technology. Network admins are used to thinking at packet level; the software folks are used to thinking in terms of components, services, or application modules; while the business folks wonder why they can’t get their reports on time or why there’s so much latency when they attempt a supply chain optimization. The dilemma gets compounded when we start talking run time governance of SOA, a situation we were reminded of last week when Tibco announced addition of Service Level Performance Manager to their ActiveMatrix SOA management stack. Obviously, when gauging whether service contracts are fulfilled, you need the ability at the level of named service to see if it is available and whether latency is within what’s called for in the service contract. The problem is that, while software development factors like how a service is designed and whether the SOAP headers and XML schemas are properly formed will impact performance, at some point, when demand for a service spikes, you’ve got to start provisioning underlying infrastructure.
As we’ve written previously, there’s still a disconnect between SOA run time governance and underlying infrastructure management that for now is handled through email or SneakerNet. At the technology level, nobody is yet talking about how service level management issues identified by tools from folks like Tibco or AmberPoint are going to automatically generate trouble tickets in Remedy or Peregrine. At the mindset level, nobody is yet talking about mapping SOA run time governance to ITIL processes.
Until we do, the goal of conceiving service connectivity, performance, and SLA management will remain a tale of two IT silos.