Summary

The term 'decisioning' is in growing use in the business systems lexicon.  The concept of 'decisioning' recognizes the fundamental importance of decision making to any business.  Decision-making know-how is the critical knowledge that differentiates one business from another in the marketplace.  This two-part article provides insight into decisioning as a new and critical driver of the Systems Development Life Cycle, as drawn from the author's many 'decision centric' development experiences.  In Part One,^[1] we presented background and definitions for decisioning, and we argued that decisioning is a practical and valuable new design approach for IT.  In this Part Two, we follow on by outlining practical approaches and techniques for decision-centric development.

Decisioning and Product Engineering

The discussion in Part One of this article positioned decisioning as a practical and valuable new design approach for IT.

But decisioning has a more direct and strategic importance to the business.  We have outlined that the decisioning approach is focused on the core objects of the business (what is traded, managed, leveraged, used, built, or sold in order to achieve the objectives of the business).  We can give these objects a more common name:  products.

Decisioning does not just support business products; more than any other concept, it defines the anatomy of products.  While decisioning does not equate to product exactly, it is what makes one business' products different from another's -- without decisioning, the products are just commodities.

Decisioning is the primary differentiator of like (non-commodity) products.

Decisioning is therefore what makes one business more successful than another.  It determines how that business accepts customers, how it approves offers and contracts, pricing, and terms and conditions.

We have described an approach that allows control of decisioning to be returned directly to business owners.  Can this now be extended to include the entire product definition and so provide a 'configurable product'?

A Model for Configurable Product

The idea of a product definition that is managed directly by the business is not new, but our experience is that Gartner was optimistic in its projection as described below.

"Product Configurators: New Tech for Insurance Marketplace" [Gartner, 29 November 2001, Kimberly Harris].  Competition is driving insurers to quickly create and launch new insurance products, often without the necessary supporting infrastructures.  New technical solutions, such as product configurators, can assist....  Approximately 40 percent of Type A insurers in the United States will purchase or build new product configuration capability by year-end 2004.

Product configuration systems do exist.  However, our experience in the marketplace is that they are not delivering expected gains.  Most have focused on allowing extensible data; fewer include effective support for business rules; none make decisioning the core of a product configurator.  And to the extent that they support configurable product, they also tend to define and constrain the entire technology platform and strategy, resulting in indigestible technology implementations for most businesses.  It should not be necessary to be a technology hostage to achieve configurable product.

Configurable product does not need to be that big -- by leveraging decisioning technology it can easily be laid out with small developments that sit alongside legacy systems.  A few man-months of effort can produce a modest but practical configurable product platform in either C# or Java.  [Note: this is not idle assertion; we have developed bespoke solutions of this type for insurance customers.]  What is required is a clear understanding of the configurable product model, some supporting generic tools in the areas of decisioning and dynamic data definition, and XML.  XML is an enabler that allows data to be defined and used as a bridge between the components of configurable product.

We emphasize the focus on product in 'configurable product'; it does not include customer, channel, accounting, or other dependent business concepts.  These all exist because we have product, not to define product.  So from the perspective of product, dependents like customer, channel, accounting, etc., are simply part of the infrastructure.  (We accept that decisioning may have a role to play in managing each of these important but dependent entities, but these are not strategic issues and do not differentiate the business like product decisioning does).

To summarize:  we can say that product engineering and support is the primary focus of any business, and that the management of both dependent entities and systems infrastructure should be driven by the needs of this focus.  Our observation is that a discrete and pre-eminent product development cycle that drives systems development is rare; the inverse is invariably the case.

The practical manifestation of the above is that the systems infrastructure, which includes all aspects of the business other than the variable elements of product definition, should be configured to support product.  The product should simply plug into this existing business infrastructure, which we can consider to be the host system for configurable product, and which should already include support for all elements of customer, accounting, management, and distribution.

Figure 1. Business Infrastructure as Host for Configurable product.

The configurable product should also be seen to plug into the underlying technical infrastructure of the host system.

Figure 2. Configurable Product in the Host's Underlying Technical Infrastructure.

Elements of a Configurable Product Solution

The configurable product solution must offer an entirely encapsulated product, inclusive of product-specific data, decisioning, process, and documentation.  It is critical that the external infrastructure is not aware of the internal product variables.  Provided that the host system is not product aware, it can present any and all products without any requirement for coding changes to itself.  In effect, the host system acts as a product engine (the 'product proxy' in Figures 1 and 2).  The following topics are elements of product that typically need to be internalized within the configurable product definition.

Product Data

We have recognized that there is a range of data that will be used in the product cycle, but that has an existence independent of it (the customer, channel, et al).  We have also described a core set of generic product data that is likely to be common across all operators within a market.

These categories of data do not include the data that is unique to any specific product implementation, and so can be implemented within the host system if required.  But it is fundamental that the host environment must have no knowledge of the product unique data, which must be fully contained within the 'configurable product' process.

The data that exists exclusively as part of the product definition will be referred to as factors.

Product factors include all factors that the decisioning for this product requires, excluding externally-managed data.

For instance, we would differentiate between the customer's date of birth and a driver's date of birth on a motor insurance policy.  Only the latter is a factor.  Customer data is not product specific, and it would be supplied by the host environment on behalf of all products, whereas a driver's birth date must be acquired by the configurable product process itself within the boundaries defined by the configurable product definition.

Factors can be further broken down into sub-groups.  These sub-groups are often involved in different phases of the product cycle:

