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.

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.

We need a BPM camp

I received yet another email about the upcoming Gartner BPM Summit, and I continue to be horrified by the price of conferences: U$1,895 for 3 days?! Or how about the AIIM records management conference in Toronto next week: C$2,899 for 3 days? By the time you add in travel and living, it’s no mean chunk of change when you’re an independent: I don’t have the luxury of a big company picking up my tab. Even those of you working for larger companies know that it’s not easy to find funding for attending conferences, even if you believe that they’ll be of value.

I know that analysts are in the business of making money from knowledge (so am I), but knowledge is becoming a commodity these days, and a lot of people won’t (or can’t) shell out that much cash just to sit in a room for three days and hear someone talk when the same information is available (albeit in a less structured manner) in a variety of other forms at a much lower cost: blogs, podcasts, vendor seminars, webinars, analyst reports and other sources that don’t believe that it’s in their best interests to charge everyone an arm and a leg just to have a conversation.

I only attend these big-money conferences once every few years; in the interim, I do just fine with my RSS feeds, daily email newsletters, webinars, vendor seminars, and other sources of free or reasonably-priced information. For example, in the past year, I’ve attended two major conferences: BPM 2005 in London, where I paid full price as an attendee, and FileNet’s user conference in Las Vegas, where I was a speaker so had my conference fee waived (check out the series of entries in my November archive, where I was blogging live from the conference sessions by emailing from my Blackberry). I also attended some local seminars/mini-conferences at little or no cost, such as e-Content Institute, plus some vendor seminars; in fact, I spent yesterday morning at a LabOne seminar hearing about how their next generation of products is going to better integrate into my insurance clients’ systems.

I attended a ton of webinars last year, most from ebizQ and BPMinstitute.org, but also from vendors such as Global 360 and Proforma (search my archives for “webinar” to see my comments on the webinars). I have a list of past webinars that I want to watch but haven’t found time yet: a wealth of information delivered to my desk, for free, with a relatively modest amount of vendor promotional material wrapped around it.

There is something to be said about a conference atmosphere, however. As much as I dislike most professional networking (I’m a closet introvert), conferences provide a great opportunity to meet people with the same interests: for me, that includes potential clients, but also vendors, potential partners, industry analysts and a variety of other types. Most conferences also include some sort of vendor showcase where I can have a peek at the latest and greatest technology.

The dilemma is this, then: given that much of the “information” (content) of the big conferences is available in the public domain or through lower-cost alternatives, how do we share that information in a conference-like networking atmosphere?

The answer may lie in the new generation of “un-conferences” or “camps”. These still exist mostly as technical conferences, but with the focus on collaboration rather than presentations (i.e., have a conversation guided by an actual practioner rather than death-by-Powerpoint from a hired speaker), limited enrolment, and free (or nearly so) fees for attending, this movement has the potential to expand into other traditional conference areas. One popular technical camp is BarCamp, including the recent TorCamp. David Crow, the prime organizer of TorCamp (and my neighbour), just posted about the camp format for un-conferences, and links to Chris Heuer with more about these sort of amateur conferences. A camp with a specific focus on integration is Mashup Camp next month in San Jose, which I’ll be attending because I want to explore how to use mashup concepts in the context of enterprise application integration: this is the part of the future of orchestration. And the expected “conference fee”? $0.

Camps are still, for the most part, for techno-geeks (I admit it, I am a geek). But how long before this “amateur” format hits the mainstream? How long before Gartner’s BPM summit is competing with BPMcamp?

Selecting a BPMS without falling into the chasm

This week’s BPTrends Advisor newsletter discusses the “crossing the chasm” paradigm when it comes to BPM, and highlights a current issue with BPM within organizations that still leaves us in the “early adopter” (i.e., pre-chasm) phase:

Most companies talk about processes these days, but few are willing to make a comprehensive, top-down commitment… [T]hey see business process management as a means of curing specific problems or of making specific, incremental improvements. Most companies don’t see process as a management philosophy and a way to organize the company.

I see a lot of that happening with companies that I work with: BPM is typically selected, purchased and customized for a departmental project, and when it comes time to look at other applications, it’s like starting all over again since no one considered the enterprise requirements from the beginning. Sadly, one exception that I saw to that was an organization that selected an integration broker suite as their BPM “standard” after looking at only the EAI-type process requirements across the organization, with the type of results that you might expect. There’s some fairly well-accepted criteria for selecting a BPMS these days; Gartner recently published a report on them that’s worth reading if you’re in the marketplace.

