Enduring Requirements are Coded, Volatile Requirements are supported as Configuration Models
When dealing with requirements and change the "best practice approach" could be summarised as:
- Gather current requirements
- Establish known points of variation
- Investigate likely future requirements
- Build a highly parameterised application to cope with this anticipated level of change
This is all well and good: difficulties arise when:
- Unanticipated change occurs (often driven by regulatory change)
- Anticipated change does NOT occur (the system is left with unused and confusing configuration mechanisms)
- There is an attempt to extend the scope of the existing system to areas not covered by initial analysis (new lines of business, new territories)
Very often, despite the best efforts of talented developers, systems will not have adequately been prepared for the change that comes. Chaos ensues.
How can we do things differently? We can take a very wide definition of which requirements should be regarded as volatile, and plan to support this in a structured way:
- Anything driven by regulation is volatile
- Anything driven by “products” is volatile
- Anything driven by markets and competition is volatile
- Anything unique to the line of business, market sector, or territory should be regarded as volatile.
We can then analyse these volatile requirements and capture their variation in open-ended and structurally sophisticated configuration. We call this process modelling, and the configuration definitions thus obtained are models. Every effort goes into making modelling easy, so that as far as is possible, model change becomes a non-programming skill.
Enduring requirements are those aspects which are unlikely to change over a period of decades. “In a contract, we need to know who the contracting parties are”, “We will need to keep track of financial movements” are examples of enduring requirements. Enduring requirements are supported by software applications that we call engines.
Engines provide raw, generic capability.
Models shape that capability into purpose-specific services.
When volatile requirements change, as we expect them to do, these changes are managed without change to the engines, purely as model change.
This is not to say that engines do not change: they do. But engines change only to extend generic capability. This means that engine change is exclusively a positive thing. This is hugely important. It means that as time progresses, we expect the engines to improve: extended capabilities, better performance, more flexibility in deployment.
Engines + Models = Services
