Archive for June, 2006
One of the trends I detected at the Brainstorm BPM Conference in San Francisco this week is an effort to make BPM more engaging to users via Web 2.0 and Ajax. This dovetails with Ismael’s suggestions about how to make BPM cool again.
Adobe is now all over Flex and Flash technology to turn what we used to call “forms” into animated, engaging end user experiences (online or off) for, say, the applicant for a loan or potential purchaser of some good or service. In Adobe’s conception, engagement is focused at the requester of a business process (e.g. customer), and the BPMS hooks the output of that end user experience into the fulfillment of the request.
Pega just came out with a new release that features Ajax widgets to give process task participants a more engaging user interface, such as dynamic screens that lead the user to provide just the information required, without annoying roundtrips to the web server. Lombardi also emphasizes engaging task participants through its “coach” user interface paradigm.
While IT architects may debate the merits of the BPMS plumbing, business users evaluate technology based on things they can see on the screen, and Adobe, Pega, and Lombardi are going to ride that wave.
June 29th, 2006
Yesterday Gartner unveiled their magic quadrant for BPM Suites. For those unfamiliar with the format, it’s a square in which the horizontal dimension represents “completeness of vision” and the vertical represents “ability to execute”. Only BPMS products meeting Gartner’s feature/capability checklist are eligible to compete. The evaluation is generally via a questionnaire and interviews and the result is a dot somewhere in the square, which is divided into 4 quadrants. The upper right “leader” quadrant is the place to be. The lower right “visionary” quadrant generally indicates a small company with good technology but not a large customer base or sales resources. The upper left “challenger” quadrant usually indicates more mature products with significant installed base but which lack (in Gartner’s view) the “vision” of the leaders. The lower left (”niche players”) is where you don’t want to be… unless you’re happy just to be in the Q at all! From a starting point of “over 150 companies,” only 17 made it over the checklist hurdle this time.
The four happy leaders are Pegasystems, Savvion, Lombardi, and Fuego (now BEA), and overall I think that’s about right. If you just look at the vision axis, the top two are Pega and Tibco (Staffware) — that’s crazy — and if you just look at the ability to execute axis, the top two are Fuego and Savvion — totally crazy. My interpretation of the ability to execute axis must be outdated. How do you explain Ultimus and Appian having a higher ability to execute than IBM, Tibco, or Adobe?
A few other observations. Of the 13 rated products I’m familiar with (I know nothing about the 4 languishing in the lower left corner), only one (IBM) is BPEL-based — even though Gartner continues to flog BPEL, ESB, and other SOA-ish things in its definition of BPMS. The rest are human-centric. Also, all the leaders and visionaries are Java-based; Windows-based BPMS all fall on the left side of the vision axis.
Gartner also makes special mention of a few future contenders whose BPMS is still “under construction.” I.e. they don’t make it over the checklist hurdle today but probably will soon. These include Oracle, SAP, Cordys, Handysoft, and K2. My list would probably also add EMC and webMethods.
Of the 8 products in the leader and visionary quadrants, 6 are reviewed in detail in my 2006 BPMS Report series, which is available for free. These include Pega, Savvion, IBM, Adobe, Fuego (BEA update in process), and Lombardi (available in August). If you want to understand more about these offerings than where their dot falls in the Q, check it out.
Note added: If you want to see the MQ report for yourself, you can get it through Lombardi here.
Further update: If you want to avoid registering with Lombardi, Sandy Kemsley has posted the Q here. At least until she gets the cease-and-desist letter from Gartner.
June 29th, 2006
I know nothing about the corporate turf wars surrounding BPM, so I hope someone out there can help my anonymous friend, who writes:
I manage the business analyst group for our company (our firm is about $4 billion in revenue annually) … I work in the IT department. In a different department, they thinking of forming a BPM group. I’m trying to stay proactive so that the business analysts in IT don’t get run over …
Do you know of any material that starts to clearly differentiate what the people in a BA group do verses that of a BPM group? I want to clearly define the roles and responsibilities of each group BEFORE the BPM group is fully formed.
June 24th, 2006
Richard Brown, an IBMer from across the pond, blogged recently about BPEL4People and took issue with my contention that it was too grandiose and after-the-fact to achieve wide adoption as a standard. He tracked back to my original post in February, saying
I’m increasingly of the opinion that standardisation often occurs too soon and that major revisions are a reflection that the initial specs fail to anticipate potential problems or extended use cases. Unfortunately, if vendors choose to delay standardisation, they’re accused of being proprietary or risk finding themselves with no influence amongst those who decide to standardise earlier. When the incentives are so strongly stacked in favour of early standardisation, it’s not surprising that those who gain the most experience with a spec discover its deficiencies and seek to remedy them.
Anyway, since my original post was from February (before I even had my own blog), I’m hoping for a restart on the discussion of BPEL4People. What’s the right way to include human tasks in a BPEL process, and why?
June 20th, 2006
The following is my latest column for BPM Institute:
You can’t attend a BPM conference or webcast nowadays without hearing how SOA provides the critical technology underpinnings of BPM software. And there is even a grain of truth in that statement. For example, most BPM Suites provide integration adapters that can introspect backend systems and turn them into process components that are, in an important sense, service-oriented: Regardless of the internal platform, programming API, or data model of the backend system, integration adapters can expose functions of those systems via XML parameters, perhaps even an actual WSDL, and allow the process engine to orchestrate them without code. That’s huge, really the key to making application integration more agile and enabling point-and-click composition of end-to-end process implementations.
But in the SOA world, that’s not really SOA.
If you go to an SOA conference or webcast, you’ll find they talk little about orchestration and almost never about integration adapters. Instead, you’ll hear a lot about architecting collections of business services, the fundamental units of reuse across the enterprise. You’ll also hear about tools to build those services, repositories and governance policies to manage those services as long-lived enterprise assets, and registries to advertise them for discovery by solution developers. Of course, you’ll hear about graphical tools to orchestrate services in composite applications, but you’ll hear a lot more about an enterprise service bus – the scalable communications infrastructure interconnecting those services – and the ESB’s elaborate instrumentation to monitor service levels in real time.
Certainly, there will be some hand-waving about SOA enhancing business-IT alignment and BPM, but nothing concrete in the toolset to support it. Once they mention BPM, there is again a disconnect from reality. Orchestration is not BPM.
BPM is business-driven. It’s about optimizing and improving business performance at the end-to-end process level, innovating the business, making it more efficient, faster, more agile, more compliant with policies and best practices, and more measurable. It’s top-down because it begins with the end-to-end process.
SOA is IT-driven. It’s about transforming IT infrastructure, leveraging existing investment and breaking it into reusable parts, providing a high-performance reliable communications fabric for interconnecting those parts, and managing those parts for optimal discovery and reuse. The goal is making solution implementation faster and less costly, but it’s bottom-up because it begins with the parts, not the end-to-end solutions.
BPM and SOA are both important, and they should be used together. But today at least, they’re not.
So why do I say that most BPMSs today are not really layered on SOA? No architected business services, for one thing. Process components generated by integration adapters, for instance, are easy to create, but they are not architected as optimal units of reuse. Also, there is no enterprise service repository, no enterprise service registry. Well, there is probably a catalog of service-like components managed at the process or project level, but nothing to manage them as long-lived assets at the enterprise level. And there is no enterprise service bus.
The absence of an ESB is the most readily identifiable sign of a BPMS that is not really layered on SOA. In fact, in some ways the functions of an ESB are at cross-purposes with those of the BPMS process engine. For example, ESBs provide data transformation and content-based routing of messages from one service to another. Wait a minute, isn’t the process engine supposed to do that? Instead of managing all the process logic in one place – the process model, executed by the process engine – it’s now split into two, part in the process engine and part in the ESB.
ESB providers use a phrase that you never hear from BPMS vendors: loose coupling. Loose coupling is a central tenet of SOA and a core feature of the ESB. It means that a business service is a logical description of a function, not hard-wired to any particular implementation of that function. The service may be provided by replicated instances of a system throughout the enterprise, or even by a variety of diverse business systems, or by third party providers. Optimal reuse of the business service means the implementation of that service can be selected by logic independent of the process model, and can change over time without composite applications or business processes that use the service having to change, or even having to know. All the necessary selection, mapping and routing is done by the ESB.
That’s not how most BPMSs today work. In the usual arrangement, the integration middleware of a BPMS introspects a particular service endpoint (i.e. implementation of the function), not a logical description of the function that will be mapped to an endpoint by ESB logic at runtime. A BPMS process design tool that is expecting to use the mediation logic and adapters of an ESB would look a bit different than one that is expecting to use its own adapters and data mapping, which explains why it’s not a trivial matter to simply layer BPMS from vendor A on top of an ESB (SOA Suite) from vendor B. Today, if you want a true BPMS layered on true SOA, it’s easiest to get it pre-integrated from a single vendor. There are a few vendors providing it now, including IBM, Cordys, and webMethods, with BEA and Oracle, among others, waiting in the wings.
We must not lose sight of the fact that a BPMS without an ESB, enterprise service repository, governance framework, or registry still provides great business value and is all you need in many – probably most – situations. Creating architected business services and rolling out SOA infrastructure is a multi-year process that still is in its early stages in most companies, while BPMS lets those organizations build real solutions today.
So where is it most important to look for BPM layered on top of real SOA? Today the sweet spot is with high-volume, mission-critical, transactional processes with a heavy emphasis on system-to-system integration, as opposed to human-centric or collaborative processes. Another sweet spot is where service reuse and the benefits of loose coupling outweigh BPM’s more immediate benefits. For many organizations, that is still a few years off.
While BPMS layered on SOA is today the exception or special case, that won’t always be so. As BPM merges into the mainstream IT infrastructure, this layering will become the norm, and BPMSs will likely be able to work with any of the popular ESBs of the day. But we’re not there yet.
June 19th, 2006
No I don’t mean moblogging. More like “even my 79-year old Mom is into blogging.” Not about BPM (that would be scary), but the more invigorating throw-da-bums-out-in-Washington variety. So over the weekend we both went to the YearlyKos convention in Las Vegas, where 1000 of the top political bloggers and their subscribers — along with a surprising number of big-name politicians trying to grab onto the “netroots” wave — got together face-to-face in a bunch of panels, workshops, and general socializing. It was a bit chaotic as you might expect, but overall an amazing thing that Kos and friends pulled off.
One thing that resonated for me re BPMS Watch came from a panel on how blogs are affecting the mainstream media. It was how a blogger can tap into the distributed intelligence of the readership to advance everyone’s understanding. I think it was said by Christy Smith of firedoglake — supposedly the nation’s top Plame-ologist — who after gathering and publishing public documents on the CIA leak investigation heard from dozens of readers who had scrutinized various parts of it to bring out things that no individual would ever figure out. MSM journalists no longer have a monopoly on “the facts”.
That’s something I’ve tried to tap into on my blog, with somewhat less success, but I’m still trying. The ESB-and-BPM question got a few responses that helped me take the next step (I’ll post more on that soon) and I still think BPMS Watch readers are going to let me win my bet with Ismael. Unlike Christy Smith, my blog doesn’t get 100,000 visits a day (more like 200-300)… so it just takes longer.
June 12th, 2006
I’ve been focusing a lot of my publishing and marketing – monthly column, 2006 BPMS Report, BPMS training – in the past year through BPM Institute, which is owned by Brainstorm, the conference group, and now I’m thinking about next year. Which BPM portal do you think has the widest reach, most interesting stuff, is best to deal with, etc? Take a minute to vote in the poll in the blog home page sidebar. I’ve listed a few sites that come to mind. If you have another favorite, click the link in Other and it will take you to this post, where you should add your suggestion in a comment. And you can add any comments you have on any of these sites/organizations in this thread as well.
June 8th, 2006
Don’t ask me how, but Ismael turned the hubbub over BPM vs SOA into a discussion of top-down vs “middle-out.” Both threads (including comments) are semi-instructive, but somehow in the course of things he challenged me to come up with proof that top-down (i.e. BPM implementation driven from the business model) has ever worked. The challenge came in the form of a double-dog dare, with the promise of a trip to Hawaii tacked on if I could come up with 3 top-down implementations that met his “BPM 2.0″ qualifiiers. Doubting he was good for the Maui deal, I reduced it to a simple dinner bet, so now we both have some skin in the game.
Here are the ground rules:
- Significant-enough project (the process map has more than 100 steps)
- Integration with transactional systems through WSDL
- Human workflow through web-based interfaces
- Modeling and skeleton design done by process analysts* using BPMN
- Implementation done by IT people without writing code
- No technical support from the BPM vendor through executable design and deployment. [He doesn't say into production, just deployment.]
* process analyst defined as: “cannot explain the difference between DO-WHILE, WHILE-DO, and FOR-EACH loops, even when promised a free trip to Hawaii with friends and family.”
I’m hoping some BPMS Watch readers will come to my defense on this one, most likely vendors supporting BPMN, but user organizations who raise their hand would be even better. I need 3 to win the bet. We haven’t set a deadline yet. You will be lavishly praised in the blogosphere and in the real world as well for proving that BPMS actually does what it says!
June 7th, 2006
Also summaries of the roundtables. Check out this from OMG.
June 7th, 2006
Derek Miers called my attention over the weekend to two posts from the SOA blogosphere suggesting “bad blood” between BPM and SOA, framing it as the latest proxy war in an age-old struggle between business and IT. I suppose Derek, who doesn’t blog himself (yet), wanted me to point out how ridiculous this is (or at least embarrass myself trying). Anyway, I’m taking the bait.
The original cherry bomb was thrown by Christoper Koch in CIO Magazine’s blog, who described BPM vs SOA as “a new front developing in the war between business and IT,” and Joe McKendrick on ZDNet quickly poured gasoline on the flames. Koch tries to set himself above the fray but tips his hand by centering the discussion on business’s frustration with IT’s lack of agility and concluding that SOA is more likely to foster agility than anything he sees from the BPM camp. Thus, like most discussions of BPM from the SOA world, he gets a few facts right but generally misses the point.
Agility is important, and SOA is all about agility, but agility is really IT’s concern and not the central focus of business executives, nor is dealing with change the key objective of BPM. Better aligning processes with business goals; making processes faster, more efficient, and more reliably compliant with policies and best practices; making business performance more visible even when the process crosses organizational or system boundaries, and more actionable in real time… these are just as important as agility to business.
Koch’s ephiphany came at a recent BPM conference, where it dawned on him that “veterans of the [failed] business reengineering battle have… adopted BPM as their weapon of choice in gaining control of processes.” In contrast, at IT conferences, “SOA is all people talk about. SOA is the way that IT will enable the business to change its processes. But of course, SOA almost completely focuses on IT and integration rather than process.” He should add, but doesn’t, that process is about more than business integration. It’s also about improving human work, and as even the integration-centric BPM software vendors are now discovering, this is where the most energy is coming from in the BPM market today.
Yes it’s true, BPM people and SOA people are concerned about mostly different things, but they are hardly opposing armies facing off with guns blazing. As a veteran of BPM conferences myself, I can vouch for the fact that the keynoting class there does tend to put forth a generally anti-technology message, but I think more directed against vendors of BPM software than at IT architects laying the groundwork for SOA.
The grain of truth buried in this pseudo-war is IT’s discomfort with the BPM notion that implementation of business process solutions can and should be, at least in part, driven by models created by “the business,” the so-called top-down approach. Some in IT would rather take a few years to roll out a complete SOA infrastructure before thinking about orchestrating a few services to solve business problems. For some reason, they don’t understand BPM’s top-down model-initiated approach can actually accelerate the SOA rollout by fostering business-IT alignment with concrete performance metrics, and encouraging an iterative approach to the production implementation.
Assuming Koch does speak for at least a segment of the IT community, my take-away from all this is that BPM software vendors need to address IT’s concern that BPM is “unsafe” technology. So far their message has mainly addressed business values and concerns, and while they give frequent lip service to SOA, they haven’t really addressed how BPM can help IT in its transition to SOA.
BPM and SOA are natural allies, not enemies. While outrageous headlines and trumped-up issues are the staple of the blogosphere, this is one we can do without.
June 5th, 2006
