We're Running Out of Words II

It's interesting when you have a shared blog... sometimes coordinating posts with others so there is no talking over each other leads to no one posting. It's especially hard for me, as I'm a "mood poster" - meaning, I post when I'm in the mood. Fortunately, I'm usually in the mood to talk about something I profess to know something about, so there's no shortage of material.

Which of course, leads to a brief apology. I've been quiet lately, even though there is a ton of good stuff going on (not all of it in my head). I just find it hard to be creative when I'm busy, and it's been a busy few weeks (in-and-outside of Progress) for me. Probably will be for another three weeks or so... so to all my fans, my apologies!

Back in November, I jokingly titled a post that "We're Running Out of Words." Something you could, of course, never tell by how much I talk.

The idea is that we "overload" words with meaning and often don't even realize the assumptions we make (and more importantly, others hear) when we use overloaded words. The most overloaded word in our space (IMO) is discovery. Another, management.

When I first started at Actional, our mission was to educate the market. I started presentations with a slide that said "Web Services Management" -- what the market was calling our space at the time. I then went on to put big red X's through Web and Management. What we were doing had little to do with the associations that come up when people think "[World Wide] Web" or "Management." It was a challenge then, and it's a challenge now.

SOA What? Well, today, you should be asking "SOA Why Now?" - I mean, I talked about this back in November.

My brain works weird. I read Dana's post, Progress Software adds cross-process visibility with Actional 7.1, over at ZDNet, and one thing stuck in my head. Knowing that I haven't been around for a while, I thought I'd comment on how we've overloaded the phrase "Business Process" (and the associated "Business Process Management"), and as a result might be missing the really interesting point.

Let me share an customer situation: very large telco in the mid-east - actually an Oracle customer. It was about 20 months ago, so that gives you an idea of where Oracle's BPM solution was in terms of maturity. This customer needed visibility into their business processes. Oracle told them (as would most anyone out there, I'm singling out Oracle, but picking on everyone) if they wanted to track business processes, they needed to implement them in a BPM engine. Long story short, they took their existing processes and implemented them in Oracle BPM. It was hard to do... so they only implemented their most important processes. Once implemented, they realized they had only 1/12th of the performance they had before - all in exchange for knowing where a process fails and being able to track it from end-to-end.

So, let me summarize:

1. They reimplemented processes that were already working just fine. BPM offered no process-value-add.
2. They were limited to their most important processes because of the difficulty they had implementing their processes in a BPM engine.
3. They suffered performance and scalability in exchange for visibility; visibility that was limited to what was going through their BPM engine.

This is the key point that Dana, and I think everyone else, misses when they look at Actional. Processes don't need to be orchestrated to be managed. Ad-hoc processes can be managed just as easily as anything else. And, perhaps, that means in some cases (not nearly the majority - but some) BPM isn't needed. I'd argue that most processes are actually informal... and only become formal so they can be orchestrated and controlled. What if you could gain all the visibility and control you need, without the overhead of orchestration?

Instrumenting an SOA infrastructure with Progress® Actional® means they get all the visibility they need, into ALL their processes, whether those processes are orchestrated or not, without impacting performance or scalability, and they get it cross-platform and protocol:

• All the visibility they need; anything on the platform is automatically displayed and correlated across the entire infrastructure.
• All their processes; since there is no need to change code or re-implement a process that already works, every process (ad-hoc or orchestrated) can be tracked in real-time and, more importantly, in the business context in which it is executing [that telco I was telling you about had a provisioning service - we were able to track it for landline vs mobile separately with just a few configuration steps. Then, we enhanced tracking by separating mobile provisioning into pre-paid and post-paid just as easily, and without affecting performance].
• Without impacting performance or scalability; if Oracle slowed things down to 1/12 with just some processes orchestrated, then we can be said to have been more than 12x faster than Oracle!!! And, Actional has no single point of failure like a BPM engine (and many other service management solutions) does.
• Cross platform and protocol; Do I even need to explain this? Gosh, we have customers using TIBCO BusinessWorks alongside Sonic ESB, and exposing everything as web services over SOAP, and we can track everything end-to-end from the HTTP call to the portal, to the service, to the "bus", to the BPM engine, out to the database, and back - synchronously or asynchronously. A mouthful, I know, but cool nevertheless.

There's a reason Forrester ranked us #1. But, to know what they know, I need to ask you to listen to what we mean, at least until we can make new words.

By the way, if you want to see this end-to-end visibility yourself, apply to evaluate the solution. It won't include the business process "stuff" we do, but will give you an idea of how easy it is to discover and correlate across platforms and protocols.