Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     ARTICLES ARCHIVES ...
untitled

Decisioning
A New Approach to Systems Development (Part 1)

by Mark Norton

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 paper 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.  For context, we first present background and definitions for decisioning and then outline practical approaches and techniques for decision-centric development.

The new approach recognizes that decision automation is a key motivation for many systems development projects, particularly where 'zero touch processing' is important.  Enormous effort is invested in discovering and elaborating decision-making know-how as part of the development process.  Typically, this know-how has then been 'deconstructed' into an amorphous code base so that the integrity and identity of the decisioning knowledge is lost.

The decision-centric development approach inverts the traditional design approach so that decision-making know-how is acknowledged as a primary design artifact of the system.  Data and process then become supporting players, which in turn drive technology development.  The integrity and identity of decisioning is retained so that it can be directly owned and managed by the business on an ongoing basis.

Building on these decisioning fundamentals we suggest that decisioning is the primary driver of (non-commodity) product development and management.  What decisions a business makes in support of product selection, pricing, approval, and terms and conditions is the key characteristic that differentiates one business from another.  Developing this concept, we present a case for a new product development cycle based on decision-centric product engineering.

Using this approach it is practical to build systems that become containers for products, with the products themselves being built externally and submitted to the container for execution.  Product configuration can be a reality.

Introduction

Our journey towards a new development paradigm -- and why you should not have programmers doing your business rules.

The discovery and normalization of data is a proven and accepted design approach that underpins systems design activity.  Similarly, various approaches to process discovery and decomposition can be used to drive a process centric design approach.

These primary design approaches have evolved over decades, and while each has their adherents, both are mature and give rise to formally structured models.

This article proposes that we add a new primary design artifact to this select group -- the decision.  Like both data and process, decisions can be the subject of original discovery and can drive further design activity.  In fact, decision modeling takes precedence over process modeling as a primary design tool.  Processes only exist to service either data (collect, modify and/or distribute) or decisions; without data or decision-making activity, there is no process requirement.

A further purpose is to discuss methods by which decisions can be discovered and modeled in a structured manner, analogous to data normalization.  Data and decisioning are peers in this decision-centric approach -- each showing a different and complementary view of the same system.  Data models show the valid states of the system at rest; decisioning models describe the valid transitions between the states.  It is the state change as described by the decision models that generates value for any business.

Then we introduce a powerful new business approach that leverages the hidden power of decisioning.  This approach, 'product engineering', builds on the fact that decisioning is the core element of product definition and management -- decisioning is the key differentiator of vendor products.

Note:   In this discussion we will generally use the insurance industry for examples, but virtually any productive enterprise provides a wealth of examples. Decisioning is pervasive across all industries.

What is Decisioning?

Decisions are the critical mechanisms by which we choose one action from the set of all possible actions.  The purpose of a decision is to select the action that is most beneficial to the decision maker in a given situation.  A decision is 'made' when we resolve the available facts to a single definitive outcome; a decision cannot be multi-valued, ambiguous or tentative.  A decision results from applying discipline, knowledge, and experience to the facts within the decision context.   This application of discipline, knowledge, and experience within decision making is the characteristic that most closely defines the unique character of any business.

Definition - Decision:  the result of applying structured business knowledge to relevant facts to definitively determine an optimal course of action for the business.

Recognizing the power of decisions to regulate and control system responses in a zero touch processing environment is driving increasing interest in decision automation.

Businesses do not make decisions merely because they have available data; nor do they act without making a decision.  Decisions are clearly identifiable at the heart of any automated systems response, giving purpose to the data and direction to the process.

When decisioning approaches are used in the early requirements design of systems, they can be used to drive the discovery of data and its relevance to the business -- the need for the decision drives the need for the data.  And because the decision predicates any process response, it also implicitly drives the process definition.

Decisions are also drivers for the discovery of other decisions.  For instance, the decision to accept insurance business depends on precursor decisions regarding the customer, the insured risk, pricing, etc.  Each additional decision can also depend on further decisions until a tree structured model of decisions is formed (the 'decision model').

Our experience suggests that decisions are the easiest of the primary design elements to discover and model, because decisions are the core of business knowledge and are intuitive 'first order' knowledge for domain experts in a way that both data and process are not.  When the decision model is used to fast-track the discovery and modelling of both data and processes, it gives rise to a 'decision oriented' system -- a system that has business decision making as its core architectural consideration.

Definition - Decisioning:  the systematic discovery, definition, and management of decisions for the purpose of decision automation.

We have asserted that decisions are first order citizens of the requirements domain.   To provide a conceptual basis for this, let us go back to the beginning of any requirements analysis.

A business derives value from changing the state of a recognized business object.   This focuses us on the very core of the business -- what is traded, managed, leveraged, used, built, or sold in order to achieve the objectives of the business.   Until something happens to the object, the purpose cannot be achieved and no value can be derived; therefore, in order to generate value, we must have a state change on the object.  Note that we are interested only in the objects that are the basis of value and which are fundamental to the purpose of the business.   We are not interested in data entities per se, including such traditionally important entities as customer (we do not generally derive value from changing the state of customers).

Changing state implies that there is activity against an object, and this observation gives rise to the traditional process (activity) and data (object) approaches.