I don’t think that every acquisition should be held up in order to perform a full enterprise-wide needs analysis, but for a technology that is becoming as pervasive as BPM, you should at least be looking beyond that first project. You wouldn’t buy an RDBMS without considering enterprise-wide needs; we need to start thinking about BPMS in the same way, or we’ll never get across this chasm.

Integration FUD factor

A good article in DMReview (where normally I find much more about data warehousing and business intelligence than integration) on Fear, Uncertainty and Doubt about integration, especially for small-to-medium sized businesses that don’t have IT budgets that look like the GDP of a small Pacific nation. I just love it when someone cuts through all the crap:

Integration is moving data elements from point A to point B with the necessary translation in between…Tier-one integration vendors have conditioned the market to believe that integration should cost millions of dollars and take years to implement. With today’s offerings, this is simply no longer the case.

Couldn’t have said it better myself.

Chief Process Officer revisited

A while back, I read a post by Phil Gilbert (CTO of Lombardi) on his blog about the position of Chief Process Officer. Although he joked (I think) that the term sounds somewhat Orwellian, he rightly points out in this increasing complex world, the process is becoming the business, and that every business needs someone — the CPO — to focus on making this transition to a process-based organization.

About a week ago, I saw this CSC white paper From CIO to CPO via BPM by Howard Smith (co-author of BPM – The Third Wave with Peter Fingar), which opens with:

The prediciton that the CIO’s job will evolve into managing business processes — not just technology — is not new. What is new is the state of process technology. It has reached a point where it is about to go mainstream.

(Note that normally I don’t bother to quote from PDF files that have such an overabundance of DRM wrapped around them that they disallow copying text, and force me to retype a few sentences to reference, since I know that they’re not all about sharing the information anyway. Even Gartner doesn’t do that.)

It’s a rather thinly-veiled CSC promotional piece, and a bit academic and long, but there are some interesting points. First, he makes the point that BPM can fit in a lot of places. He uses an ERP orchestration example, which is really just a subset of the entire SOA/orchestration integration picture that BPM helps to pull together. I believe that too many organizations still think locally when they’re buying BPM initially, and end up with departmental systems that don’t have the legs for the enterprise needs; Smith talks about some situations where BPM can replace ERP (which even I think is a bit radical).

He has a great sidebar called “Distortion of BPM by the IT Industry” (page 24) that I completely agree with, about how any vendor who had anything to do with process suddenly relabeled themselves as BPM. I teach a seminar on BPM called Making BPM Mean Business, and I spend what must seem like an inordinate amount of time on this exact subject, looking at how all of these disparate technologies came to be called by the same name.

Ultimately, Smith’s white paper says almost nothing about the role of a CPO. Is this a new role for the CIO? Or, as some others believe, is this a business-based role (rather than a technology-based role) that works in tandem with the CIO to effect process change across the organization? Or something that lies in between IT and business, much like the postion for the enterprise architect that I discussed back in this post? Organizations have been using this title internally now for a few years, and I’m sure that it will take a few more for there to be any sort of agreement on what a CPO really is, and does.

Business Process Modelling for Dummies

I blogged last week about Human Interaction Management as a process modelling notation, along with some dissenting opinions that favour BPMN for process modelling. I tend towards the BPMN camp, and don’t see any benefit in using different modelling notations for some artifical divisions between “human” or “system” processes, considering that the goal of most BPM implementations is to convert some of the human processes into system processes in order to gain efficiency.

One of the biggest problems with any process modelling notation is that the techies (and, having a very techie background, I sometimes fall prey to this myself) tend to put too much detail in the models that are used to gain consensus among all stakeholders: once a model gets past a page or two, anyone who isn’t intimately involved with the modelling efforts won’t understand it — not because they’re not capable of understanding it, but because they don’t want to spend the time tracing through pages of stuff that has way more detail than they really need to know.

In a recent article on Keeping BPM Simple for Business Users, Michael Havey discusses the inherent problem of comprehensive notations such as BPMN or UML activity diagrams: the business users don’t understand them. Well, they get the gist of them, but don’t understand many of the finer points of the notation, which means that much discussion of the business processes during requirements gathering and functional design ends up being about the notation rather than the business processes that are being modelled. He proposes a “dumbed down” notation of just boxes and arrows, but I think that by modelling processes at a higher level for general communication with the business users, they can understand the notation: I think that the bigger problem is too much complexity in the diagrams — such as trying to present business users with sufficient BPMN detail to map directly to executable BPEL code — not an overly complex notation.

There’s been a significant focus on process modelling notations in the past few months, both as an adjunct to a BPM initiative, and as a way of modelling non-automated processes as part of a Lean or Six Sigma process improvement initiative. As process becomes a key competitive differentiator for more and more businesses, that interest will only increase.