Stability and Transience In Information Requirements

Blogger: Joe Maguire

Some information requirements are stable—incontrovertible, permanent aspects of reality—whereas others are transient—subject to changes that naturally arise in a dynamic business environment.

The task of distinguishing between stable and transient requirements has been left to requirements analysts working on the front lines—with no guidance from thought leaders, notation designers, or tool vendors, who have really dropped the ball here.  Working requirements analysts are given not-very-useful advice like this:

• Model the entities before the attributes
• Investigate column-level constraints before row-level constraints
• Investigate row-level constraints before cross-table constraints

...instead of useful advice like this:

• Model things with mass before things without mass.
• Model things and places before things-in-places.
• When two users disagree about a requirement, the requirement is more likely to be a policy-motivated requirement than a data-motivated requirement.
• When modeling a taxonomy, expect users to start at the middle levels of the taxonomy, rather than at the top or bottom. 

Side note:  Linguists and anthropologists have observed that regardless of culture, the basic levels of a taxonomy are neither the most general nor the most specific; they are somewhere in the middle.

The not-very-useful advice institutionalizes syntax-based priorities.  This is only marginally useful because syntax correlates poorly with human priorities.  The folks who love syntax are the IT folks, because syntax is a fundament of software patterns and abstract thinking.  Unfortunately, syntax is also a linchpin of model-driven development.

The more useful advice honors realities about human cognition and human’s relationships with information.

Modeling techniques and notations that are based on the “not-very-useful” advice above might be called “naïve modeling techniques.”   I hope that someday we will be able to reminisce about the weakness of such techniques, a bit like the way the current automobile designers must shake their heads at pre-ergonomic designs of passenger cabins and operator controls.

I mention naïve modeling techniques for three reasons:

• I’m a modeling guy; it’s in my nature.
  

• When using model driven architecture, bad models will propagate every which way, compromising systems, governance, compliance, security, … almost anything you can name.  Messing up models deserves special attention because models are supposed to be foundational.
  

• Naïve modeling techniques are GUARANTEED to yield bad models.  That is, even if you perform modeling techniques exactly as the designers of those techniques recommend, you will get poor results.  This is true for UML, Object-Role Modeling, and all the various flavors of ER modeling.  That’s because modeling techniques honor the distinctions that IT folks consider important (e.g., the differences between entities and attributes) and completely ignore the distinctions that users consider important, e.g.:

• • the difference between policy requirements and process requirements or …

  • the difference between strict policies (e.g., you cannot get an after-hours badge until your email account is active) and aspirational policies (e.g., we ship 100 percent of orders within 24 hours).
    

Modeling notations do not help IT folks to contemplate or express the distinctions that matter to business folks.  But these distinctions should also matter to IT folks, because they should influence architectural and implementation decisions.  For starters, the stability or transience of a requirement should affect how it is implemented.

• Hard-and-fast data requirements (which are relatively few) deserve aggressive enforcement in a hard-to-circumvent layer of the application stack. 

One example:  Every matrix cell is at the intersection of a matrix row and a matrix column and that row and column must be part of the same matrix.

• Any strict policy deserves aggressive enforcement in a hard-to-circumvent layer of the application stack.  However, because it is merely a matter of policy, it should be implemented in a way that can be relaxed later after the system is deployed (because this is how humans deal with policies; they relax them when motivated by nepotism, changing business climate, whatever).
  

• An aspirational policy is, strictly speaking false.  However, aspirational policies can still deserve to be implemented, perhaps as on-demand reports that indicate how well (or poorly) the company is realizing its aspirations.

In a nutshell, the problem I'm describing is this: Two syntactically identical requirements might not be equally stable or equally transient.  Because modeling notations concentrate on syntax, this important difference in stability is concealed from requirements analysts.  Furthermore, the usefulness of model-driven architecture is compromised, because algorithms of model-driven architecture (such as forward-engineering algorithms that translate logical data models into physical database designs) use syntax-based transformation rules.  Two syntactically equivalent requirements would be translated into identical implementation artifacts, even if those requirements deserve different implementation strategies based on their stability/transience.

Previously published Burton Group research describes how working modelers and requirements analysts can overcome these shortcomings in the current state of the art.  For more information, see "Mind Your Business: Serving Business With Data Models That Focus Exclusively On Data."