Grow up, guys

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.

BPM and Web 2.0

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.

Just feed me

Email newsletters: the web 1.0 of permission marketing. How many of these do you subscribe to? How many that you receive do you actually read? I receive a number of email newsletters each day, almost all on the subject of technology in some way, but I have to confess that there are over 300 of them sitting unread in my email, dating back many months. I read these selectively, usually sorted by sender, during times when I have no internet access, such as on long flights (although that practice is now under review if I’m not allowed to bring a laptop on board).

RSS feeds, on the other hand, are the ultimate web 2.0 form of permission marketing: I subscribe to feeds that I want, without passing along any personal information that might result in unwanted spamming to my email. I read them online using Bloglines when I’m connected to the internet (which is almost all the time), and since each entry typically is a single subject rather than a collection of topics that I would find in an email newsletter, I can quickly go through them and figure out which ones that I want to spend more time on and which that I want to delete.

What this all has to do with BPM is that a number of the BPM portals (Business Process Management Group, Business Process Management Institute and Business Process Trends) don’t syndicate their content using RSS, but make you sign up for email newsletters. A couple of exceptions are BPMEnterprise.com, and ebizQ (which hosts this blog), a broader-based integration-related site.

A good percentage of you read this blog via the RSS feed — many through the Feedburner feed that provides some extra widgets on each post — so I know that you appreciate my complaint.

Customers that I’d like to fire

I’ve had two “inconsiderate customer” incidents this week; actually, both are customers who I’ve done quite a bit of work for in the past but have been inactive for some time.

With customer #1, I contracted in as their business and application architect for several months; even though they didn’t really get what enterprise architecture is all about, I spent most of a year trying to do some internal education on the necessity for EA to help sort out the legacy linguine that was rampant in their organization, as well as the lack of business-IT alignment. A while after leaving, on April 29th 2005 to be exact, I dropped my key contact there an email about the (then) new report from BPTrends on EA tools, saying the following:

…there’s a new report out from BPTrends on enterprise architecture that you can download for free. I gave it a quick review on my business blog, which includes a link to the report. Although the product information in the report is nothing that you can’t get from the vendor’s sites, the first 25 or so pages are a great overview of enterprise architecture, process modelling and simulation tools that provide good background material if you’re ever promoting a related project. I did an earlier post on their report on BPM suites that you might also find interesting.

Usually this type of email at least gets a “thanks”, or “hey, it’s been a while, let’s meet for coffee”, but nothing came back from this. No big deal, customer #1 is a busy person. Then on Tuesday of this week, 340 days after my original email, it arrives:

With customer #2, I did the architecture and design of their original BPM system, and they now need some analysis and design assistance to further increase efficiencies (which presumably would more than pay for my engagement there). Their internal IT architect contacted me in November 2005, we chatted on the phone and by email, then he connected me with the project manager. Long pauses in the conversation ensued, punctuated by several emails and voice mails from me to the PM. Responses took as long as six weeks, or never came at all. Finally, they made a request to have me fly to their site this coming week — the week leading up to Easter, with Friday a holiday here in Canada, and Saturday being when 13 members of my family will be descending on my home for Easter dinner. That, of course, is my problem, so I said yes. Turns out that no one had the funding approved, however, so I received an email two weeks ago saying that the trip was off. I immediately responded with some suggestions on how to restructure the project to reduce the funding issues while still providing value. Their response? Silence, so far.

The thing that frustrates me is that I’m not an unknown salesperson cold-calling these people, I’m a geeky engineer type who worked on site as part of the in-house team with both of these customers for several months and did significant amounts of work that were well-received. Are they just snowed under with the amount of email that they receive, and ignoring all of their business contacts equally, even if they were the one to initiate the conversation? Or, because I’m a contractor/consultant, don’t they consider it worth their time to reply to my email (or even open it for almost a year)? At least I’m pretty sure that they’re not reading this blog entry…