Pure-play partnerships: helping light the way to BPM + SOA?
Enterprise Service Bus (ESB) players often talk about their ability to support
BPEL, and this is often mistaken for
BPM support. But BPEL is a misleading beast (as I've blogged about
previously). It's not a bad technology for helping IT folks with declarative specification of service-to-service integration processing, but it's not the same as BPM. This is often overlooked, and is where a good deal of the
confusion surrounding BPM stems from.
The gap between BPM and BPEL is one perspective from which
Cape Clear's recent
tie-up with
Appian - and
Sonic's earlier
tie-up with
Lombardi - are newsworthy.
BPM initiatives need to be supported by technology that can flexibly integrate existing application, system and information assets into executing process instances. BPM pure-plays like Appian and Lombardi are both frequently tested against larger platform vendors (think IBM, BEA, TIBCO, Software AG, Oracle, etc) and, when standing alone, their integration stories are less comprehensive than those of the big boys.
Conversely, many SOA initiatives are pursued in the context of business process integration and improvement initiatives, and ESB specialists like Sonic and Cape Clear are frequently tested against the larger platform vendors, which on paper can offer more sophisticated support for runtime management of business processes. They certainly have more engineering and marketing resources.
So figuring out that partnerships between BPM specialists and ESB specialists are sensible is hardly rocket science. There are plenty of organisations out there which (for whatever reason) don't want to spend too much money with the big platform vendors, preferring instead to work with specialist suppliers.
What's more intriguing to me is how the separation of technologies forced by these partnerships can actually encourage good practice in "BPM + SOA".
It's often the case, where BPM and SOA tools are presented as part of broad tool suites, that separating business-focused process models from more technical models and service integration models is not encouraged in any meaningful way. Unless you work hard to keep these different models separate, over time artifacts which by rights should remain separate end up bleeding across models and it becomes harder and harder for different teams and stakeholders to remain actively involved in the programme, using tools and models that make sense to them.
By separating business-focused BPM modelling tooling from BPEL tooling and ESB configuration tooling, but still making it easy to link and reference where necessary between models and tools, these partnerships may well help to enforce good practice. It'll be really interesting to see how these partnerships develop, and whether the participants can make 1+1 = 2 (or more). If they can, then I agree with
Sandy: these partnerships have the potential to create market-leading positions.
[Another interesting angle, IMHO, to the Appian-Cape Clear tie-up that's not really been picked up is that both companies are active in the area of SaaS. Cape Clear is doing quite a lot of work enabling integration of SaaS and on-premise capabilities for customers; Appian has a SaaS implementation of its technology called Appian Anywhere.]
Labels: Appian, BPEL, BPM, Cape Clear, ESB, Lombardi, sonic
First MWD FM SOA interview: David Clarke, Cape Clear
We interviewed David yesterday and asked him our
standard SOA vendor questions. Considering it was the first interview, we think it went OK...
There were a couple of interesting things to come out of the interview:
- Cape Clear markets itself as an ESB vendor, but its view of what is "in" an ESB is much broader than that of most other vendors - David in particular calls out BPEL-based service orchestration
- the sweet spot for the company is really a "mainstream", "mid-market" company which may not have much in the way of deep in-house web services or SOA technology skills
- the company is currently working quite a lot in software-as-a-service (SaaS) and other commercial service delivery scenarios - helping companies in the digital service delivery business create more sophisticated and valuable services
- David also specifically calls out the need for potential SOA "customers" to make clear distinctions between management of SOA-related technology, and management of the automated processes supported by that technology. These are two separate problems with different solution needs, and they should be evaluated as such
- it's pretty obvious from the conversation, we think, that Cape Clear is very firmly a technology company selling its capability as a standards-based middleware solution to integration problems. This makes it quite different from many of the other SOA players, which position themselves almost as business change agents.
The interview lasts 32'55". The audio file containing the interview with David Clarke is
here - or alternatively you can
subscribe to the podcast feed.
Labels: Cape Clear, MWD, podcast, SOA
