Reconfiguration Agility

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal , and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross

One of the sidebars[1] to the Business Agility Manifesto[2] introduces the notion of Reconfiguration Agility.  It's a fundamental capability your organization needs in the Knowledge Age.  What's it about?

Procedural vs. Declarative

In the big scheme of things, you have two basic choices for conceiving, and ultimately implementing, business capabilities:  procedural or declarative.  They are fundamentally different.

Traditionally, the vast majority of business systems have been modeled and constructed on a largely procedural basis — virtually all things tied together step-by-step in processes.  Unfortunately, that procedural approach simply doesn't scale.

What do the terms procedural and declarative mean?  Here is how Merriam-Webster Unabridged defines procedural.

procedure:  1a: a particular way of doing or of going about the accomplishment of something 1b (1): a particular course of action (2): a particular step adopted for doing or accomplishing something (3): a series of steps followed in a regular orderly definite way

You can spot the seeds of the scalability problem right away in the definition with repeated use of the word "particular" and with the phrase "regular orderly definite way."  How much business activity naturally occurs today in a particular and regular orderly definite way?  The answer, of course, is less and less with each passing day.

The essential characteristic of procedures is that they flow.  The flow comprises the steps by which a thing is intended to become a different thing (or the same thing in a different state).  The essence of 'procedure' is therefore that something will be hopefully transformed.  For sure, that's a very basic, very important, very necessary part of any business capability.  The problem arises from depending on procedures beyond that point.

Something declarative, in contrast, doesn't flow.  It just states something that must (or should) be true.

declarative:  2: having the characteristics of or making a declaration : ASSERTIVE; specifically : constituting a statement that can be either true or false

True business rules[3] are that way; they simply give guidance.  They don't do anything.  They don't flow anywhere.  They can't be anything other than true or false, obeyed or violated.[4]  In short, true business rules are declarative and therefore fundamentally different than procedures.

Problems with Pure-Procedural Solutions for Business Rules

Traditional processes embed detection, evaluation, and enforcement of business rules in step-by-step procedures (process models, process flows, and procedural code).  What happens when things that are naturally declarative are treated procedurally?  You get bloat.  You lose business intent.  You produce needless complexity.  As you scale, the problems grow exponentially.

How many business rules are we talking about?  Any given business capability easily has hundreds, sometimes thousands, of business rules.

At the scale and pace of today's business, step-by-step embedding of support for business rules simply isn't manageable.  It results in un-agile infrastructures and lost business knowledge — solutions set in concrete.  It's unnecessary and very counterproductive.

More Problems with Pure-Procedural Solutions

Procedures and business rules are just two of the elements of business capabilities.  Other elements include:

  • operational business decisions
  • structured business vocabularies (concept models)
  • business goals and risks
  • business events
  • business locations
  • business roles and authorizations
  • timing

In pure-procedural solutions, all these elements become entangled in flow (procedure).  The result is configuration stagnation.

Reconfiguration Agility

The key questions for building more agile business capabilities lies with how the following questions are answered:

  • How elements are specified.  You need granular, semantically-rich specification.  All elements (except procedures, of course) should be specified declaratively.

  • How elements are configured — and quickly reconfigured — for operation at any given point in time.  True business rules, being declarative, exactly fit the bill.

From an engineering perspective, the secret to agile configuration is 'late binding' — that is, bringing all elements together for execution (i.e., performance of procedures) as late as possible.  That way, all elements can be as up-to-date and as agile in their own right as possible.

This kind of engineering results in what the Manifesto calls Reconfiguration Agility.  It should be the new mantra of business agility.  In a world of constant and accelerating change, is there really any alternative?!

References

[1]  Sidebar for the Software Industry:  Reconfiguration Agility https://busagilitymanifesto.org/accompaniments/supplements/sidebar-for-the-software-industry  return to article

[2]  The Business Agility Manifesto:  Building for Change, by Roger T. Burlton,  Ronald G. Ross, and John A. Zachman, (2017) https://busagilitymanifesto.org/ return to article

[3]  I say true business rules because rules supported by many current rule engines and decision management platforms (not all) are actually not reliably declarative. return to article

[4]  Business rules that can be violated are behavioral business rules, a central notion of the OMG standard Semantics of Business Vocabulary and Business Rules (SBVR).  For more information on SBVR, see SBVR Insider on BRCommunity.com, http://www.brcommunity.com/standards.php?id=620 return to article

# # #

Standard citation for this article:


citations icon
Ronald G. Ross , "Reconfiguration Agility" Business Rules Journal Vol. 19, No. 8, (Aug. 2018)
URL: http://www.brcommunity.com/a2018/b963.html

About our Contributor:


Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal , and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the IPSpeak methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:


Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997., now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.