Tag: BPMN

BPM Think Tank Day 1: BPEL

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.

BPM Think Tank Day 1: BPDM

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.

I posit that business processes can change in response to changing business because they’ve been implemented using BPM tools that enable this agility, and services tend to stay the same because they haven’t been architected to allow for change. Possibly Cummins’ views are a reflection more of EDS’ client base and their own practices than what’s really possible in terms of agility. Of course, there’s also the view that published services need to stay the same (or at least their external interface) since the publisher may be unaware of all the uses of the service and doesn’t want to risk breaking it, but that doesn’t mean that a service shouldn’t undergo internal optimization or an extension of its functionality as long as it can be easily changed to adapt to changing business requirements.

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.

Modelling processes without a BPMS

An article by Bruce Silver in Intelligent Enterprise discusses the recent spate of BPM vendors releasing their process modelling tools for free. He lists Savvion, Oracle and Intalio, but the trend is widening — TIBCO just announced the availability of their modeling tool, and although the press release doesn’t specify, I heard a rumour that it’s free as well (how could it not be, considering the competition?). These offerings, from companies who make their money on the BPMS engine side so can afford to give away the modelling tools, will certainly make a dent in the market share of some of the dedicated modelling tools, such as Proforma, although many of the dedicated tools provide more extensive enterprise architecture-type modelling, not just process modelling.

One significant problem with these free tools is that although the vendors assume that they will just spread to all the desktops in an organization like wildfire, most corporate IT departments lock down user desktop configurations so that you can’t install applications. Although this might seem like a bit of Big Brother, there’s a good reason for this: it’s completely impossible for a corporate IT department to support several thousand PCs if the users can just install anything that they want on them. A case in point: a few years ago, a workstation at a client of mine started freezing “randomly”, which they blamed on the BPM software that we had installed on it. After several service calls where the problem did not recur, followed by uninstalls and reinstalls, one of my engineers finally just hung around until the problem occurred. The culprit? A non-corporate-standard screen saver that showed an animated football game; the machine hung right around the first down when the cheerleaders came out. When we reverted to a standard Windows screen saver, the problem disappeared. Since then, I’ve never complained about the restrictions that corporate IT makes on standard user desktops, even though it keeps me from using Firefox at most customer sites.

What this means is that even if a vendor makes their software available for free, that doesn’t assure acceptance, because it’s not free for an organization to regression test that against their standard desktop environment(s) and all of the other applications with which it might coexist. There’s two possible solutions to this:

  • Create an entirely web-based process modelling tool. (Do BPMS vendors know about Web 2.0 yet?)
  • Use a modelling tool that is already on most users’ desktops, namely Microsoft Visio.

I had a chat with one of the BPMS vendors recently about the first option, and he asked if I felt that web-based was the way to go (I love it when BPMS vendors ask me my opinion on product direction 🙂 ). My reply:

I like web-based since it lowers the barrier to use… many people of the type that I see in my customers who are doing process modelling are doing so at their office location and could be doing it much more easily if they don’t have to get permission from their IT department to install something on their PC, but use a purely web-based tool.

We also discussed how an installed version was necessary for people who aren’t always connected, but most real process modellers aren’t doing it from 35,000 feet or at a trade show, they’re doing it from their desk with a high-speed corporate internet connection. Yes, you have to have something for the road warriors and your sales people, but ultimately you’ll be most successful if you build what’s best for the target audience.

Which brings me to the second solution: Visio. Last year, Bruce Silver had a couple of articles on using Visio for process modelling, referencing the itp-commerce product. I just had a demo of a competing product, Byzio from Zynium (which sounds like a fictional space alien and his planet, sort of like Mork from Ork), another Visio add-on that allows for more robust process modelling in that ubiquitous tool. Yes, you still need to install the add-on, but chances are that a corporate IT department will find it much easier to approve a Visio add-on for installation than a full application.

