The 5 Step ’Decision Centric’ Development Approach

Mark Norton  11 April 2011 08:32:54 AM

The 5 Step 'Decision Centric' Development Approach™

The 5 Step Decision Centric Management Approach™ is an approach that uses the specification and management of decision making to assist the development and implementation of business strategy, with particular emphasis on optimising the development of systems to support the business strategy. This approach leads to:

·        Tighter alignment between business strategy and the systems that implement it;

·        Direct, immediate hands-on control of automated decision making by the business owners;

·        More responsive, more agile, more versatile business products and services;

·        Accurate, timely, decision making provided within frontline systems;

·        Faster, safer, cheaper systems development and ongoing maintenance;

·        Increased auditability, transparency, and control of operational business decision making.

The approach can be implemented progressively and without duress into most organisations, starting with small targeted business areas, and progressing as the rewards become apparent and confidence builds. The minimal investment required provides immediate returns through lower systems costs and improved business effectiveness.

Step 1 – Business Concept Modeling

Purpose: To understand the business value proposition and to build a vocabulary that describes the value proposition in the business’s own terms (an "idiom", Defn: the characteristic vocabulary or usage of a specific human group or subject. http://www.thefreedictionary.com/idiom).

Outcomes: Entity Relationship Diagram (ERD); a list of important and related events that the business recognizes and responds to; a matching list of the key value transformations that the events trigger.

Duration: 1-10 days, depending on the size of the target domain.

Analyze and describe the business domain in terms of business concepts (‘entities’) using the founding documents of the business – business strategy, business policy and procedures, mission statements, etc. These documents define the core value proposition of the business. The concept model should reconcile 100% to these business documents so that there is no disagreement between them before proceeding any further.

Expand and confirm the model through analysis of existing systems, practice and procedures, and by direct reference to subject matter experts (SME’s). However, be careful that these sources do not describe outdated concepts that do not align with the current aspirations of the enterprise.  The inertia in legacy systems, and in manually supported practice, procedures, and expertise creates an environment that protects legacy concepts and slows the organization. The founding documents as described above are, by definition, forward looking and should not be contaminated by legacy concepts.

Work the set of business entities and their relationships until you have addressed the full scope of the target problem domain.

The most useful tool for this process is the whiteboard, followed by an Entity-Relationship diagramming tool to capture the results of the analysis.

Note that we have referred to an ERD, not a data model. At this stage we are interested in the existence of concept level or primary entities, and the relationships between them. We are not interested in their attributes or in entities derived by normalization. At best, note attributes if they help to clarify the meaning and intent of the concepts.

Examples: Insurance policy, risk, claim; hospital patient episode, clinical pathway; airline frequent flyer, ticket; superannuation fund member entitlement, fee; government service application, consent.

The business value proposition is defined in terms of the entities in the business concept model. Value is derived by changing the state of these entities – if there is no change, then by definition no value has been created.

Furthermore, the change in entity state must be the result of a decision by this organization. The value created by a state change originating elsewhere belongs to the originator (for instance, the increase in value of an asset does not create value for the organization until a decision is made to buy or sell the asset, or revalue its book value). Creating value without making decisions is a zero sum game – if it were not, it would be the equivalent of perpetual motion and we would all be wealthy!

Events trigger each state change. The concept analysis should capture the core value changes and their triggering events as a list of candidate decision models.

Examples: Insurance underwrite and rate risks, approve claims; hospital cost patient episodes, evaluate participant locations on a clinical pathway; airline calculate frequent flyer awards, price tickets; superannuation fund calculate monthly entitlement for member, charge fees; government service approve applications, set consent conditions.

Continue development of the model until the ERD, core value changes, and major events comprise a consistent whole, and that there are no unexplained discrepancies between them (eg major events with no value change, entities that do not participate in value change, value changes without event drivers, etc).

At this point we have sufficient information to ballpark size the systems that will be required to support it, at least for standard commercial profile systems. The entity model is the basis of this sizing as follows:

·        Database: likely to expand by an order of magnitude (10 concept entities give rise to 100 database tables);

·        Functions: assume 5 externally usable functions per database table;

·        Function points: 1-2000 per entity.

Step 2 – Decision Modeling

Purpose: To specify how this organization creates value in sufficient detail for empirical testing, and to then test and prove the value assertions.

Outcomes: Demonstrably correct and perpetually maintainable decision models, schema definitions, and test cases that collectively define (define, not describe!) the business domain irrespective of systems and implementation concerns. The decision models and schemas provide:

a)        a rigorous ‘idiom’ that explicitly defines this business for clear communication between all internal parties, specifically including business executives, IT, and subject matter experts;

