1. Invest in Training Operations Staff in BPM
   
2. The Rise of Business Technology
   
3. KROME: Modular Model
   
4. KROME Module: Functional Components
   
5. KROME Module: Decision Engines
   
6. KROME Module: Process Flows
   
7. KROME Module: Business Object Binders
   
8. Rules Governance Framework: 4 Phases
   
9. Rapid Deployment of Simple Processes
   

Investments 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

It 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.

Fundamental to the KROME schema is the division of the universe of possible combinations of policies and procedures in a computer-enabled business into four universal archetypes. The “Modular Model” shows the four archetypes in relation to each other. It is intended to address the design of BPM/BRE solutions by creating discrete, recognizable concerns each with its own appropriate mechanism for implementation and inclusion.

The role of the module is to encapsulate the complexity and detail in a way that maximizes reuse through simplified use. The separation of concerns increases the likelihood of reuse by encouraging the creation of larger recognizable units of behavior with well-defined boundaries. This separation also enables a division along lines of intimacy with either business or IT expertise.

The quadrants of the Modular Model lay out four component archetypes.

While “rule reuse” is an important element of the application design, there is little practicality in expecting reuse at the PRPC rule level of granularity. It simply takes less time to replicate a single rule, when and where you need it, than it does to locate a potentially “reusable” one. Specialized elements, typically single rules or tightly coupled data functions, are not worth the investment to build as reusable.

Reusability is best employed at the level of providing common business functions, and at the business policy decision level. By subdividing applications into key modules we simplify the answer to what can and should be reusable and the particular knowledge required to create and/or use these modules. The more common a function or a business policy is, the higher the opportunity for reuse.

The components of the Modular Model, their definitions, and the guiding principles of their design and development are explained on the following four pages:

KROME Module Functional Components

KROME Module Decision Engines

KROME Module Process Flows

KROME Module Business Object Binders

One form of PRPC Module is the Functional Component. Such components can be expressed as s core objects which provide one or more related actions to clients of the object. They are used to perform well defined computations which avoid changes of state and mutable data. They perform functions rather than make decisions. They are relatively generic. A typical Functional Component will have a purpose and interface which would be familiar to designers of similar data systems inside or outside of the enterprise. Each will tend to support an archetypical set of functions using general purpose parameters.

Identification

Functional Components are used in the applications as means to complete some external directive of the process. They are the implications of the process rather than a functional specification participating in the process. For example, any application involving a calculation process may want to generate an invoice of the same. In this case the invoice generation feature would be identified and implemented as a Functional Component. The external nature of the Functional Component makes it naturally closer to traditional IT/development mindset. These modules are often easily specified and therefore likely targets for remote construction.

Design

Functional Components should be built in a way that makes them analogous to a DLL or Shared Library. The implementation of specific functionality should be abstract and disentwined from the software that leverages them. The class structure used to implement the Functional Component shall be entirely independent of the application’s main class hierarchy but may be related to the class hierarchy of similarly designed Functional Components. The separation of class structures ensures that the usage and the implementation of the functionality are kept independent.

Usage

Functional Components are made available for use in a PRPC application by the inclusion of a containing RuleSet. The infrastructure will interrogate the rulebase at run-time to determine the list of currently available Functional Components. These may be added dynamically or statically; though the invocation of a specifically offered Function on a Functional Component will require some level of design-time introspection to take advantage of it.

Implementation

The implementation of each Functional Component, on the other hand, is free to vary as long as the interface (or signature of the functions) is held constant. The Functional Components will be represented at runtime by a branch of a single high-level clipboard page, and not embedded within the pyWorkPage. Interaction between work objects and Functional Components is accomplished in the same way as that of an interaction between separate, in-process objects.

KROME: Modular Model

Decision Engines are modules exploited for their ability to apply one or more business policies to a narrow set of criteria to derive a decision in the form of a small set of simple output variables. A simple Decision Engine may take a list of conditions as input and return a Boolean value indicating the true or false interpretation of those conditions. However, not every discrete policy will guarantee the creation of a decision engine. The art is in picking between simple decision rules, more complex Decision Engine candidates, and overly complex Process Flows that chain multiple decision rules/engines.

Identification

Like a Functional Component, a Decision Engine will not cater to the change of state or the operation on mutable objects or data. Each interaction with a Decision Engine should be stateless. Keeping the Decision Engine’s boundaries crisp will allow ultimate flexibility in selecting the appropriate host for the decision. This discipline will ensure that the decision is separated from its intended implications, which may vary from application to application. This will also increase the likelihood of reuse and limit the scope of change introduced by modifications to the Decision Engine’s implementation. Moreover, such separation greatly aids the testing of a module which is likely to represent tens of thousands of possible outcomes with frequent modifications.

Design

The specification, construction, and maintenance of a Decision Engine are tied closely to the business side of the project owners. The need for iteration with interactive sessions and knowledgeable subject matter experts makes development of this module-type more suitable for:
• agile programming methodologies;
• that are best done at onsite locations;
• by developers trained in client-facing disciplines and the problem domain.

Part of the discipline of designing Decision Engines is to isolate discrete, single decisions from a more complex intertwined chain of decision processes. A single Decision Engine should make a single decision. Complex decisions will be orchestrated by remote SOA consumers or through Process Flow modules which chain the output from one decision engine to the input of another. Doing so makes each Decision Engine simpler and more likely to be reused.

