Intelligent Enterprise BPM cover

Today’s Intelligent Enterprise cover story “Business Process Management is Under Construction” is focussed specifically on modeling, analysis and reporting, business activity monitoring (BAM) and simulation features (since they cover integration and automation features in an earlier article).

Their assessment shows BPM as still at a relatively early adoption state:

BPM software is headed for mainstream adoption, but it’s still a relatively small, immature market… Plenty of organizations have yet to discover BPM… 36 percent said they were considering BPM and 29 percent said they had no plans to implement it, while only 24 percent said they were either piloting, rolling out, in production with or upgrading BPM.

That’s certainly what I’m seeing in many organizations, and why BPM evangelism is going to be required for some time still. Yes, there’s lots of successful BPM case studies to point at, but if you dig into the infrastructure at a large financial institution (for example), you’ll find a lot of EAI and not a lot of real BPM. Intelligent Enterprise states that even the basic automation and integration are still a challenge for many organizations, but I’m finding that the integration part has pushed forward because EAI is typically an IT initiative to integrate systems behind the scenes: the business benefits obliquely but their environment may not be impacted at all. On the other hand, automation requires true BPM (including human-facing workflow, modelling and simulation, and a whole raft of other features not typically found in EAI), plus full involvement of the business in order to achieve success, so gets hung up on the continuing disconnect between IT and the business that they serve.

Compliance is certainly going to push BPM forward, although that requires closed-loop process control throught the addition of analytics and simulation. There needs to be a bigger focus on making BPM performance monitoring and improvement a part of the larger corporate performance management framework, and showing how BPM fits into an organization’s enterprise architecture framework.

There are two more BPM articles in this issue of Intelligent Enterprise, “IT Detours on the Road to BPM” that discusses nine BPM suites’ closed-loop capabilities, and “Simple Process Management: Quick, Cheap and Easy” about Nsite, a hosted solution for a limited range of administrative-type workflows. I’d love to stay and blog all day about them, but it’s a holiday here and I’m going sailing.

SOA from a BPM perspective

Terry Schurter of BPMG has a great article yesterday on about using a BPMS as the core of your SOA. His take on the current craze of SOA as a standalone big budget item:

Granted, I may be flying in the face of a storm of pundits, analysts, and technology gurus that endorse, promote and make great claims regarding the value SOA will deliver as I expose the seamy underside of this wolf in sheep’s clothing but hey — they’ve been wrong before — and the hard facts of the matter are that SOA expenditures will in many cases push important expenditures onto the backburner while they fiercely consume limited resources on a one way track to zero ROI.

I met Terry at the BPMG conference in London in May, and he definitely tells it like it is. I think that he’s just stirring the hornet nest here to see what happens, but he has some valid points about how a competent BPMS already does a lot of what you may be reinventing with your SOA initiative.

Interestingly, this post on Six Sigma Technologies’ site this week went through a checklist of SOA uses and benefits that sounds an awful lot like BPM…

Process Orchestration 101

Today’s Integration 101 webinar talked about why it’s important to integrate applications. Basically, if you don’t, then you probably have the following problems in your business processes:

  • No real-time visibility into the process
  • Long cycle time due to manual data gathering and other non-automated tasks

In other words, your customer drops their information into a black hole and nothing happens for a long time, so there is a higher risk that they take their business elsewhere. Not only is the process inefficient (and therefore costs you more to operate), but it results in lost revenue.

When you use BPM for your large scale processes where several internal and external applications are integrated, you’re moving into the area of process orchestration: the BPMS is invoking, controlling and tracking what goes on in all of the applications. Add in a business rules engine to automate decision-making in the process, and BAM to publish a real-time view of what’s going on, and not only are things more efficient due to fewer manual steps in the process, but your customer can see what’s going on at each step of the process.

Realistically, the only way to do this level of enterprise application integration such that it’s maintainable, flexible, extensible and reusable, is to use a service oriented architecture to expose the applications’ functionality as services to be called by the BPMS. Otherwise, you’ll be right back in a spaghetti mess with the same (or competing) business logic embedded in multiple applications.

Integration 101 webinar

If you’re new to the world of integration, EAI, SOA and all those other good things, you can tune into the ebizQ webinar Integration 101 – From Application Integration to SOA on Tuesday at noon Eastern:

In this webinar, Roy Schulte, Vice President and Research Fellow in Gartner Inc., joins Lance Hill, webMethods Vice President Solutions Marketing, to make some sense of all the acronyms (BAM, BPM, SOA, EDA, CEP) and to describe at a fundamental level the different integration technologies that can be leveraged to integrate and enhance business systems and processes.

Roy Schulte is pretty smart about these technologies, and webMethods has just won the ebizQ EAI Buyer’s Choice award. Should be an interesting discussion.

Strategic process optimization

