Although labelled "The business value of BPM", this is really a webinar on BPM standards as a wrap-up of the recent OMG BPM Think Tank, which I blogged extensively about.

Since I was at the Think Tank and have a lot of opinions on the subject of BPM standards, I'll be presenting at this webinar (as opposed to my previous role as moderator) along with Connie Moore from Forrester and Jeanne Baker from OMG and Sterling Commerce. Connie will be covering the business value of standards, Jeanne will be doing a wrapup of the Think Tank, and I'll be doing an interactive discussion between the three of us on the future of BPM standards.

Being a presenter on this webinar prompted me to finally update my bio on the ebizQ site; a few people who I've met lately assume that I work for ebizQ, which I don't, so this should clear it up.

The webinar is on August 9th at noon Eastern, and you can sign up here.

Posted by sandy in BPEL • BPMN • BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (0) | Add to del.icio.us

The Spring OMG newsletter is available online (direct link to PDF) with a 2-page article "OMG and Service-Oriented Architecture":

In essence, SOA is an architectural approach that seeks to align business processes with service protocols and the underlying software components and legacy applications that implement them.

So far, so good. Then they go on to say:

Both processes and services need to be carefully coordinated to assure an effective SOA implementation. You can’t really do SOA without a clear model of the business process to be supported.

Not sure that I fully agree with that: you have to have a clear model of your business process before you can implement SOA? Aren't the underlying services supposed to be reusable even if the business process changes? Isn't that really the whole point of SOA?

And you can’t link your business processes to your service models without the modeling standards the OMG is developing as part of its Model Driven Architecture® (MDA®).

Oh, I get it now.

They do include a nice diagram showing where the OMG standards fit in one representation of an SOA environment (see the newsletter for the full-size version). You can see where BPMN, BPDM and BPEL fit in, which I talked about in my posts from the BPM Think Tank last week, plus other standards such as SBVR (Semantics of Business Vocabulary and Rules) for business rules.

I also like that they're platform-independent about this, and that they don't equate SOA with WS-*.

You can check out the newly-formed OMG SIG on SOA if you want to get involved in discussing this MDA approach to SOA.

Posted by sandy in BPEL • BPMN • BPMThinkTank2006 • SOA | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

Since I only finished posting about yesterday's sessions at the end of this morning, I decided to just do a final conference wrapup instead of separate wrapups for yesterday and today.

In general, the BPM Think Tank was great, and I'll definitely attend again in the future. I learned a lot about some of the standards that I didn't know much about before (like BPDM), and met some really smart people with lots of opinions on the topic of standards. It's been so long since I was involved in any sort of standards work (AIIM in the early 90's, and topographic data interchange formats for the Canadian Council of Surveying and Mapping back in the late 80's), and I had forgotten about both the frustrations of dealing with standards committees and the excitement of being able to contribute to a little bit of computing history that will make things work better for a lot of people.

I'm still mulling over the XPDL/BPDM conundrum (and, to a lesser extent, BPEL), but the fact that different standards bodies are all here participating is a good indicator that there is the collective will to head off problems like this. At last year’s Think Tank, discussions between BPMI and OMG around the competing graphical process models of BPMN and UML activity diagrams helped lead to the absorption of BPMI into OMG, and the championing of a single standard, BPMN, being put forward by the merged organization. We can only hope that something similar will happen with XPDL and BPDM in order to avoid future problems in the BPMN serialization domain.

