Author: sandy

Circular quotes on BPM and SOA

All of a sudden, there’s a lot of noise around enterprise mashups. Dennis Howlett posts about BPM and SOA, quoting a post by Jeff Clavier on the same topic. Dennis’ post also quotes a post by David Berlind which is actually a quote by me from an earlier quote that David quoted, and Jeff quotes David’s post that refers to me, so it all seems to come around in a circle to my earlier post on mashups and corporate SOA. Sometimes blogging is a bit like the telephone game.

Equally interesting is Jeff’s post about a TiE SIG Software event next week on Web 2.0 in the enterprise. I would SOOOO like to be there; if I had know about this earlier, I might have left for Mashup Camp a few days early.

What it comes down to is that Web 2.0 is, or will be, all about integration. David Linthicum posts about Salesforce.com becoming a web service provider (without yammering on about how they had another outage in the past week, as everyone else has been doing, ignoring the fact that outages occur all the time inside corporate IT but you just don’t hear about it) and links to Phil Wainewright’s interview with the Salesforce.com CEO, who has the grace to admit that he didn’t visualize the integration potential back when it all started.

Killing me softly…with SOA

Joe McKendrick posted last week about whether open source or SOA is killing the software industry faster, right on the heels of a couple of articles in eWeek about how E-Trade is switching to open source (E-Trade’s not just implementing Linux, which would hardly raise an eyebrow these days, but also components higher up in the stack, such as web server, application server and transaction management software).

From the point of view of the software industry, these are both disruptive technologies that fundamentally change the way that business is done. Funny, after all these years of introducing disruptive technologies to other businesses that resulted in some pretty major upheavals, software companies are getting it back in spades.

As for SOA and other technologies that make software development faster and easier, I say “bring it on”. I have little tolerance for systems integrators (or the professional services arm of software vendors) that won’t use newer, better technology when it makes them less money, although there are a few of them that seem to get it.

Business rules out of the trough

Jim Sinur, who is THE name in BPM at Gartner, has a recent article about business rules. He believes that BRE is finally out of the trough of disillusionment (a part of the Gartner “hype cycle”, and not a good part as you might guess by the name) and finally has the functionality and ease of use for mainstream usage:

Today’s rule technologies run well on all mainstream technology platforms and are being included in hybrid business and infrastructure solutions running in high-volume situations. Because of this change, a number of technology sectors are embracing and embedding rule technology, including Business Process Management (BPM), application integration, simulation, and Business Activity Monitoring (BAM).

He goes through 12 reasons to embrace rules technology (the BRE 12-step program, if you like), split across beginner, intermediate and advanced uses of BRE. Pretty much everything that you would ever need to convince your organization to take a good look at BRE is there, ranging from agility to cost savings to understanding the business to complex problem-solving to dynamic policy compliance.

BRE is definitely a boon to business agility if it’s used properly and control is (at least partially) in the hands of the business. As I’ve pointed out in the past, however, acceptance is still a bit of an uphill battle in spite of the obvious benefits. In particular, I consider BRE to be essential as a component of (or tightly integrated with) BPM in order to handle the necessary complexity, to allow sharing of rules across applications, and most importantly because it enables changing in-flight processes. Having BRE in your BPM also helps with your compliance initiatives as well as agility. Remember that BPM focuses on how people and systems interact, whereas BRE focuses on how decisions are made, and you really need both in order to build good process management.

By the way, I welcome any comments from the business rules experts (which I’m not) on the proper acronym for business rules these days: BRE? BRM? BRMS? Help me out!

Gartner disses tactical BPM

In the findings from their Insurance Industry research meeting published this week, Gartner states the bleeding obvious:

Tactical BPM Approaches Will Cause Rule Management Nightmares for Healthcare Payers

It’s been pretty obvious for some time that BPM should not be a tactical, departmental decision, regardless of your industry. I’ve been working in this industry long enough to remember when BPM (workflow or EAI, before the Grand Consolidation) was sold as an application. Then, it was sold as a toolset. Then (again), it was sold as an application. Now it’s being sold as infrastructure, and I think the vendors finally have it right.