A webinar going on right now on BPM, BAM and SOA: Optimizing both Business and IT focussing on the ROI of process integration. Beth Gold-Bernstein contrasted the tactical versus strategic approaches to process integration:

  • Tactical approach requires defining underlying integration infrastructure
  • Strategic approach — enterprise integration architecture defines infrastructure, business defines the process

This goes back to one of the key ideas that I’ve been working with lately, namely the role of process and BPM in an enterprise architecture framework.

She also made a distinction between web services orchestration and business process management, where she sees WSO as providing a graphic way to design and control flow between web services, but without all the process governance (monitoring, analytics, management and simulation) that you would find in BPM. Given the role being assigned to BPEL, is this just another artificial distinction in the process marketplace?

OASIS takes on the meaning of SOA

OASIS announced yesterday the creation of a technical committee to develop a core reference model for Service Oriented Architecture (SOA). To quote their goal:

The SOA reference model will offer an understanding of the core elements within a service oriented environment and the associations and relationships among those elements. The reference model itself will not be directly tied to any standards, technologies or other concrete implementation details. Rather, it will be an abstract, designed to be used as a tool by software and enterprise architects developing specific SOAs.

The end-user organizations seem to be strongly behind this, given the participation of Boeing, General Motors, Lockheed Martin, Mitre, VISA, USA’s Department of Homeland Security, Japan’s Electronic Commerce Promotion Council, and Canada’s Public Works and Government Services. However, The Register reports today that some of the biggest names in enterprise computing have not yet hopped on board: Microsoft and Oracle, to name two. Shame, shame; you guys aren’t planning to go the proprietary route, are you?

BIJ online edition

Business Integration Journal (formerly EAI Journal) now makes their magazine available via free email subscription, for those of us who are not in the U.S. and therefore not eligible for a free paper subscription. A lot of the content is “advertorial” written by vendors, but there are a few gems in there, such as this month’s article on process-centric business intelligence by Keith Gile at Forrester Research, wherein he tackles the problem of out-of-context BI data by looking at ways for BI platforms to associate data with processes in order to deliver decision-making capability to the operational level.

Given BIJ’s policy of not publishing PDF copies of the current edition’s articles on their website until the next month’s edition is available, this e-subscription is the only way to get the content in electronic format at the time of publication, and I actually prefer an electronic copy of these “read and toss” magazines anyway. I think that I was sent an invitation for the subscription, but have no idea why; poke around on their site and you’ll probably find something. They also have issues back to January 2000 online, some of which are really a blast from the past.

My only complaint is that the e-subscription issue is hosted on Olive Software’s “ActiveMagazine”, which is really not a nice way to read online. It also doesn’t produce very readable copies if I print to PDF, so if I want to save a copy of an article or send it to a client, I have to either put up with the poor quality or wait until next month for it to come available on the BIJ website.

SOA and process designers

A post last week on the problem of the economics of process change by Christopher Koch at states the problem succinctly:

IT is in a mess because we have business processes that are locked into source code that is difficult to change or modify?that?s the real issue underlying the argument. That makes customization a dirty, expensive word.

Although he admits to possibly being “drunk on the Service Oriented Architecture Kool-Aid” that’s around, he sees SOA as a potential solution to the problem:

There needs to be a separate layer in the architecture for integration and business process change and coordination. Though web services aren?t always at the core of the layer, the concept of services is.

“Services” as a concept is interesting in this context, although I believe that SOA is just the flavour of the month in terms of naming. We did things like this years ago through appropriate encapsulation of functionality, and although our tools were a bit cruder than what is available now, we were essentially building services — when we did it correctly. Web services, WSDL and UDDI certainly make it easier to share these services, and I completely advocate their use for services to be shared within or between organizations.

The basic issue is that process designers shouldn’t need to understand the internals of the applications that they are orchestrating: they need to see applications such as ERP as a set of properly encapsulated, business-oriented functions that they can call at any point in a process. That means that the relevant functions within “legacy” applications (for lack of a better word) need to be exposed as discrete operations, and that an appropriate process orchestration tool be used to tie them all together.

And in another article of Mr. Koch’s that he links to from the above-mentioned post, he wraps the whole issue together with enterprise architecture, a concept that I also mentioned in a post last week. As more companies recognize the flexibility and business alignment that EA brings, process orchestration will take a more central role since it allows the IT assets that are enumerated through EA to be combined in new ways to serve the business needs.

Caution: rogue TLAs

I was listening to a presentation on IBM WebSphere today when the speaker, Deon Newman, IBM’s Director of WebSphere Marketing and Communications, made what I consider to be an excruciating misappropriation of a TLA. (I know, two consecutive posts about IBM: consider it a statistical anomaly)

First of all, the presentation was supposed to be about using WebSphere to automate business processes, that is, business process management, or what most people who have anything to do with process-based technology would abbreviate as BPM. However, it was very narrowly focussed on using WebSphere MQ V6 for the EAI (system-to-system) portion of BPM, in spite of a nice boilerplate slide on integrating people, processes, information and applications. Fair enough, still some interesting information, but if these MQ guys are going to join the party, they have to realize that MQ-type EAI is part of a larger BPM picture.

