Businesses aren't machines, and enterprise architecture can't make them so
Via
Service Oriented Enterprise, I recently picked up an
Infoworld blog post by SOA journeyman David Linthicum, where he makes a couple of very strange points about SOA and ESBs. It may be, of course, that the post is pure
link bait: certainly, David appears to have said some relatively sane things in the past, so that might be it. If it is link bait, I'm going to fall for it now.
In his piece David quotes a representative from
iTKO, who repeats the now well-understood insight that in some large organisations, there's a challenge that arises because different groups with SOA initiatives find themselves having to integrate different ESBs in order to pull together implementations for cross-silo scenarios. He then goes on to comment (I?ve taken the liberty of extracting elements of his piece below):
First, if there is indeed 'enterprise architecture' and an 'enterprise architect' then the different divisions should not be using different ESBs, or even an ESB for that matter... Second, considering that my first point is correct (which it is), why the heck are you attempting to integrate these integration engines when they should perhaps be displaced altogether. Because, call me crazy again, that would be cheaper... just to be clear, you determine your requirements, and then the solutions patterns, and then the technology.
The most charitable explanation I can come up with for David's position is that he believes passionately in the transformational power of enterprise architecture. The problem with this perspective is that even where EA is highly effective (and in many places it isn't), it can at best only be one of many forces shaping the way that IT evolves to support changing business conditions and requirements, and each force has its own vector. Some forces, like a good EA team, try and combine business and technology focus, and promote the value of global optimisations, good practice and standardisation. But most of the most powerful forces are business forces, and in 99.99% of organisations, their power, when something really big and important happens, will trump any righteous splutterings emanating from IT departments.
As any experienced IT staffer who's been on the sharp end of a big business merger or acquisition, or even a radical change of leadership, will tell you, businesses don't act like machines that EAs can simply steer so that they tend towards technology optimisation. In fact, it's the opposite: business change forces (new competitors, new product launches, new market launches, new regulations, mergers and acquisitions, and so on) will always drive entropy, tending to push IT estates towards chaos. The best value an EA team can really provide in this environment is to help the IT organisation to absorb these changes with as little stress as possible, and drive consistent, planned responses.
Still, there's always been a vocal (and quite often technically brilliant) part of the IT industry that seems to misunderstand this, and persists in maintaining that once people see beautiful models, they'll modify their behaviour to enable the models to be made real. They see businesses as deterministic machines that can be algorithmically decomposed, analysed, predicted, and shaped. I can only think that David is one of these people.
Unfortunately, no matter how clever your EA team might be, no amount of architecture astronautics can make businesses change their nature.
Labels: EA, ESB, inside-out IT, SOA
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
