Recently I participated in a podcast with fellow ebizQ bloggers to make some fearless predictions for BPM in 2007. Making predictions, of course, is a dicey affair. There are only two ways to do it. Either you make a firm prediction and hang your hat on it, or you make a fairly general prediction that few can refute and fewer still will bother to do so.

One interesting example that actually achieved both objectives (unintentionally, of course) was this statement of Henry Ellsworth, Commissioner of the U.S. Patent Office, in his 1843 report to Congress: "The advancement of the arts, from year to year, taxes our credulity and seems to presage the arrival of that period when human improvement must end." This is apocryphally misquoted as: "Everything that can be invented has been invented."

Check out our fearless predictions on this podcast. Fellow intrepid gazers at the crystal ball are Keith Harrison-Broninski, James Taylor, Joe McKendrick, Sandy Kemsley, Michael Dortch, and David Kelly (whose article put the said crystal ball temptingly on our bloggers' table). Elizabeth Book, ebizQ's editor-in-chief, moderated the podcast.

Of course, if none of the predictions come true, then we'll borrow a leaf from Yogi Berra and claim that 'the future ain't what it used to be.'

But a large part of where the BPM market goes is really in our collective hands. One of the 'sooths' that I say is that there will be an increasing awareness and adoption of BPM within companies. It is up to us—bloggers and readers— to make sure this comes true, by actively evangelizing the benefits of BPM, educating our colleagues on the concepts of BPM, and boldly going where no ERP ever ventures.

I'll be in Chicago this Thursday, bravely spreading the word along with some of my colleagues through a BPM Master Class. Oh yes, the classes are free. Attendees get a free copy of my book ('The Power of Process'), and get to hear Bruce Williams, co-author of three 'For Dummies' books in Six Sigma and Lean. But most important, attendees get a ton of information and practical tips on BPM, plus a first-hand look at BPM in action through webMethods' Fabric 7.0 platform.

Posted by kirankg in BPM • SOA | Permalink | Comments (0) | TrackBacks (2)

At the beginning of the thirteenth century, the Tatars of the East were a ferocious people. They were very effective at raiding and plundering. Their most remarkable aspect was their speed of execution. They copied Caesar’s ‘Veni, vidi, vici’ mantra, but conveniently omitted the ‘vidi.’ Not for them the survey of their opponents or any attempt at understanding them. Instead, they came as a flood and departed, seemingly in one breath, leaving behind total destruction. They nipped at the edges of Genghis Khan’s empire so persistently that he was determined to either exterminate them or discipline them. Fortunately for both parties and unfortunately for his enemies, he managed to discipline them by the simple expedient of killing any Tatar who was taller than the axle of one of his desert carts (James Michener, Poland).

Every time I talk to both IT and business users, listening to their description of the mess of applications, I am reminded of the Tatars. Like each set of functional applications may be very effective, much like a small band of Tatars. But best of breed solutions do not make up a coherent enterprise architecture, just as the Tatars never won any major wars or leave any lasting legacy behind them. It took a Genghis Khan to control them, and orchestrate them into his campaigns. Before you start wondering if you should pull the plug on applications that don’t conform to the axle wheel of your architecture stack, consider how to achieve the same positive outcome—discipline—without resorting to catastrophic measures.

Firstly, realize that discipline need not be boring or bureaucratic. Secondly, discipline need not add overhead; in fact, properly cultivated, discipline can increase speed of execution. Thirdly, discipline can become part of corporate culture, a habit, a way of doing business. It means picking an investment strategy and sticking to it, without second-guessing it or letting your emotions upset it. It means growing your company in a responsible way (i.e., paying attention to risk). It means complying with the highest standards of business ethics. It means methodically ticking off the pre-flight checklist before takeoff without relying on memory, even though you have done it a thousand times before.

To institutionalize discipline, a governance process is essential. This is the umbrella process that ensures all other project methodologies, ways of doing business, operational mechanisms, etc. comply with best practices, ethical guidelines, and regulation. In the context of process management and its cousin, SOA, governance implies, among other things, the following:
• Processes & services are documented correctly and completely
• Documentation is maintained and kept current
• Projects reuse processes and services
• Implementations take into account the full end-to-end process, and not just the sub-process that is in scope for the project
• There are policies for submitting processes and services into the repository, and that these policies are followed
• Processes that are executing are monitored against key performance indicators, and that proper alerts and notifications are in place

This is not an exhaustive treatment of governance, of course. But the key is that companies cannot avoid the consequences of non-governance. They will end up paying the piper sometime. But companies do have option of making governance part of their corporate culture. To do so, top executives must be ready to lead the change in mindset. At some point, they must be prepared to pay for solutions that are comprehensive and address the various aspects of governance.

If you spot a copy of the Management Secrets of Genghis Khan floating about your CEO’s office, quietly substitute it with the Power of Process.

Posted by kirankg in BPM • SOA | Permalink | Comments (0) | TrackBacks (0)

My fellow eBizQ blogger Beth Gold-Bernstein has been using Alfred Chuang's comment that "BEA is the only unified SOA platform" to spark a conversation about the definition of a complete and unified SOA platform and whether SOA is really a product. I think she makes a lot of good points about the current state of the market, about what SOA really is, and about how the various SOA tools and components should converge.

However, it's also started a bit of a side conversation about the veracity of Alfred's comments. And to the people in that conversation I say "lighten up". CEOs and product marketers have been saying "the only solution to offer a complete..." since the beginning of time. A quick Google search for "'the only' BPM solution" reveals 94,000 different claims of uniqueness in a very crowded marketplace. Some of the top claims were "the only integrated platform to deliver both SOA and BPM", "The only unified ECM & BPM enterprise platform", "the only BPM solution that combines the industry leading analytics capabilities with a powerful business process management platform", "the only BPM solution that seamlessly integrates content", "the only BPM solution that offers enterprise-class search", and "the only vendor in the industry to combine the power of process, knowledge, and analytics in a unified BPM suite".

Every one of these claims is based on a very narrow definition. If you challenged any of these claims the vendor would come back with the argument "other vendors aren't really 'enterprise'", or "other vendors aren't really 'unified'", or "other vendors aren't really 'seamless'" or some other nonsense.

The bottom line is that anybody can be the market leader if you get to make your own narrow market definition. Alfred was trying to call attention to the fact that one of the SOA thought leaders and enterprise middleware platform leaders now owns one of BPM leaders. And highlighting that the unification of those technologies and strategies can benefit customers. A legitimate point, in my opinion. Let's not get too caught up in reading more than that into a press release.

Posted by davidogren in SOA | Permalink | Comments (0) | TrackBacks (0)

Continuing my "SOA versus" theme, I really enjoyed Daryl Plummer's "Web Services At A Crossroads" article in Optimize magazine. In the article Daryl, a Gartner fellow, describes the conflict between the enterprise architects that are using web services as the platform for Service Oriented Architecture and the Web 2.0 architects that are using web services to build mash-ups, AJAX, and other consumer oriented applications.

One of the points that Daryl specifically mentions is how the desire by SOA architects to use web services for enterprise applications is driving the increasing complexity of the WS-* set of standards. He suggests that if you are looking for a enterprise-level distributed-transaction environment you should look to a real distributed transaction system rather than waiting for the WS-* standards needed to support that level of functionality.

I can't be the first one to see the parallel to EJBs in the Java world. When EJBs were added to Java they were designed to support this enteprise level of functionality. And as a result there was a lot of complexity in using EJBs. The problem with EJBs was that only a very small percentage of applications actually needed this enterprise functionality. And so, EJBs developed a very bad reputation as overly complex. And an entire movement demanding a more simplistic model emerged and the EJB model is now struggling to complete with more simplistic POJO-based systems.

I see the same thing happening in the Web Services world. The WS-* crowd is trying to meet the needs of enterprise SOA architects, but they are alienating the mainstream web services developers with their complexity. Not to mention the bickering that's going on in the standards bodies which scares people aware by making them worry about which standards will "win". One of the things that I like about ESBs is that they can encapsulate some of this complexity. The bus can abstract out some of the complexity and the services can just be services.

Let's learn from the past for once. Let's not let web services be another EJB debacle or compatability challenged CORBA. Let simplicity rule the standards and let the infrastructure manage the complexity.

Afterword: After typing this up, I see that Elizabeth Book commented on this article a couple of weeks ago. Not sure how I missed her post, but better late than never.

Posted by davidogren in SOA | Permalink | Comments (0) | TrackBacks (0)