Bruce Silver, well known BPM analyst, has a new blog. Right now, it's mostly some entries that he originally posted on IT Redux, but I missed some of them the first time around, so it was good reading. Of note, he posts a followup to his post about the BEA/Fuego merger in which he responds to my rebuttal. In quick response to a technical question he raises: yes, AquaLogicBPM is a native BPEL engine. It can execute BPEL natively without requiring any conversation back and forth to any other format.

I also found his response to Edwin Khodabakchian, from Oracle, interesting. (By the way, as an example of how small the world is, I knew Edwin back when he was the manager for Netscape's Process Manager product.) I think it's another example of how far the BPEL standard has to go before it's really a good standard for business process. As I said before, I have great hopes for BPEL. It's the best hope we have for a portable standard for service orchestration. But right now, I worry that people have unrealistic expectations.

Just this week I had a line of business analyst asking me about about AquaLogicBPM's BPEL support. After I demo'ed AquaLogic Studio's BPEL functionality they started asking me "what about roles", "what about global activities", "what about people" and I had to explain to the the big long story about BPEL4WS 1.1, WS-BPEL 2.0, and BPEL4People. Their response was basically, "I can't believe that IT told us that BPEL was the solution we were looking for. We're primarily interested in human to human modeling." It was a classic example of using the wrong tool for the wrong job because of "management by magazine".

Posted by davidogren in BPM | Permalink | Comments (1) | TrackBacks (0)

Continuing my "SOA versus" theme, I really enjoyed Daryl Plummer's "Web Services At A Crossroads" article in Optimize magazine. In the article Daryl, a Gartner fellow, describes the conflict between the enterprise architects that are using web services as the platform for Service Oriented Architecture and the Web 2.0 architects that are using web services to build mash-ups, AJAX, and other consumer oriented applications.

One of the points that Daryl specifically mentions is how the desire by SOA architects to use web services for enterprise applications is driving the increasing complexity of the WS-* set of standards. He suggests that if you are looking for a enterprise-level distributed-transaction environment you should look to a real distributed transaction system rather than waiting for the WS-* standards needed to support that level of functionality.

I can't be the first one to see the parallel to EJBs in the Java world. When EJBs were added to Java they were designed to support this enteprise level of functionality. And as a result there was a lot of complexity in using EJBs. The problem with EJBs was that only a very small percentage of applications actually needed this enterprise functionality. And so, EJBs developed a very bad reputation as overly complex. And an entire movement demanding a more simplistic model emerged and the EJB model is now struggling to complete with more simplistic POJO-based systems.

I see the same thing happening in the Web Services world. The WS-* crowd is trying to meet the needs of enterprise SOA architects, but they are alienating the mainstream web services developers with their complexity. Not to mention the bickering that's going on in the standards bodies which scares people aware by making them worry about which standards will "win". One of the things that I like about ESBs is that they can encapsulate some of this complexity. The bus can abstract out some of the complexity and the services can just be services.

Let's learn from the past for once. Let's not let web services be another EJB debacle or compatability challenged CORBA. Let simplicity rule the standards and let the infrastructure manage the complexity.

Afterword: After typing this up, I see that Elizabeth Book commented on this article a couple of weeks ago. Not sure how I missed her post, but better late than never.

Posted by davidogren in SOA | Permalink | Comments (0) | TrackBacks (0)

A question that I've been answering frequently recently is, "What is the relationship between BPM and SOA?". Of course, there is no single answer to this question because no two people can agree on an exact definition of either BPM or SOA.

But fundamentally, I believe that BPM and SOA are two sides of the same coin. From a business perspective, both are about providing more flexibility and control to the business, increasing agility and time to market, and allowing different business units within the enterprise to work together. From IT perspective, both are about building and orchestrating composite applications, enabling re-use of existing services and systems, and using open standards.

The difference, fundamentally, is the direction at which SOA and BPM approach the problem. BPM starts with a business process and develops a solution from top down. SOA starts of an existing catalog of services and builds up. As a result, BPM projects tends to be tactical and SOA projects tends to be strategic.

A BPM project will typically start with a process that needs to be implemented or optimized. After modeling and simulation, integration will be put in place to meet the particular needs of that process and the process deployed as a composite application that orchestrates all of the needed pieces. In other words, integration will be done on an "as needed" basis where only the functions needed for that process will be integrated. A SOA project, in contrast, will take a more forward looking approach. The services developed in a SOA project are designed for long term re-use and may not have an immediate short term need. Integration to back end systems will be designed not based on the needs of a specific project, but for long-term re-usability.

There are exceptions, of course. There certainly are companies with long-term strategic visions for BPM, with a well organized catalog of re-usable business processes that are leveraged across the enterprise. (I am seeing this scerario much more frequently as BPM matures.) Similarly, many companies use a short-term tactical project as a way to test the waters of SOA and order to get a more concrete return of their investment in SOA. But the more strategic a BPM project, the more it will be intertwined with a company's SOA strategy.

Posted by davidogren in BPM | Permalink | Comments (2) | TrackBacks (0)

Speaking of GTD, I've recently implemented a GTD system on my laptop using AquaLogicBPM. Yes, I'm using enterprise software designed for multi-user, complex processes that span multiple systems and organizations as a simple single-user tickler system. This is pretty much the definition of overkill.

But I've got all of this infrastructure running on my laptop anyway in order to demo to clients. And BPM suites certainly are good at managing workitems, lists, and deadlines. I even took advantage of some of the system integration: I can add an action to my GTD system just by forwarding an email. (My GTD system will periodically poll the mailbox and automatically create an properly categorized item with the original email as an attachment.)

Posted by davidogren in GTD | Permalink | Comments (0) | TrackBacks (0)

Merlin Mann's 43 Folders website has been running a series of articles recently called Inbox Zero. If you use email at work, which is probably everyone reading this, you should read these articles. My current favorites are 5 Sneaky Email Cheats, and Delete, Delete, Delete.

This acquisition has meant that that we are getting invited to lots of opportunities we never would have reached as an independent company. Which has meant an overwhelming amount of work for me. I don't know how I could keep up without using GTD.

Posted by davidogren in GTD | Permalink | Comments (0) | TrackBacks (0)

In a recent article, Bruce Silver asserts that "The world of BPMS is divided into BPEL-lovers and BPEL-haters". I certainly understand what he means. It seems that the BPM community is splitting on whether BPEL can be saved. On one side, the purists know that BPEL is the best chance for a standard that will be portable across vendors. On the other side, the vendors know that there will be a huge chasm to cross between BPEL4WS 1.1 and WS-BPEL 2.0, and that even WS-BPEL 2.0 is only a tiny subset of what a BPM vendor needs to include in their product. Frankly, I believe that it's largely a moot issue. BPEL support is a technical implementation detail in an technology solution that is supposed to be aimed at business users.

As such, I guess you'd have to classify me as a BPEL-hater. BPEL is woefully inadequate for modeling real life BPM applications. This has been validated by both the marketplace, with rampant vendor extensions, as well as the standards body, who have shaped BPEL 2.0 to be very different and very incompatible with BPEL 1.1. Meanwhile the specification is so loose that real portability between vendors isn't possible anyway. Bruce himself has written about the huge problems that remain for the standard in his article about BPEL4People.

But I hate to characterize myself this way. BPEL is our best hope as an industry for standards based solutions. I really want to love BPEL. But BPEL doesn't even have the concept of roles or human activities. Until BPEL vastly improves, BPEL is only one tiny, tiny piece of BPM.

Since Bruce clearly understands the good, bad, and ugly about BPEL, I was very surprised to read his comments about the the Fuego/BEA merger. In part, he writes:

"FuegoBPM appears to have already morphed lock, stock, and barrel into BEA’s AquaLogic BPMS. Not that FuegoBPM isn’t a fine BPMS, but it’s not based on BPEL wasn’t BEA a “founder” of that standard? ... For example, process activities in Fuego are not SOAP calls to remote services, but user-defined “methods” of the activity implementation written using Fuego’s VB-like FBL script. Architecturally, that puts it closer to a workflow engine than to a BPEL engine. . .

Companies like IBM, Oracle, and Intalio have shown that you can build a complete BPMS with human workflow, business rules, BAM, and the rest on top of a unified service orchestration stack, so why would BEA want to go back to the old dual architecture approach workflow for the end-to-end process and BPEL just for system-to-system integration? That makes sense for a pureplay like Fuego, but not for a core platform provider like BEA.

First, let me straighten out a couple of technical inaccuracies. A process activity in FuegoBPM can have any number of implementations. In might be a FBL script, as Bruce describes. Or it might be a form. Or a series of forms organized into a screenflow. Or a web service. Or a call into an external system. Or an Business Activity Monitoring Dashboard. Or any number of other things. A BPM tool that only could only implement process steps as web services would be a very poor tool indeed.

Second, FuegoBPM does support BPEL. You can define a BPEL process, implementing all of the activities as SOAP calls to remote services, if you like. I'd assert that architectually FuegoBPM includes both a workflow engine and a BPEL engine, as well as a lot of other other things. BPM is the convergence of a lot of technologies and BPEL is only one extremely tiny part of what makes a BPM product.

The companies the Bruce lists as good examples of BPEL based servers is very telling. None are considered, at least by Forrester, as strong players in human focused BPM. They are all classified as "integration focused BPM" players. (Interestingly, Forrester says that FuegoBPM uniquely can work as both a human focused BPM solution or an integration focused BPM solution. Perhaps because of FuegoBPM's dual support of XPDL and BPEL.) I'd assert that the BPEL focus of the vendors Bruce mentions is is holding them back. That if FuegoBPM had been a BPEL-only solution that it wouldn't have been nearly as capable of fulfilling the AquaLogic stack.

Posted by davidogren in BPM | Permalink | Comments (2) | TrackBacks (1)

Welcome to the new incarnation of BPM Blog.

Two weeks ago, the company I worked for (Fuego) was acquired by BEA Systems. In one of my blog posts about the acquisition, I questioned what effect the acquisition should have on BPM Blog. Should I keep BPM Blog independent, or should I make it a part of BEA's Dev2Dev blogging site?

In response to the rhetorical question, I got an invitation to join the ebizQ blogging team. Obviously, I accepted the offer. I knew from my web server logs that many of my readers were ebizQ readers, so joining the ebizQ bloggers seemed a natural fit. (Especially given how much I've been linking to Column2 over the last couple of weeks.

For those of you who are new readers, you may want to to check out the archives at BPM Blog's original home: http://www.bpm-blog.com . I plan on keeping the original site around until I can get all of the content imported into the ebizQ system.

For those of you who are already readers, and are following the link over to here, thanks for reading. You may want to change your feed readers over to the new feed if you are using an RSS reader. Pardon the typical migration struggles as I try to resolve all of the stylesheet issues.

To re-introduce myself, I'm a BPM Systems Engineer. I work for BEA Systems in the Business Interaction Division, which includes the AquaLogic Business Process Management products (formerly FuegoBPM). This means that spend most of my time working with customers in pre-sales. Basically everything from speaking engagements to customer demos to implementation planning and architecture.

In addition to blogging about the BPM industry, I've been known to stray offtopic to discuss the Getting Things Done productivity methodology, the technology industry in general, and even weightlifting. One of the conditions of joining ebizQ was that I post more regularly. Which means that I'll have even more chances to be offtopic. :-)

So check this space in the coming weeks. I'll be posting some more thoughts about the BEA acquisition of Fuego as well as some posts about exactly what I think the future of BPM may hold.

Posted by davidogren in Blogging | Permalink | Comments (0) | TrackBacks (0)