I had the chance to meet several people who I had connected with online but never met face-to-face: Dana Morris of OMG, Bruce Silver, John Evdemon (who I'll be having ongoing discussions with about BPM and Web 2.0) and others. Jeanne Baker, who did such a great job at keeping things moving along during the sessions, even remembered one of my posts from last year about a webinar that she gave on standards -- she turned to me at lunch yesterday and asked "Did you write that blog post called 'Alphabet soup for lunch'?" -- proof that people will remember if you mention them in print. I missed other people completely in the crowd (Phil, where were you?).

There were a few logistical problems (conference rooms way too cold, no free wifi, not enough herbal tea, and no free t-shirts with vendor logos, about which I heard a lot of whining when I got home), but these were only minor annoyances in an otherwise well-executed conference with excellent content.

Posted by sandy in BPEL • BPMN • BPMThinkTank2006 | Permalink | Comments (3) | TrackBacks (1) | Add to del.icio.us

The last of the four roundtables that I attended was on BPDM, led by Fred Cummins. I started with my (by now) usual question about the distinctions and overlap between XPDL and BPDM: his response was that XPDL is an XML specification, and BPDM is a metamodel that can be exported to XML via XMI. He seemed to imply that they could coexist, but given that BPDM will include a serialization specification for BPMN (in addition to other models that can be represented in BPDM), I'm not sure I see the need for both in the standards world. He later stated that there is an expectation that people will model in BPDM (as visualized by BPMN or other visualizations as appropriate) and transform to an execution language such as BPEL, rather than BPDM being an interchange format; this seems to leave no room in the landscape for XPDL if you adopt BPDM, unless you need it as a legacy interchange format.

Moving on to other points about BPDM, it will include both orchestration and choreography (process flow, messages and collaboration), and will include more concepts than can be represented in BPMN, hence will support other views, e.g., process dependency diagrams, roles/organization view, choreography. A draft submission of the standard is due on June 5th, with a rough plan to finalize the underpinnings to provide BPMN support within 3-4 months, although there is no plan to issue a version with just the serialization as a preliminary release. In order to complete the release, they will likely do BPEL export from BPDM and a UML mapping to BPDM in order to demonstrate usability of the standard on a broad enough basis to initiate its acceptance.

When Cummins provided a summary of all of his roundtables at the end of the conference, he pointed out a couple of questions that had arisen during the discussions:

• Is there a potential for executable BPDM? [I say that if there can be abstract BPEL then why not executable BPDM?]
• Is there a way to achieve compatibility between XPDL and BPDM? [I think that there better be]

Posted by sandy in BPMN • BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (0) | Add to del.icio.us

This afternoon, I attended technology roundtable on XPDL led by Keith Swenson.

Keith went around the table and asked how we (or our customers) are modelling processes now. The biggest faction by far use Visio, but PowerPoint (!), UML activity diagrams (using the IBM/Rational tools) and proprietary/internal tools specific to an industry were also mentioned. For the most part, people are concerned with sharing processes between tools, not between organizations, since most organizations are very protective of their processes. A major issue with most of these tools is round-tripping and process lifecycle issues, since in many cases it's a one-way trip from the modelling tool to the execution engine. We talked about Byzio, the Zynium add-on to Visio that allows BPMN to be modelled in Visio, and a mapping from either a BPMN template or any other Visio set of shapes to XPDL. I reviewed Byzio several weeks back, and Keith is quite familiar with the product too.

We discussed how XPDL could be used to aggregate process models from disparate BPMS' that might be in use within the same organzization.

In discussing BPEL, Keith felt that XPDL provides all of the support for everything that BPEL can do with respect to the interface to web services; this further pushes the issue that BPEL is not really required if it's not being used as an execution language and if there is a transformation from XPDL to the specific engine's execution environment (which implies that the BPMS vendor's design tool can import the XPDL file).

XPDL provides support for extensions modelled in a BPMS vendor's design tool that are specific to that engine; these are preserved in XPDL and should not be affected if the XPDL is manipulated by another process design tool. This is critical for supporting round-tripping from a design tool to the BPMS vendor's engine (via their design tool) and back again, since the design tools should preserve the extensions even if they don't interpret it. An example of such an extension is assigning colour to swimlanes (which Fujitsu allows in its design tool): the file can be read into a tool that doesn't interpret the colour information, but when it is saved and read back into the design environment that does support colour, the colour's there. Vendor extensions such as this may be brought forward at XPDL TC meetings for inclusion in future versions of the standard.

The most recent set of major changes to XPDL were BPMN-related enhancements including X-Y coordinates of lines, topology, etc.; however, they forgot to include scale, since some measures are in real-world units (inches/cm) and some are in pixels. This caused further discussion on the separation of presentation and logic data, since both are included and intermingled in XPDL when it’s used to serialize BPMN, and if logic and presentation be versioned separately, since some purely cosmetic changes can be made to presentation without affecting logic. Other presentation-related information includes a "page" indicator, since a process may span multiple pages when visualized.

We had a lengthy discussion on additional versioning information that could be included in XPDL, and how this ties in with SOA governance initiatives for maintaining the integrity of interfaces and functionality.

I repeated what I said in an earlier post about blaming the large analysts for forcing (sometimes inappropriate) standards by creating RFP checklists that are used (somewhat blindly) by customers -- Keith agreed with this view.

We ended up with a bunch of ideas that deserve more thought: Should Java be extended to subsume BPEL functionality? XPDL is graph oriented, and BPEL is block structured; BPEL4people implies that you can extend a block-structured language to represent human-facing process flows which are inherently graph-oriented. Should BPDM be the metamodel behind XPDL? (This is not a viewpoint endorsed by OMG since XPDL uses some notation not recommended by OMG, and BPDM has a broader scope that inclues BPMN serialization.) If XPDL were made MOF-compliant, could it replace the need for BPDM?

Posted by sandy in BPEL • BPMN • BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (1) | Add to del.icio.us

Following this morning's panel, Nancy Craft of Volvo gave a keynote on Process Integration in the Supply Chain. She works for the IT department that supports three different truck brand divisions (Volvo, Mack and Renault), and they initiated a business process innovation project for sharing and optimizing their Order to Delivery processes while still maintaining separate identities for the brands.

They used Proforma's ProVision as a modelling tool, but found that it was complex and they struggled with the tool especially when they tried to use it interactively during meetings. She recommends having a trained modeller in the room if you're going to try to do this while gathering the information, and not letting the documentation get behind.

They made use of SCOR from the Supply Chain Council in order to drive their modelling, starting with the identification of 50 best practices before the study even started as a comparison. They modelled their processes to level 3:

• Level 1 = process types = the scope and content within each business domain
• Level 2 = process categories = strategy or capability for level 1 process types
• Level 3 = decomposed processes = process elements layer, used by companies to fine-tune their operations strategy

It appears that SCOR was a big part of their success in these modelling efforts by providing a framework for the information to be captured, standard language, and best practices. I don't typically work in supply chain or manufacturing, so the SCOR details were new to me, but there's obvious benefits from such a framework in terms of analyzing and optimizing processes. She later highlighted it as a "significant accelerator".

She covered off their analysis and design techniques, and gave some fascinating insights into how to get people from these three competing brands to collaborate on improving business processes: more than just working with different business cultures between divisions, but the harder task of overcoming the desire for secrecy between competitors.

They've also put together a six-year roadmap for improving the Sales to Order, Order to Delivery, and Delivery to Repurchase processes (which is essentially all the processes in the organization), which had a very enterprise architecture-like view of mapping from the strategic direction and business drivers to business processes, then used that to push through to IT requirements. Their initial take on this turned out to be much too complex (what she referred to as a "horrible methodology"), and they ended up with a simpler model to map busines objectives through to specific IT application implementation projects. Not quite so EA-like, but at least providing some alignment between business and IT.

The rest of today will be the remaining to roundtables -- XPDL and BPDM for me -- and ongoing discussions, so the rest of my posts about the conference may be delayed until tomorrow.

Posted by sandy in BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (0) | Add to del.icio.us

I finished yesterday afternoon by attending a technology roundable on BPEL led by John Evdemon. There was a lot of ground covered there that I had heard in his workshop on Day 1 and the panel earlier yesterday that I won't repeat here, so just a few brief notes.

There are some things that can be described in BPEL that can't be modelled in BPMN, which I didn't realize. The example that Evdemon gave was an online order for a book, then a follow-on process kicked off the next day when the customer cancels the order. Although both of the processes can be modelled in BPMN, I think that his point is that the interaction between the processes can't be modelled there. There are apparently a few use cases like this that are being considered for inclusion in BPMN (if I understood correctly), but I didn't hear anything about this in the earlier BPMN roundtable. Stephen White's mappings of BPMN (available on the old BPMI.org site, so I imagine all still available on OMG's site) has many peole thinking that BPMN models a superset of BPEL, which is not strictly true.

Like the BPMN roundtable and some hallway discussions, there were a lot of comments about the linkage between process standards and enterprise architecture.

The issues that we discussed, and the notes that I made from the discussion:

• BPEL doesn't provide all the functionality that can be modelled in BPMN.
• If BPEL isn't used as an execution language, but just as an import/export language as is done by Microsoft, IBM and others, what value does it add over XPDL (or eventually, BPDM)?
• Are we eventually going to end up with just BPMN, BPDM (or XPDL, if you believe Bruce), and a vendor-specific execution language in the process chain?

I have some additional research to do, some of which will start in this afternoon's roundtables on XPDL and BPDM, about whether BPEL does add value over these standards by providing more specific web services information such as endpoints or ports. You can definitely use BPEL as an import/export and exchange format, or to store the representation of a process for future rehydration, but it appears that you could also use XPDL or eventually BPDM to do the same thing and provide a richer interpretation of models created using BPMN.

At the end of the day, when we all reconvened as a group, Evdemon gave a summary of what we discussed:

• What is the value of BPEL if XPDL is a direct serialization of BPMN? BPEL had a lot of press because of who's backing it, not necessarily because of its capabilities. (A direct quote from him during the roundtable itself on this subject: "Unless you're going cross-platform, you may not need BPEL.")
• Use BPEL to store current processes to be rehydrated later if needed for audit or other legal and compliance requirements. BPEL is also being used by other standards such as RosettaNet to provide process-related templates for those standards.
• Process formats may just become different serialization formats with different capabilities, accessible from many tools just like all the document formats that are available if you select File...Save As within Word.

Posted by sandy in BPEL • BPMN • BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (0) | Add to del.icio.us

Today started off with a panel called What the Business Needs: Standards and Technology for BPM Success. Derek Miers moderated, and the panelists were Joe Olsey of Morgan Stanley, Greg Meyer of iJET (who gave a keynote yesterday), Nancy Draft of Volvo (who will be giving a keynote following the panel) and Bruce Silver.

Miers started with a question to the panelists on the value of standards to the business, which ranged from modelling to technology standands. Responses across the board included that a shared understanding of a process is a big reason for modelling standardization, and technology standards such as those used within web services help to create a more agile development and deployment environment.

[Eek! I just heard the phrase "service orientated architecture" from one of the panelists! I may be just an engineer, but I roomed with an English major at university and some misuses of language really grate on me.]

An audience member jumped in and said that there is also a benefit to standards when organizations merge: if everyone is using standards for modelling, serialization and implementation, it makes is a lot easier to put systems together down the line.

The XPDL and BPDM smackdown started with some comments from Silver, which he also discussed in his blog yesterday. He quoted Keith Swenson from the WfMC XPDL technical committee as saying "The BPDM metamodel and BPMN schema are available today. It’s called XPDL.", then added his own comment: "That’s basically true. OMG has effectively given XPDL a two-year window to establish itself as the de facto BPMN schema, and make the official OMG epic irrelevant." I think that the XPDL/BPDM war is going to be a long and messy one.

Meyer stated that he sees very little benefit to businesses in being early adopters of standards: it's a lot of work; it will probably change at least once before everyone else adopts it, requiring significant rework; your trading partners will likely to slower to adopt, hence the creation of externally-facing standardized interfaces won't be used for the first several years; and when it does become mainstream, the cost of adoption will be significantly lower than for the early adopters. An audience member jumped in to say that standards have become part of the marketing war between vendors (with the big guys trying to discredit the smaller ones because they haven't adoped the standards yet) rather than providing real benefit early on within customer organizations, and that there needs to be more control by the customer organizations. If you take a look at standards committees, many of them are heavily loaded with big vendors with their own interests in mind; there's certainly a benefit for customer organizations to be involved at least at the requirements stage. Silver summed it up by stating that standards lead to commoditization of technology, which lowers price, but that doesn't help the early adopters: really a restating of Meyer's point. Although there was a call to arms for customer organizations to get more involved in standards, I'm not sure that's the answer: there's still going to be a long adoption curve for standards, with lots of extra costs for organizations that are early adopters before it becomes a commoditized part of every vendors' offerings.

Jeanne Baker jumped in and asked the three panelists from customer organizations about their secrets to success with BPM, which led to a discussion about functional and organizational modelling, and how organizational modelling can lead to further enforcing the silos within an organization rather than breaking down the cross-silo boundaries that can occur with pure functional modelling. Not surprising, the need for a high-level champion came up -- this true of pretty much any enterprise-wise implementation of technology that impacts the business users -- and the process of evangelizing the implementation within the organization.

Olsey made some great points about the acceptance of standards, and how although we may not get any particular area down to one standard right away, having a small number of standards is better than no standards at all. The flip side of that is that vendors (and some customer organizations) will almost certainly need to implement multiple standards, but with luck there will be a small number of them and there will eventually be some convergence. Meyer said a major problem with the standards is that they're too rich and cover too much ground, which means both a long time to develop and standardize the standards, and a long time to implement them. He issues a call for "just getting it done", which echoes his earlier comments on the pain of being an early adopter of standards, as an end-user organization: if the standards are simpler, they will be adopted faster and will cost less to do so.

Silver blames the customer organizations for turning standards into just check boxes on an RFP, but I put that blame with the large analysts who write RFP templates used by customers, and by large vendors who implement the standard in some way, then push out the message that you must embrace that standard or a plague of locusts will fall upon you.

I haven't done a post on the BPEL roundtable that I attended yesterday afternoon, or a Day 2 wrapup, so they'll be out of chronological order relative to the conference but in the order that I actually write the posts (I don't usually play with the times on my posts to insert something before an existing post since people who read this blog directly rather than through an RSS reader might miss them).

Posted by sandy in BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (0) | Add to del.icio.us

Since I'm here in part to firm up my knowledge about BPM standards, I chose to attend four technology roundtables and none of the executive (business focussed) ones. The first one that I attended was on BPMN, led by Petko Chobantonov of Lombardi. Petko's involved with the development of the BPMN standard and was really pushing us to find out what else should be added to the standard in the future. I was the scribe for that session so have a ton of notes, my problem is trimming them down and making them understandable in this post.

First of all, Petko made the statement that OMG is not recommending XPDL for serialization of BPMN (i.e., a file format in which to save BPMN), but recommends the use of BPDM (which isn't released yet, although a very early draft is due next month). This sets up for an interesting showdown between XPDL, which is already in use by 30+ modelling and BPM vendors, and BPDM when it finally is released this year or next.

For the first time, I heard about BPRI, Busines Process Runtime Interface, which incorporates information gathered at runtime such as metrics and statistics about a process (I think). Petko has a bit more on his blog about it here, and I'll be looking at this in more detail since I think that this is a necessary standard as well.

One of the participants from an end-user organization said that they have extended BPMN with 3-4 custom types in their internal use, one for applications and one for data elements. He also said that they have difficulties in publishing and communicating BPMN diagrams because of the complexity, and that there needs to be some easier ways to abstract a flow in order to present it to someone who is not intimately involved with the process, such as executive management. Although using just a linear set of milestones was suggested as an abstraction model, removing all of the split/merge and other flow information, I think that some of the flow information should be left in place even in a high-level diagram in order to provide sufficient value.

This was also one of the times during the day when I heard about the crossover between BPMN and enterprise architecture. We discussed different perspectives (similar to the perspectives in a Zachman diagram), and although Petko felt that the standard could be extended to become effectively a higher-level diagram from which you could invoke other EA perspectives, like organizational and motivational models, I think that BPMN holds a place as a standard for creating artifacts in one or two of the Zachman cells in column 2 (process), not as an overarching EA model.

We had a discussion about the standard organizational tree-type chart, and how the boxes in that correspond to swimlanes in a BPMN diagram. From that, we talked about how to represent information in the org chart based on which processes that a particular role participates in, and also discussed the stickier subject of assigning roles a bit more dynamically based on a collection of capabilities rather than a pre-determined role. That got me thinking about whether we're asking the question the wrong way around: instead of the asking what capabilities exist in a role or person, should we be creating the roles or services based on what combinations of capabilities exist? Something to think about later.

We talked about a dependency diagram for subprocesses used in multiple processes, and whether this should be a standard view defined in BPMN, or if it's informational rather than notational. If the audience for this information is primarily the business analysts who use BPMN, then perhaps a graphical standard is appropriate, although it's a "report" of sorts, not a working model.

Petko finished up with some ideas about defining aspects of a process, such as security, escalation and exception handling, in order to simplify the primary representation. The aspects would be invoked whenever an activity is executed, but represented on separate diagrams. In that way, an aspect would effectively be a template for activities that could be overlaid on any of the activities in the main diagram and extend the meaning of the main diagram. Each activity in the main diagram would need a mechanism for passing some number of parameters to the instance of each aspect that may execute for that activity, for example, some measure of the time-criticality of an activity in order to trigger an escalation at the approriate time.

Tons of ideas came out here, as they did at the later roundtable that I attended on BPEL, and I'm looking forward to the roundtables today.

Time to head off to the conference (I'm already 5 minutes late and still have to finish packing and check out); more throughout the day as I get a chance.

Posted by sandy in BPMN • BPMThinkTank2006 • EnterpriseArchitecture | Permalink | Comments (0) | TrackBacks (1) | Add to del.icio.us

In the afternoon yesterday were the first two of four roundtables (the other two will be this afternoon). I really like this format, kudos to Dana Morris of OMG and his team for setting this up, and to Jeanne Baker for herding the cats so successfully when the time came.

When I signed up for the event, I was given a choice of 10 executive roundtables and 10 technology roundtables, and four time slots to choose from. Each of the 20 roundtables run simultaneously in each of the four time slots, with the same leader but a different group of up to eight attendees. The discussions are very dynamic, and there's a scribe appointed for each session so that the ideas are captured and will eventually be distributed to the conference attendees.

Because the groups are small and the discussions interactive, it wasn't the right environment for whipping out my laptop and blogging live, so I kept notes on paper which I've had to transcribe in order to report on the sessions. Posts on yesterday's session follow this post; today's will likely be delayed until tomorrow unless I get some wifi at the airport this evening.

Posted by sandy in BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (1) | Add to del.icio.us

We finished Wednesday morning with a panel on the business value of process standards, moderated by Connie Moore of Forrester, with panelists Richard Soley of OMG, Keith Swenson of Fujitsu and John Evdemon of Microsoft representing the BPMN-XPDL-BPEL value chain.

I'm now on the search for the Holy Grail of BPM standards: what's going to survive the coming shake-out, and how exactly do XPDL, BPDM and BPEL overlap, compete and complement each other? Swenson started his intro with a statement about BPDM and XPDL: basically, there's some great work happening on BPDM, but XPDL is here now and can be used in the interim. Was this an admission that XPDL is going to go away and be replaced by BPDM? I had a side conversation with Fred Cummins (who gave the BPDM workshop yesterday) before the panel, and he sees BPDM as providing a superset of functionality such that transforming to XPDL or BPEL doesn't add any value unless the particular BPM execution engine requires the transformation. BPMN has clearly won the graphical representation skirmish; can BPDM take the rest of the field? [Note to Phil Gilbert, who dissed me yesterday for asking why use BPDM if you have XPDL: this is live blogging so pretty much stream of consciousness, I'm just blogging what I hear and think during the session and haven't had time to formulate any real opinions or analysis of all this. So back off, buddy. :-) ]

Evdemon said that in his personal opinion, BPEL has a 3-out-of-5 importance rating for most organizations, mostly for checking off boxes on an RFP (in his position on the TC of the OASIS BPEL group, he said that it's a 5/5, which makes me wonder why OASIS would choose to use him as a public speaker on the standard when his corporate affiliation and personal opinions aren't really in line with the goals of the standards committee). He feels that BPEL got a lot of press unfairly, and that when he found out yesterday that XPDL can save a complete representation of all BPMN objects, he seemed to think that BPEL could become even less important and possibly even subsumed -- recall from my post yesterday on his workshop that he sees BPEL as more useful as an abstract (modelling or exchange) language rather than an execution language.

Swenson came back to the issue of XPDL versus BPEL, which he doesn't see as competing. XPDL is about process design, about serializing and saving what you drew in BPMN, and not so much about execution. He sees XPDL as a way of moving a process from one design/simulation/analysis tool to another (about 30 tools support it today), whereas BPEL is about the nuts and bolts of sending messages from one location/service/system to another. As Evdemon said, XPDL is like XMI for business processes. Swenson states that XPDL will continue to track and adjust to any changes to BPMN.

Interesting that the BPEL proponent thinks that BPEL is less important in the face of XPDL's current functionality, whereas the XPDL proponent thinks that BPEL and XPDL should coexist.

Even more interesting is that the panel did not directly address the issue of the business value of standards, only the standards themselves. It would have been good to hear a bit more about how to promote the idea of BPM standards within an organization, although given the current somewhat confusing state of overlapping standards, it's hard to know exactly what to recommend.

A last question was posed about BPDM that Soley addressed, namely, what is it and how does it compete/overlap with the others that we're talking about here. He claims that it's not intended to compete with any of these other standards, although that's still not clear to me.

A really valuable and lively session, I just wish that I had recorded it since the opinions and comments were flying by and I'm sure that I've missed some key points. Hopefully, I'll be able to explore these further in the roundtables this afternoon and tomorrow.

Posted by sandy in BPEL • BPMN • BPMThinkTank2006 | Permalink | Comments (3) | TrackBacks (3) | Add to del.icio.us

Greg Meyer from iJET gave a "practioner keynote" about process and risk management, and came out with the best quote of the conference so far: "I'd rather have someone tell me how to do something right, than something cool". Having been at a lot of events recently where people were showing me cool things, but at a lot of customers who want to do things right (and equate "right" with "old and proven"), I find that the real challenge is keeping on the "right" path but remembering that "right" and "cool" are not mutually exclusive: how else do we bring innovation into the mainstream?

Meyer's talk about risk assessment and human intelligence is fascinating, and anyone who uses the term "combinatorics" casually in his presentation has a place in my engineering heart. :-) As a non-American, however, I'm uncomfortably reminded that this is all about making US government intelligence better: iJET started out providing travel information/advisories to travel agencies, then 9/11 happened, the hits on their website increased by 60,000x since they could provide in-depth analysis of the impact of events, and they started providing information to multinational organizations and government agencies.

Putting my uneasiness about their customer base aside, they were dealing with the problem of being a small company that acquired a lot of large customers over a short period of time and had to grow quickly. They implemented an SOA, using an ESB to integrate data and services from many partners and implemented web services to allow partners and customers to access their services quickly and easily. They added a portal architecture to let them create new products and services in weeks or even days, rather than the months that it used to take. However, it didn't help their bottom line because they had no better insight into how customers were using their products. Basically, they had their head stuck deep in the technology and weren't considering it from the standpoint of how to improve the real business issues.

Meyer talked about then doing an implementation in the context of the enterprise that actually achieved the success that they were seeking, which appeared to be mostly adding BI (or more accurately, corporate performance management) to feed back metrics to the appropriate parts of the organization, and some better integration with other enterprise applications such as billing systems. The bottom line, not surprisingly, is that you have to consider the entire enterprise for a successful BPM/SOA/ESB implementation.

Posted by sandy in BPM • BPMThinkTank2006 • ESB • SOA | Permalink | Comments (0) | TrackBacks (1) | Add to del.icio.us

Today started with Connie Moore and Colin Teubner from Forrester delivering the keynote "Making Sense of the Business Process Management Landscape". Moore addressed the ever-present (and ever-changing) issue of defining the BPM landscape. She thinks that BPM was co-oped by the integration vendors -- a view that I've heard a few times over the past day, and with which I agree to some degree -- and thinks that it needs to be given back to the business. She splits the landscape into pure-play BPM, integration, traditional B2B, enterprise content management, application platform, and enterprise application. I found her comments about ECM vendors interesting (paraphrasing): "they don't really understand it, but they created some of the early workflow products". Considering that they put FileNet in this "don't get it" category but that FileNet also ended up right on the border between "strong performer" and "leader" in their Wave for Human-Centric BPMS doesn't match up (I mention FileNet specifically because I worked there a long time ago and still work with some of their products, so have a good idea of their capabilities), so not sure of the value of these categorizations.

She started out showing the results of a Forrester survey from last year about problems with enterprise application implementations, where several of the top responses were related to BPM in some way: inadequate support for cross-functional processes, limits on process change due to application inflexibility, lack of visibility and analytic insight into process results, and inability to extend business processes to external partners.

She showed how BPM evolved from workflow, although I think that her view is simplistic since it only considers the human-centric side. She then went on to talk about Ken Vollmer's view, which is that BPM evolved from EAI; as you can imagine, I think that's also a simplistic viewpoint. As I discussed in my history of BPM, I think that the market started to merge a few years back when workflow vendors started adding EAI, and EAI vendors started adding workflow, although all of them maintain an orientation in one direction or another. Forrester now ranks the integration vendors and the human-centric BPM vendors separately, and has very different analyst teams working on them, effectively tearing apart the originally artificial, but now well-accepted, combination of everything integration-related under the BPM umbrella that Gartner made a few years back. It feels like they're trying to put the toothpaste back into the tube, and I don't think that it's going to work. Moore does make a valid point that one product won't do it all, which is exactly what I've been telling my customers for some time: I think that most organizations need two in order to cover all the requirements currently, although they need to work together closely.

They showed a great diagram where BPM is positioned as the crossover technology between business and IT, whereas ESB and other more integration-focussed technologies are clearly on the IT side of the fence. Let's face it, an IT person might talk to a business person about BPM, but they're never going to talk about them about ESB or SOA with any degree of success: BPM lives in both of their worlds, although may show different faces to each side.

Moore then said those words that always chill my heart when I hear them from an analyst: "I'm going to talk about where BPM vendors ought to be thinking". I had a lengthy conversation yesterday about how I disagree with the power that Gartner has as a market-maker, as opposed to an organization that analyzes and reports on the market and trends, and here's Forrester playing the same game. I was quite relieved when she presented a very vanilla view of a value pyramid of BPM-related functions plus some predictions like the user experience will change dramatically (without mentioning Web 2.0), and that better integration between BPM and BI is needed. Whew.

Posted by sandy in BI • BPM • BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (1) | Add to del.icio.us

First, a major thumbs down to OMG for not providing free wifi in the conference rooms -- this is an expected level of service at any computer-related conference these days. The Doubletree (where the conference is being held) has paid wifi throughout the hotel so I was able to get online, at a price. One of the conference speakers later made the comment in response to all the requests for wifi that we should just turn off our laptops since we were supposed to be paying attention to the conference rather than reading our email. Thanks Mom, but I was actually taking notes and live blogging about the conference, not reading my email.

On a more serious note, every presenter who I heard speak today was an expert in their particular area, but knew almost nothing about competing standards. I heard the phrase "I'm not an expert in xxx" too many times today, and I think that anyone involved in standards like this who is speaking at such a workshop should be at least familiar with the other standards that they are inevitably going to be asked about. I'm still sorting through how all these standards and formats fit together, which are competitive versus complementary, and it doesn't help when the speakers don't have a vision of at least their part of the landscape.

My favourite presentation was John Evdemon: not only was he informative, he also has a lot of passion for his topic. We had a brief chat afterwards about how we can bring together process and Web 2.0 that I hope to continue later.

Posted by sandy in BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (0) | Add to del.icio.us

I'm now in the final session of the day, with John Evdemon talking about BPEL. He's dealing with a number of interesting points, such as name (WS-BPEL versus BPEL versus BPEL4WS), pronunciation (he doesn't care, as long as you use it), the lack of graphical notation, and orchestration versus choreography. I particularly like his description of orchestration versus choreography, which is crystal clear: orchestration has the concept of a controlling party, even if other external organizations are involved in a process, and is concerned with the process from the viewpoint of that party includes its internal activities; choreography is at a higher level and looks at a process as message-passing between peers, without delving into the processes internal to any of the participants. BPEL is an orchestration language, and you can think of choreographing between the BPELs at each organization (sort of).

The motivation behind BPEL was application integration both within and between organizations -- EAI and B2B -- where everything is described as a service. It covers both non-programmers implementing flows by assembling components with flow logic, and programmers implementing the granular services using function logic that will make up those processes. There's also the idea of being able to model both executable processes and abstract processes using BPEL, although most of the excitement around BPEL has been due to the platform-independent nature of it as an execution language, that is, the logic for how messages actually get processed. Abstract BPEL, on the other hand, can be used to describe an organization's services at a deeper level than can be done via WSDL, without concern for execution.

Evdemon showed a diagram of how BPEL fits together with the rest of the WS-* stack, and shows how business process models and choreography models need to still be layered on top of BPEL to provide full capabilities.

Something that I didn't really think about before, but which came up in response to the questions "where does BPEL live?" is that Microsoft doesn't run BPEL directly, but translates it into BizTalk (unlike a product like Oracle BPEL Process Manager, which executes BPEL directly).

BPEL 2.0 is scheduled to go out for public review next month. New since v1.1:

• New activity types (if-then-else, repeatUntil, validate, forEach, extensionActivity)
• Completion condition in forEach activity
• Variable initialization
• XSLT for variable transformations (new XPath extension function)
• XPath access to variable data (XPath variable syntax)
• XML schema variables in web service activities (usability enhancements for WS-I compliant doc/lit-style WS interactions)
• Locally declared messageExchange
• Abstract processes (common base/syntax and profiles/semantics)

Evdemon's recommendation and predictions about BPEL shocked me: it's still under development, so don't use it yet in production and the portability of executable BPEL will be low to non-existent. He sees that many organizations implementing BPEL are using it like a programming language, which he implies is an inappropriate usage since it's missing some core capabilities, but that it's more of an orchestration modelling language. If that's the case, and the vendors are going to just translate it into their own proprietary execution language, then there seems to be little advantage to adopting BPEL over something like XPDL that can capture everything that BPMN can model, except possibly for better WS handling.

Posted by sandy in BPEL • BPMN • BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (0) | Add to del.icio.us

I'm in Fred Cummins' BPDM workshop, where his stated goal is to provide a general understanding of BPDM, engage us in a discussion of the requirements, and discuss the implications of BPDM to enterprise agility. Fred's an EDS fellow who writes occasionally on the EDS Next Big Thing blog.

BPMN and BPDM are both standards that are designed for use by business people, with the inclusion of non-automated as well as automated business processes, and they are both business models as opposed to execution models (like BPEL, WS-CDL or proprietary vendor execution models). BPMN is a standard for the graphical representation of a business process, whereas BPDM is the XML file format in which such a representation can be stored: hence, a tool might display a business process as BPMN and save it as BPDM (which makes BPDM competitive with XPDL from WfMC, which I previously discussed as a file format for BPMN, although Cummins later stated that the scope and goals of BPDM exceed those of XPDL).

We had a lengthy discussion about the relationship between choreography (a collaboration between multiple participants) and a business process/orchestration (how one of the participants manages their view of the interaction): the roles typically map directly between processes and choreography, whereas only the steps in a process that involve interaction with another one of the participants will appear in the choreography. BPDM is intended to capture both orchestration and choreography information, although there was some discussion about whether BPMN has all the graphical representation for everything needed for choreography. It does include the concept of pools (like swimlanes, but representing different organizations, not different functions within an organization) and can collapse a pool so that it is effectively a black box, so I think that it has most or all of what's required for representing inter-organization choreography. An organization only needs to map the other parties in a choreography as a black box (i.e., a collapsed pool), whereas it will map it's own internal activities fully within swimlanes in its own pool.

Cummins then moved on to the hot topic of BPM and SOA, with the following definitions/relations:

• BPM: Business processes are the orderly execution of activities that achieve defined objectives.
• SOA: Services offer capabilities that can be used in a variety of contexts.
• Business processes may use services to achieve their objectives.
• Services implemented with explicit business processes can be more quickly adapted to business changes.

Personally, I find that list a bit circular, and I think that his "definition" of SOA is actually a definition of services -- maybe a bit of a fine point. He made a vague point about how processes and services provide different levels of granularity of agility, then came back to make two statements about agility:

• Primary impact of business changes is on the business processes and organizational structure.
• The actual work (concrete services) and data of the business tend to stay the same.

There's a lengthy discussion going on now about the difference between defining a meta-process and defining a paradigm, which is getting just a bit too esoteric for my taste (the accusation "you're being too rigorous!" was just flung around the room), but does remind me that OMG is a standards organization and this is exactly why I prefer implementation to theory, in general... (several minutes elapse)

Cummins finished up with some things that are being considered for BPDM but are still unresolved, such as the integration of business rules (and presumably a BRE) into a business process model, and the integration with strategic planning that's necessary to make business process modelling a fully participating activity in enterprise architecture.

At the end of it all, this workshop had a lot less to do with BPDM than I wished that it had, and a lot more about some particular views on SOA and business agility that didn't really have anything to do with BPDM. I understand that BPDM is still a work in progress, but it would have been nice if the artists had unveiled the canvas for us to take a preliminary peek.

Jeanne Baker, who sat in on the session, pointed out that this think tank is for all standards groups, and that last year's think tank resulted in the merging of BPMI into OMG due to the overlapping scope of BPMN and UML activity diagrams. Maybe the next move is to bring together XPDL and BPDM instead of indulging in an unwanted standards war for business process metamodels.

Posted by sandy in BPEL • BPM • BPMN • BPMThinkTank2006 • BRE • SOA | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

I'm in the BPM Think Tank pre-conference workshop on ebXML BPSS (Business Process Specification Schema), relabelled no less cryptically as ebBP (eBusiness Business Process, with the "specification schema" implied), presented by Sally St. Amand of the OASIS ebBP Technical Committee. St. Amand is obviously very knowledgable on the subject matter, but is a less-than-engaging speaker -- call it the bureaucratic style of presentation, full of long pauses and paper shuffling.

According to the TC's site:

The ebBP is a technical business process specification. It defines a standard language so that business systems can be configured to support the execution of business collaborations between partners or collaborating parties rather than the processing accomplished from the perspective of one business partner. The formal designation has been eBusiness eXtensible Markup Language (ebXML) Business Process Specification Schema (BPSS). It is more commonly known as ebBP (after the OASIS ebXML Business Process Technical Committee).

In other words, ebBP is an execution language for business collaboration between peers, like most eBusiness (and EDI) specifications before it, although it also allows for non-first-class participants (such as others in the supply chain) who may wish to observe the state of the process at certain points. In its basic format, it's very similar to other XML-based eBusiness specifications that I've seen, usually from vendors; these vendor-provided specifications will hopefully migrate towards the ebBP standard as V2.0.X is adopted. The benefit of including observer participants became really obvious in a diagram of an eBusiness exchange that includes an observer: the message flow can include messages to the observer at any time, rather than just between the two main participants, although only the first-class participants can initiate the signals.

ebBP specifies the XML format, but does not include any graphical representation or modelling. There is an open source ebBP editor, which I've downloaded but haven't tried out yet.

Working this into the general standards landscapte, ebBP is a choreography language for collaboration between different organizations, whereas BPEL is an orchestration language for processes that are controlled by one organization (although may execute across organizations).

Posted by sandy in BPEL • BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (1) | Add to del.icio.us

Yesterday was a holiday in Canada, and on this long weekend we headed for the cottage as many Canadians do. After a weekend of dealing with a tractor that wouldn't start, a clogged septic tank and a phone line that wouldn't work amid projects such as putting in the docks and launching the boat, it was almost a relief to get up at a ridiculous hour this morning and get on a plane for Washington.

Here in Washington (Arlington, actually), I'm about to head off to the BPM Think Tank -- watch for posts under the BPMThinkTank2006 category over the next three days while I'm here. I'm also trying to finish up the Short History of BPM series, since JC is fast translating the previous ones into French.

If you're at the think tank, look me up or drop an email/comment to setup a meeting.

Posted by sandy in BPMThinkTank2006 | Permalink | Comments (0) | TrackBacks (2) | Add to del.icio.us

I've just registered for the OMG's BPM Think Tank in Washington DC on May 23-25. The program is mostly about standards, which is a big focus for me right now. It will be a chance to see some people who I've met before, such as Phil Gilbert and Derek Miers, and meet a few others for the first time face-to-face, such as Bruce Silver, Keith Swenson (who I heard speak at the Gartner BPM Summit) and John Evdemon (who was referred to me by Harry Pierson when I met him at Mashup Camp).

If you're going, look me up. If you haven't signed up yet, discount registration fees for the BPM Think Tank are still available until May 1st.

OMG gets full marks for including bloggers when they're handing out press passes; my thanks to Dana Morris and Stephanie Covert for their forward-thinking press relations policies. I'll be blogging more about the event before, during and after.

Posted by sandy in BPEL • BPMN • BPMThinkTank2006 • Blogging • GartnerBPM2006 | Permalink | Comments (0) | TrackBacks (2) | Add to del.icio.us