1. The Case for Refactoring in BPM
   
2. Rules Governance Framework: 4 Phases
   

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.

Rules Governance is a specific form of corporate governance applied to ensure consistency and predictability of an organization’s approach to managing fundamental business rules. Rules Governance is a concern within forward-thinking organizations that recognize that business rules are at the core of a company’s operational performance and must be managed to:

• Minimize risks of non-compliance with regulatory and legal procedures
• Maximize the competitive advantage of business practice intellectual property

Business rules are the guiding principles behind every transaction between an organization and its key stakeholders:

• External stakeholders: Customers, suppliers, and shareholders
• Internal stakeholders: Divisions, departments, and individuals.

Business rules need not be embodied in a computer system. Business rule implementations may be just as effectively implemented by documenting them in training and SOP documents as by encoding them in an IT application. Rules Governance, therefore, does not immediately suggest that IT is involved. Business Rules Engines (BREs) are the most highly evolved repository for business rule embodiment. However, one must consider that not all business rules are suitable for embodiment in software and indeed not all businesses are prepared to begin to solidifying business rules into software.

As business leaders become aware of the importance of managing fundamental business rules as strategic assets, Rules Governance practices will evolve. To begin our exploration of the Rules Governance practice, we require a few simple tools to allow us to frame-up the domain.

Rules Governance is a process—ideally, an iterative process—which seeks to unearth common business practices and facts, bring them into focus for management, enrich them through re engineering, and finally to ensure their usage in the proper business contexts.

So, roughly, there are 4 phases of the iterative Rules Governance process:

1. Discover
2. Document
3. Design
4. Deploy

The Discover and Document Phases are alike in that they are best owned by the Business Operations staff, while Design and Deployment are best owned by Business Engineering (see Rules Governance Framework: 2 Partners). The Discovery and Deployment phases should encourage broad participation in an organization; to achieve buy-in and ensure completeness. Document and Design phases, on the other hand, require small audiences of accountable individuals to avoid excessive analysis and the traps of consensus decision making.

Each phase evolves a body of business rules (technically called a RuleSet); validating, improving and clarifying the RuleSet.

Discover Phase

The starting place for any governance process is to gather the common understanding of the rules currently used to govern business decisions. Discovery typically involves a combination of SME interview, documentation review, and software code inspection. The modern organization will house their SOPs in each of these forms. Initial discovery will often uncover redundancy and inconsistency in application of business rules; the guiding directive of this phase, however, is to collect rather than to judge. The discovery phase may be enabled using advanced knowledge management tools. (see RulesSeeker)

Document Phase

Once candidate business rules are collected, they must be recorded in a format that makes them available to the stakeholders for consideration. The documentation phase is about classification and clarification. Evolution of a business rule catalog begins in this phase. The end goal is to render existing business rules in a format most easily understandable by business stakeholders. Clear language, consistent structure, and a common lexicon of terms is required. This will unlock the underlying meaning of the recorded rules for debate and decision by management.

Design Phase

The Design Phase begins the formal analysis of RuleSets to remove redundancy, improve efficiency, and further define the appropriate contexts for rule application. Re engineering methodologies such as Lean BPM or Six Sigma may be applied to complex situations to provide objective analysis that may feed improvement of common practices. The Design Phase will introduce new hybrid rules which capture the best of an organization’s wisdom and eliminate rules which do not reflect internal best-practices.

Deploy Phase

The final phase for each iteration involves putting an evolved RuleSet into effect in an organization. This will require updates to SOP document, encoding of processing rules into formal executable language, and functional training curricula. Deployment efficiency requires that RuleSets are conveyed in a timely manner to any and all related decision points in the organization’s value chain. That deployment must include means to measure the adoption and application of the RuleSets—this information is useful for auditing the impact of RuleSets, informs the next iteration of the governance process, and allows management to score and improve operations.