Category: process

business process management

Appian/Zynium webinar

If you haven’t had the chance to see Zynium’s Byzio product in action yet, Appian is hosting a webinar on June 21st that will show off how Byzio works with their BPMS. As I discussed previously, Byzio lets you draw your process map in Visio, then export it to XPDL as a standard BPMN map for importing into a BPMS for execution. I expect that a lot of the webinar will not be specific to Appian, so if you want to get a look at Byzio this should be a good forum.

CIO as dinosaur

From Baseline/CIO Insight, a report on emerging technologies; specifically, a survey of CIOs of what technologies that they’re actually using. Some results that I find to show the incredible short-sightedness of many corporate CIOs is the percentage who find the following technologies “of no interest/not on the radar”:

  • SaaS, 32%. How could this number of CIOs possibly have no interest in SaaS? Only one answer comes to mind: empire building.
  • SOA, 30%. The percentage of CIOs who prefer to remain mired in legacy linguine.
  • AJAX, 46% and RSS, 38%. How to they plan to deliver information, both interactively and via publication, in the future? This isn’t just an externally-facing issue; in large organizations, these technologies are equally important for serving it up to internal users.
  • Social networking, including tagging, 51%. Although other things were mentioned in this category, I see tagging as the key contributor to a corporate environment here. How long will it be before all ECM systems have tagging as a standard feature? When will CIOs stop characterizing this as “allowing the lunatics to run the asylum” and just put the right categorization tools in the hands of their users?
  • Wikis, 46%. Okay, I get why a lot of companies are still uncomfortable with blogs. But wikis for collaboration make a lot more sense than clogging up everyone’s email with multiple out-of-date copies of a Word file that everyone is trying to update at the same time. It’s only a matter of time before Microsoft adds wiki capabilities to SharePoint (if they haven’t already), at which time everyone will be using wikis below the CIO’s radar. David Berlind posted yesterday about how many IT leaders have never even heard of wikis, which is likely where the “not on the radar” is really coming from.

There are a lot of other equally shocking stats about just how far behind corporate CIOs are in their thinking. Many of my clients are large financial institutions, so I suppose that I shouldn’t be that shocked: if I polled them directly about these same issues, I’d likely get similar results. Unfortunately, that doesn’t give me much hope that these organizations are going to become a lot more efficient or offer better services to their customers any time soon.

On the BPM front, only 21% show as “deployed”, 19% “testing/piloting”, 27% “evaluating/tracking” and 32% “no interest/not on the radar”.

Update: I just saw this post on why AJAX and RSS matter for in-house user interfaces, particularly for BPM.

Update: Robert Scoble reports that wikis will, indeed, be in Sharepoint 2007. The meteor has landed, you guys can all just head for the tar pits.

Webinar on supply-chain integration

Although supply-chain integration is definitely not my key area of expertise, I’ve been asked to moderate an ebizQ webinar this Thursday featuring Extol. I’ll do the introduction up front, then ask the questions that the audience sends in at the end. You’ll be able to watch a replay of the webinar shortly after it finishes using the same link.

BPM Think Tank Day 2: Greg Meyer keynote

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.

BPM Think Tank Day 2: Connie Moore keynote

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.

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.

Column 2 translated: Colonne Deux anyone?

Jean-Christophe Dichant is with the FileNet Paris office, where I had some memorable moments during my brief tenure with FileNet in the early 00’s, and he blogs in French about BPM, which I’ve mentioned previously.

I invited JC to translate my “Short History of BPM” into French — with his own commentary — and publish it on his blog, and he has the first two parts up here and here. When you’re mostly unilingual, like me (my French is so bad that I can’t possibly refer to myself as fluent), there’s something weird about seeing your own writing translated into a language that you know slightly, but it’s pretty cool at the same time.

A Short History of BPM, Part 6

Continued from Part 5.

Part 6: The Tower of Babel I’m going to skip forward a few chapters in Genesis to describe the utter confusion that happened next when the combined space was relabelled, primarly by the big analysts, as business process management. Now, instead of being confused by what’s a workflow product and what’s an EAI product, customers were confused by which product serves which part of this still-fragmented market. To make the confusion even worse, the same analysts who lumped all of this together as BPM created divisions within the BPM space based on functionality. For example, here’s my previous diagram overlaid with Gartner’s BPM taxonomy from 2003:

They called it all “BPM suites”, but broke it down into five categories, with the key part of the market falling into the “pure-play” and “integration-focussed” categories:

  • Integration-focussed BPM manages system-to-system flows for process integration across multiple applications. At the time, products in this category were slowly emerging into the human-to-human flow applications but lagged in user sophistication and user-friendliness.
  • Pure-play BPM provides overarching design and connection between application-specific and integration-focussed workflows, for example, by triggering a subflow in another system and carrying the result back to the master process. These were the über-BPM products, modeling processes across the enterprise, not just subprocesses within the enterprise, and including modeling and analysis tools, business rules engines, and process simulation and optimization.

Basically, Gartner (and other analysts, quickly and slavishly followed by the vendors) put the words “workflow” and “EAI” out of fashion, and ushered in the era of referring to anything even remotely related to process as BPM. They then split the BPM space (mainly) into pure-play and integration-focussed, which corresponded roughly to the old divisions of workflow and EAI vendors. Along the way, I’m sure that they sold a boatload of analysis and consulting.

Keith Swenson has a post this week about how the term “workflow” fell out of favour during this period due to “marketing fluff”, a point with which I completely agree — after about 2001, you couldn’t use the word workflow in a conversation with an IT group without someone sneering at you for being old school. His point is that BPM has now come to be synonymous with EAI; I’m not sure that I agree with that, but I do think that BPM is one of the most misused and misunderstood terms around today.

Next: The new arrivals

A Short History of BPM, Part 5

Continued from Part 4.

Part 5: Creation finishes, but what’s left?

Now, the workflow and EAI markets started to converge. Both workflow and EAI products extended to include functionality that was useful in both spheres, such as business rules engines and more advanced process modelling tools. Business rules engines were typically integrated through OEM agreements, while process modelling was usually built as an integral part of the workflow or EAI product. Workflow products beefed up their EAI capabilities, and EAI improved their workflow tools.

Customers started to get confused: where did workflow end and EAI begin? When should you choose one product over another?

Next: the Tower of Babel