To confuse things further, there is a field of business intelligence and analytics called business performance monitoring — also abbreviated as BPM — which is what we used to call executive information systems (EIS) or decision support systems (DSS). Within the process world, the monitoring of business processes and performance is referred to as “business activity monitoring” (BAM), probably to distinguish it from the “real” BPM, and because it can include raw activity data as well as aggregate performance measures. The upshot is that for process-centric players, BPM means business process management, and monitoring of the processes and other performance measures is BAM. Gartner published an interesting report on the convergence of BPM and BAM last year, but they still classify them separately, and under those names. To clarify the overlap, a BPM system may include “BAM Lite” capabilities for monitoring the processes that it models and executes, but a full-on BAM system allows for inputs from several systems, including BPM systems, to create an overall view of the business activities. Of course, there’s also another BPM, business process modelling, although that is widely accepted as part of business process analysis (BPA) because of the round-trip nature of modelling and simulation.

Anyway, at the end of the presentation, Mr. Newman was asked a question about whether WebSphere MQ included BAM. He started his response by re-labelling BAM as “business process monitoring” and stating “We use the moniker ‘BPM’.” Huh? A third, slightly different meaning for an already overloaded TLA? Tsk, tsk. I was left with the feeling that either IBM doesn’t really have a clue where WebSphere MQ fits into the world of BPM (that’s business process management), or they’re not paying attention to anything that anyone else is saying, or they’re attempting some creative marketing spin.

I’m not beating up on IBM specifically, I’m beating up on the marketing department of all vendors who misuse commonly-understood terms or invent completely new ones, to the detriment of the businessperson who is trying to wade through all of the doublespeak. Although some part of what I do with any customer is to sort out vendor terminology and product taxonomy, it’s not always a very exciting part (for me), and I wish that the vendors could just follow some basic guidelines for not confusing the customers. Like agreeing on their TLAs.

IBM tops AIM market, but what of BPM?

A press release this week from IBM announces that a preliminary Gartner report on application integration/middleware (AIM) and portal software has crowned IBM as the market leader based on 2004 licence revenue. Their figures put IBM’s share at around 37% of the worldwide market, with chief rivals BEA, Oracle and Microsoft trailing far behind at 7.2%, 4.4% and 4.3%, respectively. The full report is due out at next week’s Application Integration and Web Services Summit.

As you poke around in the data, however, you find out that the number is made up of several products, including application servers (where they compete with BEA), integration software (where they compete with TIBCO, Microsoft BizTalk and webMethods) and portals (where they compete with Microsoft SharePoint). In fact, I suspect that anything that carries the “WebSphere” brand is considered part of their AIM stable, including ongoing licence fees for tons of pre-WebSphere-era MQSeries installations connecting ancient IBM mainframes using proprietary protocols. If you check out IBM’s software product list, there’s a whole lot of WebSphere going on, and it didn’t all start under that brand. In fact, I remember when what is now WebSphere MQ Workflow was rebranded from “FlowMark” to “MQSeries Workflow”, prior to its re-rebranding as WebSphere a year or so ago. Since MQSeries was the hot new brand at the time of the first rebranding, it was seen as an attempt to “standardize by branding”, although FlowMark wasn’t even based on MQSeries until much later.

From a BPM standpoint, the biggest complaint that I have about IBM’s products is the apparently piecemeal strategy. In recent years, we’ve seen a number of products put forward by IBM as BPM and/or workflow: WebSphere MQ Workflow (a somewhat clumsy workflow product that never really developed into a cohesive contender), Content Manager’s Document Routing (a very simple routing capability for document-based workflows), Lotus Workflow (I’m not even going there), Advanced Workflow (now apparently being sunsetted), and the latest entrant, WebSphere Business Integration.

WBI, previously called WebSphere Process Choreographer, is based on the CrossWorlds EAI product acquired by IBM: just type in and see where it takes you. Because of that origin, it’s coming from the EAI space, and my concern is that the product focus will remain on integrating systems and will never fully develop the human-facing functionality, including business-focussed tools for modelling, simulation and analytics. Gartner’s 2004 magic quadrant for pure-play BPM doesn’t mention any of the IBM products, although they did show up in the 2004 magic quadrant for business process analysis due to the Holosofx acquisition.

If this is going to be the next-generation BPM product, IBM needs to stop spending so much time listening to the IT departments (who get far too excited about EAI) and spend more time listening to the business departments in order to develop the human-facing components that they need to move into the pure-play BPM market. At the very least, they need to perform a mercy killing on MQ Workflow as soon as possible to reduce customer confusion and focus their efforts on a single BPM product offering.

Of course, there’s always going to be some platform limitations to WBI: it’s going to require WebSphere Application Server and WebSphere MQ. Given the market penetration of WAS and MQ in large organizations, however, I don’t see that as a problem; the opportunity to grab a huge BPM market share is theirs to blow.