b)        a provably correct foundation for all subsequent systems development activity;

c)        a workbench for analysis of the impact of strategy and operational changes against the current state of the business;

d)        and with the aid of a generator, the working set of decision models that drive business value, ready to implement without fingerprints!

Duration: 1-50 hours per decision model – this time is for the relatively prescriptive process of capturing and testing a known decision making process, not for deriving the process itself from original sources, for instance, if it is represented simply by the undocumented ‘skill’ of multiple SMEs.

A decision model is a reasonably large unit of work, and should not be confused with a ‘business rule’. For instance, underwrite and rate a complex business protection insurance product for a significant business; or calculate the claim for a multi-month patient episode on an hour-by-hour basis across multiple funding contracts.

A simple model that can be built and tested in a day will have 10’s of decisions representing hundreds or even thousands of underlying atomic ‘rules’, and will generate thousands of lines of computer code. A complex decision model will be an order of magnitude larger, 100’s of decisions generating 10’s of thousands of lines of code (or more).

It is likely that the analysis of decision making will cause some ‘deep thinking’ by the SME’s and the organization itself, leading to greater understanding of the business value proposition, and often, to changes that can reach right back into the strategy itself. This activity can extend the time frames noted above.

This step focuses on building decision models for the core value propositions from Step 1. This will require development of transaction data models; that is, data models that are context specific for the proposed decision making. These data models will extend the entities in the ERD, and will be fully normalized subsets of any eventual enterprise data model. The most appropriate standard for describing transaction data models is the XML Schema standard (.xsd), which can be described as a data model for a specific context.

Develop the schemas in concert with the decision models. A decision model is a tree structured set of atomic, single valued decisions (each of which embodies many underlying rules) that takes the business entity from one valid state to another, and which creates value for the enterprise in doing so. A decision model is the specification of how the organization creates value.

The decision models both create and consume data – expand the schemas to describe this data as required.

Develop business use cases to test that each decision model fully addresses the business requirement – these test (use) cases can be manufactured for new decisioning and for testing hypothetical business boundary situations, and/or they can be acquired from existing real world systems for regression testing and impact analysis.  Ensure that the test cases are a true and complete reflection of the business problem domain.

Test the decision models against all test cases to ensure completeness, correctness and consistency of the decision models, the schemas, and the test cases collectively. When complete, we have a precise and executable model of the business that is fully aligned with the strategic intent of the business, and which is entirely independent of any technology platform or system.

We have now proven the business value proposition, and the viability of automating it, and we have strengthened the sizing estimates. Together, these results have significantly de-risked any downstream development at a relatively small cost. Furthermore, the models produced are reusable by ALL projects that arise from the analysis, directly reducing subsequent project cost, complexity, and time.

Step 3 – Systems Planning  

Purpose: To identify suitable platforms to support the decision making of the enterprise.

Outcomes: A plan describing one or more systems to be accessed, updated and/or developed to support the decision models built in Step 2.

Duration: Days to weeks.

The concept and decision modeling has provided a proven specification of the data required to support the business’s value proposition, and of the events that will drive it. By implication, process requirements have also been defined as follows:

·        The events need to be responded to;

·        The data needs to be acquired and supplied to the decision models;

·        The decision models need to be executed;

·        The decisions made need to be responded to in a manner that is consistent with regulatory requirements, industry practice, and the internal standards of the organization.

