Let's Call LiveCycle ES What It Really Is

May 23, 2008 · 3 Comments

The more I get into looking at what LiveCycle can really do, I start to understand the concept of what it is: An Enterprise Service Bus (ESB).

One of the problems with LiveCycle, right now, is that it has a bit of an identity crisis. Nobody can definitively tell you what LiveCycles is and what all it does. Look closer, for yourself, and you will start to realize that LiveCycle ES is an ESB. If Adobe were to change the name to LiveCycle ESB, a lot more people would be able to easily recognize what it is and maybe even jump on board. LiveCycle is really a powerful set of tools, it just needs to get over its identity crisis. Once it does, I think you will see a much wider adoption of LiveCycle beyond Data Services.

Let's Call LiveCycle ES What It Really Is

Tags: LiveCycle ES · Flex · General · BlazeDS · Adobe

3 responses so far ↓

1 Eric Geddes // May 23, 2008 at 5:43 PM

You are absolutely correct. I had the opportunity to see the entire package working together during a private demo by one of the developers. Staggeringly wonderful and powerful. Certainly, tremendously expensive, but clearly worth every penny. And yes, it certainly is an ESB and would seem to be more than capable of functioning as such in a document/form-centric environment. And you're right. Nobody knows what the hell it is and what it does (or more importantly, what it can do "for me"). I read through everything I could find, and eventually had to corner someone at a conference to get a definitive answer (and even that was challenging). It forms the basis of a robust BPM/SOA architecture with significant and noteworthy document/form services out of the box, as well as the tools to construct marvelous and robust workflows from start to finish. For better or worse, the product information contains a lot of buzzwords, but few of the ones that _I_ would use, or recognize... more to the point, there is little of the language that would help the reader to classify it and accordingly consider it for integration into an existing architecture. Humbling. Impressive. Breathtaking. I feel as though I caught a glimpse of the future when I learned what it can do (and how), and I like it.
2 Kevin Hoyt // May 24, 2008 at 12:13 AM

Although there are vendors in the ESB space that would laugh at LCES as an ESB (usually for random buzzword/checklist missing features), I have to say that I couldn't agree more with you. Let's call an ESB an ESB (wink).
3 Rob Brooks-Bilson // May 31, 2008 at 8:47 PM

I have to disagree with you guys here. I see LiveCycle ES as more akin to a BPM solution (many of which ride on top of various ESBs). It certainly has some overlap with traditional ESBs, but it my opinion, it is missing key differentiators that most ESBs have (such as distributed processing via light weight containers - extremely important when you are processing tens of millions of transactions). If anything, livecycle is more like a broker than an ESB. @Eric, LiveCycle is geared specifically at form and UI centric processes, which is a bit more specific than where the ESB fits (for example, I don't see LiveCycle as an optimal solution for system to system integration - a space where an ESB is well suited). Most analysts (out there squarely place LC ES in the BPM for human centric processes category and don't list it with ESBs because that's where it fits best. I'm not saying that LiveCycle ES couldn't evolve to include a full blown ESB as part of its stack, but I think that the strategy they seem to have at the moment (service enabling all LC functionality) is a better approach. We're currently looking at LC ES as part of our overall SOA, but it has a specific purpose (for us), which is document centric processes. LC ES will play nicely with the SOA infrastructure we already have, including our existing ESB, registry, and repository.

Andrew Powell

Into The Mind of A Solutions Architect