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.
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—even downsizings. 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.
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.
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.
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.
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 (unless you take the French pouce as an exact nonmetric inch), 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.
Dear KV, I've been reading your column occasionally and havent seen you address anything related to user interface design and how it can completely torque a piece of software. I happen to work as a programmer on a project for a company that sells point-of-sale software, which is a nice way of saying cash registers. The goals of the marketing people and user interface designers (we have several for our different product lines) always seem to twist the software into directions that only make it more fragile. These people ask for features that, while to a naive user might make the user interface easier to customize or use, to any of the programmers on the project its obvious that the feature in question will have a negative impact on code size, clarity, or some other nasty side effect. Several times our releases have been delayed because midstream we were asked for a feature that proved to have such a horrible side effect that it had to be removed right at the end. Sometimes these features are really just visual changes, but our system is so easy to change visually that it seems to invite the marketing and design folks to make changes just for the fun of it, as if the color of the buttons ought to be red one day, then blue the next. Is there any way to make these pests go away?