Comprehensive heterogeneous service-oriented architecture (SOA) management is in a state not unlike the current status of the U.S. lunar exploration program. There is no program. Sure, NASA has all the technology and engineering expertise to send astronauts back to the moon, but it cannot at this point assemble them into an actual space vehicle that could go to the moon.
The same is true of comprehensive heterogeneous SOA management. The technology, some of it cutting edge, exists, but getting it to interoperate in any standard way remains a goal, perhaps even an unreachable star.
Dana Gardner, principal analyst at Interarbor Solutions LLC, notes that he has worked in business computing for 20 years and management standards have always been talked about, but like the weather, nothing gets done.
Gardner notes that the demands of SOA are making demands on management that did not exist in the pre-SOA era which he characterizes as requiring a more simple "red light, green light" approach that indicated that the server or the application was either running or it was not.
Jason Bloomberg, senior analyst with ZapThink LLC., explains how the management requirements for SOA escalated from even the early part of the decade when Web services management was still mostly about watching servers.
"Essentially, loose couplings are a management problem," Bloomberg said. "When you talk about loose couplings, you have service consumers and service providers which are pieces of software that interact in a SOA environment and they need to be controlled independently from each other. You have a service consumer, which is some piece of software, it could be a portal, it could be a business process tool, it could be any number of different things. It's going out and it's going to be discovering and binding to extracted services out on the network somewhere and for all this to work, to get this whole SOA vision to work, the services have to be able to meet the contract that's sent out for them.
"So, whether it's quality of service or reliability or availability, all of these capabilities the services have to have, they have to work properly. If the service consumer has to worry, 'Oh, well, maybe that service is up or down or maybe it's too busy today, maybe it's just not doing what's it's supposed to do,' then you no longer have loose coupling and your SOA doesn't work. So, it's core to making the SOA work. Loose coupling is sort of the core capability that service providers and consumers need to have in order to build the flexible architecture we talk about."
What is frustrating in the analysts view is that while the technology to manage this SOA complexity exist, it just isn't happening yet in anything like a comprehensive way.
"I think we have increasingly the ability to look deeply into the business processes that are running on our networks and make real-time decisions based on them," said Brad Shimmin, principal analyst for application infrastructure at Current Analysis LLC. "So there's no excuse. We should be able to do this."
That said, however, Shimmin recounts that he has been disappointed when he talks to platform vendors about the need to take SOA management to the next level.
"When you look at an SOA platform vendor and they say we do full SOA lifecycle management and governance, they are looking at the processes pretty well," Shimmin said. "They can do that across heterogeneous environments, but they really don't do a great job of tying what happens to those processes to the underlying systems that they run on. So when you try to talk about virtualization for application performance and you try to tie that to how a given process is running on your system and what it's designed to do and its thresholds. It just becomes a sort of 'that would be nice.' That's about all they can do right now."
It isn't as if there aren't any vendors doing cutting edge work in this area. Shimmin thinks IBM with its Tivoli and Rational technologies might be moving in the right direction. Bloomberg is impressed with a lesser-know vendor, Tidal Software Inc., which has acquired Intersperse with its SOA management tools. Intersperse started out focused on BEA WebLogic, but now works with IBM WebSphere, JBoss, SAP NetWeaver and even Microsoft .NET.
"So, they're able to instrument EJBs in all these different environments, or the .NET CLR, or the object in the NetWeaver environment," Bloomberg said. "They give you all this management capability in a heterogeneous environment whether or not you have an ESB or any particular integration in place, that's sort of irrelevant. If you have an ESB, they can manage that as well."
Regardless of the potential of these and other products from vendors ranging from Hewlett-Packard Corp. and Computer Associates Inc. to AmberPoint Inc. and SOA Software Inc., which the analysts say have potential, Gardner doesn't see that as the ultimate solution.
"It's a difficult question, like with a lot of things in SOA," Gardner said. "I don't think it's a question that can be solved by a product. It really is going to be a combination of people, process and machines and it's going to involve a lot more interoperability."
No matter how great the technology from the pure play vendors might be, without a standard agreement on interoperability, Gardner sees the SOA management products becoming a management headache.
"More important than a niche-by-niche approach is how these all work together," he said of the pure play vendor products. "The last thing that enterprises want is the necessity of managing dozens of management systems and that's what a lot of these management vendors are forcing them to do."
Despite the cutting edge technology, Gardner does not see it fitting yet into anything that would be comprehensive.
"There's a number of vendors that have both agent-based and agent-less," he said of the current state of SOA management technology. "There's predictability and real-time approaches, but none of them fit into a common fabric."
Asked when that common fabric might arrive on the scene, Gardner is not overly optimistic, because all of the current vendors are still angling for their product to be the only management product in an SOA implementation.
"The fact is the management system is so integral, everyone wants their management system to run the whole shebang," he explained. "It's a great place to be if you're a vendor. There's the competing interest of the vendors trying to get supremacy on the one part of the system that going to be the touch-point between the business and all the technology below the surface. They all want to be in the role of providing the steering wheel to the business and IT leadership, but at the same time, the interests of the enterprise are such that they are not going to be in the position to pick a single vendor. So they're stuck with a handful and in some cases many more than a handful of different management approaches."
Gardner foresees several possible scenarios where this might change in the future. It is possible that one vendor might come up with SOA management technology that is so superior to anything else that it emerges as a de facto standard. But it is more likely that the same competitive pressures currently driving vendors to try to be the one and only SOA management product in the shop will eventually force the market to compromise on interoperability if not a real standards-based approach.
"SOA is not going to progress if we have to manage dozens of management systems," Gardner said. "The enterprises themselves are the ones that are going to have to step up and say, 'We're interested in having differentiation but we're also interested in having standardization and interoperability in management.' Usually when there's enough demand and it's holding up sales of larger systems something gives. Eventually the problem is going to become unavoidable. And at some point SOA is going to be hobbled conceptually until the management and interoperability issues get resolved. We just haven't matured SOA sufficiently that that's happened. It could be anywhere from two years to five years before the pressure builds sufficiently to force a resolution around management standards and interoperability."