Basically, Byzio allows you to draw a process model in Visio, then export it to XPDL for import into a BPMS’ process modelling tool. [In case you’re not up on XPDL, it’s an XML file format used to store BPMN; BPMN is the graphic modelling notation.] You can use a BPMN stencil in Visio so that you’re using the standard BPMN shapes, but the real power of Byzio is in the ability to map from any shape to a BPMN/XPDL construct, so if you already have a corporate standard for what shapes to use in a process model, you don’t have to change that, you just have to set up the mapping. The really cool thing is that Byzio has the ability to use the text within a shape to assist in the mapping, for example, detecting the words “and” or “or” in a decision shape and choosing the correct decision type. The mapping setup, which includes a regular expression parser, is not something that you’ll want every user to be playing around with, but as long as everyone in a department is using some standard notation, you should be able to set up the mapping once and replicate it around.

Although XPDL is supposed to be a standard, every BPMS vendor has their own flavour of XPDL, so the Byzio installation has to be specific to the target BPMS: the version that was demonstrated for me was for Fujitsu Interstage, but they also list Appian and DST on their website and I know that there are others in the works. In the case of Interstage, after the XPDL file is exported from Visio using the Byzio add-on, it’s opened in the Interstage process designer, where it can be further enhanced with engine-specific parameters. Byzio also plans to support round-tripping, where the XPDL can be exported back from the BPMS process designer for import into Visio for rework — I think that there’s some serious challenges in making this happen, but it’s doable. Not as integrated as using the BPMS’ process designer directly, but it has the huge advantage of using software that’s already installed on every business analysts’ desktop.

I’m still torn on the best solution in the long run. I feel strongly that there’s a place for BPMS vendors to create fully web-based versions of their process modelling tools intended for use by business users: namely, versions of the tools that don’t include all the yucky technical details, but provide a business view of the process models as they exist in the BPMS — no importing/exporting required. However, Visio is used for so much more than just what’s going to be automated in a BPMS that it will retain its dominance in process modelling by business users for the foreseeable future. That being said, I’ll give the edge to Visio paired with add-ons such as Byzio or itp-commerce.

BPM Think Tank

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.

Webinar: Taking BPM to another level

I’ve just finished listening to an ebizQ webinar How to Take BPM to Another Level in Your Organization, featuring Jim Sinur from Gartner. webMethods is the sponsor, so Susan Ganeshan, their VP of Product Development, is also on the line.

Sinur made a quick plug for the upcoming overpriced Gartner BPM summit, but then dug into some interesting material. Much of it was a duplicate of what I had seen presented by Michael Melenovsky in Toronto a few weeks ago — such as the comparison between a functionally-driven and process-driven enterprise, and the set of practices required around BPM — but it was good to see it again since I still haven’t received a set of slides from the Toronto seminar so had to rely on my rough notes. I liked the slide on the roles and responsibilities of business and IT, especially the centre column showing the shared responsibilities:

  • Process deployment
  • Process execution and performance
  • Business and process rules analysis and management
  • Operational procedures including version level control
  • Creation of process, rules, and events repository
  • Detailed process design
  • Training and education
  • Event analysis and management

This lines up with what I’m seeing with my customers, as IT relinquishes more control to the business, and the business starts to step up to the challenge in order to ensure that what gets implemented is actually what they need. I believe that the business still needs to be more proactive in this area: in the large financial institutions that I mainly work with, many parts of the business have become completely passive with respect to new technology, and just accept (while complaining) whatever is given them. I’m not in favour of giving over design control to the business, but they definitely need to be involved in this list of activities if the BPM project is going to hit the ground running.

I also liked the slide on what’s happening with rules and BPM in the context of policy-managed applications:

This is a very enterprise architecture-like view of the process, where you see the business policies at the top, the resultant rules immediately below that, then the linkages from the rules to the data and services at the bottom, which are in turn plugged into specific steps of the process. Making these linkages is what ultimately provides business agility, since it allows you to see what parts of the technology will be impacted by a change in a policy, or vice versa. There really needs to be more enterprise architecture modelling going on as part of most organizations, but particularly as it related to process orchestration and BPM in general.

