Workflow Systems

Vol. 4 No. 2 – March 2006

Workflow Systems

But, Having Said That, ...

80 percent of the useful work is performed by 20 percent of the code.

A persistent rule of thumb in the programming trade is the 80/20 rule: "80 percent of the useful work is performed by 20 percent of the code." As with gas mileage, your performance statistics may vary, and given the mensurational vagaries of body parts such as thumbs, you may prefer a 90/10 partition of labor. With some of the bloated code-generating meta-frameworks floating around, cynics have suggested a 99/1 rule - if you can locate that frantic 1 percent. Whatever the ratio, the concept has proved useful in performance tuning.

by Stan Kelly-Bootle

A Conversation with Steve Ross-Talbot

The IT world has long been plagued by a disconnect between theory and practice.

Academics theorizing in their ivory towers; programmers at "Initech" toiling away in their corporate cubicles. While this might be a somewhat naïve characterization, the fact remains that both academics and practitioners could do a better job of sharing their ideas and innovations with each other. As a result, cutting-edge research often fails to find practical application in the marketplace.

Going with the Flow

Workflow systems can provide value beyond automating business processes.

An organization consists of two worlds. The real world contains the organization's structure, physical goods, employees, and other organizations. The virtual world contains the organization's computerized infrastructure, including its applications and databases. Workflow systems bridge the gap between these two worlds. They provide both a model of the organization's design and a runtime to execute the model.

by Peter De Jong

Under New Management

Autonomic computing is revolutionizing the way we manage complex systems.

In an increasingly competitive global environment, enterprises are under extreme pressure to reduce operating costs. At the same time they must have the agility to respond to business opportunities offered by volatile markets.

by Duncan Johnston-Watt

Best Practice (BPM)

In business process management, finding the right tool suite is just the beginning.

Just as BPM (business process management) technology is markedly different from conventional approaches to application support, the methodology of BPM development is markedly different from traditional software implementation techniques. With CPI (continuous process improvement) as the core discipline of BPM, the models that drive work through the company evolve constantly. Indeed, recent studies suggest that companies fine-tune their BPM-based applications at least once a quarter (and sometimes as often as eight times per year). The point is that there is no such thing as a "finished" process; it takes multiple iterations to produce highly effective solutions. Every working BPM-based process is just a starting point for the future. Moreover, with multiple processes that could benefit from BPM-style automated support, the issue becomes how to support dozens or even hundreds of engagements per year.

by Derek Miers

Human-KV Interaction

We can't guarantee you'll agree with his advice, but it'll probably be more effective than anything you've tried thus far.

Welcome to another installment of Kode Vicious, the monthly forum for Queue's resident kode maven and occasional rabble-rouser. KV likes to hear your tales from the coding trenches, preferably those ending with a focused question about programming. KV also has a tried-and-true arsenal of techniques for dealing with interpersonal relationships so feel free to enlist his help with those characters as well.

by George Neville-Neil

People and Process

Minimizing the pain of business process change

When Mike Hammer and I published Reengineering the Corporation in 1992, we understood the impact that real business process change would have on people. I say "real" process change, because managers have used the term reengineering to describe any and all corporate change programs. One misguided executive told me that his company did not know how to do real reengineering; so it just downsized large departments and business units, and expected that the people who were left would figure out how to get their work done. Sadly, this is how some companies still practice process redesign: leaving people overworked and demoralized, while customers experience bad service and poor quality. I am reminded of poorly managed mergers and consolidations in the retail banking industry and what employees and customers have suffered.

by James Champy