Each Decision Engine should be built to support a SOA interface. This is done to facilitate unit testing, increase the likelihood of reuse, and enforce the discipline of separation of decision elements from process elements. The Process Flows that leverage a Decision Engine may use the SOA interface to engage remote decision making or interact through a proxy interface in-process with a single Requestor. External consumers will leverage the decisions provided by a Decision Engine through SOA invocations or through in-process invocation (batch-style) using Rule-Service-Java or the JSR94 features of PRPC.

A Decision Engine will contain no user interface rules, and should never be used interactively. Neither will it contain integration rules, as all data required to make a decision should be supplied through input parameters defined in the signature of the module. And, as previously mentioned, no mutable data should be altered, therefore there are no transactional implications of invoking a Decision Engine.

Usage & Implementation

Decision Engine modules are typically incorporated into Process Flows using Decision Shapes in the Flow rules. As a result, they are implemented along with the Process Flows. A Map or When Rule shall be used as a simple, familiar façade to a more complex decision. More complex decisions, which may return multi-dimensional results, shall be implemented using a Utility activity as a façade.

KROME: Modular Model

Process Flows are the most commonly understood form of module in a PRPC design and are typically where all of the elements are orchestrated to realize business process. Using “drag and drop,” processes can be constructed out of decision engines, functional components, Business Object Binders, and often user interface rules by those with business intimacy. Due to the fast nature of this construction and the frequency of change to business process, process flows and their low level elements are not typically candidates for reuse.

Identification

Process Flows are close to the business, and are intended to be malleable enough to support rapid prototyping activities. As a module, the Process Flow is the most context-aware. This makes reuse unlikely except as a source for cut-and-paste code. Moreover, the nature of the Process Flows as implemented in PRPC makes reuse less necessary because the barrier to recreation is quite low. Therefore the major driver for reuse will be consistency rather than efficiency of construction. Nonetheless, careful reduction of the units of a Process Flow into more generic sub-flows may encourage reuse where possible. Embracing this distinction will help guide the design of individual Process Flow modules. This module will include flows which orchestrate User Interface elements with Decision Engines, Functional Components, and Business Object Binders as appropriate. For PRPC, the presence of a task-oriented user interface is the key to identifying a Process Flow from other module types.

Design

To support the rapid prototype approach to initial implementation, Process Flows should be designed following Pegasystems’ recommended guardrail to “Do nothing that is hard.” That implies that the heavy lifting should be left to (and partitioned into) other module types which can be conditionally included within the Process Flow. So the KROME framework modifies the approach to say “Do nothing in a Process Flow that is hard.” Naturally an application’s value will increase with the inclusion of more complex capability, but the value of the Process Flow as a module will depend on the exclusion of those complicated implementation into other modules.

Usage & Implementation

Though normally resident within PRPC, Process Flow modules may be implemented in other third-party BPM or workflow tools with SOA or in-process invocation capabilities of core PRPC modules. The orchestrating modules are best chosen based on the strength of performance in the application domain. For example, interactive processes within a single task-owning group are best implemented in PRPC, while those that orchestrate processing across multiple systems or departmental boundaries may be best implemented using an integration-oriented BPM tool such as Tibco.

KROME: Modular Model

Business Object Binders allow for controlled access to complex data-oriented objects whose persistence is maintained and managed by one or many external systems. The Business Object Binder module provides an abstraction over the retrieval and storage of such objects. Consumers of the services offered by Business Object Binders will request objects by type and identifying elements (specific or search oriented) and receive either a specific instance of an object or a list of possible objects. The Business Object Binder will manage data retrieval, transactional boundaries, data transformation, and enrichment.

Identification

Business Object Binders live between data consumers and interfaces that provide the data. The nature of Business Object Binders makes them very close to IT. The objects represented are of interest to the business, but the structures and sources of the data are not. These more technical aspects are likely to be specific to the system environment in which the application resides. It is likely to change as IT initiatives change underlying systems of record and as architectural imperatives drive change of underlying access methods. Because the Business Object Binder is more intimate to details of surrounding systems (some of which will certainly be custom made or legacy systems), the details of the plumbing of integrations requires the ability to interact directly with IT stakeholders. These modules can be specified fairly easily following message standards and ETL specifications. Core development can therefore be done offshore. However, actual integration into the environment should be done onsite or at least by time-zone equivalent remote staff.

Design

A Business Object Binder is heavier-weight module which requires that the solution demand more complex orchestration of integration and transformation tasks that transcend the context of use. It makes a convenient place to implement common, complex processes related to data maintenance, hiding the “hard job” from the simple consumer modules such as Process Flows. Business Object Binders may include limited User Interface components related to data enrichment. Knowledge of context should be limited. A Business Object Binders is not a replacement for simple interfaces. It will provide an interface that is likely to be reusable across an enterprise or at least a department. The implementation, however, is more likely to be bound directly to a specific group and period of time. It is intimate with the details of surrounding systems even if it is not intertwined with the context of data use.

Usage & Implementation

Business Object Binders will be used by Process Flows and Functional Components through a set of façade activities that implement create/read/update/delete (CRUD) type operations on complex objects in the system. The objects will be represented by a single, nested clipboard page. Interaction with the page, once instantiated by the Business Object Binder, is standard. Implications of manipulations on the persistent objects underlying the represented instance can be managed by the consumer through explicit façade calls through the Business Object Binder or by the Business Object Binder itself. Implicit operations implemented without the knowledge of the consumer will be needed to enforce contracts between the managing systems and the Business Object Binder outside the scope of a consumer’s interest.

KROME: Modular Model

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.

Although 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.