• Information that describes the product instance.

• Information that indicates customer choices and preferences regarding the product instance.

• Data that is created by the series of decisions that define the product (derived data).

The product factors must usually be interactively presented to the user.  This requires a dynamic and generic user interface -- that is, a UI that presents factors per se rather than explicitly-named data attributes.

State

We have asserted that value is created by changing the state of the product instance.

Each state change needs to be explicitly identified and discretely managed.  In our insurance example, important state changes might include:

• Quote

• Proposal -- turn a request for insurance into a proposal

• Policy -- turn the proposal into a policy

• Endorse -- re-run the policy decisioning with potentially new input variables

• Renew -- re-run the policy variables with potentially new decisioning

• Cancel

There must be some element of workflow management that matches the user request for a state change with the appropriate decision model that executes and governs the state change.

Contract Documents

With each change of state, one or more documents attesting to the change is usually required.  Construction of the document is a decision-driven activity that selectively collates pre-built text into one or more output documents.  The documents must accommodate dynamically-defined data.

Accounting

The accounting and portfolio effects of the state change should be stripped off in a standardized manner and submitted to the portfolio management system/accounting system.  This is often a legacy system.  This aspect of product is easily achieved by having the product decisioning routinely populate standardized accounting and generic 'class of business' variables.

Implementing the Concept

How it Works

We have identified a series of components that are required to implement the configurable product concept, many of which are available in some form today from various vendors.

• A product server that encapsulates and executes the configurable product definition (the product proxy in Figures 1 and 2).

• A workflow template that associates all of the following elements with a specific product state change request.

• XML schemas to define:
  • The data that will be supplied from the host in support of the decisioning;

  • The product specific data that will be captured or generated by the configurable product process;

  • Output to be returned to the host for upload.

• Forms for presentation and collection of data to/from users.

• Contract templates for production of contract documentation.

• Decisioning to:
  • Govern the state change;

  • Control the workflow;

  • Configure the form;

  • Compile the contract document.

These components can be integrated into an application that we refer to as a product server.  All interfaces within and to the product server should be defined in XML.  The product server is then accessed through a simple request interface, and it can be encapsulated into a loosely-coupled, self-contained application -- a product 'black-box'.

• The agreed interface data (customer, et. al.) as one or more XML documents.

• The description of the service required.

• The URL of the user's browser if forms are to be used.

Control is then passed to the product server.

The server uses its internally-held meta-data definition of the product's data and decision requirements, plus the workflow template, to process the product state change, including managing the interaction with the user if required.  When the appropriate decision signals that the product process is complete, the server returns the updated product documents to the host.  The product-specific data will remain anonymous to the host within an XML 'product' document. .

Any data that the host requires knowledge of (e.g., policy status, premium amount, etc.) is duplicated into standardized fields that are visible to the host for upload to the portfolio management system.  The anonymous policy specific data is stored as a single 'document' within the host database, along with appropriate 'real world' keys so that it can be recovered for future processing by the product server.

Forms

Forms are an important element of configurable product.  The configurable product solution requires that data is able to be collected automatically once defined.  The power of the browser as a user interface device allows us to generate a wide range of possible screens dynamically and quickly.

The use of frames and style sheets allows the host environment to independently manage the overall screen 'image', even as the product server generates the content.  There are several possible approaches to achieve dynamic forms, including XSD-based approaches championed by XForms.

An even more declarative design can also be achieved by adding meta-data to product factors that will drive the UI component.  In this design approach, dynamic HTML is generated according to the meta-data, while the factors themselves are carried as anonymous content.  In this way, generic presentation code is written once and is not aware of any explicit factor.  Provided that a meta-document exists to describe the factors, the generated form will be able to present and collect data.

Document Generator

The Document Generator will contain a library of pre-built text components that are assembled under the control of decisions to reflect the underlying product agreement (as defined by the XML).  With variable substitutions and formatting templates, reliable commercial-scale documents can be produced within the product server without human intervention.

The Product Configurator

A new tool -- the 'product configurator' as referred to earlier -- is required to manage the meta-data definition and deployment of products.  Business rules to govern the definition of products can be embedded into this application, using an even higher level of meta-data.

• This application has a very narrow focus.  Its use does not require any of the traditional 'IT' skills (platform knowledge, programming, database, etc.).

• Its view of the world is restricted to the data that is agreed and defined by the host system interfaces (e.g., customer) and to the set of factors that are defined for the product itself by the product owner.

• This limited 'world view' is then enhanced with product decision models, also supplied by the product owner.

The strong and well-defined focus of the product configurator allows us to create an application that is tailored for use by product specialists.  If supplied with built-in unit and regression testing, it will allow a product specialist to safely define and maintain products without the intervention of technologists.

Deploying the output from the product configurator is a matter of transferring the product metadata definition to the server, at which point the product becomes 'live'.

Conclusion

This article (comprising Parts One and Two) has presented a case for fundamentally changing how systems development views and manages decisioning within the Systems Development Lifecycle.  While valuable in its own right, this shift in emphasis can be substantially leveraged by the business by extending decisioning concepts to include other facets of product engineering.  While presented as a series of concepts, our experience is that every feature described herein is readily achievable with modest effort in today's development environment.

References

[1] Mark Norton, "Decisioning:  A New Approach to Systems Development (Part 1)," Business Rules Journal, Vol. 8, No. 1 (Jan. 2007), URL:  http://www.BRCommunity.com/a2007/b326a.html  

# # #