At the 22 minute mark, Sinur returned to another 2 minutes of shameless plugging for the conference. Considering that we were just warming up for the “real” vendor to start plugging their product, the commercial content of this webinar was a bit high.

Although webMethods supposedly entered the BPM market back in 2001 on their acquisition of IntelliFrame, I’m not seeing them on any BPM radar screens — they’re really considered more of an integration suite. Ganeshan really should have practiced reading her script before she read it on the air, too, although she was much better at the Q&A. Except for the remark about how they don’t do BPMN because their customers really like webMethods’ “richer” proprietary interface instead (as if they have a choice).

At the end, the moderator showed the results of the survey question that she had posed near the beginning of the webinar. No big surprises here, although interesting to note that all of the drivers (except for document compliance) are becoming equally important to people. The trend that I’m seeing is that the goal of improving operational efficiency (shown on this survey as “reduce operational costs” and “reduce process errors”) are being taken for granted: everyone expects that will be the result of implementing BPM, so it’s not considered the main business driver. Instead, process visibility and process orchestration are moving to the forefront, which in turn drive the agility that allows an organization to bring its products and services to market faster.

ebizQ is using some new webinar software lately (or maybe a new version) which has some nice new features. It allows you to download the presentation at any time (other webinar providers could learn a HUGE lesson from that), zoom on the slides, and other features from the previous version, but now also shows a list of upcoming webinars in the sidebar and allows you to pop up a list of the attendees (first name and company only). Unfortunately, I had some major connectivity problems that resulted in a five minute gap right at the beginning of the Q&A, so I’ll have to go back to the replay and check it out. Fortunately, they publish the replays very quickly after the event, using the original URL, another good lesson for other webinar providers.

Investing in BPM webinar

Understand that first of all, I think that Bruce Silver is a very smart guy, and don’t take it the wrong way when I say that he is a less-than-scintillating speaker. He was featured on Appian‘s Investing in BPM webinar today, and his talk turned out to be just a slight expansion of his Intelligent Enterprise article that I discussed earlier; it wasn’t exactly edge-of-the-seat stuff. Maybe he should spend less of his time reading from a script, and more just talking about this subject matter that he knows so well. And although he was giving a beginner’s guide to BPM, I have a bit of a problem with him starting out his talk with “I want to talk to you about a new kind of software, business process management…” New kind of software? Not.

After the requisite 20 minutes of “independent content” that the vendors use to hook you into attending their webinars, Appian’s Director of Product Management, Phil Larson, stepped in and talked more about BPM in general and about their product. He was interesting enough to keep me on the line for the remainder of the webinar, and he had good illustrations of some of the concepts, including the prettiest diagram that I’ve seen to show how BPM and SOA fit together. Not the most complete, but sometimes you just need a pretty version to make your point.

Larson quoted from the recent Forrester report — “[Appian] has the widest breadth of functionality among the suites we evaluated” — although he didn’t mention the bit that came later in the same paragraph of the report: “However, breadth comes at the expense of depth in features like simulation and system-to-system integration“. He showed a snap of their BPMN implementation, which gets good marks off the bat for having the swimlanes running in the right direction.

I’m not sure if Appian will have the webinar available for replay later, although it’s not really worth it unless you’re a true beginner. I think that you can get most of the information from Silver’s portion of the talk from the earlier-reference Intelligent Enterprise article, and most of the Appian information from their web site.

BPM think tank

Last March, a BPM think tank was held with support from WfMC, BPMI, OMG and other standards organizations (original link here, but the BPMI.org site seems to be down), then a follow-up session at the AIIM conference in May. This year, the 2006 BPM think tank is an OMG event (OMG absorbed BPMI last June), to be held in Fairfax, VA in May.

