Standards lead to modularity
Standards lead to modularity, which drives speed and innovation. Collaborative standards development uses a consensus process that over the life of a technology and its applications provides; a guide for applying the technology, recommended practices to tighten up the applications, and standards that recommend specific rules for applying technology. The knowledge increases about a technology and application as it progresses through this evolution. There are several reasons why this happens, here are a few:
- Standards are developed through a consensus process used by many standards developing organizations (like UL and IEEE) and, as a result of this specialization of talent, the standards display modularity.
- During the development of standards, frameworks are used that describe general attributes of technology and its application. This often results in describing the system, subsystem, and interfaces.
- Knowledge developed about the operation of complex technologies and systems requires engineers to specialize in technology groupings that align with modules.
- Platform engineering is used in many product development organizations. Under this concept, common core components are grouped together and used in a variety of "derivative" products that have different functions or appearance.
Modularity is an important benefit of standards that often gets overlooked. Modularity has had a long history of enabling breakthroughs in innovation of technology. A great example of this is the computer industry. Through the widespread adoption of modular designs, the computer industry has dramatically increased its rate of innovation. As a result, not only have computer companies transformed a wide range of markets by introducing cheap and fast information processing, but they have also led the way toward a new industry structure that makes the best use of each company’s unique abilities. Modularity is at the core of this remarkable accomplishment-building a complex product or process from smaller subsystems that can be designed independently yet function together as a whole.
Modularity has been referred to most often in the field of software engineering. Relevant definitions are:
- Modular: Composed of discrete parts.
- Modular programming: A software development technique in which software is developed as a collection of modules.
- Modular decomposition: The process of breaking a system into components to facilitate design and development, an element of modular programming.
A September 1997 Harvard Business Review article entitled "Managing in an age of Modularity," modularity is discussed as:
A strategy for organizing complex products and processes efficiently. A modular system is composed of units (or modules) that are designed independently but still function as an integrated whole. Designers achieve modularity by partitioning information into visible design rules and hidden design parameters. Modularity is beneficial only if the partition is precise, unambiguous, and complete.
The visible design rules (also called visible information) are decisions that affect subsequent design decisions. Ideally, the visible design rules are established early in a design process and communicated broadly to those involved. Visible design rules fall into three categories:
- An architecture, which specifies what modules will be part of the system and what their functions will be.
- Interfaces that describe in detail how the modules will interact, including how they will fit together, connect, and communicate.
- Standards for testing a module’s conformity to the design rules and for measuring one module’s performance relative to another.
Another benefit of modularity is the aspect of separating a complex system into subsystems, which reduces management costs by dividing the development program into independently managed pieces. Each subsystem can then use a specialized design and manufacturing workforce, enabling more sophisticated solutions and rapid improvement.
Viewing the benefits of modularity-it is helpful to look at the system level. An extreme example can be made of the old "tightly coupled" way of designing power plants. Generally, the design of the Three Mile Island Nuclear Plant was highly complex and the subsystems were tightly coupled. A "system accident" that occurred in 1979 caused an unanticipated interaction of multiple failures in a complex system. It effectively tied all the risks together in a long chain of cascading dependencies.
In contrast to this, a modular approach breaks the system up into semi-autonomous, "loosely coupled" modules. This is illustrated by Figures 1 and 2.
Figure 3 generally describes the elements of the System/360 modularity.
This system concept and modular architecture was so successful that, by 1980, hundreds of firms made S/360 "plug-compatible" components. The progression is shown in Table 1.
With the PC, IBM decided to make strategic use of external innovators.
Modularization is a process with a history, the following list of milestones illustrates the development:
- "Invented" by Task Group for IBM System/360
- Explained by Bell and Newell, Computer Structures, 1971
- Refined by Parnas, "On the Criteria for Decomposing…" 1974
- Independent invention, Mead and Conway, Introduction to VLSI Systems, 1980
In summary, standards lead to modularity. Standards develop the framework from which design rules emerge. Eventually, standards for testing a module’s conformity to the design rules and for measuring one module’s performance relative to another open up many possibilities for innovation. Additional benefits include:
- Decoupled systems
- Lower cost
- More complete specifications
- Intellectual property
- Increased rate of innovation
Mark Siira, ComRent International, is chair of IEEE P2030.2 Guide for Interoperability of Energy Storage Systems to the EPS.