Column 2

Enterprise 2.0 on my mind

It’s been an Enterprise 2.0 sort of week (or two). First, this post by Dan Farber points to an Enterprise 2.0 meme map by Stephen Danelutti, and also to some of Dion Hinchcliffe’s latest, including 10 predictions for Enterprise 2.0 in 2007. Although Hinchcliffe’s entire list is worth reading, #7 stood out for me:

It will be a make or break year for the first round of Enterprise 2.0 tools that add a process aspect. While SOAs and even Web 2.0 apps tend to be more about services and capabilities, the world of business is much more about processes. This has triggered some discussion that the best way to add enterprise context to consumer tools may be to make them more process-oriented. Thus, a number of upcoming Enterprise 2.0 tools have a process bent to them including the above mentioned Itensil, but also the nascent BPM 2.0 movement which can be enabled with these same tools. By the end of next year, we should have a good feeling if this is a good bet or not. My guess: A new market leader in this space will begin to emerge.

This week, the buzz is all about the Under The Radar conference “Why Office 2.0 matters” in Mountain View today, where a few people who I know from the TorCamp community are presenting their enterprise collaborative solutions: Firestoker, a blog-like platform for the enterprise, and ConceptShare, for online design collaboration.

2007 is shaping up to be an interesting year for Enterprise 2.0. As Hinchcliffe puts it, “2007 will probably be the year that will uncover the issues, and determine the fate of one of the more interesting offshoots of the Web 2.0 phenomenon.”

Update: congrats to Scott and the boys at ConceptShare for winning both the judges and audience vote in the Web Sharing category at UTR. If you’re doing geographically (and/or temporally) dispersed collaboration on a design process, check out their hosted solution.

Intro to BPEL

I just listened in on To BPEL or Not To BPEL, the title of which I believe resolves the pronunciation issue once and for all: although the presenter (Danny van der Rijn, principal architect at TIBCO) said “BEH-pull”, clearly it must be “BEE-pull” to make the title work. 🙂

Intended for those with a technical interest in BPEL, van der Rijn went through the history of BPEL from its origins as a melding of IBM’s WSFL and Microsoft’s XLANG, through the BPEL4WS 1.0 specification in 2002, 1.1 in 2003 and the soon-to-be-approved WS-BPEL 2.0. More importantly, he looked at why BPEL emerged: basically, the web services stack didn’t do enough to allow the orchestration of processes.

He then talked about what you’re not going to do with BPEL — it’s not a process modelling notation, it’s not for service creation — and stated that it’s not for portability: he mentions XPDL as a solution in that area (with no mention of BPDM). What I’m seeing, however, is that although BPEL may not have been intended as an interchange format, that’s exactly what it’s being used for in many cases. For many BPM engines, the “E” in BPEL is apocryphal: BPEL is a format that’s used to import process models from other applications, but it’s then converted to an internal (proprietary) format for the actual execution.

He covers off all the changes in 2.0: data, scoping model, message handling, activities and more, and walks through the basic BPEL components in some amount of detail. Overall, a good technical introduction to BPEL.

Unfortunately, about 40 minutes into the presentation, I received an “Invalid Flash Player Version” stating that I needed Flash Player version 8 to view the current content, and I lost all audio and video of the presentation. Flash? I was supposed to be using the Windows Media Player version of the presentation! On24.com really needs to get their act together: changing system requirements mid-presentation is not cool. Even when I installed the new Flash version and did a successful test, I wasn’t able to get back in. Guess that I’ll have to see the last bit in reruns.

Bruce Williams joining webMethods

I don’t usually blog about someone getting a new job, but this one was interesting: webMethods has hired Bruce Williams (who, according to their press release, is a Renowned Process Improvement Expert, but I’d never heard of him prior to the Gartner conference) as VP and GM for BPM solutions:

Drawing upon all of the company’s global resources, including product engineering, marketing, industry solutions, professional services, and business development, Williams will direct webMethods’ go-to-market strategies, solution development and customer evangelism for the BPM market.

I saw Williams speak at the recent Gartner conference, and I didn’t find that he had much to say about BPM: he seems to be a Six Sigma expert rather than having any direct experience in BPM, which makes him (in my opinion) an odd choice for what is essentially a BPM product marketing leadership role.

XPDL and BPEL

An interesting bit on the WfMC site comparing XPDL and BPEL that was highlighted in a WfMC mailing this week:

BPEL and XPDL are entirely different yet complimentary standards. BPEL is an “execution language” designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from point-to-point. For this reason, it is best suited for straight-through processing or data-flows vis-a-vis application integration. The goal of XPDL is to store and exchange the process diagram, to allow one tool to model a process diagram, and another to read the diagram and edit, another to “run” the process model on an XPDL-compliant BPM engine, and so on. For this reason, XPDL is not an executable programming language like BPEL, but specifically a process design format that literally represents the “drawing” of the process definition. To wit, it has ‘XY’ or vector coordinates, including lines and points that define process flows. This allows an XPDL to store a one-to-one representation of a BPMN process diagram. For this reason, XPDL is effectively the file format or “serialization” of BPMN, as well as any non-BPMN design method or process model which use in their underlying definition the XPDL meta-model (there are presently about 50 tools which use XPDL for storing process models.)

A good distinction between the best uses of BPEL and XPDL, except for one point: very few vendors are using BPEL as an execution language; they’re using it as an interchange format, which is causing a lot of confusion about what format to use (XPDL or BPEL) to move process maps between a modelling and execution environment. As the above paragraph points out, XPDL maintains the graphical drawing information as well as the execution-specific information; it also supports everything that can be modelled in BPMN (which BPEL currently can’t).

