Rick Dove, Paradigm Shift
International, www.parshift.com, 
Good engineering is applied science. Some would argue about management as science, and others believe a manufacturing science remains elusive. Nevertheless, the design of manufacturing enterprise systems, from production process to business procedure, can result in a more or less adaptable system to the extent that certain design principles are employed. The expression of Agility design principles explored in three production systems (Sep, Oct, Nov ‘95) is assembled on the next page in tabular form showing various applications.
Science is born from gathering data, analyzing this data for patterns, making hypothesis on principles, and iterating toward validation. We are not employing the rigors of scientific investigation yet; but we are finding repeatable patterns that appear to govern adaptability.
Few would disagree that information automation systems are critical enablers for modern production; but what will the information automation system do to support an Agile operating environment? Perhaps more importantly, what will make the system itself Agile so that it can continue to support an Agile operating environment rather than guarantee its obsolescence? Are there fundamental characteristics that provide Agileness that we can look for in selecting information automation systems?
Adaptability (Agility) actually became a reasoned focus with the advent of object-oriented software interests in the early '80s. The progress of software technology and deployment of large integrated software systems has provided an interesting laboratory for the study of complex interacting systems in all parts of enterprise. The integrated software system, whether it's in the accounting area, providing management decision support, or spread over countless factory computers and programmable logic controllers, is understood to be the creation of a team of programmers and system integrators. We recognize that these people also have the responsibility for ongoing maintenance and upgrade during the life of the system. In short, the integrated software system is the product of intentional design, constant improvement, and eventual replacement with the cycle repeating.
As engineering efforts, the design and implementation of these integrated software systems proceeds according to an "architecture", whether planned or defacto. Over the years the size and complexity of these systems grows to a point where traditional techniques are recognized as ineffective. This awareness comes from experience:
The problem stems from dynamics. Traditional techniques approach software design and implementation as if a system will remain static and have a long and stable life. New techniques, based on "object oriented" architectures, recognize that systems must constantly change, that improvements and repairs must be made without risk, that portions of the system must take advantage of new sub-systems when their advantages become compelling, and that interactions among subsystems must be partitioned to eliminate side-effects.
These new approaches have been matured over a decade now and are emerging most visibly into everyday employment under the name client-server architecture. Though there are significant differences between systems concepts called client-server and those called object-oriented, "encapsulated" modularity and independent functionality are important and shared key concepts. More to the point, information automation practitioners are now focusing a good deal of thought on the architectures of systems that accommodate change; providing a rich laboratory and experience base from which fundamental Agility principles are beginning to emerge.
The ten "RRS" (Reusable, Reconfigurable, Scalable) design principles introduced earlier (Aug ‘95) and tabulated below are based on object-oriented concepts augmented with understandings from production and enterprise systems exhibiting high degrees of adaptability.
Readers far removed from systems engineering or computer technology may find the words used to describe these principles too abstract at first. A human resources director, for instance, might feel more comfortable with "empowered work team" then with "encapsulated modules", though the two are similar architectural concepts. But then, few people in business are taking a business engineering approach as yet.
The Agile RRS design principles identified here are presented as a useful working set that will undergo evolution and refinement with application. Their value is in their universal applicability across any system that would be adaptable. Instead of simply lurching to the next competitive state, Agile design principles facilitate continuous evolution.
Each of these principles will be subsequently examined in much greater depth, as will methods for establishing the objectives of an Agile system and the metrics of success. Though we have focused on the "solution" approach here, it is critical to establish an objective understanding of the opportunity and "problem" before embarking upon the solution.
©1995-1998 RKDove - Attributed Copies
Permitted