Understand that first of all, I think that Bruce Silver is a very smart guy, and don't take it the wrong way when I say that he is a less-than-scintillating speaker. He was featured on Appian's Investing in BPM webinar today, and his talk turned out to be just a slight expansion of his Intelligent Enterprise article that I discussed earlier; it wasn't exactly edge-of-the-seat stuff. Maybe he should spend less of his time reading from a script, and more just talking about this subject matter that he knows so well. And although he was giving a beginner's guide to BPM, I have a bit of a problem with him starting out his talk with "I want to talk to you about a new kind of software, business process management..." New kind of software? Not.

After the requisite 20 minutes of "independent content" that the vendors use to hook you into attending their webinars, Appian's Director of Product Management, Phil Larson, stepped in and talked more about BPM in general and about their product. He was interesting enough to keep me on the line for the remainder of the webinar, and he had good illustrations of some of the concepts, including the prettiest diagram that I've seen to show how BPM and SOA fit together. Not the most complete, but sometimes you just need a pretty version to make your point.

Larson quoted from the recent Forrester report -- "[Appian] has the widest breadth of functionality among the suites we evaluated" -- although he didn't mention the bit that came later in the same paragraph of the report: "However, breadth comes at the expense of depth in features like simulation and system-to-system integration". He showed a snap of their BPMN implementation, which gets good marks off the bat for having the swimlanes running in the right direction.

I'm not sure if Appian will have the webinar available for replay later, although it's not really worth it unless you're a true beginner. I think that you can get most of the information from Silver's portion of the talk from the earlier-reference Intelligent Enterprise article, and most of the Appian information from their web site.

Posted by Sandy Kemsley at 03:05 PM in BPM • BPMN • SOA | Permalink | Comments (3) | TrackBacks (0) | Add to del.icio.us

The first of a series of posts on scrAPIs (which I commented on following Mashup Camp last week) by Thor Muller of Rubyred Labs. I'm looking forward to the rest of the series this week.

Posted by Sandy Kemsley at 11:31 PM in mashupcamp | Permalink | TrackBacks (0) | Add to del.icio.us

Forrester just released a report on human-centric BPMS, and Lombardi is just busting with pride over their position: so much so, that they're giving the report away here (registration required). Phil Gilbert must be doing a little happy dance, especially considering that their "dot size" has increased from a tiny blip on the radar to a more respectable market presence. Forrester's had a soft spot for Lombardi for a while: the March 2004 "Pure Play BPM" wave (that's when we were still calling this "pure play") had Lombardi at the cusp between Strong Performer and Leader. Relative positions of many players have stayed pretty much the same since then in the Forrester rankings (Garter's rankings are quite different), although TIBCO and Pegasystems have made significant increases in market presence. I'd have to say that Forrester must have been looking mostly at the American market presence, since TIBCO (which was still the Staffware product during the 2004 ranking) had a huge presence in UK, European, Australian and other markets that I saw.

Excerpts from Forrester's executive summary regarding those in the Leaders category:

Lombardi Software, Pegasystems, and Savvion lead with comprehensive suites that foster rapid, iterative process design; Appian leads with a richly featured suite for people-intensive work; and TIBCO leads with a human-centric BPMS that leverages its integration-centric product.

In fact, later in the report, they more categorically state "Lombardi Software, Pegasystems, and Savvion lead the pack -- hands down", then they proceed to break out the specific reasons for their evaluation. However, they also stated "If you could only buy one BPMS product, Fuego offers the best -- bar none -- product supporting human-intensive and system-intensive processes", an assessment with which I don't disagree, after seeing things like Fuego's web services introspection (although I still insist that they put their swimlanes sideways). They go on to say that "Appian and FileNet innovate beyond the boundaries of human-centric BPMS" by integrating collaboration tools that allow a non-standard process to go off the rails in a somewhat controlled manner.

One thing I didn't like is how Forrester categorizes business processes:

• Integration-intensive
• People-intensive
• Decision-intensive
• Document-intensive

I don't really agree with this categorization, first of all since it's not normalized: integration-intensive and people-intensive certainly are at opposite ends of the same scale, but their definition of decision-intensive is really people-intensive with a strong need for business rules (which I think are necessary pretty much all the time), and document-intensive is just people-intensive with a lot of scanned documents involved. Although document-intensive processes would always be people-intensive, I believe that decision-intensive could fall anywhere along the integration-to-people scale since it is primarily about the use of business rules. Although many organizations are still choosing separate products for integration-intensive and people-intensive (or human-interrupted, as one of my customers once so charmingly put it) processes, the real issue in this report should be about any given product handles all three of (what I see the artificial divisions of) people-, decision- and document-intensive functionality.

The last half of the report shows the explicit criteria ranking for each vendor, and a detailed paragraph of strengths and weaknesses for each vendor. Definitely worth the read.

