VOSibilities

I am very pleased to be able to post the first public screenshot of the Designer in our upcoming ActiveVOS 6.0 product. Click on the thumbnail above to see the image full size.

Those of you who knew us for ActiveBPEL, the world’s leading Business Process Execution Language (BPEL) engine, will be delighted to discover that BPEL remains at the core of ActiveVOS 6.0. All of our BPEL execution engine’s virtues — a superior visual design environment, rigorous adherence to the BPEL 2.0 specification, process versioning, the world’s first implementation of BPEL4People, remote testing and debugging, dynamic switching of endpoints on failure, clustering and failover — remain as you’ve known them. And there are some truly magical new enhancements, like support for POJO’s that turns old Java applications into web services with a few clicks of a mouse. Clearly, on the BPEL engine feature list, what few competitive lights there were in the rear view mirror grow far dimmer in ActiveVOS 6.0. (Message to Oracle BPEL Process Manager users: it’s about time to get to a real implementation of BPEL 2.0, don’t you think?)

But ActiveVOS is no longer just a BPEL engine. We are, truly, a VOS or visual orchestration system. BPEL is, in part, how we accomplish services-based applications. But it’s no longer what ActiveVOS is. Consider this partial list of new capabilities that will be included in ActiveVOS 6.0 and you’ll see why nothing else — not “open source” arrivistes like Inalio or the stack oligarchy of SAP, IBM and Oracle can compete.

• ActiveVOS 6.0 implements a spectacular Business Process Modeling Notation (BPMN) capability. Now, business analysts can design processes and transform them into executable BPEL at the click of a mouse. Wait until you see it. It’s just astonishing.
• ActiveVOS 6.0 contains a complete complex event processing engine (CEP). One of the things that our BPEL engine has always done is emit the events needed to produce CEP applications. But now, for the first time, these two capabilities are combined in a single product. That means developers never have to integrate things themselves…they simply take advantage of it. CEP in ActiveVOS 6.0 is specified at process deployment time, eliminating the need to code CEP into the process itself and making it easy to add CEP to deployed processes.
• Killer new reporting, BAM and BI capabilities. I don’t have screenshots from development for these yet, but these will not only win the eye-candy wars, [update: after they saw this post, guess what? I received a great screenshot of our new console] they’ll actually make it a snap for businesses to easily understand the overall state of the enterprise.

With these and other new features, we believe that the age of the visual orchestration system has begun. Now, when developers are considering how to do services-based applications, the choice couldn’t be more clear. You can do what the stack oligarchy wants: buy a bunch of indigestible piece parts and engineer the equivalent of a VOS in your shop before you can even hope to begin writing applications. Or, you can use the all-in-one, standards-based capabilities of ActiveVOS 6.0 and get done better and faster.

ActiveVOS 6.0 will be generally available in a few weeks.

Well, this is my first real “content” post and I am about to challenge no less than eminent industry notable and EDS Fellow Fred Cummins, who recently took the opportunity to declare BPEL4People dSOAoa (pronounced d-SEW-ah-oh-ah and meaning “Dead SOA on arrival”).

I am not sure if Fred’s problem core problem is with BPEL4People as much as it is with BPEL itself, which he dismisses as “for programmers.” But it’s clear he doesn’t think much of either standard, favoring instead BPMN. And I’ll be the first to admit that I am not the one who can specifically refute many of his technical arguments.

But I do know one thing: being “for programmers” when it comes to standards-based workflow ain’t a bad thing. That’s because from my relatively non-technical perspective, two things have always been true about workflow systems. First, the support for them in programming languages has been abominable and, second, every single end-user workflow system that has ever been tried has been a failure.

If the charge is “BPEL (and therefore BPEL4People) is a programming language,” then my counter-charge is that BPMN is about non-executable pretty pictures. Wikipedia says, “The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders…”

Pretty diagrams do not a business application make.

In short, workflow is something that has to be developed into an application, not “specified” by some end-user on a canvas. That’s because while you can expect a developer to be capable of understanding the workflow process and adapting it to the application, you can be certain an end-user won’t be able to integrate his or her expert-level knowledge of the business process into a database or transaction system.

One area I suspect Fred and I agree on, though, is the need for standards. Another reason workflow has been ineffective in business applications is that business are loathe to lock up their processes in proprietary formats. What BPEL4People and BPMN offer users is the opportunity to free themselves from proprietary workflow engines, which is surely a good thing.

This is a big moment for me…if not for you. This is the first post on our brand-spankin’ new blog. And I’m all excited about the possibilities.

I’ve been involved with a number of blogs for other companies over the last year or two. And I’ve discovered that a surprising number of people come back to read the first post. A first post therefore needs a little of the mixture of celebration and relief people feel when that new ocean liner actually launches when the woman (always a female for some reason) breaks the bottle of champagne over its bow. Or maybe it’s just me being traditional, but it seems all new blogs that are any good start with a bit of …ahem… manifesto.

So, herewith our objectives. We hope this blog will be informative and in the words of some people I recently worked with, cheeky. We already are showing a little cheek (sorry, it starts right away) by naming this blog "VOSibilities." The pun on visual orchestration systems and the word "possibilities" is courtesy of our own Victor Chan.

Let me say for the first time something we’ll be saying repeatedly: we believe strongly that visual orchestration systems will revolutionize the way project teams design, develop, test, deploy and maintain composite applications. We seek nothing less than mass adoption of services-based applications, all done in an open, standards-based way. So, VOS is the category, VOS is the means, VOS is the objective…VOS is the answer.

But it’s the answer to what, exactly? It’s the answer to app dev miasma. That big, dark, noxious cloud of proprietary this and that, the uncertainty of being able to leverage skills and the inability to effectively absorb technology in a way that makes developing composite applications not just fast and efficient, but fun.

And because good technology is always fun, we’re gonna have a lot of it here. We’re going to get loud, we’re going to get visceral and we’re going to say what we think.

So, if you found this post before there was anything else on the blog, thank you. If you are reading it to wonder who the heck these loudmouths are, thank you. If you are one of the competitors I intend to skewer regularly here, a special thank you. And remember…it’s all in the name of open, direct debate.

This is just the first of many times we’ll get to talk to each other.