SOA Governance: 'An Ongoing Committee Exercise'

There have been some recent announcements that highlight some of the directions that SOA (service oriented architecture) tools are taking, most of them devoted toward integration. However, some of the tools are also looking more at the development stage of how to create services and then join up services, perhaps in some sort of event processing.

It makes sense for architects and developers and even business analysts to start devoting logic of process to the ESB (enterprise service bus) and let the plumbing take care of itself, vis-à-vis standards and module connectors.

We've also seen the recent release of Fabric 7.0 from webMethods, which provides a virtualized ESB/SOA development environment with a strong business process modeling notation (BPMN) angle and a strong metadata infrastructure.

Recently, I sat down with a panel of analysts -- independent industry analyst Steve Garone, research consultant Joe McKendrick, Macehiter Ward-Dutton Research Director Neil Ward-Dutton, and Current Analysis Principal Analyst Jim Kobielus -- to discuss the current state of SOA integration and development.

Listen to the discussion (41:56 minutes).

Here are some excerpts:

On TIBCO & SOA Tools

Ward-Dutton: What TIBCO is doing with ActiveMatrix is shifting beyond its traditional integration focus and providing a rear container for the development and deployment of services, which is subtly different and not what TIBCO has historically done.

[This] extends to service bus in two ways. One is into the tooling, if you think about what Microsoft (Nasdaq: MSFT) is doing with Windows Communication Framework. From a developer perspective, they're abstracting a lot of the glop they need to tie code into an ESB, and TIBCO is trying to do something similar to that.

It's much more declarative. It's all about annotations and policies you attach to things, rather than code you have to write. On the other side, what was really surprising to me was that, if I understand it right, [TIBCO] are unlike a lot of the other ESB players. They are trying to natively support .NET, so they actually have a .NET container that you can write .NET components in and hook them into the service bus natively. I haven't really seen that from anywhere else, apart from Microsoft. Of course, they're .NET only. I think there's two ways in which they're moving beyond the basic ESB proposition.

It's much more of a development infrastructure focus than an integration infrastructure focus. That took me by surprise and it took me a while to understand what was happening, because I was so used to expecting TIBCO to talk about integration. What I started thinking about was, "What is the value of something like ActiveMatrix?" Because at first glance, ActiveMatrix appears to be something with JBI, a Java Business Integration implementation, basically a kind of standards-based plug-and-play ESB on steroids.

There are loads of tools around to help you take existing Java code, or whatever, right-click on it, and create SOAP and WSDL bindings, and so on. But there are other issues of quality, consistency of interface definitions, and use of schemas -- more leading-edge thinking around using policies, for example. This would involve using policies at design time, and then having those enforced in the runtime infrastructure to do things like manage security automatically and help to manage performance, availability and so on. It seems to me that this is the angle they're coming from, and I haven't seen very much of that from a lot of the other players in the area.

ESBs as Platforms

McKendrick: There's actually quite a raging debate out there about the definition of an ESB, first of all, and what the purpose of an ESB should be. For example, I quote Ann Thomas Manes ... She doesn't see ESB as a solution that a company should ultimately depend on or focus on as mediation. She does seem to lean toward the notion of an ESB on the development side as a platform-versus-mediation system. I've also been watching the work of Todd Biske; he is over at MomentumSI. Todd also questions whether ESBs can take on such multiple roles in the enterprise as an application platform versus a mediation platform. He questions whether you can divide it up that way and sell it to very two distinct markets and groups of professionals within the enterprise.

Kobielus: [ESB] came into use a few years back, popularized by Gartner (NYSE: IT) and, of course, by Progress Software as a grand unification acronym for a lot of legacy and new and emerging integration approaches. I step back and look at ESB as simply referring to a level backplane that virtualizes the various platform dependencies. It provides an extremely flexible integration fabric that can support any number of integration messaging patterns, and so forth. That said, looking at what TIBCO has actually done with ActiveMatrix Service Grid, it's very much to the virtualization side of what an ESB is all about, in the sense that you can take any integration logic that you want, develop it to any language, for any container, and then run it in this virtualized service grid.

One of the great things about the ActiveMatrix service grid is that TIBCO is saying you don't necessarily have to write it in a particular language like Java or C++, but rather you can compose it to the JBI and service component architecture specifications. Then, through the magic of ActiveMatrix service grid, it can get compiled down to the various implementation languages. It can then get automatically deployed out to be executed in a very flexible end-to-end ESB fabric provided by TIBCO. That's an exciting vision. I haven't seen it demonstrated, but from what they've explained, it's something that sounds like it's exactly what enterprises are looking for. It's a virtualized development environment. It's a virtualized integration environment. And really, it's a virtualized policy management environment for end-to-end ESB lifecycle governance. So, yeah, it is very much an approach for overcoming and taming the server complexity of an SOA in this level backplane. It sounds like it's the way to go.

webMethods Fabric 7.0

Fabric 7.0 is really like TIBCO with ActiveMatrix in many ways. It's a strong development story and it's a strong virtualization story. In the case of Fabric 7.0, you can develop complex end-to-end integration process logic in a high-level abstraction. In their case, they're implementing the BPMN specification and notation for business process modeling notation. Then you can, within their tooling, take that BPMN definition, compile it down to implementation languages like BPEL that can then get executed by the process containers or process logic containers within the Fabric 7.0 environment. It's a very virtualized ESB/SOA development environment with a strong BPMN angle to it and a very strong metadata infrastructure. WebMethods recently acquired Infravio, and so webMethods is very deep now both on the UDDI (Universal Description Discovery and Integration) registry side and providing the plumbing for a federated metadata infrastructure that's necessary for truly platform-agnostic ESB and SOA applications.

Garone: I think the hurdle that we'll need to get over here in terms of users taking a serious look at this is the confusion over what an ESB actually is and what it should be used for by customers. The vendors who talk to their customers about this are going to have to get over a perception hurdle that this is somewhat different. It makes things a lot easier and resolves a lot of those confusion points around ESBs. Therefore, it's something they should look at seriously, but in terms of the functionality and the technology behind it, it's the logical way to go.

Ward-Dutton: What's happening with IBM (NYSE: IBM) around SCA (Scalable Computing Architecture), and what TIBCO is doing around ActiveMatrix, and what webMethods is doing, have the capability for people with the right skills and the right organizational attributes. They have the ability to create this domain, where change can be made pretty rapidly and in a pretty manageable way. That's much more than just being about technology. It's actually an organizational, cultural process, an IT process, in terms of how we go about doing things. It's those issues, as well as a matter of buying something from TIBCO. Everything's bound up together.

Kobielus: This isn't getting any simpler. In fact, the whole SOA governance -- the development side of the governance process -- is just an ongoing committee exercise of the IT geeks and the business analyst geeks getting together regularly and fighting it out, defining and redefining these complex flow charts.

Click here for more podcasts.