3 min read

Tear Down This Wall

E-commerce expert Peter Fingar and CSC Europe CTO Howard Smith are business process management systems (BPMS) evangelists. They envision a world where application design teams don't have to worry about the IT stack and don't have to throw their requirements over the proverbial wall to programmers.

You've said BPMS is a killer app for service-oriented architecture (SOA). How so?

Fingar: Web services are to business-to-business interactions what the World Wide Web was to business-to-consumer: a dramatic simplification of the distributed computing infrastructure. A BPMS is a business-level tool that exploits this simplified infrastructure, giving companies a new capability to innovate with their unique business processes. Web services are about technology, the BPMS is about business exploiting that technology.

So a BPMS as you define it has to be something a business analyst can use independently of IT collaboration?

Smith: There's a sophomoric notion that using a BPMS is terribly easy and businesspeople can "just do it." The BPMS has this potential, but BPMS products today are on a journey. And just like when early relational databases became available to business, the schema design and reporting tools weren't terribly business friendly. But the database platform had the potential to become very business friendly, as does the BPMS today. Some companies are already at that stage with BPMS.

Fingar: We need a common platform, a common semantic, so that everyone is working on a common, directly executable model. You're not taking requirements specifications and throwing them over the wall, with umpteen levels of translation. Essentially, the process design, just as with a spreadsheet, is the execution model. It is the system.

Smith: It's not so much that businesspeople are going to be left alone to do their requirements modeling. Requirements modeling is complex in all but trivial workflow processes, demanding contributions from multiple disciplines, including IT. But at least the team knows that when it agrees on the design, it can be put into operation in a single step, without distortion. All this sounds ambitious, but case studies show it's happening.

Is the ultimate goal of BPM for organizations to operate in real time and become event driven?

Smith: It's not the whole reason, but could be related. If I can lower the time it takes to conceive and deploy new functionality, then I've got an agile business.

Fingar: In my book, The Real-Time Enterprise (Meghan Kiffer, 2004), I categorize two kinds of time, response time to tactical events and restructuring time: How long does it take when a major event occurs in your industry for you to be able to restructure your company, to reallocate resources?

In terms of "event driven" — we've had publish-and-subscribe messaging for a long time; all modern systems are event driven. But one area where event driven is relevant to BPM is business intelligence. There, I point to the work of David Luckham in the field of complex event processing: How do I take low-level noise in this message-driven world and start deriving higher-level, useful business intelligence? Instead of just going into a data warehouse to pull out historical information, let's monitor messages that may have nothing obvious to do with an individual application. You're listening to a lot of low-level messages to see if there's a higher-level meaning. It can be a very useful augmentation to the feedback loop in your process-driven enterprise.


What's your favorite thing to do with your kids?

Smith: We're building and launching model rockets. My son designed "Oli 3," with a digital altimeter, using CAD/CAM software.

What's your passion?

Fingar: Gardening. I feel like I'm directly participating in the deep mysteries of the universe. I recently discovered the moon flower, which blooms only at night.