Posted by Sandy Kemsley at 11:18 PM in BPM | Permalink | Comments (3) | TrackBacks (1) | Add to del.icio.us

Further to my initial post on OMG's BPM Think Tank coming up on May 23-25, it's now open for registration. There's one day of pre-conference workshops, then two days of conference, including four sessions of executive and technology roundtables. Looks to be more interactive than your average conference.

Book by May 1st for early-bird discount pricing.

Posted by Sandy Kemsley at 07:54 AM in BPM | Permalink | TrackBacks (0) | Add to del.icio.us

I recently discovered some notes that I had made back in November 2004 from a TIBCO webinar "Enabling Real-time Business with a Service-Oriented and Event-Driven Architecture". Randy Heffner from Forrester spoke at that webinar, and I remember that it was his words that made me realize what an impact that SOA was going to have, and how strategic SOA requires a focus on enterprise architecture, particularly the application architecture and technical architecture layers, so that business and IT metrics can be tied back to defined services.

Although it seems obvious now, that webinar really crystallized the idea of services as being process steps to be orchestrated, and how this allowed you to focus on an end-to-end process across all stakeholders, not just what happens inside your organization: the Holy Grail of BPM, as it were. EA often does not include business architecture, but services force it to consider the business process architecture and business strategy/organization.

Posted by Sandy Kemsley at 04:29 PM in SOA | Permalink | TrackBacks (0) | Add to del.icio.us

May 8th and 9th, no location or agenda specified as yet, but there's a Web 2.0 conference being organized in Toronto. Mathew Ingram, one of the organizers, has a post about it here.

Posted by Sandy Kemsley at 04:18 PM in Web2.0 | Permalink | TrackBacks (0) | Add to del.icio.us

My wrapup of Mashup Camp wouldn't be complete without mentioning the fabulous Computer History Museum in Mountain View where the event was held. Great venue, and the part of their collection that we were able to view during the party on Monday night was very nostalgic (although I can't quite say that I miss RSX11M). Definitely worth a visit if you're in the Bay area.

On my return to Toronto, I had lunch with a friend who works for Alias, the day after she emailed me to say that their corporate email addresses have changed from @alias.com to @autodesk.com following the recent acquisition. The end of an era for a long-running innovative Canadian software company. There since the late 1980's, she saw many transitions, including the purchase of Alias by Silicon Graphics (and its subsequent sale). SGI was, at the time, housed in the building that now holds the Computer History Museum, and she remembers visiting there when it was SGI headquarters. An interesting footnote after spending the first part of the week there.

Posted by Sandy Kemsley at 03:48 PM in mashupcamp | Permalink | TrackBacks (0) | Add to del.icio.us

I'm still wrapping my brain around some of the ideas that started in my head at Mashup Camp, but I've been having fun browsing through all of the photo-detritus of the event. I was surprised that I made the first photo in Valleywag's coverage of the event, and Doc Searls caught me at the XDI session on Monday (bonus tip: wear purple at popular events so that you can find yourself in the photos). There's over 900 Flickr photos tagged mashupcamp, and likely many more still languishing out there on memory cards.

Posted by Sandy Kemsley at 07:05 PM in mashupcamp | Permalink | TrackBacks (1) | Add to del.icio.us

That's the thing about mashups, almost all of them are illegal

I heard that (and unfortunately am unable to credit the source) in the "scrAPI" session at Mashup Camp, in which we discussed the delicate nature of using a site that doesn't have APIs as part of a mashup. Adrian Holovaty of ChicagoCrime.org (my favourite mashup at camp) was leading part of the session, demonstrating what he had done with Chicago police crime data (the police, not having been informed in advance, called him for a little chat the day his site went live), Google maps, Yahoo! maps (used for geocoding after he was banned from the Google server for violating the terms of service) and the Chicago Journal.

Listening to Adrian and others talk about the ways to use third-party sites without their knowledge or permission really made me realize that most mashup developers are still like a bunch of kids playing in a sandbox, not realizing that they might be about to set their own shirts on fire. That's not a bad thing, just a comment on the maturity of mashups in general.

The scrAPI conversation -- a word, by the way, that's a mashup between screen scraping and API -- is something very near and dear to my heart, although in another incarnation: screen scraping from third-party (or even internal) applications inside the enterprise in order to create the type of application integration that I've been involved in for many years. In both cases, you're dealing with a third party who probably doesn't know that you exist, and doesn't care to provide an API for whatever reason. In both cases, that third party may change the screens on their whim without telling you in advance. The only advantage of doing this inside the enterprise is that the third party ususally doesn't know what you're doing, so if you are violating your terms of service, it's your own dirty little secret. Of course, the disadvantage of doing this inside the enterprise is that you're dealing with CICS screens or something equally unattractive, but the principles are the same: from a landing page, invoke a query or pass a command; navigate to subsequent pages as required; and extract data from the resultant pages.

There's some interesting ways to make all of this happen in mashups, such as using LiveHTTPHeaders to watch the traffic on the site that you want to scrape, and faking out forms by passing parameters that are not in their usual selection lists (Adrian did this with ChicagoCrime.org to pass a much larger radius to the crime stats site that its form drop-down allowed in order to pull back the entire geographic area in one shot). Like many enterprise scraping applications, site scraping applications often cache some of the data in a local database for easier access or further enrichment, aggregation, analysis or joining with other data.

In both web and enterprise cases, there's a better solution: build a layer around the non-API-enabled site/application, and provide an API to allow multiple applications to access the underlying application's data without each of them having to do site/screen scraping. Inside the enterprise, this is done by wrapping web services around legacy systems, although much of this is not happening as fast as it should be. In the mashup world, Thor Muller (of Ruby Red Labs) talked about the equivalent notion of scraping a site and providing a set of methods for other developers to use, such as Ontok's Wikipedia API.

We talked about the legality of site scraping, namely that there are no explicit rights to use the data, and the definition of fair use may or may not apply; this is what prompted the comment with which I opened this post.

In the discussion of strategic issues around site scraping, I certainly agree that site scraping indicates a demand for an API, but I'm not sure that I completely agree with the comment that site scraping forces service and data providers to build/open APIs: sure, some of them are likely just unaware that their data has any potential value to others, but there's going to be many more who either will be horrified that their data can be reused on another site without attribution, or just don't get that this is a new and important way to do business.

In my opinion, we're going to have to migrate towards a model of compensating the data/service provider for access to their content, whether it's done through site scraping or an API, in order to gain some degree of control (or at least advance notice) of changes to the site that would break the callling/scraping applications. That compensation doesn't necessarily have to mean money changing hands, but ultimately everyone is driven by what's in it for them, and needs to see some form of reward.

Update: Changed "scrapePI" to "scrAPI" (thanks, Thor).

Posted by Sandy Kemsley at 07:29 PM in SoftwareDesign • mashupcamp | Permalink | Comments (6) | TrackBacks (3) | Add to del.icio.us

The flight home from Mashup Camp was a great opportunity to catch up on my notes from the past couple of weeks, including several ideas triggered by discussions at the TIBCO seminar last week: some because I disagreed with the speakers, but some because I agreed with them. I split my opinions on the discussions about implementing BPM systems, specifically about the role of a business process analyst, and agile versus waterfall development.

First of all, the business process analyst role: Michael Melenovsky sees this as important for BPM initiatives, but I tend to feel the same way as I do about business rules analysts: just give me a good business analyst any day, and they’ll be able to cover rules, process, and whatever else is necessary for making that business-IT connection. Furthermore, he sees the BPA as a link between a BA and IT, as if we need yet another degree of separation between the business and those who are charged with implementing solutions to make business run better. Not.

There were some further discussions on how business and IT have to collaborate on BPM initiatives (duh) and share responsibility for a number of detailed design and deployment tasks, but this is true for any technology implementation. If you don’t already have a good degree of collaboration between business and IT, don’t expect it to magically appear for your BPM initiatives, but do take note that the need for it is at least as great as for any other technology implementation. How we’re supposed to collaborate more effectively by shoehorning a BPA between a BA and IT is beyond me, however.

Melenovsky also had some interesting “lesson learned” stats on the correlation between the time spent on process discovery and model construction, and the success of the BPM initiative: basically, do more work up on your analysis and up-front business-focussed design, and your project will be more successful. Gartner found that over 40% of the project time should be spent on process discovery, another 9% on functional and technical specifications, and just 12% on implementation. In my experience, you’ll spend that 40% on process discovery either up-front, or when you go back and do it over because you implemented the wrong thing due to insufficient process discovery in the first place: as usual, a case of choosing between doing it right or doing it over.

That directly speaks to the need for agile, or at least iterative, development on BPM projects. You really can’t use waterfall methods (successfully) for BPM development (or most other types of technology deployments these days), for so many reasons:

1. When implementing new (and disruptive) technology, whatever business tells IT that they want is not accurate since the business really isn’t able to visualize the entire potential solution space until they see something working.
2. While IT is off spending two years implementing the entire suite of required functionality in preparation for an all-singing, all-dancing big bang roll-out, the business requirements will change.
3. During that two years, the business is losing money, productivity and/or opportunities due to the lack of whatever BPM is going to do for them, and is building stop-gap solutions using Excel, Access, paper routing slips and prayer.
4. That all-singing, all-dancing complex BPM implementation is, by definition, more complex and therefore more rigid (less flexible) due to the amount of custom development. It makes sense that you can’t use a development methodology that’s not agile to implement processes that are agile.
5. The big bang roll-out is a popular notion with the business right up to the point when it happens, and they discover that it doesn’t meet their needs (refer to points 1 and 2). Then it becomes unpopular.

Instead, get the business requirements and process models worked out up front, then engage in iterative methods of designing, implementing and deploying the systems. Deliver “good enough” processes on the first cut, then make iterative improvements. Don’t assume that the business users aren’t capable of providing valuable feedback on required functionality: just make them do their job with the first version of the system, and they’ll give you plenty of feedback. Consider the philosophy of an optional scope contract rather than a fixed price/date/scope contract, whether you're using internal or external resources for the implementation. Where possible, put changes to the business processes and rules in the hands of the business so that they can tweak the controls themselves.

Posted by Sandy Kemsley at 01:47 PM in BPM • SoftwareDesign | Permalink | TrackBacks (0) | Add to del.icio.us

I hate to spend too much of my time dissing the analysts, but sometimes I really wonder where they get their information. At a seminar that I attended last week, Michael Melenovsky from Gartner characterized the current state of BPM as workflow-oriented departmental implementations that included software deals in the $60K range. That’s not what I’m seeing, although maybe my view is skewed because I’m actually helping to implement these systems rather than taking the long view from the top of an ivory tower. I’m seeing BPM projects spanning the functionality spectrum from human-facing to STP, and spanning multiple departments across the enterprise to become part of the enterprise infrastructure. Furthermore, organizations are spending a lot of money on them, and have budgeted to spend even more in the next year (I seem to recall blogging about a recent study that showed application integration as the #1 spend for CIOs this year, but can't seem to find it).

Melenovsky also showed a graph of the “BPM stages of value creation” over time, which showed productivity as being the greatest value of BPM now, visibility having the greatest value by 2012, and innovation having the greatest value by 2017. Besides the obvious point that predicting anything to do with a still-fluid technology 11 years in the future is about as accurate as reading tea leaves, the idea that visibility won’t be the dominant value added by BPM until 2012 is just plain wrong. Process visibility kicked into gear as a dominant driver for BPM over the past few years of intense compliance scrutiny, and it’s already poised to overtake productivity as the biggest benefit provided by BPM. Although the definition of process metrics is still more of an art than a science, the various levels of process-centric business intelligence that provide process visibility (corporate performance management, business activity monitoring, complex event processing) are being mandated in the boardroom and implemented across the enterprise. Process visibility is the new black, and it’s in style now.

I also don’t see another 11 years elapsing before innovation overtakes visibility to become the primary value provided by BPM, since agility and innovation are so closely tied, but the Ouija board hasn’t yet given me enough information about when it will happen.

Posted by Sandy Kemsley at 01:31 PM in BPM | Permalink | TrackBacks (1) | Add to del.icio.us

I’ve posted a number of times in the past about the importance of business rules engines (BRE) in conjunction with BPM in order to keep rules and process separate. To sum up my thoughts on this:

• Most BPMS don’t have sufficient functionality in their in-process expression builders to offer true business rules capabilities. A notable exception is Pega, which is built on a rules engine. I’m not going to wax poetic on the benefits of business rules, since there’s lots of other people who can do that better than me, but take my word for it: you really need business rules.
• Having the ability to change work in progress. If the business logic is embedded within the process map, then typically that logic is fixed for a particular item of work at the time that it is instantiated. For straight-through short-running processes, this isn’t a problem, but for long-running processes (with or without human interaction), it is, since most BPMS don’t provide for changing the business logic or process map for an item of work once it is instantiated. If the BPMS retrieves its rules from a BRE at the time that each rules-oriented step is executed, then the rules are as current as what’s in the BRE.
• Using the same rules engine and rules across multiple applications, not just within the BPM. Imagine it: the same business rules about, for example, how you deal with a customer’s order in a particular situation being applied identically across your CRM, your BPMS, and any other applications that it might impact, because they all retrieve their business rules from a common business rules repository at the time of execution. This idea is just starting to creep into the consciousness of most large organizations (they’re still digesting the first two reasons), and is ultimately the most critical since it not only provides for greater business agility, but also has a huge impact on compliance.

This last point is exactly why I see Pega’s position as a disadvantage rather than an advantage: although they market themselves on the fact that they’re built on a BRE, the requirement for business rules in multiple applications across the enterprise is finally being recognized, and stand-alone BRE will become more commonplace in organizations in the next few years. And if you’re using Fair Isaac for all of your business rules across the organization, you’re not going to want to use a different, proprietary BRE inside a BPM product to re-implement some of the same rules that exist elsewhere in the organization.

I thought of this last week at the TIBCO seminar when I learned that they also have a proprietary rules engine embedded in their BPMS, although the BPMS is not based on the BRE (as with Pega), it’s just there to provide additional functionality, and TIBCO allows for integration with popular third-party BRE including Fair Isaac and ILOG. My prediction is that as organizations start to roll out these best-of-breed BRE across the enterprise, TIBCO will abandon their own rules engine in favour of integrating only with well-known third-party BRE.

Posted by Sandy Kemsley at 12:57 PM in BPM • BRE | Permalink | Comments (3) | TrackBacks (5) | Add to del.icio.us

Now that I've been disconnected from the fire hose of information that was Mashup Camp, I've had a bit of time to reflect on what I saw there.

Without doubt, this is the future of application integration both on the public internet and inside the enterprise. But -- and this is a big but -- it's still very embryonic, and I can't imagine seriously suggesting much of this to any CIO that I know at this point, since they all work for large and fairly conservative organizations. However, I will be whispering it in their ears (not literally) over the coming months to help prepare them for the new world (dis)order.

From an enterprise application integration perspective, there's two major lessons to be learned from Mashup Camp.

First, there's a lot of data sources and services out there that could be effectively combined with enterprise data for consumption both inside and outside the firewall. I saw APIs that wrap various data sources (including very business-focused ones such as Dun + Bradstreet), VOIP, MAPI and CRM as well as the better-known Google, Yahoo! and eBay APIs. The big challenge here is the NIH syndrome: corporate IT departments are notorious for rejecting services and especially data that they don't own and didn't create. Get over it, guys. There’s a much bigger world of data and services than you can ever build yourself, and you can do a much better job of building the systems that are actually a competitive differentiator for you rather than wasting your time building your own mapping system so that you can show your customers where your branches are located. Put those suckers on Google maps, pronto. This is no different than 1000's of other arguments that have occurred on this same subject over the years, such as "don’t build your own workflow system" (my personal fave), and is no different than using a web service from a trusted service provider. Okay, maybe it's a bit different than dealing with a trusted service provider, but I'll get to the details of that in a later post on contracts and SLAs in the world of mashups.

Second, enterprise IT departments should be looking at the mechanics of how this integration takes place. Mashup developers are not spending millions of dollars and multiple years integrating services and data. Of course, they’re a bit too cavalier for enterprise development, typically eschewing such niceties as ensuring the legality of using the data sources and enterprise-strength testing, but there's techniques to be learned that can greatly speed application integration within an organization. To be fair, many IT departments need to put themselves in the position of both the API providers and the developers that I met at MashupCamp, since they need to both wrap some of their own ugly old systems in some nicer interfaces and consume the resulting APIs in their own internal corporate mashups. I've been pushing for a few years for my customers to start wrapping their legacy systems in web services APIs for easier consumption, which few have adopted beyond some rudimentary functionality, but consider that some of the mashup developers are providing a PHP interface that wraps around a web service so that you can develop using something even easier: application integration for the people, instead of just for the wizards of IT. IT development has become grossly overcomplicated, and it’s time to shed a few pounds and find some simpler and faster ways of doing things.

Posted by Sandy Kemsley at 11:04 PM in mashupcamp | Permalink | Comments (2) | TrackBacks (1) | Add to del.icio.us

It's the second day of Mashup Camp, and I've had zero time to blog about what's going on here -- much like everyone else here, so it seems. I'll be posting my thoughts later this week, but in the meantime you can check out the other blog posts about Mashup Camp and look at the pictures that people are taking here (over 600 at this time).

Posted by Sandy Kemsley at 04:51 PM in mashupcamp | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

I haven't had a lot of comments on this blog yet (especially since I got rid of all the comment spam), but I like the idea of being able to track all the conversations that result from my posts. To that end, I learned something new about Movable Type and added a comment RSS feed. As with my main feed for posts, I have a FeedBurner feed for it so that it's location independent. You can find both feeds in the right-hand sidebar with the feed icons .

Posted by Sandy Kemsley at 04:37 PM in Blogging | Permalink | Comments (4) | TrackBacks (0) | Add to del.icio.us

I spent this morning at a seminar co-hosted by TIBCO and Intelligent Enterprise, featuring Michael Melenovsky from Gartner. One of my reasons for attending was to find out more about TIBCO's newly-released version of General Interface, which they purchased a year ago, and find out just how tightly that it's integrated with the TIBCO BPM product. In other words, I was on the BPM mashup hunt that I talked about here.

Jeff Kristick, TIBCO's Director of Product Marketing, gave a presentation where he showed a screenshot of an AJAX-based rich client interface to their BPM product (I would have loved to have seen a demo rather than PPT-ware). I asked if their out-of-the-box UI for BPM was AJAX-based, and he said that they had taken advantage of the acquisition of GI to rebuild their BPM interface using their own AJAX development environment, and that's what's shipping now. Cool.

GI is available for free for public applications, and really cheap for enterprise (inside the firewall) applications, so off I went to the TIBCO technical site this afternoon to check it out. Quick signup, wait for a password via email, then off to the download page. I noticed the page of sample projects, each with both a preview and the source code, so thought I'd check these out before installing. Clicked on the first "View Preview" link:

Yikes! You want me to give up Firefox for this? I'm sure that the 45% of my readers who don't use IE agree with me on this one.

More on GI and the rest of the seminar after I remember where I hid IE...

Posted by Sandy Kemsley at 05:04 PM in BPM • Web2.0 | Permalink | Comments (2) | TrackBacks (1) | Add to del.icio.us

I just watched a webinar hosted by BPMinstitute called "Proven Steps to BPM Success". By the time the webinar started, it was retitled as "Breakaway BPM -- Leveraging Business Process Innovation for Strategic Advantage", although there wasn't really a lot of content that fit that description. Unfortunately the webinar started with a (short) presentation by the hosting vendor, Metastorm, then proceeded to a presentation by AMTI, one of their partners. Basically, vendor followed by vendor. Whatever happened to having customers talk about their experiences?

A couple of good ideas and graphics from the Metastorm CEO, including this one on the evolution of BPM as driven by complex process initiatives:

However, pretty tame stuff from the "featured speaker" from AMTI talking about their process improvement efforts, like "reward success" and "process should be integral to the way you work". And he totally didn't understand why a recent Gartner survey (summarized in InfoWorld) showed that CIOs' top business priority is improving processes but their top technology priority is business intelligence. Um, BPM and BI are related, dude -- that's what business activity monitoring (BAM) and corporate performance management (CPM) are all about.

You'll be able to find a replay of the webinar on the BPMinstitute site within a few days, listed under their Round Tables section.

Multi-tasking during the webinar did give me a chance to glance through an interesting article in a recent copy of the Economist, Thinking for a living (paid subscription required), the title of which is based on the book of the same name by Tom Davenport. The article has a great nugget of truth from a consultant at Boston Consulting Group:

Mr. Morieux concludes that companies should concentrate on designing the processes that knowledge workers carry out, rather than measuring their performance.

Rather a different view on the whole BAM/CPM issue.

Posted by Sandy Kemsley at 01:59 PM in BI • BPM | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

Phil Gilbert (CTO of Lombardi) posts about how to evaluate vendors, and makes some comments that are likely to cause a few groans from people inside his own sales organization, like the 60-day money-back guarantee.

I'd like to add one more thing to his list: request that one of the references be from within the vendor itself; in other words, how are they using their own product? Every company has processes, and if a BPM vendor can't show how they're improving their own processes using their own product, you want to know why. And we're not just talking their expense report approvals process here; ask to see something that's critical to the revenue-generation side of their business.

Before you head out to evaluate vendor products, however, you need to have a good understanding of your own processes, or at least the general category and order of complexity; otherwise, the vendors will just show you what they want you to see, not what you need to see in order to evaluate how well the product will serve your needs. Think globally (across your entire organization) even if you'll initially be acting locally (within a department).

Review a checklist such as the recent Gartner BPM Suite Selection Criteria report and think about which of those capabilities that you require before you start talking to vendors.

Talk to a variety of people inside your organization: not just business users, and not just IT, but a reasonable survey of both viewpoints. Some of the biggest BPM disasters that I've seen have been because the product was selected purely on the basis of one of those two viewpoints (business or IT), but not both.

Posted by Sandy Kemsley at 10:13 AM in BPM | Permalink | Comments (1) | TrackBacks (0) | Add to del.icio.us

One of the first BPM-related blogs to be added to my newsreader was The Vision Thing, and today Ethan announced that he's shutting it down. I had the pleasure of being interviewed by Ethan for one of his Sound of Vision podcasts last May, then meeting him face-to-face at our own little bloggers dinner in Dallas in December.

There's a few things that you should check out on his site: the flowchart article archive (anyone who can write five articles on the theme of "Visio is Evil" has to have something to say about process mapping!), the rest of the Sound of Vision podcast archive, and the snippets in Process for the People.

This month, Ethan launched Vision Monthly, an online magazine that covers a much wider range of business issues. The first issue included an article by Elisa Camahort (co-founder of BlogHer), one by Paul Gimbel of Razorleaf which led me to his blog on process analysis, and others.

Ethan, we're sorry to see TVT go, and good luck with Vision Monthly.

Posted by Sandy Kemsley at 09:35 AM in BPM • Blogging | Permalink | TrackBacks (1) | Add to del.icio.us

It's a good sign when a niche technology starts getting a lot of coverage in mainstream IT press. I don't consider BPM "niche" any more (okay, maybe "niche-ish"), but it's still not as widespread as it could be. Judging by the popular press, however, we're slowly creeping across the chasm.

Case in point: BPM is all over Intelligent Enterprise the past few months. An article by Bruce Silver discusses five reasons to invest in BPM: simplification, efficiency, compliance and control, agility, and continuous improvement (I think that his first two are actually the same, but no matter, the point is the same). Other articles discuss the incredible number of BPM vendors and the inevitable impending consolidation, the move to BPM suites (now that Gartner claims that "pure-play" BPM is dead), and the inclusion of BAM (business activity monitoring) in the BI (business intelligence) space.

As BPM, SOA, mashups and other integration technologies overlap more both from a technology and usage standpoint, it will drive all of them to greater recognition.

Posted by Sandy Kemsley at 08:22 AM in BPM | Permalink | TrackBacks (0) | Add to del.icio.us

Attention, all you Mashup Camp attendees: go to Attendr to see a cool mashup example from Jeff Marshall that allows you to link to other attendees you already know or would like to meet. If you're going to be at MashupCamp next week, be sure to look me up and say hi.

As for the rest of you, head on over and add yourself to my Frappr map. You can see where other readers of Column 2 are located, and I've added the capability to use coloured pins to denote whether you're a customer, product vendor, services vendor or "other" as it relates to BPM and integration technologies.

Posted by Sandy Kemsley at 10:19 PM in Web2.0 • mashupcamp | Permalink | TrackBacks (0) | Add to del.icio.us

No, I don't think any of you are dummies -- the title (however appropriate) is in sympathy with a letter received by Jason Calacanis and a follow-up suggestion by Jeff Jarvis. Check for related posts with the fordummies tag on Technorati.

Back to the point of this post: an email that I received eariler this week from the BPM Academy, which is a thinly-veiled marketing site for Appian, although it does contain some interesting links. The email was directing me to a BPM Primer webinar that they're holding next Wednesday, which probably holds some value for those just starting out with BPM or looking to learn the terminology and concepts. (You can probably find the same information poking around the links on my Squidoo BPM page, but some people prefer the webinar format). The really funny part, however, was the title of email that they sent promoting the event:

Go from BPM Beginner to BPM Brainiac in one short hour

I don't know what's funnier: the use of the word "brainiac", or the idea that someone in their marketing department thinks that people are dumb enough to give credence to their claim. They don't claim to be the definitive education on BPM, but I'm still laughing.

Posted by Sandy Kemsley at 09:56 AM in BPM | Permalink | TrackBacks (0) | Add to del.icio.us

I've written about business blogging in the past, and I firmly believe that it has become an essential tool for small business marketing in any business where the personalities and personal knowledge of the participants form most of the value of the company. As a company of one, I'm all I've got, and I blog in part as an online portfolio but also as a way to engage smart people in conversations of mutual interest. Somehow along the way, I became an evangelist for blogging.

For the past couple of years, I've been doing some very occasional mentoring for the son of a friend and his two buddies as they start up their company, Trioro. Every time that we have met for the past year, I've asked them when they were going to start blogging, and gradually their looks changed from "she's crazy but we'll tolerate it" to "hmm, that might be a good idea if I can fit it into my spare time" (Scott, I can read your face like a book). I strongly suggested that all three of them blog, since they are the company, and a few weeks ago they finally came through. I think that they're still finding their voice, but it's a great start.

It's a little strange to have to push this new-fangled technology to people young enough to be my own kids (well, okay, if I had decided to have kids instead of taking grade 11 algebra), but when I think about it, I'm not really pushing the technology, I'm pushing the concept of a blog as marketing. I can't fault them for not getting it: a huge part of the business world doesn't get it yet, either.

I have several friends with small businesses, many of them one-person businesses, and very few of them realize the power of blogging for their business. My long-time friend Pat, a very talented photographer, has her first show of photographs for sale hanging at Barrio Lounge (a great local restaurant) this month. She takes beautiful photos of fruit and vegetable arrangements, lit to look like 16th-century Flemish still life paintings, and prints them on large-format canvas. She'd like to eventually quit her job as a technical writer and do this full-time, and this show is her first step towards making that happen. So you think that she'd be blogging about it, right? About the technique in creating and lighting the arrangements. About the settings on the Canon Digital Rebel that she uses. About the difficulties of finding a printer who could print the large canvases. About the technique for stretching and mounting the canvases. About how we scrambled to hang the show in two hours last Saturday afternoon. If you thought that, you'd be wrong. Okay, she's busy: while preparing for this show, she was also finishing her Master Gardener certification, in addition to holding down that fulltime job. But at some point, she's going to realize that success at selling her photographs is going to come much more quickly through greater exposure, and that a blog about how she creates these masterpieces is a powerful tool for gaining that exposure. It's not like she doesn't have the skills: Pat's a professional writer with a degree in English, and she writes many emails to me every week about the same stuff that she should be blogging about.

Another friend of many years, Ingrid, is also a writer. She has degrees in law and journalism, and specializes in plain language business writing on a variety of subjects that usually aren't so understandable, like tax law. She writes a semi-monthly email column, On Being, that I would love to be able to point you to except that she doesn't post it online. In other words, she's a wealth of information on topics that many people would be interested in, but very few of us get to see them. Unlike Pat, however, I think her reasons are more around intellectual property than time constraints: during our latest discussion about On Being, she said that she hoped to be able to sell the columns to a magazine, so didn't want to put them in the public domain. (I blame the legal training.)

Maybe the problem is that when we write for a living, or if we're used to highly-polished "marketing writing" as being the world-facing view of a company, we think that everything that we publish has to not only contain pearls of wisdom, but be perfectly proofread. Blogs make that untrue. It's not like you shouldn't have something to say, and use your spell-checker once in a while, but you're not writing your Ph.D. thesis, it's a blog post! The half-life of the interest in any particular post is less than two days, so there's not much sense in spending more time than that writing each one.

Interestingly, I wrote most of this post yesterday afternoon, then was interrupted to head off for dinner with Ingrid. We discussed blogging again, and she offered up this last concern -- that she was a professional writer and that more casual writing in her blog might impact someone's view of her finished product -- but I think that she's going to come around on this one.

I rarely write about personal blogging, since I read very few purely personal blogs -- most of my reads are technology or business-related. One trend that I have noticed in the past year is "elderblogging", or blogging by seniors. I'm not talking about what baby boomers are doing as they finally start to retire, I'm talking about their (our) parents: the 70+ crowd. Just as businesses started to realize a few years back that "grey power" was a huge market force, mainstream media is finally starting to notice that the geezers are blogging. That made it easier when I was trying to explain blogging to my 82-year-old mother last month: I just showed her a blog written by a woman her age. Two weeks later, the inevitable email from Mom arrived:

I read Millie's note today wondering why there aren't senior bloggers and that she'd helped some get started. As you know my computer skills are not too good but thought that learning how to blog might be fun. Can you tell or send something about how to do this? Don't know what I'll blog about but it might be fun.

She started blogging last week. No evangelism required.

Posted by Sandy Kemsley at 09:01 AM in Blogging | Permalink | Comments (1) | TrackBacks (1) | Add to del.icio.us

On the heels of an announcement that TIBCO is supporting AJAX for developing interfaces to their BPM, I'm attending a TIBCO seminar next Thursday in Toronto, "Harness the Power of Process to Tip the Competitive Scales: What BPM Can Do for Your Organization". It's a freebie, but you have to pre-register. Also taking place in New York on the 14th and Denver on the 23rd.

If you're at the Toronto seminar, track me down and say hi.

Posted by Sandy Kemsley at 11:14 AM in BPM | Permalink | TrackBacks (0) | Add to del.icio.us

Here's an interesting tidbit from the very bottom of an article on TIBCO's recent upgrades to its BPM platform (formerly the Staffware product):

The company [TIBCO] has upgraded the BPM user interface, as well, to include AJAX for the development of RIA (Rich Internet Applications).

Significant that a large BPM vendor acknowledges the existence of Web 2.0.

Considering that BPM products are, by their nature, typically both consumers and providers of web services (they are, after all, orchestration tools), how long until a mainstream BPM vendor jumps into the mashup fray? There's already companies such as The Process Factory offering BPM in a software as a service (SaaS) model, we just need a BPM SaaS provider who also opens up the functionality via web services for integration into other applications, like Salesforce.com has done.

Or should BPM remain a part of an organization's internal backbone?

Posted by Sandy Kemsley at 09:14 AM in BPM • Web2.0 | Permalink | Comments (1) | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 07:55 AM in BPM • SOA • Web2.0 | Permalink | TrackBacks (0) | Add to del.icio.us

There's been a veritable deluge of spam on this blog recently, both in comments and trackback, so I'm experimenting with a few settings to try and make it go away:

- Enabled comment moderation. Unfortunately, although the default template claims that you only have to be approved once, that doesn't seem to work so I'll be approving each comment. There aren't that many (many more spam than real) so that's not really a problem, but you will see a delay when you post a comment.

- Disabled HTML in comments. I suspect that if a spammer can't create a link, then adding a spam comment to my blog isn't of much use to them.

- Disabled notification to blo.gs and weblogs.com on publication of a new post, which are used by trackback spammers to track new entries. Feedburner does a check every 30 minutes, however, so if you use the Feedburner feed, new entries should appear in your RSS reader fairly promptly.

(Yes, I know about the ul tag, but the formatting is incredibly screwed up and I just don't have the patience to fix it. Some days I really miss Blogger, believe it or not.)

If these measures appear to clear up the problem, then I'll try backing off on the comment moderation.

This blog is created with Movable Type 3.17; any further suggestions from MT experts are welcome.

Posted by Sandy Kemsley at 06:37 AM in Blogging | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 06:43 PM in SOA • SoftwareDesign | Permalink | TrackBacks (0) | Add to del.icio.us

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!

Posted by Sandy Kemsley at 08:51 AM in BPM • BRE | Permalink | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 08:23 PM in BPM • BRE | Permalink | Add to del.icio.us