I’m not sure what that means to those of us who want to attend but aren’t OMG members, but I’m sure that Phil will keep us posted.

Business Process Modelling for Dummies

I blogged last week about Human Interaction Management as a process modelling notation, along with some dissenting opinions that favour BPMN for process modelling. I tend towards the BPMN camp, and don’t see any benefit in using different modelling notations for some artifical divisions between “human” or “system” processes, considering that the goal of most BPM implementations is to convert some of the human processes into system processes in order to gain efficiency.

One of the biggest problems with any process modelling notation is that the techies (and, having a very techie background, I sometimes fall prey to this myself) tend to put too much detail in the models that are used to gain consensus among all stakeholders: once a model gets past a page or two, anyone who isn’t intimately involved with the modelling efforts won’t understand it — not because they’re not capable of understanding it, but because they don’t want to spend the time tracing through pages of stuff that has way more detail than they really need to know.

In a recent article on Keeping BPM Simple for Business Users, Michael Havey discusses the inherent problem of comprehensive notations such as BPMN or UML activity diagrams: the business users don’t understand them. Well, they get the gist of them, but don’t understand many of the finer points of the notation, which means that much discussion of the business processes during requirements gathering and functional design ends up being about the notation rather than the business processes that are being modelled. He proposes a “dumbed down” notation of just boxes and arrows, but I think that by modelling processes at a higher level for general communication with the business users, they can understand the notation: I think that the bigger problem is too much complexity in the diagrams — such as trying to present business users with sufficient BPMN detail to map directly to executable BPEL code — not an overly complex notation.

There’s been a significant focus on process modelling notations in the past few months, both as an adjunct to a BPM initiative, and as a way of modelling non-automated processes as part of a Lean or Six Sigma process improvement initiative. As process becomes a key competitive differentiator for more and more businesses, that interest will only increase.

Human Interaction Management and other process modelling notations

The latest BPTrends newsletter pointed to a case study on Human Interaction Management by Keith Harrison-Broninski which, unfortunately, didn’t do a lot towards explaining the benefits of HIM. It’s a bit like any sort of process modelling that uses swimlanes, except that the swimlanes are boxes rather than lanes, so the topology of the process is quite different that the left-to-right flow that we’re used to in most process modelling notations. He uses, as justification for HIM, the following anecdotal evidence:

The person responsible for re-engineering this process spent several months drawing up process documents which no-one used, and struggled even to understand, before turning to the techniques of Human Interaction Management, and finding that everything they had written so far, and more, could be expressed in a single 1-page diagram — further, a diagram that elucidated the processes concerned so clearly that all parties involved were able to agree on a re-engineered version within 2 meetings.

Doesn’t that just support the argument that a simpler process modelling diagram is easier to communicate than a complex one, without necessarily saying that the simpler diagram needs to be HIM? I believe that it’s possible in many modelling notations to create simpler diagrams that are more appropriate for a widely-varied audience through various levels of abstraction. HIM diagrams tend to cram a lot of information on one page (see the example on page 2 of his article), but I don’t see that it’s any more or less understandable than other process models.

The same issue of BPTrends has an article in which Paul Harmon decries the dichotomy between modelling techniques for human and system processes, in counterpoint to Harrison-Broninski. This is labelled as a “A Response to Harrison-Broninski’s Response to My November 15th BPTrends Email Advisor”, so obviously these guys have been having some heated discourse over this topic for a while. I tend to agree with Harmon (although the name-dropping in the article gets a bit thick), since his reaction to Harrison-Broninski’s article is pretty much the same as mine:

A case study developed by Harrison-Broninski has been posted on BPTrends this month. It contains a RAD diagram of a Business System-Support Process. To my eye, that diagram is just a complex version of a Rummler-Brache swimlane diagram, turned on end. If you reduced it to swimlanes, boxes, and arrows, I think it would make it easier for most business people to understand. Obviously there a lot of subjectivity about what looks simple to whom. All I can tell you is that I’ve worked with lots of business people. Most weren’t interested in automation, and workflow diagrams have always worked just fine.

