In my Links post last Friday, I linked to a post on Mike Gammage’s blog that quoted Janelle Hill of Gartner speaking at the recent Gartner BPM Summit in London:

The right answer in selecting a BPMS is often three BPMSs, based on the particular projects’ needs.

I commented that this seemed to indicate that Gartner is bowing to pressure from platform vendors that have multiple fragmented BPM offerings (e.g., IBM), and that it’s not a good thing for customers.

Just before midnight that night, I received a reply from someone who I met at a conference last year:

<begin rant>

Regarding your links today – and the Sourcing Shangri-La post featuring the Janelle Hill/Gartner quote :  "The right answer in selecting a BPMS is often three BPMSs, based on the particular projects’ needs." 

Couldn’t agree with you more on how disappointing this is.  This is a very unfortunate message that I seem to be hearing more and more lately.  For those of us out there getting muddy in the trenches, who use and implement a BPMS for business processes executed by [humans] that have [document] and line of business system [integration] inputs and outputs required for most activities within a single business process, this "three different BPMSs " reasoning doesn’t make any sense at all.  It does make a convenient pitch, however, if you’re a vendor trying to explain why you’ve acquired products that overlap in a confusing way and perhaps don’t want to lay out the money to integrate them.   Maybe I’m missing something, but I’m a little stunned that it seems to be so widely accepted. 

As long as vendors (and research VPs) continue to put this out there, the vendors (like Pega) who would never punish their end users or application support teams in a single organization with three different BPM suites to deal with will continue to see results like this (in a severe recession, no less):