As soon as you start looking at your business processes, you’ll find something in your organization that could be helped out by the functionality provided by a BPMS: automation of manual steps, orchestration across disparate systems, process governance, whatever hits the hot buttons. And what you’ll find in almost all cases is that the actual business processes span several business departments, although the systems that support them don’t, leading to a lot of manual processes handling the interfaces between departments. So although you could make a tactical decision to buy a BPMS just for a specific business department’s urgent needs, if you don’t consider where the tendrils of that process reach, then you’ll still be stuck with those manual handoffs to areas outside the core of the process. The only path to a solution is to have BPM as part of the enterprise-wide infrastructure that supports all business departments, so that your business processes can extend their reach across the organization (and beyond) in the most effective way possible.

The same goes for business rules, which is part of what Gartner is saying: although they state that rules need to be integrated across applications and multiple rule engines, I’d go a step further and say that a common business rules engine (BRE, or BRMS) needs to be part of the enterprise-wide infrastructure as well. It’s critical that different departments have access to the same business rules: the same rule might be applied at a step in a back-office process, by call centre staff during a customer call, and by auditors when creating compliance documentation. The same rules need to be universally accessible by applications throughout the organization, without the propagation delay or lack of synchronization that could be caused by using multiple BRE.

Your business processes and business rules reach across your entire business. Your BPMS and BRE have to do the same.

Mashups and the corporate SOA

I listened to a podcast last week of David Linthicum interviewing Dion Hinchcliffe that really helped to coalesce my thoughts about mashups, Web 2.0, SOA, composite applications and the future of integration. I was walking along a street in downtown Toronto, listening to it on my iPod, and making enough facial expressions, hand gestures and remarks aloud that I was likely written off as one of the usual crazies: it’s very exciting when someone with very similar ideas to your own states them much more clearly than you could have said it yourself.

A couple of weeks ago, I posted about mashups and the implications for enterprise integration, which of the integration vendors is likely to jump on this bandwagon early, and noted that I’ll be at Mashup Camp later this month because I really want to explore the convergence of mashups and enterprise integration. Unbeknownst to me, Dion Hinchcliffe had published an article in the SOA Web Services journal in late December entitled Web 2.0: The Global SOA, which was the focus of the podcast, and blogged about the 100’s of services available on the “giant service ecosystem” that is the web:

An important reason why the Web is now the world’s biggest and most important computing platform is that people providing software over the Internet are starting to understand the law of unintended uses. Great web sites no longer limit themselves to just the user interface they provide. They also open up their functionality and data to anyone who wants to use their services as their own. This allows people to reuse, and re-reuse a thousand times over, another service’s functionality in their own software for whatever reasons they want, in ways that couldn’t be predicted. The future of software is going to be combining the services in the global service landscape into new, innovative applications. Writing software from scratch will continue to go away because it’s just too easy to wire things together now.

The information on this is now starting to explode: David Berlind (organizer of Mashup Camp) discusses the bazaar-like quality of the mashup ecosystem, Stephen O’Grady pushes the concept of SOA to include mashups, and even Baseline Magazine is talking about how mashups can free you from the tyranny of software vendors with a discussion about how some of the services feeding mashups could be used in an enterprise integration context.

All of this has huge implications for business processes, and the type of BPM that currently resides completely inside an organization. Most BPM vendors have enabled their products to be consumers of web services in order to more easily play an orchestration role, and some customers are even starting to take advantage of this by invoking web services that integrate other internal systems as steps in a business process (although a lot are still, unfortunately, stuck in earlier, more primitive generations of integration techniques). Imagine the next step: as corporate IT departments get over their “not invented here” fears, the BPM tools allow them to integrate not just internal web services, but external services that are part of the Web 2.0 mashup ecosystem. Use a Salesforce.com service to do a customer credit check as part of processing their insurance application. Integrate Google Maps or Yahoo maps to determine driving directions from your service dispatch location to your customer’s location in order to create service call sheets. It’s like software-as-a-service, but truly on a per-service rather than per-application basis, allowing you to pick and choose what functions/services that you want to invoke from any particular step in your business process.

Dion Hinchcliffe thinks that 80% of enterprise applications could be provided by external services, which is a great equalizer for smaller businesses that don’t have huge IT budgets, and could almost completely disconnect the issue of business agility from the size of your development team. I think that it’s time for some hard introspection about what business that you’re really in: if your organization is in the business of selling financial services, what are you doing writing software from scratch when you could be wiring it together using BPM and the global SOA that’s out there?

Update: David swamped his podcast provider and ended up moving the podcast here. Reference also updated above.

Business (rule) analysis

I received the call for papers for the 9th International Business Rules Forum, which has prompted me to browse through the other business rule-related tidbits that I’ve been viewing over the past few weeks. If you’ve been reading Column 2 for a while, you already know that I think that business rules are a crucial feature in BPM, whether the BPM contains them inherently or as an add-on: you can find some of my previous posts on BPM and business rules here, here, here and here.

