The reduction (or elimination) of the cost of system change is a notion that is core to the value proposition of modern Rules-driven BPM systems. With the current sophistication of rapid prototyping tools, like Pegasystems’ SmartBPM where the velocity of functional change is reaching escape velocity, system owners will be tempted to believe that authoring tools alone will ensure a long, agile life of their new BPMS investments. Yet, BPMS systems are more susceptible, not less to system decay and the accumulation of what agile programmers call “code debt”. Refactoring is an architectural process of reorganizing a working software system with the intention of reducing the cost of future change—of paying down accumulated code debt to ensure that BPM systems remain long-lived, easy to change and inexpensive to evolve along with the business.
Code debt is the result of the steady accumulation of small mistakes, compromises, and misunderstandings that result from the incorporation of new and the alteration of existing application features. When code debt is left to accumulate, software become unnaturally complex, entangled, and obscure—three deleterious effects that turn today’s showroom-shiny systems into tomorrow’s junkyard-bound legacies.
The most highly accomplished software engineers continually struggle against the effects of code debt: it is not the result of ineptitude, rather the result of imperfect knowledge of future demands and the insistent nature of software change demands. To avoid the onset of analysis paralysis, software engineers have developed agile processes and techniques that allow them to operate effectively in an environment of potentially crippling uncertainty. Indeed many of those agile techniques have been coopted by the new generation of Business Technologists driving the adoption and expansion of BPMS systems throughout the modern enterprise.
As BPM practitioners, let us not overlook the inevitable effect of code debt. As BPM masters, let us seek to build on the wisdom of those whose backs we now stand upon. We must understand and embrace the tools proven to reduce code debt and do what we must to ensure that our rallying cry “Build for Change” is not immediately followed by the call for retreat. Refactoring is the process that must become part and parcel of the enablement package for the BPM-enabled enterprise.
Typical software refactoring seeks to make small, continuous improvements that increase the simplicity, flexibility, and clarify of implemented functionality. This approach works when the demand for new features is in equilibrium with the availability of expert resources to address the demand; this model will work once BPMS reaches steady-state within an organization. At the moment, most organizations are struggling to fulfill their initial, aggressive commitments with teams that are still learning their roles in the new world. In this stage, refactoring will most likely achieve results through separately-funded, architecturally-focused projects executed after the successful rollout of major new functionality.
Refactoring projects need not be large and expensive though their scope may suggest that they should be. Refactoring projects must rely on small teams of expert individuals working flexibly against a variable list of priority tasks (as with the SCRUM). Since refactoring is never done, time-boxing is the only practical measure of project completion. The governance and ROI measurement of such projects will seek to measure the improvements in efficiency and effectiveness of follow-on change efforts rather than on the individual merits of the refactoring process itself.
Refactoring is an essential element of agile software development processes—in the BPM world, it must also be recognized as a critical element of agile process development—an indispensible hygienic habit of the agile business.
