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.
top of pageIt has been a solid two decades since Information Technology overtook Data Processing as the moniker for application of computational tools and techniques in business environments. More than a mere label, Information Technology was a transitional approach that served to bridge the gap between a generation oriented by computational scarcity to a generation formed through computational abundance. It served us by providing an organizational model for reducing the risk and cost of adopting computer technology in the banishment of redundant and menial tasks. It served us by carving out an elite class of technology gurus who lived with one foot in the esoteric world of DLLs and one foot in the rigorous world of CMM-level deployments.
But we are entering a new era—an era defined by unprecedented familiarity with computational tools. The generation now feeding the workforces in the developed world is made up of comfortable consumers of technology—and more than that, they are expectant consumers. IT was born from a consumer world that required advanced degrees and multimillion dollar grants to access computer technology; Business Technology (BT) was born from a consumer world where such technology is ubiquitous, friendly, and taken for granted.
The rise of Business Technology means a shift in power from Information Technology gurus driven by the need to protect sensitive systems from harm to Business Technology leaders strewn throughout the lines of business, and driven by the expectation that systems are at their disposal to make work life faster and more connected. The Business Technologists will not report to CIOs and work on guarded floors—they will work in the call centers, the claims processing departments, and the branches. Business Technologists will begin to solve the operational problems facing them with the technology tools that they have grown-up using: the internet, cellular telephony, and mobile computing.
It is a risky proposition to be the first to embrace this new generation of transformational leaders, but it is also a promising one. Technology in the hands of people most familiar with the ins-and-outs of daily business can squeeze out cost by automating routine fulfillment tasks and can coax out additional revenue by enabling risk-reduced, customer-smart decision making at the grass roots level. To gain these advantages today, a business should have a guide. A guide that can work with both the business operations and information technology staff to chart a safer journey that encourages the direct application of flexible business technologies without risking the health of core systems and safety of core data.
top of page