Workflow Systems

Vol. 4 No. 2 – March 2006

Workflow Systems

Interviews

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.

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.

This is why the world needs more people like Steve Ross-Talbot. He has more than 20 years of experience leveraging cutting-edge research and applying it to real business problems. Recently he founded Pi4 Technologies where he and his team draw on the field of the pi-calculus to improve the ability to design, automate, and analyze business processes.

Articles

Best Practice (BPM)

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.

Best Practice BPM

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

DEREK MIERS, ENIX

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.

As the intervals of change get shorter and shorter, companies need to develop effective methodologies to get around the business optimization cycle quickly enough.

by Derek Miers

Curmudgeon

But, Having Said That, ...

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.

But, Having Said That, ...

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.

An intriguing analogy exists in NL (natural language). In English, for example, a reasonably exact 99/1 split has been found by counting those entries in the OED (Oxford English Dictionary) that have Anglo-Saxon roots. You will be aware that English is (in)famous for borrowing outrageously from other tongues, but the extent of the borrowing may surprise you. Just 1 percent of our current lexicon is truly “native” Old English from around 500-700 CE, and even that language was a complex mix of marauding Old Norse and other Germanics, with a colorful dash of indigenous Celtic. Yet, the further startling fact is that the 1 percent of natively derived words makes up some 60 percent of everyday usage. The reason, you’ve probably guessed, is that most of those short, busy words such as the, a/an, I/me, if, and, but, and not are of Anglo-Saxon origin in addition to the many common nouns such as axe, shield, and blood that enliven Beowulf!

by Stan Kelly-Bootle

Articles

Going with the Flow

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.

Going with the Flow

PETER DE JONG, MICROSOFT

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.

Organizations are continually evolving. Workflow models represent the organization’s design in a visible way. The workflow runtime interprets the workflow design. The combination of model visibility and organizational execution tied to the model facilitates both a top-down and a bottom-up evolution of the organization’s computerized infrastructure.

by Peter De Jong

Kode Vicious

Human-KV Interaction

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?

Human-KV Interaction

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—the annoying co-worker, the micromanager, the spaghetti-coder—so feel free to enlist his help with those characters as well. We can’t guarantee you’ll agree with his advice, but it’ll probably be more effective than anything you’ve tried thus far.

by George Neville-Neil

Articles

People and Process

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.

People and Process

Minimizing the pain of business process change

JAMES CHAMPY, PEROT SYSTEMS

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.

I have also experienced the exhilaration of people when business process change is well managed. Members of process design teams have told me that they can never go back to thinking about or doing work in the old way. Their lives have changed. But this is countered by a challenge: transformed work often requires fewer but more highly skilled people, whose jobs are now more complex. Just think of the service representative whose changed job is to solve the customer problem, rather than pass the customer off to another person or push the hold button.

by James Champy

Under New Management

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.

Under New Management

Autonomic computing is revolutionizing the way we manage complex systems.

DUNCAN JOHNSTON-WATT, ENIGMATEC

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.

Leveraging IT for competitive advantage is fundamental to a company’s success, while maximizing its use of IT infrastructure is crucial to cost reduction. Moreover, architecting systems to handle peak activity and to provide adequate business continuity backup is a prerequisite that adds to both capital and operating costs.

by Duncan Johnston-Watt