Rolando Hernandez recently posted a short term outlook for business rules — in short, that BR provide huge competitive advantage through business agility — plus an opinion on the differences between a business analyst and a business rules analyst.

The business rules analyst is focused on separating rules from code. The rule analyst walks and talks business… The rule analyst talks about business rules and business logic. The rule analyst means business.

The business analyst sees rules as code. The business analyst talks about the system. A business analyst is often a systems analyst by nature, and by training… The systems analyst means code.

I don’t think that there is a big difference in the inherent skills of business analysts and business rules analysts; rather, I think that systems analysts need to stop foisting themselves off as business analysts. Rolando starts a paragraph describing the business analyst (“the business analyst sees rules as code“), segues through an assumption (“a business analyst is often a systems analyst by nature, and by training“) and by the end of the paragraph is referring to the systems analyst rather than the business analyst, as if there were no difference. Yes, this happens, but it’s unfair to paint all business analysts with the same brush.

I also see the opposite problem, where a business user is designated as a business analyst, even though he (or she) has no skills or training in analysis; since he’s not trained to write requirements that are both necessary and sufficient, the resulting solution will not do what the business needs it to do. Furthermore, since he’s probably not up on the latest in associated technology areas, he’s unlikely to think outside the box because he doesn’t even know that the box exists.

The trick is to meet somewhere in the middle: a business analyst or business rules analyst needs to be focussed on the business, but be aware of the capabilities and limitations of the technology. The first job of the business (rule) analyst is to determine the business requirements, not write a functional specification for how the system might behave, as I’ve posted in the past. A business analyst needs training in the business area under study, but also needs training and experience in gathering requirements, analyzing business functions, optimizing business processes and documenting requirements, plus a high-level understanding of the functionality (not the technology) of any systems that might be brought to bear on a solution.

BPM Implementation Challenges

I just finished writing an article for the March/April edition of AIIM‘s E-DOC magazine on some of the pitfalls that I’ve encountered in my experience implementing BPM systems in the past, and my only problem was keeping it down to 750 words as I started to reminisce about all the ways that things can go wrong with BPM implementations.

Today, I saw a very timely post on Competitive Excellence Through BPM where Vinayak Khadye discusses the challenges that his employer, an insurance company in India, is expecting to encounter in their upcoming BPM/ECM implementation. Interesting, but not surprising, that his first three concerns are management-related (change management, managing expectations, and resource committment), while he has only two technical concerns (integration with back office systems, and migration of a proprietary image repository).

Also of interest is that the top three BPM implementation mistakes that I identified in my E-DOC magazine article are completely different from any identified by Vinayak, since I chose to focus on issues around product selection and the design of the solution — I am an architect, after all, so that’s what I spend a lot of my time thinking about. However, I’ve promised the E-DOC editor that I won’t blog the same material until they publish the article, so you’ll just have to wait until next month for my top three!

More BPM links

Thanks to J-C for pointing me to the e-workflow portal, which is co-sponsored by the Workflow Management Coalition (WfMC) and the Workflow And Reengineering International Association (WARIA). The white papers and case studies are a bit out of date, but it’s worth poking around the links. I’ve added it to my BPM lens under the “BPM Information/Reference” section.

BPOKI 06

Dr. Markus Strohmaier, a Column 2 reader in Austria (although I don’t see him on the Column 2 Frappr map!) has alerted me to a special track on Business Process Oriented Knowledge Infrastructures (BPOKI) at the International Conference on Knowledge Management to be held in Graz this September.

According to the website:

The event aims to critically discuss new theories, concepts, ideas, instruments and systems that address support for knowledge intensive business processes in organizations.

If you’re interested in presenting a paper, the BPOKI call for papers is looking for contributions on research prototypes, theories, conceptual frameworks, taxonomies and ontologies, technical applications and solutions, and all manner of critical arguments and discussions.

BPM think tank

Last March, a BPM think tank was held with support from WfMC, BPMI, OMG and other standards organizations (original link here, but the BPMI.org site seems to be down), then a follow-up session at the AIIM conference in May. This year, the 2006 BPM think tank is an OMG event (OMG absorbed BPMI last June), to be held in Fairfax, VA in May.

I’m not sure what that means to those of us who want to attend but aren’t OMG members, but I’m sure that Phil will keep us posted.