There’s also an article by Jon Pyke of WfMC in Computer Business Review Online where he smacks them down for calling XPDL a failure in a previous article, and states that XPDL is “often incorrectly perceived to be competitive with the business process execution language, BPEL, standard”. XPDL and BPEL aren’t competing in the sense that someone would elect to use one over the other, but they are competitive in that they’re both used as interchange formats, just for different types of processes or in different tools. Unless your BPM engine actually uses BPEL as an execution language (which few do), you’re not going to go from BPMN to XPDL to BPEL and then on to your BPM engine’s proprietary execution language, because there’s no value added from an additional data transformation: you’d do BPMN=>BPEL=>[BPM engine execution language] (obviously skipping the last transformation if the native execution language is BPEL) for web services orchestration-type processes that can be described completely using BPEL, or you’d use BPMN=>XPDL=>[BPM engine execution language] (where the latter may or may not be BPEL) for the larger set of functions supported by XPDL, like human-facing steps. In many cases, the choice of XPDL or BPEL is dictated by what’s supported by the tools that you use for processes modelling; those tools intended to model processes of web services orchestrations are more likely to support BPEL, whereas those targetted at the “BPM suites” market are more likely to use XPDL.

EAI -> BIJ -> BTI -> Align

Three months ago, I wrote about how the free BIJ (Business Integration Journal), formerly EAI Journal, was becoming Business Transformation and Innovation — available only as a paid subscription. I believe that my comment at the time about paying for mostly vendor-written and vendor-sponsored material was “hahahahaha”. And my comment on the new name was “it doesn’t actually mean anything”.

This week, I received an invitation for a free subscription to Align Journal (their tagline is “Aligning IT and Business Strategy”), and when I went to the site (and the online PDF version of the Jan-Feb issue), it looked familiar, so I dug into their About page:

Align Journal is the next step in the evolution of Business Integration Journal (BIJ). Over the past two years, the focus of BIJ was broadened to bring a business perspective to the use of technology for gaining such benefits as faster time to market, governance, increased agility to pursue new opportunities, improvements in managing business processes, and cost savings through the reuse of application components. Since the editorial focus of BIJ had evolved to no longer be strictly focused on integration topics, it was time to also evolve the magazine’s name to Align Journal.

No mention of BTI, although if you go to the BTI URL that was advertised back in December when I wrote my post about it, it redirects to Align Journal.

If this first issue is any indication, it’s definitely trending away from purely integration topics: the table of contents divides the articles into Business Strategy (3 articles), Leadership/Communication (3 articles), Technology (2 articles), Innovation (1 article), and Governance/Compliance (1 article). It’s not clear to me, however, why “Maximizing IT for Effective Inventory Management” falls under Business Strategy, while “Leverage SOA to Increase Your Revenues” falls under Technology.

The paid subscription model is gone, unless you want the print copy and you’re outside the U.S., and the digital copy is provided in a PDF that allows printing, but unfortunately not content extraction (so you won’t see me quoting from it here — I’m too lazy to retype what they’ve already published). And the name still doesn’t actually mean anything.

BI 2.0

Eleven months after I used the phrase “BI 2.0” in a blog post (and James Taylor loved it), Intelligent Enterprise used it in an article. Doing a Google blogsearch on the phrase shows a lot of other use in the last few months.

An inevitable naming trend, but I like to think that I was there at the beginning. 🙂

Assorted thoughts on BPEL

There’s been a few interesting posts about BPEL lately.

First, SOA World Magazine (which appears on the WebSphere Journal site, not sure if it actually exists elsewhere since there was no back-link) has a post on BPEL’s Growing Up, covering a brief history, current status and the view forward, including BPEL4People:

Going forward, we’re already seeing the next generation of standards around BPEL being discussed. For example, the “BPEL4People” effort was first announced in late 2005 and is intended to standardize an approach similar to the one described above for incorporating human workflow tasks in BPEL processes. Besides being one of our favorite standards acronyms, BPEL4People is an important area of work since most business processes span both systems and humans.

They neglect to mention that BPEL4People is not really much more than a white paper, although a lot of people talk about it as if it’s a standard just about to hit the big time. I recently linked to a Oracle Contractors blog post where one of the comments on the post (#5) pointed out that “so far, there is no BPEL4PEOPLE”. Or as I put it in my commentary on the link, the emperor is looking around for his boxers.

SOA World Magazine goes on to say:

While BPEL vendors provide easy-to-use graphical tools for creating and editing BPEL processes, the very fact that BPEL processes are so detailed as to be executable makes these tools too complex for most business users. Instead, business users need to be able to specify higher-level process blueprints that can then be filled in by developers to make them executable.

Business Process Modeling Notation (BPMN) is a standard from OAG [sic] to address the above requirement.

Um, not necessarily. Now, the article was written by two guys who work for Oracle, so I can see why they have this view, but I’m not sure that everyone would share the view that developers are required to fill in the details in order to make models created by business analysts usable.

Secondly, the comments about Microsoft supporting BPEL. As David Chappell put it:

Like BizTalk Server today, WF [Windows Workflow Foundation] treats BPEL as a way to move process logic between different workflow engines, not as an executable format (and certainly not as a development language).

He goes on to nail the real reason for Microsoft’s adoption of BPEL:

Adding the ability to export and import BPEL workflows to WF — and thus to Windows itself — will help WF in situations where support for BPEL is a political necessity.

BPEL has become more of an RFP check item than a real requirement, since most end-customer organizations don’t really understand what it is or what it might do for them. And if you believe a recent Burton Group report, BPEL is just a placeholder for WS-CDL until that choreography standard is ready for prime time.