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 pageKnowledge Rules is proud to be a Gold-level sponsor of the industry’s premier Business Process Management event, PegaWORLD 2010. This year’s PegaWORLD conference was filled with practical advice from experienced practitioners for organizations at every stage of BPM adoption.
The Knowledge Rules kiosk in the Partner Pavillion showcased elements of our customizable service offerings:
- BPM learning modules
- KR GuidePost Community Wiki
- Cloud computing best-practices
- BPM-enabled CRM for Utilities Companies
- FXM Financial Data Exchange for Treasury Operations
Many new clients too advantage of our offer to participate in our industry-leading needs assessment methodology, the Business Technology Roadmap, free of charge. To learn more and to access this valuable free service, contact us to schedule an appointment for your organization.
| Schedule Business Technology Roadmap: |
From the very beginning, Knowledge Rules staff have been the ambassadors of the growing Pegasystems community. Our friendly staff was visible throughout the conference proceedings.
Read our Blog Posts from last PegaWORLD!
top of pageInvestments in formalized BPM training your business staff can yield higher returns than investing in additional formal training for your IT staff. Why? Two reasons:
1. Formal learning methods have a negative or inverse relationship to competence:*
While IT staffers generally understand technology principles well enough to absorb new developments into their repertoire without formal training, business staffers rarely have the background necessary to quickly and informally grasp the full implications of a new technology development such as Business Process Management.
2. Understanding of the SDLC process is asymmetric:
Most IT staffers have a strong understanding of the software development lifecycle as employed in the enterprise—they live within the ecosystem defined by that lifecycle. On the other hand, operations staff is only rarely exposed to the SDLC process—their daily lives being dictated by the ebb and flow of the operational processes not by the processes of IT solution creation. With BPM and BRE technologies transforming both the pace of change and the roles and responsibilities of solution deployment, a well-informed business partner is more important than ever in squeezing value from IT investment. By training business stakeholders to better fulfill their expanding roles in the SDLC process, organizations create a stronger partnership between IT providers and Business consumers. The improved partnership creates a virtuous cycle which reduces uncertainty in projects and increases the translation fidelity between business need and IT solution.
Making business leaders and subject matter experts more fully conversant in the power of BPM, businesses can harness their creativity and experience to create more effective requirements—requirements that improve operations, reduce costs, and expand the business.
*Source: Altus Learning Systems, presentation to Learning Economics Group Nov. 17, 2004
top of pageAlthough RDOSP isn’t a very compelling acronym, it is a compelling concept. 40% of job activities are ad-hoc in nature according to a 2004 report published by McKinsey. The report refers to these as “tacit tasks”. These 40% of processes are currently unaddressed or under-addressed by most BPM software solutions. Organizations are making due with band-aid applications, the competition in this space being email and spreadsheets.
What leaves these 40% unaddressed by more rigorous solutions is that their impermanence makes them hard to target:
• Following a traditional project lifecycle, by the time the requirements are understood, the need may have passed or the focus radically shifted.
• The short duration of an ad-hoc process’s lifecycle also makes an ROI-based, project justification difficult. For a 2-week long process, payback can’t be justified over 2-years.
These problems can be addressed. There is a single barrier to overcome: deployment time. How does one achieve the rapidity and simplicity required to address, in a cost-effective way, the ad-hoc processes that make-up a substantial portion of the world’s work?
Rapidity requires two key ingredients:
1) Frictionless instantiation of a development/processing environment.
2) Digestion and implementation of process details inside of a minute.
Frictionless instantiation is becoming more feasible with advent of Cloud Computing and Platform as a Service (PaaS) movements. Simplicity requires two additional key ingredients:
1) A scaled-down definition of what constitutes an ‘adequate’ solution.
2) The unearthing of workable assumptions and the pre-building of widgets to allow processes to be ‘mashed-up’.
We find applications for RDOSP capabilities in traditional “transactional” process fulfillment as well. An organization might start the journey toward automation by first taking a single, simple step. A multi-generational approach is certainly more palatable to certain organizations because it allows for ongoing organizational learning and a faster path to short-term value.
top of page