But if we look closely at any process causing state change, we will see that the change is always the result of a decision within the process rather than the process itself.  Many processes can execute against the object, but value is only derived when a state change occurs.  Whenever state change occurs, the process can be shown to be a container for decisioning -- the state change is a result of the decision rather than an inherent characteristic of process.   Confusion between decision and process clouds the issue and hides the importance of decisioning -- to the extent, for instance, that UML does not include decisioning within the UML standard.[1]

Processes are merely mechanisms by which data is supplied to a decision, and by which the systems respond to the decisions made.  If these pre- and post-decision activities are wrapped together with the decisioning logic, then we have a complete end-to-end process that takes the business from one valid state to another, and which generates value in doing so.  But it is clear that the entire process is built around the decisioning kernel.  We know customers who supply decision content for third party processes -- the commercial supply of decisioning and process by different parties emphasizes the distinct and separate existence of both decision and process.

Our arguments so far suggest that data and process both exist to serve decisioning in the same way that memory and peripherals exist to serve the CPU in a computer -- each has a futile purpose without the decisioning requirement or the analogous CPU respectively.

Traditional Approaches

We have argued that decisioning is the root of the enterprise (its 'CPU') and that decision designs are tangible IP assets.  Decisions should be catalogued and managed like any other important IP asset, visible to and operable by the business as required.  Decisioning knowledge should not be 'deconstructed' into an amorphous code base, as often occurs in traditional development models.

