In the spirit of blogging about something a big lighter over the holiday week, I’m going to talk about my latest gadgets and their quirks next week, possibly sprinkled with some of my usual BPM-related fare. Due to some long-overdue upgrades, the past few months have been one big gadget-buying spree for me, so there’s lots to talk about.
Also check out my new Squidoo BPM lens, and sign yourself up at my Frappr map.
Catching up on a few webinars that I missed live, I just reviewed the replay of ebizQ’s Integration Trends 2006. There’s a nice summary slide up front by David Kelly, an ebizQ analyst, where he talks about the current focus of most businesses (reducing costs, increasing flexibilty, becoming process-driven) and most IT departments (composite applications, modernizing legacy systems, moving to SOA and event-driven architecture). Certainly true for all of my customers.
The webinar was sponsored by PolarLake, makers of an ESB product, and it turns out that the CEO, Ronan Bradley, has a blog that includes some interesting stuff, such as his recent post that “exposes the myth” of run-time discovery of web services (he quotes and comments on a post on the same subject by Brenda Michelson). Alas, I’m unlikely to read his blog much since he chooses not to publish full feeds, and I find it too much of a hassle to click through to every blog on my list of daily reads.
Anyway, back in the webinar, Ronan Bradley made a huge point about how ESB is not EAI, but I’m not sure that the lines are that clearly drawn. David Kelly later asked how he made that distinction, and it seems to be based on attributes such as “distributed, standards-based, extensible” and providing “productivity and agility”, but I don’t think that the lines are that clearly drawn between ESB and EAI: it’s more of a spectrum of capabilities than the black-and-white picture that Ronan puts forward. He depicts EAI as having functionality without these attributes, “lightweight ESB” as having the attributes but little functionality, and (of course) PolarLake as having both the functionality and the attributes.
Of course, what vendor doesn’t find a graph to publish where they’re in the upper-right quadrant? Gartner probably just calls it all integration-focused BPM anyway.
Regardless of any distinction between EAI and ESB, he does make an interesting point about how orchestration isn’t so simple as it is often portrayed, but requires “mediation” around the orchestration that may be many times larger and more complex than the orchestration itself: things such as complex data manipulation and translation beyond simple XSLT transformation, interaction with existing infrastructure and applications, and complex and recursive data transformation, enrichment and management.
I grabbed an invitation a few months back to participate in the beta for Squidoo, the latest Seth Godin project. I haven’t had much time to do anything with it, but a few things prompted me to go back and fiddle with the BPM “lens” (portal) that I created on Squidoo: first, there was an email that came out from some anonymous prat on the Squidoo beta team that threatened to nuke my lens if I didn’t do something with it, which was promptly retracted in a second email from Seth himself — that at least had me think about it again (which may have been the carefully crafted intent…hmmm). Second, I was playing around with moving my bookmarks into del.icio.us, and after adding a number of BPM-related links to my list, I linked through to other people’s lists with the same links to see what else that they had of interest and found that David Ogren’s list had a link to my Squidoo BPM lens on his list. Yikes! There’s nothing that kicks me into action faster than having someone watching me.
I’m not sure what direction that I’m taking it in, but for now, my BPM lens is a variety of information related to BPM that I use as a reference, and may be of use to you as well. Click here to check it out; I’ve organized the following modules so far:
If you’d like to suggest something to add to it, just drop a comment or email.
How much information and how it is used is a fundamental issue that I always deal with when designing processes: the usual tendency is to put too much information into the process itself (typically because the line-of-business system is so ugly that no one wants to deal with it directly), but that over-replication of data causes problems with synchronization and potentially performance. I’m a big fan of keeping the data in a process to the minimum as long as those other systems can be accessed in some way, and replicating data into the process for three reasons only:
As Value Wizard points out in Process/information integration, too much information can be just as bad as too little, and can lead to delays and inefficiences while a human operator sorts through a mass of data to find the one piece that they need to execute the task at hand. He points out that we need to be mapping information architecture right along with the process and business architecture, and points out the value of an enterprise architect in ensuring that the information (data) architecture is aligned with everything else.
I’m always interesting in my site stats that show readers from all around the world. Share your location with others that read this blog by adding yourself to the Column 2 Frappr map.
Appian has a link to Gartner’s newly-published report on BPMS selection criteria here (free registration required). Gartner has the 10 major areas of functionality used to develop the criteria listed as following:
For each of these, the report provides a description of the functionality and why it’s important, then provides a list of what to look for when you’re evaluating that particular functionality. For example, they have this to say about real-time agility:
We believe that making changes to process flows in real time is less important than making changes at the correct or relevant time.
A sentiment that I wholeheartedly agree with — in fact, I think that I said pretty much those exact words during my course earlier this week. They proceed on with several paragraphs of explanation about the factors involved and what to look for, then the dish up their “factors to seek out” list, which includes things such as BPEL support, and early warning through rules and complex event pattern matching.
Excellent reading, and a very practical checklist for anyone evaluating BPMS.
Completely unrelated to BPM, EA, or anything else that I usually blog about, I have a great idea for one of those iPod silhouette ads for Canadian viewers (readers from Michigan, Wisconsin and Switzerland will also appreciate). This came to me last week after I received a video iPod as an early Christmas gift, then had to travel halfway across the city to see a client on the day of a 3-4″ snowfall. Picture a long parka with a snorkel hood (something like this, if you’re having trouble imagining it), with the white headset cables emerging from inside the hood, then trailing into an inside pocket of the coat where the iPod is, of course, out of sight so that it doesn’t freeze over. By now, you shouldn’t have to see the actual iPod to know what’s connected to those white cables.
This would be funnier if it weren’t quite so true.
I had the unique experience of meeting two other BPM bloggers this week for the first time, one unexpected and one planned.
As I mentioned in a previous post, I was in Dallas to deliver my Making BPM Mean Business course for Imagine Solutions, and was pleasantly surprised when George Dearing of the ECM Blog walked into my classroom at the end of the first day to introduce himself. I link to his blog on my blogroll, so I knew that he works for Imagine, but I had totally forgotten about that in all of the activities around preparing for the course. He read my blog post from Sunday night (in which I didn’t mention that Imagine was my client), and thought that this was too much of a coincidence that I was in Dallas so went scouting around his office to find out if I was there.
On a more planned note, I met up with Ethan Johnson of The Vision Thing for dinner; Ethan and I have been trading blog comments for months, and he interviewed me for one of his Sound of Vision podcasts, so when I knew that I was coming to Dallas, we made the arrangements to connect. I didn’t wear my Process For The People tank top (too cold!), but we still managed to identify each other. We had our own little geek dinner, and as he pointed out, it was unusual because we had equal gender representation, which likely doesn’t happen much at geek dinners. I also noted that we had equal representation from Canada and the U.S.: sort of a NAFTA geek dinner, if you will.
Great to finally meet both of you guys face to face!
Tom Davenport posted last week about how process isn’t going away, in spite of some arguments against Six Sigma and process management. I couldn’t trace his reference to a specific entry on John Hagel’s blog (Tom, a direct reference to the post in question would be helpful!), but I agree with his assessment of Ross Mayfield’s The End of Process post as “silly”, mostly because Ross’ post assumes that business processes are static and (as Ethan points out in a comment on the post) confuses process and policy.
I especially like Tom’s last paragraphs on the balance between process and practice.
I’m in Dallas for the first part of this week, delivering my 2-day Making BPM Mean Business course to a client. This is the second time for an end-to-end delivery of the course (the first time being for a group of FileNet customers at their user conference), and it’s quite a different sort of audience from the first delivery so I expect to learn more about what’s needed and what’s not.
I’m having a lot of fun with the teaching gig: I seem to have been teaching most of my life, from the 3rd-grade teacher having me run the spelling test because I knew all the words already (and she probably wanted to sneak out for a smoke), to substitute teaching first-year university algebra when I was an engineering graduate student, to teaching machine vision and image analysis courses for Learning Tree in the late 1980’s, to the teaching component of evangelism when I ran my own systems integration group and, later, worked for FileNet.
This is the first time that I’ve completely written a multi-day course as well as delivering it, but it turned out to be easier than I expected: the biggest problem was cutting out material to keep it to two days, and I still found myself having to cut one section on the fly during the first delivery because I really tend to get carried away talking about this stuff with customers. In particular, the first part of the course (a little more than one day) is entitled “Why Process Matters”, a topic on which I can rave passionately for hours on end.
