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 Business Object Binders
top of pageOne 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.
top of pageDecision 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.
top of pageProcess 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.
top of pageBusiness 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.
top of page