The traditional practice for implementing decisioning logic has been to encode it within the application, using the same programming language as used to implement the technical aspects of the application.  The decisioning becomes intertwined with other aspects of the application, including persistence, user interface and integration logic.  This causes several problems:

  • Verifiability:   Decisions implemented in a standard programming language (e.g. Java, C#, C++) are difficult for non-technical users to understand.   It is therefore difficult to verify that the implementation of the decision matches the requirement.

  • Maintainability:   Implementing the decisioning as part of the core application logic increases the complexity of the application.  This makes it difficult to vary one aspect without affecting others, which in turn makes it difficult to maintain the application.

  • Risk, Cost, and Time:   These factors increase exponentially with overall system size.[2]   By segmenting out the decisioning, we reduce the overall problem into smaller, simpler problems and thereby reduce all three factors.

  • Redundancy and Overlap:   As systems evolve and adapt to new requirements, decisioning rules are duplicated to cater for the new requirements.  This can result in multiple implementations of logic for one business decision.

  • Misplaced Context:   Programmers often disperse decision logic into pre-existing designs -- usually architected around functional or technical requirements -- whereas a decisioning viewpoint would say that the state change of the object is always the relevant context.  These differing viewpoints lead to different architectural designs.

  • Documentation:   As systems evolve, it is normal for external decision documentation to become 'out of date'.  The implementation becomes the repository of the decision logic, and it can be difficult to reliably reverse engineer the decisioning from the implementation.

These problems, caused by implementing decisioning within the application using a standard programming language, are not resolved by modern object-oriented design methods.  Object-orientation is good for managing the complexity of an application by abstracting and encapsulating data, and the functions that operate on that data, inside classes.  However, a decision typically requires the participation of more than one business object, which can mean that the decisions become fragmented into multiple classes.

A similar problem occurs when implementing business rules in relational database management systems (RDBMS).  Typical RDBMS-stored procedure languages are data-oriented, so decisions again tend to be fragmented across the participating data.  Further, the heavy use of triggers to implement decisions can seriously impact the maintainability and comprehensibility of decisioning.

This 'deconstruction' of decisioning into the code base of a traditionally designed system occurs because the decisioning components do not have their own natural 'model' architected into the system.

Decisioning models do not map directly to the data, process or object models that are the models recognized in traditional approaches, so decisioning is 'forced' to fit.  The forced fit is unnatural and causes the fragmentation of decision logic and/or its placement out of context.

The problem originates early in the Systems Development Life Cycle (SDLC); in fact, every step from requirements to implementation adds to the problem.   The separate identity and integrity of decisioning behavior, which is usually well understood by the business sources, is progressively lost as it is translated and diluted at each step in the SDLC:

  • The original requirement is (still) usually captured in English narrative form from a variety of sources.  The narrative form introduces ambiguity, personal phrasing and interpretation, and not uncommonly, outright logical conflict.   The identity of decisions is rarely retained, to the extent that any narrative requirements specification creates its own need for downstream analysis of the narrative.

  • The narrative is then translated into structured design documents (data models, process models, use cases, etc) and expanded to include non-functional specifications.   Decision definitions are usually fragmented throughout these documents as properties of other concepts.

  • The design documents are translated into detailed design and program specifications, further dispersing the decision specifications across the technology layer (security, communications, platform, and distribution).

  • The low-level specifications are translated into program code, and they are expanded to include exception and control processing.

At the end of this process (see Figure 1) the original decisioning requirement is likely to be diffused throughout the code base without traceability to the original requirement.

Figure 1.  Systems Development Life Cycle: "The Old Way"

The business user(s) may think they have described clear and explicit decision specifications.  But when they seek to reuse or redefine them, they are usually dismayed to find that this requires reprocessing through all stages of translation and elaboration as if they were building an entirely new requirement, with the additional burden of accounting for the existing implementation.  This is a root cause of the pervasive disconnect between business and IT -- the gap caused by multiple layers of translation and dilution that loses the identity and integrity of the original decision specification.  Therefore, we suggest a new approach as shown in Figure 2.

Figure 2  Systems Development Lifecycle: "The New Way"

Decision Analysis

Getting Started

The above discussion has suggested that data is peer with decisioning -- so which comes first, the 'data egg' or the 'decisioning chicken'?

Actually, we have already defined the 'egg' -- the business derives value or achieves its purpose by changing the state of primary business objects, whether they be insurance policies, loan accounts, patients, trains, or any other object of value.  These primary business objects are the 'eggs' for both data and decisioning; we must start by discovering these primary objects from original sources.  They are usually self-evident, and a cursory review of strategy documentation will highlight and clarify any ambiguities.  But if the primary objects cannot be defined quickly (minutes, not days) and with certainty, the business should not be building a system -- it has much bigger issues to worry about!

The primary business object is by definition both tangible and discrete; therefore, it can be uniquely identified.  Also by definition, it will be a source of value for the business and so the business will assign a unique identifier to it -- its first data attribute.  In fact, a simple litmus test for these objects is to look for proprietary and unique identifiers assigned by the business (even in manual systems).

Because it exists and generates value, external parties may also be involved and cause us to add specific additional attributes for interface or compliance purposes (e.g., an IRS number), and we might also add other identifying attributes to ensure that the primary object can be uniquely found using 'real world' data.  So there is a small set of data that can be found and modeled simply because the primary object exists; this set of data is generic and will be more or less common across all like businesses.  Therefore, it cannot be a source of business differentiation.

So what other data is there that will allow us to differentiate our business?   The amount of data that we could collect on any given topic is huge -- how do we determine what additional data is relevant?

Decisioning!  How we make decisions is the key differentiator of any business -- how we decide to accept customers, approve sales, price sales, agree terms and conditions, etc.  The important additional data will now be found because it is needed for decision making.

We are now ready to do decision analysis; that is, after the initial data scoping, and prior to either detailed data or process analysis.

Decision Discovery

Decision analysis is both simple and intuitive because this is the primary activity of the business -- this is what the business knows best.

A decision is a single atomic value -- we cannot have half a decision any more than we can have half an attribute.  So we are looking for explicit single-valued outcomes, each of which will be captured as a new data attribute.

Let's start with our business object (say, 'insurance policy'), and with a state change that will cause a change in the value of that object (say, 'approve insurance policy').  Now we need to access the domain expert within the business.   The domain expert is the one who can readily answer the question:  What decisions do you make in order to ... approve this insurance policy?

There is a pattern to most commercial decision making that helps structure the decision discovery process.

Figure 3.  The Decision Sequence

The green circles are the most important in the cycle.  We can start analysis with the first of the primary (green) decisions ('Authorization or Acceptance' in the above Figure 3) -- these are the 'will I or won't I' decisions.  For our insurance policy, 'will I or won't I' accept this risk? (simply replace the business object and state for other domains as required; e.g., for a hospital, 'will I or won't I admit this patient?', etc.).  Determining this decision may identify many precursor decisions that need to be considered first.  For instance, for our underwriting question we might need to ask:

  • What is the inherent risk of the object?

  • What is the customer risk?

  • What is the geographic risk?

These decisions in turn may give rise to further decisions so that we develop a tree of decisions -- this is the decision model for authorization.

Now we can move on to the next in the primary class of decisions:  At what price? (or cost if a cost centre) -- see 'Pricing or Costing' (Figure 3).  In this case, the question is 'what decisions do you make to determine the price . . . of this risk?  ' Again, this may result in a tree of decisions (for instance, pricing based on various optional covers, pricing for the different elements of risk, channel pricing, campaigns and packages, etc.).

Following "At what price?" we can repeat the process for the 'Terms and Conditions' and then the other pre- and post-decisions:

  • Pre-Processing Check:  Do I have sufficient information to start decision making?

  • Context Based Validation:  Is the supplied data valid?

  • Enrichment:  What further data can I derive to assist with the primary decision making?

  • Product or Process Selection:  Do I need to determine one decision path from other possible paths for the primary decision making?

And after the primary decision making ...

  • Workflow:  Now that I have made my primary decisions, what do I need to do next?

  • Post-Processing:  Am I finished and complete without errors?  Are my decisions within acceptable boundaries?

Normalization

Data normalization is a semi-rigorous method for modeling the relationships between atomic data elements.  It is 'semi-rigorous' because normalization is a rigorous process that is dependent on several very non-rigorous inputs, including:

  • Scope:  determines what is relevant -- we don't normalize what is not in scope.

  • Context:  determines how we view (and therefore how we define) each datum.

  • Definition of each datum:  this is highly subjective yet drives the normalization process.

Data normalization is based on making a number of subjective assertions about the meaning and relevance of data, and then using the normal forms to organize those assertions into a single coherent model.

Normalization with regards to decisions is similar.  Each decision derives exactly one datum, and is 'atomic' in the same way that data is.

Similarly, each decision has relationships to the other decisions in the model.  The decisions are related by both sequence and context.  In this regard, context plays a similar role to the 'primary key' in data normalization.  Some of the inter-decision relationships include:

  • All decisions have a data context that is derived from the normalized placement of its output datum.

  • Each decision definition may precede and/or follow exactly one other decision definition.

  • Each decision belongs to the group of decisions that share the same context.

  • In a direct parallel of 4th normal form, unlike decisions that share context should be separately grouped.

  • A group of decisions itself has sequence and may also be grouped with other decisions and groups according to shared context.

Further Analysis

We have now defined the core analysis approach.  This section now looks at some guidelines for extending the analysis.  The 'who, what, why, where, when, how' framework is one possible framework that can help.  We have already discussed two of the elements:

  • What:  The object that has state.

  • How:  The decision process that determines the change of state.

Now try to address the rest of the framework.  Question whether decisions need to adapt to any of the following:

  • When:  The nature of the events that stimulate state change -- "Will I admit this patient differently in an emergency vs non-emergency?"

  • Where:  Are there any jurisdictional or local elements to the state change -- "Will I accept this business if it is in a war zone?"

  • Who:  Who is making the state change -- "Is a broker transaction handled differently to an internal transaction?"

  • Why:  Why is this state change important to the business -- especially, how is it valued?

All elements of the above should be considered and factored into the overall decision model to produce a robust and complete decision design.

Decision Driven Data Design

Figure 4.  Decision-centric Development

We have suggested that decision and data models are peer design artifacts.  Following the initial discovery and elaboration of the primary business objects, we worked through the decision discovery process, which in turn identified new data attributes (the decision outputs).  If we locate the decisions around the data constructs, we can build an integrated decision/data model (represented by the two triangles in Figure 4).  This combined model is self-validating and improves the overall rigor of the analysis.

Following the discovery of the decisions, we can then elaborate them with formulas.  Formulas provide additional detail regarding the consumption of data by decisions, thereby driving further demand for data.  If the system cannot provide this data, then by definition the business cannot make the decision and the process cannot continue.

In this way, decisioning can be shown to define the scope and context of the data, which then compounds with the decision usage to arrive at the data definition, which in turn drives the normalization and modeling processes for both.

Note that the data models used in decision modeling are subsets of the domain data model -- they need to contain only the data required by the decisioning that is currently in focus.  They are, in effect, normalized models of data transactions rather than a model of the entire business.  The XML schema standard is a useful standard for describing normalized transactional data.

These transactional views can be easily overlaid onto the business object model to synthesize a more complete domain model.  This model will only contain the data actually required by the business -- there is no second guessing of the data requirements as often occurs in a traditional approach, with significant cost implications.

Decision Driven Process Design

Decisioning also drives process.  For the decision to execute, the decision must be supplied with its precursor data by a process.  This data, and therefore the process, cannot be defined until the decision requirements are known.  Then, for the decision to have any effect, a process must implement some response.  While it is possible to define and build processes in anticipation of the decisioning that will drive them, it is sensible to analyze the decisioning in order to determine the range of inputs and outcomes, and then to normalize the process responses to them.

Handover and the SDLC

We can achieve a verified and tested decision model, and its integrated and co-dependent data design, with relatively modest effort.  No system design or coding is required to this point.  Most architectural and design options remain open -- at this stage even platform is irrelevant.  We have, in fact, defined and constructed the core functionality of the system from the business's perspective without constraining the technology options.  Even better, we can retain the identity of this core functionality over the long term, even across multiple implementations -- there need never be another legacy system.

Implementation is now of little interest to those business users who are responsible for decisioning -- we have a clear and well-defined handover point.  It is feasible, even desirable, to simply hand over the decision model and data schemas to systems designers as their starting point.  This highlights a critical point:  Decision analysis belongs in the inception phase of traditional SDLC's, or precedes it entirely.  By definition the subsequent system design must be able to supply and receive data that complies with the decisioning schemas.  And the system must provide appropriate process responses to the decisions made.  While these processes remain undefined, this is secondary analysis and is tightly bounded by the decisioning design that precedes it; therefore, it is of comparatively low risk.

The traditional systems development cycle is then used to design, build, and/or reuse as appropriate to support the decisioning requirements.  It is the developer's task to provide an infrastructure within which the decisioning can occur.

Resources

The Tools

With the correct tools, the above decision discovery process can be fast and efficient.

How do we choose the correct tool?

First, do not choose one that relies on narrative or colloquial language to describe the requirement!

The problem here is not the tool but the use of language.  A dearth of structured rule writing standards means that decision definition is almost always reduced to a series of personal idioms -- local phrases that have only very local, even personal, meaning.  Every practitioner finds their own decision writing style, and even that changes over time, often within a single document.

English is highly nuanced; ambiguity and imprecision are typical and endemic.  When compounded with personal writing styles, our experience is that the majority of decision declarations are imprecise, no matter how careful the author.

Therefore a consequence of capturing decisions in narrative is to create a new class of analysis problem for the downstream developer -- analyzing the narrative version of the decision model.  And because it is a personal abstraction, there will be misinterpretations (if you are lucky you might find some of these in testing, but only after significant downstream cost).  And there is a further subtle trap here.  The business analyst who produces the narrative usually considers their ('more important') job to be done; it is now over to the developer to get it right.  Similarly, the developer resents that they have to re-analyze the narrative, and that this is impacting on their (also 'more important') job.  The perception gap can be debilitating!

So what sort of tool do we want?

  • It must be definitive.  Every fact, every operator, must be clear and explicit so that the elements of the decision model are guaranteed to be unambiguous.

  • It must be structured.  The construction of elements into a semantic model must be managed to ensure that only one possible interpretation (and therefore execution) path is possible given any specific problem instance.

  • It must be easy to use.  It should be faster than writing the equivalent narrative -- using graphical modeling if possible.

  • It must produce business accessible output for verification.  The decision analyst should be able to close the loop with domain experts by hands-on guided walkthrough and confirmation of the decision constructs before expensive downstream work is undertaken.

  • It must be testable.  The decision models should demonstrate correct results before expensive downstream work is undertaken.  Only after this point can we be sure that the decision requirements are known and complete, removing much of the risk and cost of the following traditional SDLC approaches.

  • It must require no 'fingerprints' to achieve executable code.  We do not want verified and tested decision models to be hand-cranked into code, which would undo all verification and testing by definition.

The People

Who should perform decision analysis?  Anyone who has:

  • Lateral thinking and analysis skills -- to understand the decision constructs within verbatim, unstructured decision knowledge from domain experts.

  • Structured, focused thinking -- to transform verbatim, unstructured decision knowledge from domain experts into normalized and structured decision and data models.

But of course it is not that simple!  Most people come with some history that will affect their analysis behavior.  Here are some possible 'gotchas' for the more traditional roles:

Software Developers who:

  • Apportion decisions across their existing technical design, thereby destroying the integrity of the 'decision model' as understood by the business.

  • Mentally transform logic into code, and then redundantly (in their mind) record the presumed coded form as the decision; this is often preceded by actually turning it into code ("It was easier to write it as code" followed by "It was only 35 lines of C++").

  • Think in terms of systems.  Systems deal with an order of magnitude more complexity than do decision models.  It is the simplicity and purity of the decision model that the business seeks, and which we lose when we analyze decisions in terms of the rest of the system.

  • See the system as the objective.  We want the decisioning to drive the system design and operation, not the other way around.  The system exists to implement decisioning -- it has no other purpose!

  • Resent the idea of generated code ('I could do it better!'), thereby missing the point that it is not the quality of the code but the intervention of the developer that is the problem.

Business Analysts who:

  • Have developed personal styles of output that involve narrative storytelling and considerable attention to context at the expense of verifiable detail -- the 'artist' who produces large, well-considered narrative style documents that must themselves be subject to analysis.

  • Disagree that analysis outputs should be verifiable and testable.  Traditional requirements definitions are not easily testable -- and narrative especially cannot be tested.  If it's not tested, how do we know it is complete, or even consistent!

  • Are wedded to traditional approaches.  Decisions are not the traditional focus of business analysis, which usually sees them as properties of data or process, and a significant paradigm change is required to invert this traditional relationship.

  • Are wedded to traditional approaches.  Decisions are not the traditional focus of business analysis, which usually sees them as properties of data or process, and a significant paradigm change is required to invert this traditional relationship.

  • Resent being 'technical' as implied by the need to define, normalize and test.  But the analysis output must be normalized; both decisions and data must be defined once, and only once, into an exact and correct context. Without this purity, the requirements cannot be shown to be complete or consistent.

There are some additional characteristics that are helpful to the Decision Designer.

  • Domain knowledge and general business knowledge.  The more the better.

  • Normalization skills.  It is essential to understand normalization and how to apply it to both data and decision modeling.

  • Ability to move easily from broad concept to minute detail (core object to logical operation).

  • Perseverance with detail.  They should test their own decision models in detail -- this aids understanding and avoids handover costs.  The decision modeler tests because it helps them to understand both the problem and their solution!

  • Communication skills.  The decision analyst is the key interface between the domain expert and the system.  They are primarily a business representative dressed in analysts clothing.

  • Logic.  They need to be logical but it is better if they do NOT know how to code in traditional development languages!  We only want the logic -- not all the rest of the dressing that comes with these languages.

CONCLUSION

In this Part One, we have defined decisioning and put forward the idea that it is a practical and valuable new design approach for IT.  We will build on this concept in Part Two,[3] where we outline that decisioning has a direct and strategic importance to the business itself.

We will illustrate 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), and we can give these objects a more common name:  products.

Part Two provides more detail on this concept and how decisioning is, in fact, the primary differentiator of like (non-commodity) products.

Notes and References

[1] The Object Management Group (OMG) is a non-profit computer industry specifications consortium.  Its members define and maintain the Unified Modeling Language (UML).  The UML is the OMG's most-used specification, applying to application structure, behavior, and architecture, as well as business process and data structure.  OMG's UML v1.5, Section 3.22.3 appears to exclude the entire class of business rules from the methodology:  "Additional compartments may be supplied as a tool extension to show other pre-defined or user defined model properties (for example to show business rules ...) ... but UML does not define them..."  return to article

[2] Capers Jones. Applied Software Measurement:  Assuring Productivity and Quality.  McGraw-Hill (1996).  return to article

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


standard citation for this article:
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  

February 2017
Unexpected Benefits of Harvesting Rules from Production Code
By Brian Childs


December 2016
Turning the Virtuous Circles
By Roger Tregear


June 2016
Pattern Questions for Harvesting Business Rules from Business Models of Milestones or States
By Ronald G. Ross with Gladys S.W. Lam


May 2016
Pattern Questions for Harvesting Business Rules from Concept Models
By Ronald G. Ross with Gladys S.W. Lam


April 2016
Pattern Questions for Harvesting Business Rules from Business Process Models
By Ronald G. Ross with Gladys S.W. Lam


February 2016
Business Architecture, Business Requirements, and System Design Building Business Capabilities
By Ronald G. Ross


December 2015
Business Capability Modelling and Strategic Investment Planning
An Approach to Improving Capability Maturity

By Geoff King, with James Woods, Simone Clark, Ngan Ha


November 2015
The Perfect Rule Management Tool (Part 2)
By Kristen Seer


October 2015
The Perfect Rule Management Tool (Part 1)
By Kristen Seer


September 2015
Using Natural Language and SBVR to Author Unambiguous Business Governance Documents
By Donald Chapin & John Hall


July 2015
Putting Process at the Centre of Business Management (Part 2)
By Roger Tregear


July 2015
Putting Process at the Centre of Business Management (Part 2)
By Roger Tregear


June 2015
Putting Process at the Centre of Business Management (Part 1)
By Roger Tregear


May 2015
Testing Rule-Based Systems — Protect Customer Focus
By Peter K.J. Kalmijn


April 2015
BPMN, Business Rules, and the Free Will — A New Way to Look at Models
By Markus Schacher


March 2015
The Role of SQL in Decision-Centric Processes - Part 2: The Solution
By Mark Norton


February 2015
The Role of SQL in Decision-Centric Processes - Part 1: The Problem
By Mark Norton


January 2015
The Perfect Deliverable
By Kristen Seer


December 2014
Special Evaluation Specifications for Decision Rules: How to Support Very Smart, Very Friendly Business Decision Systems
By Ronald G. Ross


November 2014
OMG's Mind Your Business Event Highlights SBVR at Work
By John Hall


October 2014
Common Mistakes in Developing Solutions Using Business Rules
By Rob van Haarst


August 2014
Changes in SBVR's Meaning and Representation Vocabulary
By Rob van Haarst


July 2014
Decision Tables and Integrity: Introducing Restrictions
By Ronald G. Ross


May 2014
Designing Decision Tables - Part 2: Fundamental Styles/em>
By Ronald G. Ross


February 2014
Putting Decisions First
Why Building Decision Models Delivers Business Rules Success

By James Taylor


February 2014
Business Rules — Seriously?
By Dan Tasker


January 2014
The Perfect Methodology (Part 2)
By Kristen Seer


December 2013
The Perfect Methodology (Part 1)
By Kristen Seer


November 2013
Decision Tables Saved Our Project from Failure!
By Gwen Bradshaw


November 2013
The Business Motivation Model: Doing the Right Things
By John Hall


October 2013
Decisioning — the Next Generation of Business Rules
By Mark Norton


July 2013
Insights from the Adoption of Fact Modeling
By Chris Maple


July 2013
The Making of the Persian Business Rules Manifesto
By Peter Kalmijn


June 2013
The Business Motivation Model: An Introduction
By John Hall


May 2013
Concept Mapping and Concept Modeling
Sensemaking at the Business Level

By Thomas Frisendal


April 2013
Tabulation of Lists in RuleSpeak® — Using "The Following" Clause
By Ronald G. Ross


March 2013
Business Rules and Process Approaches in Business Analysis — Friends, Not Foes
By Casper Yeow


February 2013
Estimating the Time Required for Business Rules Harvesting — Part 2: Provide the Estimate

February 2013
Eight Steps to Crafting a Business Rule
Step 8: Make Sure the Business Rules All Fit Together

By Kristen Seer


January 2013
Estimating the Time Required for Business Rules Harvesting — Part 1: Ask These 13 Questions
By Gladys S.W. Lam


January 2013
Eight Steps to Crafting a Business Rule
Step 7: Add the Condition(s) ("If ...")

By Kristen Seer


December 2012
Overview of Common Process Analysis Techniques
By Kathy A. Long


December 2012
Eight Steps to Crafting a Business Rule — Step 6: Say Something about the Subject (Subject + Verb + Object)
By Kristen Seer


November 2012
Strategy for Business Solutions: Part 3: Adjusting and Fine-Tuning a Strategy
By Ronald G. Ross with Gladys S.W. Lam


November 2012
Eight Steps to Crafting a Business Rule — Step 5: Choose the Form of the Business Rule Keyword ('must' or 'only')
By Kristen Seer


October 2012
Strategy for Business Solutions: Part 2 — Business Mission and Business Goals
By Ronald G. Ross with Gladys S.W. Lam


October 2012
Eight Steps to Crafting a Business Rule — Step 4: Start with the Subject
By Kristen Seer


September 2012
Strategy for Business Solutions: Part 1 — The Policy Charter
By Ronald G. Ross with Gladys S.W. Lam


September 2012
Eight Steps to Crafting a Business Rule — Step 3: Determine Whether the Business Rule Computes or Derives Something
By Kristen Seer


August 2012
Eight Steps to Crafting a Business Rule — Step 2: Determine Whether the Business Rule Already Exists
By Kristen Seer


July 2012
Eight Steps to Crafting a Business Rule (Part 1)
By Kristen Seer


April 2012
Rule Governance for Enterprise-wide Adoption of Business Rules; Why Does a BRMS Implementation Need a Governance Framework?
By Chaitan Sharma


April 2012
Policy Management by Design: How to Create an Effective Policy Strategy that Covers all the Bases
By Heike Lorenz & Davin Fifield


April 2012
Putting Business Rules in the Hands of the Business
By Rik Gerrits


January 2012
Business Rules vs. Business Requirements
By Ivan Walsh


December 2011
Recruiting and Organizing Business Rules Talent
By Jerre McQuinn with Mike Lockhart


September 2011
Is Subject Focus Important for Business Rule Authors?
By Rob van Haarst


August 2011
All Rules are Not Created Equal: Using Metaphors to Govern Your Rules
By Neal McWhorter


February 2011
The Chief Capabilities Officer
By Suzandeise Thomé


July 2010
Business Rules Extraction from Business Process Specifications Written in Natural Language
By Herbert Gómez Tobón and Áldrin Fredy Jaramillo Franco


May 2010
A Discussion on Placeholders
By William Dinner


March 2010
How to Get Smarter with Decision Management
By James Taylor


January 2010
Smarter Systems: Action-oriented, Flexible, Predictive, Learning
By James Taylor


November 2009
RulesWorld
By James Taylor


September 2009
Decision Management Contrasted
By James Taylor


August 2009
A Realistic View of Business Rules Engines
By James Taylor


July 2009
Devil's Advocate View of Business Rule Engines
By Manny Gandarillas

June 2009
Six Sigma and Decision Management — An Example
By James Taylor


May 2009
Six Sigma and Decision Management — Introduction
By James Taylor


April 2009
From Spreadsheets and Computer Code to Business Rules: A Business Rules Approach to Decision Point Analytics
By Tom Debevoise

March 2009
Differentiating Standard Processes with Decision Management
By James Taylor


February 2009
Predictive Analytics in a Business Rules Context
By James Taylor


January 2009
2008 Business Rules Forum / Enterprise Decision Management Summit: Events and Trends
By James Taylor


December 2008
Next Best Action

November 2008
Adaptive Control, Champion/Challenger, and Decision Management
By James Taylor


October 2008
Moving to Predictive Analytics in Decision Management
By James Taylor


September 2008
Data Mining and the Use of Data to find and improve Rules

September 2008
Natural Language, Semiotics, SBVR, ORM, and CQL
By Clifford Heath

August 2008
Decisions, decisions, decisions
By James Taylor


July 2008
Rules, analytics, decisions!
By James Taylor


May 2008
The Need for Smart Enough Systems (Part 10): Costs of Enterprise Decision Management
By James Taylor & Neil Raden May 2008
Context is King: A Practical Approach to Rule Mining
By Mannes Neuer

May 2008
The Need for Smart Enough Systems (Part 10): Costs of Enterprise Decision Management
By James Taylor & Neil Raden

April 2008
The Need for Smart Enough Systems (Part 9): Contributing Value to your ROI Calculation: Strategic Control
By James Taylor & Neil Raden

February 2008
The Need for Smart Enough Systems (Part 8) ~ Contributing Value to your ROI Calculation: Revenue Growth
By James Taylor & Neil Raden

January 2008
The Need for Smart Enough Systems (Part 7) ~ Contributing Value to your ROI Calculation: Cost Reductions
By James Taylor & Neil Raden

December 2007
Business Rules in User Interfaces
By Kamlesh Pandey

December 2007
The Need for Smart Enough Systems (Part 6): The ROI for Enterprise Decision Management
By James Taylor & Neil Raden

November 2007
An Investment in BRMS Delivers Rapid ROI
By Thomas Cotic

November 2007
The Need for Smart Enough Systems (Part 5): Finding Hidden Decisions
By James Taylor & Neil Raden

October 2007
Business Rules Discovery from Existing Applications
Dr. Vitaly Khusidman

October 2007
The Need for Smart Enough Systems (Part 4)
By James Taylor & Neil Raden

September 2007
Business vs. System Thinking in Rule Writing
By Kristen Seer

September 2007
The Need for Smart Enough Systems (Part 3): Enterprise Decision Management
By James Taylor & Neil Raden

August 2007
Business Rules Bridge the Gap (Gap Analysis, that is)
By Michael Oara

August 2007
The Need for Smart Enough Systems (Part 2)
By James Taylor & Neil Raden

July 2007
The Need for Smart Enough Systems (Part 1)
By James Taylor & Neil Raden

June 2007
Constructing a Business Rules Process Is Like Building a Delicious Sandwich
By Kimberlea Thompson

March 2007
Improving Decision Table Rules with Data Mining
By Ian Graham

January 2007
Decisioning ~ A New Approach to Systems Development (Part 1)
By Mark Norton

December 2006
The Perfect Domain
By William Dinner

October 2006
Motivation at Zachman Row 1
By Allan B. Kolber

September 2006
JSR-94 and the Case for Business Rule Standards
By Hans Witt

February 2006
Changing the Rules of Testing ~ Testing Strategies for the Production Maintenance of Rapidly Evolving Business Rules Systems
By Pierre Berlandier


January 2006
The Role of Rule Analyst (part 2)
By Kristen Seer


December 2005
Business Rules in Requirements Analysis
By Ralph Nijpels


November 2005
The Role of Rule Analyst (part 1)
By Kristen Seer


October 2005
Term-Fact Modeling, the Key to Successful Rule-Based Systems
By Oscar Chappel


August 2005
The 2005 Business Rules Awareness Survey
Presented by Kristen Seer


July 2005
Keeping Business Rules Separate from Their Enforcement
By Oscar Chappel


May 2005
The 'Other' Rules ~ Internal Control and the Influence of COSO
By Steven Chater


March 2005
Business Rule Reuse in the Real World
By David Christiansen


February 2005

Enterprise Transformation ~ Lessons from Julius Caesar

By Daniel S. Appleton

 

September 2004

Business Rules, Can They Be Re-Used?

By Rik Gerrits

 

April 2004

Why Enterprise Architecture Is An Oxymoron

By Dan Appleton

 

January 2004

ASL -- A Formal Language For Specifying A Complete Logical System Model (Zachman Row 3) Including Business Rules

By David Bevington

 

December 2003

Verification Of Business Rules Utilization

By Rick Gerrits

 

October 2003

Business Rules, Platforms, and Inferencing

By Kirk Wilson

 

September 2003

The Business Rules Market Resurrection Continues

By Jim Sinur

 

August 2003

The Rule Transformation Approach To Business Renovation

By Andrej Kovacic

 

July 2003

In His Own Words; A Tribute to E.F. Codd

By E.F. Codd

 

June 2003

Working on a Project as a Business Analyst

By Kristen Seer

 

March 2003

Cognodigms

By Dan Appleton

 

February 2003

Using Verification and Validation Techniques for High-quality Business Rules

By Dr. Silvie Spreeuwenberg

 

January 2003

Eliciting Business Rules in Workshops (part 2)

By Ellen Gottesdiener

 

December 2002

Blueprint of an Enterprise Nervous System

By Kamlesh Pandey

 

November 2002

Eliciting Business Rules in Workshops (part 1)

By Ellen Gottesdiener

 

October 2002

Business Rules In Prolog

By Markus Schacher

 

September 2002

How to Develop Effective Business Analysts (Part 3)

By Kristen Seer

 

August 2002

Profit From Events And Patterns (Part 1)

By Alex Buckley

 

July 2002

How to Develop Effective Business Analysts (Part 2)

By Kristen Seer

 

June 2002

Extended Business Object Model

By Kamlesh Pandey

 

May 2002

How to Develop Effective Business Analysts (Part 1)

By Kristen Seer

 

March 2002

The Black Box Problem

By Malcolm Chisholm

 

January 2002

Business Rules Are Meta Data

By Alan Perkins

 

December 2001

Constraints & Predicates: A Brief Tutorial (Part 3)

By C.J. Date

 

November 2001

The Role Of Reference Data In Business Rules

By Malcolm Chisholm

 

October 2001

Powered By Rules

By Barbara von Halle

 

September 2001

Constraints & Predicates: A Brief Tutorial (Part 2)

By C.J. Date

 

August 2001

Business Rules are the Key to CRM and One-to-One Personalization

By Rolando Hernandez

 

July 2001

Constraints & Predicates: A Brief Tutorial (Part 1)

By C.J. Date

 

May 2001

Business Process Modeling As A Starting Point For Information Systems Design (Part 3)

By Jan L.G. Dietz & Paul J.M. Mallens

 

April 2001

Templates For Capturing Business Rules

By Judi Reeder

 

March 2001

Business Process Modeling As A Starting Point For Information Systems Design (Part 2)

By Jan L.G. Dietz & Paul J.M. Mallens

 

January 2001

Business Process Modeling As A Starting Point For Information Systems Design (Part 1)

By Jan L.G. Dietz & Paul J.M. Mallens

 

December 2000

Business Rules Rule Requirements

By Ellen Gottesdiener

 

October 2000

Modeling Business Rules Using the UML and CASE

By Neville Haggerty

 

September 2000

Knowledge Management - The Last Hurrah

By Warren L. Selkow

 

August 2000

Ten Ways To Improve Data Resource Quality

By Michael H. Brackett

 

May 2000

Project Scope Document: A "How To" (Part 2)

By Dave Wendelken and Betty Hilbrant Baker

 

May 2000

Thin Processes

By Neal Fishman


April 2000

Project Scope Document: A "How To" (Part 1)

By Dave Wendelken and Betty Hilbrant Baker

 

March 2000

Y2K Post Mortem

By William G. Smith

 

February 2000

Business Rule Basics from Kindergarten Tee-Ball

By Barbara von Halle

 

January 2000

Business Rule Practices In The New Millennium

By Barbara von Halle


January/February 2000

Business Systems And Information Support Systems 

By John Hall


 

September 1999

Implementing Business Rules With Inferencing (Part 2): Implementing Inferencing in Business Rule Engines

By Kirk D. Wilson, Ph.D

 

July 1999

Implementing Business Rules With Inferencing (Part 1): The Importance Of Inferencing

By Kirk D. Wilson, Ph.D 

 

May 1998

Business Knowledge ~ Packaged in a Policy Charter Policy Charter as a Deliverable

By Gladys S.W. Lam

 

 

 about . . .

 MARK NORTON

photo

Mark has 35 years history in software development, primarily with enterprise scale systems. During the 1980s Mark was actively involved in the development and use of data- and model-driven development approaches that later achieved widespread use. Application of these approaches to the development of an Insurance system for one of the world's largest insurers was formally reviewed in 1993 by the University of Auckland who concluded that "this level of productivity changes the economics of application development."

In 2001 Mark led a small group of private investors to establish Idiom Ltd. He has since guided the development program for the Idiom decisioning products toward even more remarkable changes in "the economics of application development." He has had the opportunity to apply Idiom's "decision oriented" tools and approach to projects in Europe, Asia, North America, and Australasia for the benefit of customers in such diverse domains as superannuation, insurance, health, government, telecoms, and logistics.

Mark can be contacted at mark.norton@idiomsoftware.com or +64 21 434669.

 

 

[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ]