Analysis: On SOA & BPM: Q&A With Systinet's Tom EricksonAnalysis: On SOA & BPM: Q&A With Systinet's Tom Erickson

With the likes of IBM, SAP Oracle and BEA embracing more of the integration and process management stack, where do standalone service-oriented architecture (SOA) and business process management (BPM) vendors fit in? Systinet president Tom Erickson offers the seasoned views of an executive who previously served as executive vice president at webMethods and in executive positions at Baan and FileNet. Now a division of Mercury Interactive, Systinet has the industry's leading services registry. With the January release of Systinet 2, the company offers what it bills as "a complete SOA governance and lifecycle management platform."

Intelligent Enterprise (IE): Just what is SOA governance and lifecycle management?

Tom Erickson (TE): Governance is one part of the lifecycle, testing is another, monitoring and managing is another important part of the lifecycle. That combines well with the platforms that the BEAs, Oracles, SAPs and IBMs are delivering, which are all focused around building core pieces, from assembling services to the business process management that oversees those services, to ensuring during the run time that they're working as planned.

IE: The platform vendors want to do it all, don't they?

TE: You have to consider that both BEA and Oracle use our products, but, yes, they want to do it all. If you look at BEA AquaLogic as an example, how are they going to accomplish [services] testing? That's not something that BEA does, but it is something that Mercury does. How are they going to accomplish governance? At least in the core governance pieces, the registry and repository, that's something that BEA OEMs from Mercury. How are they going to do performance analysis of the services? That's also an area where AquaLogic uses a Mercury performance-testing component.

IE: From the technology buyer's perspective, do they really know or care whether bits and pieces are OEMed from other vendors?

TE: It is absolutely imperative for the platform vendors to illustrate to their customers that they provide as complete a solution as possible so they don't have holes that competitors can exploit. That said, we've taken the same approach used by Veritas, which provides light backup and recovery tools to OEMs such as Sun and HP. If you buy Oracle Fusion, for example, you get a light version of our registry. There a number of other capabilities that you're going to want to have as you get into more sophisticated SOA initiatives.

IE: Such as?

TE: Such as defining and managing services policies. Such as managing the registration and relationship between consumer and producer services. Such as storing all of your artifacts, including WSDLs and schemas, in a repository as opposed to just having them pointed at through the registry.

IE: Won't the platform vendors add that deeper functionality?

TE: If you just go back to BEA and WebLogic, there have been a whole periphery of businesses that BEA never got into around testing and monitoring Java applets. You used Mercury or HP's Open View. SOA is no different than that. SOAs are inherently heterogeneous. That means .Net, WebSphere, WebLogic, Fusion all mixed in one enterprise. The vast majority of large organizations don't see themselves using a platform from one vendor to try to provide governance over everything. An independent player like Mercury can build an SOA testing and monitoring business across those various platforms.

IE: Where does the enterprise service bus (ESB) fit in?

TE: We don't do ESBs, but we partner with them. The stack starts with base components including legacy apps or packaged apps such as SAP. The first layer you create to get to business services is some kind of transformation. If you want to expose SAP, for instance, as a series of business services, you have to use some kind of tool to do that. You can do that with ESBs, enterprise application integration (EAI) tools, enterprise information integration (EII) technology or you can do it using [SAP's] NetWeaver, which is really a form of ESB. The ESB lets you bridge an app or a series of apps and expose them individually or collectively as business services. This layer is then orchestrated at the next layer using BPM, which is where you create composite apps. Above that is the presentation layer, where you use a portal tool of some sort.

You can create a static composite app using the stack I just described, but the minute you want to change something, then life gets chaotic, and that's where governance and testing tools come in. You use testing tools because you're going to change things many times. You need governance tools because you're going to change and reuse services many times and in many versions.

IE: And how does BPM fit in?

TE: BPM is a fundamental part of the stack. When we introduced BPM tools at webMethods, a number of customers wanted to build the integration stack from the BPM layer down. They found that they couldn't do it because the plumbing underneath didn't exactly work that way. The business process layer only connects things. It doesn't make or facilitate what's underneath. Those customers concluded that they had to do both the BPM layer down and the integration points and logic up from the bottom of the stack where they're piecing together services.

The most productive and successful projects did these things simultaneously. As long as IT uses an SOA approach, which is loosely coupled, they can pull these two worlds together better than they could with EAI, which was tightly coupled.

IE: So I guess you'd view the companies that are blending SOA and BPM as having an edge?

TE: They're in a much better position than a standalone BPM vendor or an integration vendor that hasn't focused on BPM. The Fuego acquisition filled a huge hole for BEA, and they knew they needed to fill that hole even before they announced AquaLogic. I think any ESB vendor has to have BPM attached, and I think they have to own it. In contrast, the governance side addresses things that are broader than building composite apps or a series of composite apps. It deals with the heterogeneity you encounter in any large company.