standards – Page 11

Integration FUD factor

A good article in DMReview (where normally I find much more about data warehousing and business intelligence than integration) on Fear, Uncertainty and Doubt about integration, especially for small-to-medium sized businesses that don’t have IT budgets that look like the GDP of a small Pacific nation. I just love it when someone cuts through all the crap:

Integration is moving data elements from point A to point B with the necessary translation in between…Tier-one integration vendors have conditioned the market to believe that integration should cost millions of dollars and take years to implement. With today’s offerings, this is simply no longer the case.

Couldn’t have said it better myself.

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.

One last session

I’m cutting out early for my flight home, so I’m finishing the FileNet user conference with another BPM technical session, this one on process orchestration. This is a relatively new area for FileNet in terms of out-of-the-box functionality, and a bit behind the competitive curve but they appear to be charging into the fray with strong functionality. Mike Marin, BPM product architect extraordinaire, walked us through the current state: the ability of a process to consume web services, and the ability to launch and control a process as a web service. Mike sits on a couple of standards boards and is pretty up-to-date on what’s happening with the competition and future directions. Nothing here that I wasn’t already aware of, although he provided some good technical insights into how it all works under the covers as well as an excellent distinction between choreography and orchestration. He also talked about using web services as a method for federating process engine services, that is, allowing a process to span servers, which I think is absolutely brilliant. The same thing holds for invoking and being invoked by a process on a BPEL engine (like Oracle’s), because it’s just a web service interface.

Time to grab some lunch and head for the airport. Regular (non-UserNet) blogging resumes later this week.

BPM SIG

I’m in the BPM special interest group session, which is much more sparsely attended than I expected, but it’s just after lunch and people are still trickling in. The conversation is starting out a bit granular, questions about some very specific functionality although I suppose that’s part of the goal.

Chris Preston just made a statement that the clear direction for interoperability is BPEL, which is definitely the right answer although there’s still a lot of issues around handling the human-facing steps in a process. Unfortunately, in the absence of any questions from the audience, he’s off on a long rant about “re-engineering” using FileNet tools for process modelling, execution, analysis and simulation, which is a little too sales-y althoguh he’s doing his best to be consultative. He needs to encourage much more give-and-take with the audience rather than going into full oratory mode.

Minutes go by, and I’m really starting to wish that I sat closer to an escape route…

High-level product info

Dave McCann, FileNet’s SVP of Products, is talking in some very broad strokes about product directions, and I’m yearning for more details on all the new announcements. I suppose that will come mostly in the breakout sessions, I just need to be patient. He’s also talking a lot about content, which is not my focus (in case you haven’t noticed already) — I consider content to be like the air we breathe: it’s always there, I just don’t think about it.

A few interesting factoids that he’s dropped into his talk based on his conversations with customers: a large insurance company who sits on the FileNet technical advisory board stated that the largest cost in their IT budget is integration between all of the vendor products that they own. Yikes! A European customer told him that 82% of their IT budget is committed to maintaining what’s already in place, with only the remaining 18% to spend on new technology. These two facts taken together point out the need for easier ways to integrate all the things that are there, which will free up part of the budget for new technology that will help companies maintain a competitive advantage. The need for consistent architectures and reusability has never been greater.

He’s finally onto the process stuff, and is talking about the recent and upcoming enhancements to the BPM product suite:

– Productization of the Business Process Framework, which is a BPM application development framework developed by FileNet’s Professional Services for use in their own customer engagements, including things like case management and skills/roles management. They’re being very careful about positioning this so that it’s not perceived as being too competitive with partner solutions, although I’m sure that there will be a few partners who are going to be a bit put out by this.

– Business Activity Monitoring as a new product, replacing the rudimentary Process Analyzer that has been holding the fort in the BAM area for the past few years. Shipping in December. I’ll definitely be going to the lab on this later this week, since this is something that I constantly talk to customers about.

– Enhanced integration with business intelligence, especially through their recent cozying up with Cognos. I’ll be talking about corporate performance management, and mentioning Cognos specifically, in my breakout session this afternoon, since I feel that this is a critical step for most organizations.

– eForms enhancements, which are always interesting but a bit peripheral to what I usually do.

– A business rules connectivity framework that integrates to Fair Isac, Corticon and Resolution in addition to the longer-standing integration with ILOG. BRE is another functionality that I feel is essential to BPM, as I discussed in my course on the weekend.

He’s also talking about the FileNet Enterprise Reference Architecture, which fits nicely as a technical architecture for ECM against a full EA context.

The most exciting thing about the features that will be released next year is full BPMN support, which further validates my personal preference for BPMN over UML for process modelling.

All-in-all, I’m quite pleased with what they’ve announced in the BPM area, since it’s addressing some key weaknesses (like BAM) that have existed in the product suite to date.

BPM: a moving target

I’m prepping for the 2-day Making BPM Mean Business course that I’ll be delivering this weekend in Las Vegas, and it’s giving me a chance for a complete end-to-end review of a lot of material that I’ve been gathering, thinking about, presenting and rewriting over the past several months. One thing that immediately strikes me is the constant state of change: since I sent these materials for printing three weeks ago, there’s new things that I just have to include. The BPEL for People initiative (IBM-SAP white paper here), for example, which is a critical step to having BPMS products use BPEL more extensively. The ongoing effects of the OMG-BPMI merger. New versions of Enterprise Architecture modelling tools such as ProVision, since I position BPM in an EA context in this course.

There’s also a lot of wisdom that I’ve gathered over time that it will be fun to discuss with the course participants: how to do a business walkthrough, analyzing and designing business processes, and ROI calculations for BPM.

I spent this morning sitting in a local café (a good place to get away from all distractions except the Crackberry, which I am unable to detach from my psyche), putting the final touches on the workshop exercises that I’ll be having the participants do during the course. It’s a small class which should result in a lot of interaction amongst the attendees, and since they’re all from different companies, I’ve decided to do individual projects rather than group projects so that they actually have something usable to take home about their own business processes at the end of the two days. It’s sort of like speed-consulting for me, which should be fun all around.

I’m all a-quiver with anticipation.

Visio for BPMN

Another article by Bruce Silver on the value of using Visio for process modelling. His argument is that it’s already a de facto standard, with two-thirds of the world’s existing process models done in Visio, so why not find ways to just make it ready to play in the big leagues?

One way is to allow import of Visio models into enterprise architecture modelling tools such as Popkin, where they would then be “finished” by developers, but I don’t like that method because it takes control of the modelling — includuing ongoing maintenance for the models — out of the hands of non-technical process designers.

The other is to use add-ons to Visio that allow a process designer to create BPMN-compliant process models in place, then generate BPEL or XPDL. ITP-commerce, for one, has a tool to do this, and I think it could be a better solution in many cases, since it allows the process designers to use a familiar tool and easily work from their existing library of models.

What’s in a name?

Just discovered mwd blog through their post about BPEL; they believe that the “business process” part of BPEL is a bit of a misnomer, and that “at the very best what vendors are really representing are definitions of integration processing.” I knew that I was in tune with these guys when I read their earlier post on ESB, which tears a strip off technical marketing types that invent new terms for existing concepts in order to attempt to achieve some sort of marketing advantage.

Their BPEL post also includes a link to a Bruce Silver article about BPM standards that’s definitely worth reading.