The first step is to find the earliest corporate awareness of an event, and the location of any existing sources of the required data. In particular, consider acquiring the event and data from other party systems – if available and accessible, this can shorten process paths significantly.

If it is not available externally, work inwards from the enterprise perimeter, always seeking the earliest event awareness and lowest cost data sources.

This process should consider the full breadth of available systems and services, both internal and external, and all technologies and technical capabilities available to the organization, as it seeks to implement the lowest impact processes to support the decisioning. This process will inherently optimize processes and data reuse. It should not presume a system build – at this point we are still in business mode, seeking to reuse or purchase the required process capability if we can. Note that the core organizational IP is already captured in the decision models. Optimal processes will assist the business in lowering cost and increasing throughput, but they are unlikely to drive a fundamental change in the value proposition – they are an enabler, not the end goal (the exception relates to monopoly process providers).

When the internal and external environment has been searched for optimal event and data acquisition locations, create a development plan to integrate them into an overall solution that will support the full extent of the decision models, by acquiring, re-using, updating, and/or building system components as may be needed. This plan is a decision centric systems architecture.

If the plan requires one or more solution builds, then the organization’s technology development strategy is also consulted. This is the point at which business architecture meets technology architecture.

Step 4 Solution Development

Purpose: To use, modify, or build systems as per the plan according to current industry practice.

Outcomes: Execution locations and deployment procedures for the decision models.

Duration: 1 day to 6 months per system component (a decision model can be implemented and executing across an existing database in 1 day or less; at the other extreme, if not complete in 6 months, a project is too big and risks failure).  

At this stage traditional approaches come into play. However, the starting point for the systems development life cycle (SDLC) is now significantly advanced from the traditional SDLC starting point:

a)        The business critical data has been defined and is provable relevant. Overlaying the schema definitions describes to a high degree the enterprise data model (certainly they must not be in disagreement). Additional data should be added for relevant regulatory, best practice, and internal information requirements and no more.

b)        The important processes have been prescribed by the underlying decisioning requirements. Additional process requirements should be added as required for regulatory, best practice, and internal information requirements and no more.

c)        The optimal placement and architecture of processes has been assessed independently of any specific development project, to ensure that opportunities for process reengineering have been identified and included.

d)        The technical architecture was not limited or prescribed in any way by the approach, nor was the business modeling limited or prescribed in anyway by the technology architecture; the constraints and opportunities of the technology architecture are introduced to the solution planning at the most effective point in the evolution of the solution.

As the projects kick off, the ERD (Step 1) and Decision Models (Step 2) will provide a consistent and proven foundation for the project SDLC that is common across all of the projects, improving the likelihood of project success individually and collectively by an order of magnitude.

The decision models and attendant schema’s built in Step 2 are detailed and granular. As the projects extend the analysis, assume that they will revisit these models and that there will be changes, possibly substantial changes.  

But we must emphasize – at all times these models live in Step 2 – they are owned by the business analysis function that created them. They are used by projects, not owned by projects. They will exist for as long as the business exists, whereas both projects and systems will come and go.

Step 5 – ‘What-if’ Modeling

Purpose: To evolve the business operational decision making in pursuit of the business strategy.

Outcomes: Confirmed and/or updated strategy and decision models, with feedback to systems and operational development.

Duration: Perpetual.

When the decision models are in place within operational systems, they provide an assurance that operational decision making accurately reflects the business strategy, so that we can use the decision models to experiment with the strategy. For instance:

a)        Change the strategy, and test it against existing and proposed use cases. Accept improvements and reject the rest. Deploy when ready – if new data is required then system changes will need to be made, but these are now tightly prescribed.

b)        Acquire and modify operational data to represent potential changes in operational activity or market conditions. Update the decision making to mitigate negative changes and to accentuate positive ones.

This completes the 5 Step cycle.

The Idiom Decision Manager and related tools and approaches fully support the approach described herein.

Finis

• Comments [0]