“Feb. 22, 2010 – Pegasystems Inc. (NASDAQ: PEGA), the leader in Business Process Management (BPM) software solutions, today announced financial results for the year and fourth quarter ended December 31, 2009. Revenue for 2009 increased 25% to $264 million compared to 2008. Net income for 2009 nearly tripled and increased to $32.2 million.” (http://money.cnn.com/news/newsfeeds/articles/marketwire/0589312.htm)

<end rant/>

Couldn’t have said it better myself.

Aside from the really poorly scaled logo graphic at the top that looks all squished, does anyone see anything wrong with this website that pops up when I try to access the wifi at the Metro Toronto Convention Centre?

That’s right, $395 for access for a single computer. No, there’s no missing period in that number, it’s three hundred and ninety-five dollars. I realize that this is targeted at exhibitors, but seriously, this is flat-out extortion.

Note to anyone attending or exhibiting at a conference at MTCC: you’re in range of Toronto Hydro’s One Zone wifi, which is $10/day.

All week, the local tech community has been buzzing around the news that Bell Canada is throttling P2P traffic — specifically the widely-used BitTorrent protocol — for not only their direct Sympatico subscribers, but also for anyone who buys their supposedly unlimited DSL from a Sympatico reseller, such as TekSavvy. For those of you new to the traffic shaping/net neutrality wars that have been going on in North America over the past months, here’s why throttling P2P traffic isn’t good news:

• Bell Canada (and our only other "last mile" carrier, Rogers Cable) are violating their role as a common carrier: they’re supposed to deliver the data, regardless of what it is, subject to our individual bandwidth and download caps. As long as I’m not getting a higher bandwidth than I was promised, and don’t go over my monthly volume cap, I should be able to download whatever I want, whenever I want, because the contract that I signed with Bell implied that would be the case. If they can’t deliver that bandwidth, then they shouldn’t be selling it; furthermore, they should have taken the money made by all these years of overselling the same bandwidth and invested in improving the now-outdated infrastructure so that we wouldn’t have these problems now.
• The carriers, Bell and Rogers, like to position this as allowing equal access to everyone instead of allowing those evil file-sharing types to hog the bandwidth, but they don’t exactly have altruistic motives: both of them sell services (cable and satellite TV) that compete with downloaded video, and they want you paying $40+ to them each month to watch the TV that they choose rather than be able to select from a wide variety of alternative — and legal — video available on the internet. Furthermore, Rogers wants to use the same bandwidth that you would use for free video downloads to download their pay-per-view movies instead.
• Bell and Rogers have targeted the BitTorrent protocol for throttling even though it has many legal uses. Last week, CBC made history by offering a TV program available, DRM-free, for download by BitTorrent. This allowed anyone in the world with broadband access to have access to Canadian programming that might not be available on their local TV stations. By throttling BitTorrent, however, Bell and Rogers are effectively blocking access to that Canadian content within Canada, forcing people to watch it on Bell or Rogers’ TV services. Personally, I use BitTorrent not just for that CBC show, but to download new releases of Ubuntu, and other large open source downloads where the source site provides BitTorrent as an option in order to reduce the bandwidth demands on their servers.

What this all comes down to is a violation of net neutrality: Bell and Rogers are deciding which traffic on the network gets higher priority. They’re doing it now because they’ve failed to make the necessary investments in infrastructure over the years that would allow them to actually deliver what they sell, and coincidentally they choose to throttle traffic that competes with their other business areas.

Suffice it to say that Bell Canada didn’t have a good week because of this — it was all over the news, the DSL resellers are talking about suing, and even the unions are in on the action. Enter Jason Laszlo, a spokesperson (apparently associate director of media relations) for Bell Canada, who was quoted extensively on this issue in the press:

• "Regarding customers like Mount Sinai [a major Toronto hospital that was used as an example of how legal file sharing might be used for CAT scans], Laszlo said it’s their own fault for using a notorious application like file-sharing. ‘We’re blind to the content flowing through our pipes,’ he said. ‘Our goal is to ensure maximum efficiency for everyone.’" — Digital Journal, March 25th. ["Notorious"? Oh, puh-leeze. And if they were blind to the content, then they wouldn't be throttling file sharing.]
• "P2P programs are only employed by a small percentage of internet users, but they tend to make use of all the available bandwidth, Laszlo said. Reduced P2P use should provide a better balance between P2P and other users at peak times, he said. ‘I feel we’re on the side of good,’ he said." — CBC News, March 25th. [Throttling P2P is a good way to make sure that it is only ever employed by a small percentage of users, which is exactly what Bell wants.]
• "Bell spokesman Jason Laszlo on Friday reiterated the company’s position —that it was shaping traffic in order to prevent a small portion of bandwidth hogs from slowing speeds down for all customers." — CBC News, March 28th.
• "Jason is throttle-icious." — Jason Laszlo’s publicly-viewable Facebook profile, status update dated March 28th at 4:34pm.
• "Jason is realizing how little seperates [sic] most journalists from lemmings." — Jason Laszlo’s publicly-viewable Facebook profile, status update dated evening of March 28th.

Yes, those last two are real; his Facebook profile was posted on a broadband discussion forum yesterday afternoon (you can Digg the story here); he obviously was unaware of the impact of no privacy settings, since I was able to access his profile immediately after that even though we’re not directly connected and have no mutual friends.

My friend Mark Kuznicki channeled his outrage into a great blog post about how this hands the net neutrality advocates a gift, and messaged Laszlo on Facebook to let him know what we all think of his two-faced approach to media relations. Shortly after that, Laszlo’s profile was set to private so that I could no longer view it; this morning, it appears to be completely missing.

So what’s the lesson to be learned from this mess? The public is now aware and mobilized on the impact of traffic shaping on their daily lives, even if they haven’t yet heard the term net neutrality. To paraphrase Peter Finch’s character from Network, we’re mad as hell and we’re not going to take this anymore.

Oh, yeah, lesson #2: don’t entrust media relations for a sensitive subject to an inexperienced junior who doesn’t know well enough not to post inappropriate comments to his publicly-viewable Facebook profile.

Forrester just released their new report on human-centric BPMS. Hmmmm, the title is actually “The Forrester Wave?: Human-Centric BPM For Java Platforms, Q3 2007″.

BPM for Java? Good way to totally alienate the business community from ever wanting to be involved in selecting a BPMS, guys.

I was just about to start crowing over how I haven’t paid for internet access since I arrived in the Bay area last Tuesday — the ratty old Best Western in Mountain View had free wired access as well as being in the Google wifi zone, and the Hilton in San Francisco’s financial district doesn’t charge for wifi, the first Hilton that I’ve ever been in that didn’t — but I’ve arrived at the Hyatt Regency near San Francisco airport for the BPM Think Tank conference and find myself having to buy access through T-mobile.

When are the organizers of technology conferences going to start to insist on only booking at hotels with free internet access? When that starts becoming a competitive differentiator for their bread-and-butter conference bookings, the hotels will start to listen.

If you’ve emailed me this week at my kemsleydesign.com address and the email has bounced, it’s because I’m in the process of changing hosting providers and Yahoo (the relinquishing provider) is doing everything in its power to screw things up for me — like not transferring my domain to a new registrar upon request. I’ve updated my MX records to point to my new hosting provider (GoDaddy) while I’m waiting for the domain transfer to happen, and sometimes things get confused.

Email to me at the column2.com address shown on my blog profile page seems to be working fine, even though it redirects to the same kemsleydesign.com address, since the email for that domain name is routed through GoDaddy and it seems to know about other MX records hosted by GoDaddy.

With any luck, this will all be sorted out by the weekend.

I have a busy next few months lined up, between conferences that I’m attending (such as next week’s Gartner BPM summit in San Diego — check back here then for live blogging) and ones where I’m speaking (such as the Shared Insights collaboration conference in May in Las Vegas). Regardless of my role at a conference, I blog pretty much everything that I see and hear, which the conference organizers like because it gives them a lot of coverage, as well as giving me (and all of you, of course) an historical record of the conference in a searchable format.

I also had an invitation to speak at the American Strategic Management Institute’s BPM summit in Miami next month, but as of today, I’ve been uninvited (although the current version of the brochure on their site still list me as a speaker). The entire interaction with ASMI (or The Performance Institute — the email addresses are from this domain, but I’m not sure of the relationship between the organizations) has been a bit odd. It all started back in November, when I had an unsolicited invitation from Matthew Sheaff of ASMI to speak at the upcoming conference, which was at that time scheduled for March 19-21. His first email to me went like this:

On behalf of The American Strategic Management Institute, I’d like to extend to you an invitation to participate in The 2007 Business Process Management Summit being held March 19-21, 2007. Your remarks would begin at 2:30 on the 19th and last about an hour. The topic of the session that we would be honored for you to present on is “Using Business Intelligence Methods to Forecast Enterprise Process Improvement.”

Weird — what sort of conference has specific session titles preassigned four months in advance, before they even have speakers? Typically, if someone is asking me to speak (unless it’s a last minute fill-in), they specify a track or broad subject area and ask me for an abstract of what I’d like to speak about, and we’d work something out from that which suits their conference and that I’ll enjoy presenting. In most cases, I’m not paid for speaking at conferences, so I like to talk about things that I’m passionate about, and that also happen to fit into the conference theme.

I responded back to Sheaff that I was interested (after all, it’s Miami in March, how bad can it be?) and asked for a few details, and he responded:

As with all speakers, we cover your airfare to and from the event, transportation from the airport to the hotel, your food, conference attendance and one night stay at the hotel.

Okay, pretty standard stuff so far. A few weeks ago, I got an email from the event planner, Caroline Bracher, about speaker logistics. It included the phrase “We allow up to $400 for roundtrip tickets, for your reference if making your arrangements through another venue“, which in conjunction with Sheaff’s earlier assurance that they cover all travel expenses, I interpreted to mean that if I use their travel agent, everything is covered, but if I book my own tickets, they’ll allow me to charge them back up to $400. I have every intention of letting their agent book it, since you really can’t get a flight for $400 from Toronto to Miami this time of year — we are in another country, after all, and a cold one.

Yesterday, I email their travel agent and give him my planned dates of travel. He makes a couple of tentative bookings, and emails me back:

I have made two reservations for and emailed it for you. If you fly on US the fare is 603.95, but if you the AA flights, the fare is 751.90. Please let me know which you prefer cause Performance Institute will cover up to $400.00.

Huh? Must be some misunderstanding, Sheaff’s original email to me clearly stated that my airfare was covered. I emailed back, copying Bracher on the email:

Sorry, I will not be covering any additional airfare — Caroline, that’s not the arrangement that I had with you, you were to cover my airfare and hotel. Please sort this out and get back to me.

Silence descended. No phone calls, no email. Then this morning, the following arrives from Sheaff:

Due to some spacing limitations that we have encountered at the conference hotel in Miami – we’ve had to consolidate our two track event into one. Unfortunately, due to that, we’ve had to cut out some sessions. With that we’ve decided not to run the session on Business Intelligence. I want to thank you for all your help during this process and I hope that we can have the opportunity to work with you in the future. Caroline Bracher, who is cc’d on this email, will be handling all the logistics for the change in the program. I’m sorry for any inconvenience this may have caused you.

Things like this just make me shake my head in wonder. The difference between my airfare and their limit was $203.95 (or 351.90, if I went for the non-stop option so as not to have to spend 2 entire days in airports to spend 1 hour speaking at a conference). They’re charging attendees $1,795 for the 2-day conference, which means that about 60% of a single attendee’s fee would pay for all of my travel expenses.

If you’ve already booked for this conference, you may want to request the revised schedule from them: if they really have reduced it to a single track, it may no longer have the sessions that you’re looking for, and you still have a couple of weeks to get a refund. If their last email to me is inaccurate and they’ve just replaced me as a speaker because I wanted them to uphold their part of our speaker’s agreement: well, you can make your own decision on that.

Workflow Modelling, a book recommended by Bruce Silver (who knows more than a little about this subject).

Buy from Amazon in the US for $66.30.

Buy from Amazon in Canada for $106.50.

In case you’re not up on your exchange rates, today’s rates would make $US66.30 = $C77.20.

I just finished moderating today’s Gartner/Appian webinar on ebizQ, which means that I did the intro at the beginning, then moderated the Q&A at the end. On ebizQ webinars, audience members can ask questions through a typed chat window, and then I (as the moderator) can review them and pick out ones to ask. I also throw in a few of my own, especially if the questions are a bit slow coming from the audience.

Today, we had a sophomoric jerk from another BPM vendor decide to pollute the Q&A with a bunch of really stupid questions that had nothing to do with the webinar content, but were just personal jabs at Appian. I’m not revealing the name of the vendor because I don’t think that they deserve the publicity, but to the person in question, you have to realize that you acted like a complete moron, and my respect for your company just dropped through the floor. Maybe my opinion doesn’t mean much to you, but keep in mind that Jim Sinur from Gartner was also a speaker on the call, so had access to see all the questions that came up, and who asked them.

I’m off to this year’s BPMG conference, Process 2006, where I’ll be giving a presentation on Wednesday about Web 2.0 and BPM. I’m doing some final edits on my slides (I know, I should have had them in to the conference organizers some time ago) and thinking about how I want to focus my talk, and I realize that it will include some elements of a rant against what systems integrators and corporate IT departments do to ruin perfectly good BPMS’.

I come from a systems integration background, having run my own 40-person firm for 13 years, but I was never a big proponent of over-building systems. Of course, back in the old days, you couldn’t just take the BPMS out of the box and make it run, you had to write code just to have any end-user interface at all. Now, however, most BPMS have some sort of user interface out of the box, and even though it isn’t integrated with a company’s line-of-business systems and data, it’s a perfectly respectable way to get started. This is especially true in organizations that are just deploying BPM for the first time, where the users (and IT) really have no idea what it can do for them. My motto is to get something simple into production fast, then start the next round of design in collaboration with the users to figure out where to do the customization and integration that will make things easier for them.

Systems integrators and corporate IT departments may be unmotivated to allow this to happen, although for different reasons:

• Systems integrators get paid for the amount of work that they do. If they write a from-the-ground-up, all-singing, all-dancing customization on top of the BPMS, they make more money up front, and more money down the road when they are required for changes to the application. Although I was never averse to making money as a systems integrator, I tended to push solutions with less customization because I had limited resources to deploy (I kept my team small and the quality extremely high), and I was easily bored so wanted to get something into production, make the customer happy, and move on to another project. In fact, after I returned to private consulting, a large systems integrator to whom I was subcontracted as the principal architect for a client project had me sidelined on the project because I had the audacity to suggest that we do less customization.
  
• Corporate IT departments feel that they need to maintain control over all software in an organization in order to justify their existence. If the users can create what they need themselves, or can get the software that they need via an SaaS model, IT decreases in importance (and, likely, size) and might even be outsourced. Encouraging the development of software that requires a complex collaboration between IT and the systems integrator in order to install or modify it is in the best interest of an empire-building IT department. So is encouraging software that can only be used for pre-determined tasks, rather than allowing the users to modify the functionality to respond to their changing requirements.

Before you totally flame me on this, I readily admit that these are generalizations: not all systems integrators are greedy, and not all corporate IT departments are control freaks. However, when you come across resistance to doing less customization and giving more control to the users, there is often a grain of truth to these hiding in there somewhere.

Getting back to BPM, this has huge ramifications: over-customization of a BPMS has the effect of turning a nascent Web 2.0 application into a big steaming pile of legacy code. I’m not saying that all BPMS’ are Web 2.0 applications, but if you go back to the original O’Reilly definition of Web 2.0, BPMS’ score reasonably well on a number of the points:

• Web as platform, since almost all BPMS provide their end-user experience on a reasonably lightweight web interface. Many of them still haven’t moved their process designers to a pure web platform yet, which is essential for widespread collaboration on process design, and some use heavy-footprint technologies such as downloaded Java applets, but a zero-footprint web interface seems to be the direction in which most are moving.
• Harnessing collective intelligence, at least in the BPMS’ that allow for collaborative process design (not just executing of collaborative processes). This implies some sort of universally-available process repository, so that I can create the first draft of a process, and a colleague in another location can make their own modifications. Think “process wiki” as a design paradigm. Harnessing collective intelligence would be hugely improved by allowing for tagging of process instances, too.
• Data is the next “Intel Inside”, or as Tim O’Reilly puts it, “database management is a core competency of Web 2.0 companies.” Almost without exception, BPMS’ are built on databases, although the focus in the past has been more on the functionality and not so much on the data as a commodity. However, emerging standards are allowing for the exchange of process designs via BPEL or XPDL, and most BPMS’ do some sort of streaming of process execution data to a business intelligence platform where it can be sliced and diced to your heart’s content. In-flight processes are a bit trickier, since that data is usually proprietary to the execution engine, but I think that the designs and the execution data are the key ones.
• Software above the level of a single device, where the interfaces are suitably advanced to allow not only the Mac or Linux desktops to participate, but mobile devices too. This is trailing somewhat behind the “web as platform” initiatives, since many vendors are still using platform-specific extensions in order to achieve web interfaces, and as I mentioned earlier, many of them also don’t have their process design and management tools fully webified.
• Rich user experiences for those vendors who have embraced AJAX for their user interface. Those that are lumbering along with downloaded Java applets don’t meet my standard here.

The Web 2.0 areas where I think that most BPMS’ fall down is with lightweight programming models, and in ending the software release cycle. In the case of lightweight programming models, we need a way to mashup process instances with other things in a way that can be done by someone in the business unit, not IT, or even by someone external to an organization if the process has external exposure. We also need RSS feeds from processes, which could easily replace/supplement email alerts and management dashboards for monitoring processes, and put the control of the monitoring process squarely in the hands of a user who wants to monitor for a particular condition.

In the case of ending the software release cycle, this is based in part on minimizing or eliminating customizations to the BPMS that increase the regression testing cycle, and in part on getting the BPMS vendors to commit to making their upgrades completely non-disruptive. I’ve been writing software for over 25 years, and I know that that’s easier said than done, but the vendors can’t start with the initial assumption that they can just throw their customer base into complete disarray with every upgrade due to, for example, database schema changes that require significant conversion efforts. Even better, get on the SaaS bandwagon and start offering BPMS as a service. As Salesforce.com has proven, if you offer a good service at a reasonable price, people will trust you with their data.

My point in this rather lengthy post is that many BPMS’ are already halfway to being Web 2.0 when you take them out of the box. It’s what you do with them after that that determines whether they live up to that potential, or just become more legacy code.