Environment Variety in System Design

A system, and each component of it alike, has a unique environment that sets mandates on the object about what it has to deal with. It is important to quickly and broadly (not fully since impossible) and continuously realize the environment when it comes to system design. Rothe (2002) explains “requisite variety” for a system:

Internal diversity of any system must match the variety and complexity of its environment …so that they can cope with the demands they are likely to face. …requisite variety embraces proactive engagement in all its diversity…multiple disciplinary groups that have the requisite skills and abilities to deal with the environment in a holistic and integrated way. But every often practitioners do the reverse, reducing variety in order to achieve greater consensus.

A system is always designed for its environment. The environment is another way of saying the problem that a system is designed to resolve. So the environment change drives the system change.

Nevertheless, on the other side, designing a system also aims for stability – withstanding environment changes. This attribute can be achieved by focusing on a system's own coherency and integrity. A well-defined system can handle environment variety without a fundamental change. This is to say a system should NOT be concerned much about who and how it is used, which could change without notice.

So, what is the roadmap for a system design? 

First, at least in Agile way, designing a system is an on-going process alongside the on-going development. Started and initialized as a result of examining the environment, a design is then evaluated and consolidated continuously across the course of the development. This is from an inward perspective. On the other side, when more things are put into the system, the designer will also continuously evaluate from the things themselves and find what attributes or functionality could be derived as a result of synergy. This is from an outward perspective.

So a design is continuously consolidated over the course. It is much like the "refactor" iteration for coding. This is why decoupling and minimizing dependency is an the essential rule that designers are going after. Patterns are adopted for optimizing dependency, e.g., IoC, MVC, Layers etc. Meanwhile, developers are facilitated with many handy tools for quickly exploring dependency so that they know the impact of a modification.

Designing by focusing on coherency is a systematic approach rather than Agile in normal sense that respects JIT (Just in Time). But in broader sense a systematic approach can also be proceeded through Agile  - Agile is just a manner of doing things rather than defining what to be done.

Throughout the development course, when change requests can be handled by existing components then leverage them. Otherwise, a modification to the current system is needed or new components are to be added. The designer now has a choice: modifying existing components so as to satisfy the new requests; or creating new components that works on top of (extends) existing data and functionality. Clearly, based on the “open-close” rule, he will choose that latter.

Of course, creeping of environment or problem scope should be restrained. Any system design has a scope and scale limitation. Environment changes has to be evaluated before adjusting the design. 

References:
Rothe, J.P. (2002) Driving Lessons: Exploring Systems That Make Traffic Safer, S.1: Personal Sub-Systems. The University of Alberta Press. Pp.1-19