Earlier in the article, Harmon comments on how a high-level process diagram is usually sufficient in order to communicate with business people for the purposes of reaching a common understanding of the process and identify opportunities for process improvement; in other words, you don’t have to spend months creates a multi-page process diagram that details every last system function before you reach consensus on the direction to take. And, he believes that BPMN is the sort of simple, standard notation that can be understood and used by business people while still providing the power to model more complex lower levels of the process at a later point.

This holy war on process modelling notations puts me in mind of a project that I was involved in a couple of years ago, where I was doing the user requirements and functional specifications for a BPM system (a typical role for me on a project). A large SI was also heavily involved in the project for some mainframe integration portions, and when I said that I’d be doing process maps as part of my work, a project manager from the SI immediately jumped on me about notation, asking what notation that I’d be using, and listing off everything from UML activity diagrams to use cases to more exotic modelling techniques usually associated with software design rather than communicating ideas with business people. I said that I’d be doing a simple flowchart notation in order to make it more understandable to the business people, and she looked at me like I had just grown a second head (I get that look a lot). To her, modelling was part of the dark arts that were intended to be used and understood only by the technical wizards, and she never really came close to understanding why I would want to create high-level diagrams that fit on one or two pages, and are intended to be understood by all the stakeholders.

Whether you use HIM, BPMN or any other notation, there’s a key lesson in all this: the business people don’t care about multi-page, overly-detailed view of the process. You need to create the high-level views for communicating with all stakeholders, then drill down to the lower levels during detailed design and implementation as required.

If you’re interested in more information on HIM, there’s a good HIM info site (and a related product site) and an article by Peter Fingar. There’s also some information on linkages between HIM and Martin Ould’s RIVA methodology in Ould’s book. I’ve talked about BPMN many times before on this blog if you’re looking for more information and links on it.

Through a fog of BPM standards

If you’re still confused about BPM standards, this article by Bruce Silver at BPMInstitute.org may not help much, but it’s a start at understanding both modelling and execution languages including BPMN, UML, XPDL, BPEL and how they all fit together (or don’t fit together, in most cases). I’m not sure of the age of the article since it predates the OMG-BPMI merger that happened a few months ago, but I just saw it referenced on David Ogren’s BPM Blog and it caught my attention. David’s post is worth reading as a summary but may be influenced by his employer’s (Fuego’s) product, especially his negative comments on BPEL.

A second standards-related article of interest appeared on BPTrends last week authored by Paul Harmon. Harmon’s premise is that organizations can’t be process-oriented until managers visualize their business processes as process diagrams — something like not being able to be truly fluent in a spoken language until you think in that language — and that a common process modelling notation (like BPMN) must be widely known in order to foster communication via that notation.

That idea has a lot of merit; he uses the example of a common financial language (such as “balance sheet”), but it made me think about project management notation. I’m the last person in the world to be managing a project (I like to do the creative design and architecture stuff, not the managing of project schedules), but I learned critical path methods and notation — including hand calculations of such — back in university, and those same terms and techniques are now manifested in popular products such as MS-Project. Without these common terms (such as “critical path”) and the visual notation made popular by MS-Project, project management would be in a much bigger mess than it is today.

The related effect in the world of BPM is that the sooner we all start speaking the same language (BPMN), the sooner we start being able to model our processes in a consistent fashion that’s understood by all, and therefore the sooner that we all starting thinking in BPMN instead of some ad hoc graphical notation (or even worse, a purely text description of our processes). There’s a number of modelling tools, as well as the designer modules within various BPMS, that allow you to model in BPMN these days; there’s even templates that you can find online for Visio to allow you to model in BPMN in that environment if you’re not ready for a full repository-based modeling environment. No more excuses.