Abstract. Information systems have, until very recently, been build on an artisan, pre-industrial model. Building large information systems require that our assembly methods become more industrialized.
Historians describe the Industrial Revolution with lists like this:
The engineering threads of the Industrial Revolution are:
The second of these hallmarks is important to us in terms of understanding how to build large information systems. Essential components of the industrialized manufacturing model include:
The benefits of interchangeable parts is that a modest but generalized stock of spare parts can be accumulated to logistically support equipment. For example, if spare bolts and nuts are required, the bolts and nuts should all be of identical thread specifications and of a few sizes and lengths. Imagine the level of complexity of the spare parts bins if standardized threads were not used. In information systems, the analog to interchangeable parts is the ability to snap different information system components together -- cross-program, cross-platform, cross-service interoperability.
In 1798 Eli Whitney contracted with the Army to make muskets using an assembly line and featuring interchangeable parts. Prior to this innovation, weapons were logistically unsupportable as any repair parts had to be custom manufactured. Manufacturing tolerances had progressed to the point where parts interchangeability became a feasible option.
Standards are the lingua franca of information technology interchangeable parts. For instance, if a computer, router, bridge, cable modem, ..., has an ethernet interface on it, it conforms to the IEEE 802.3 standard and can be expected to interconnect with another component that also has an ethernet interface. Even though these components were built by different manufacturers. And even though the components may have been acquired by different programs executed by different services.
Standards have a role and are often abused. The role is to define interfaces. But standards do not tell one where to put the interface -- the function of modularization. Standards define the interfaces of interchangeable parts; they do not define the parts themselves.
Specialization of industry and assembly line production relaxes the constraints on both quality and quantity. Execution of most tasks gets more expert with repetition and familiarity. And speed of execution also increases with repetition. Imagine the declines in quantity and quality of, say, books if we returned to an artisan manufacturing system where a single craftsman made paper, brewed ink, composed and wrote the Great American Novel, sewed and glued the bindings and then sold the product to the end consumer. (And consider the benefits to society if we could impose these manufacturing constraints on e-mail spam;-)
While considering how we might optimize the specialization of labor in information technology, reflect for a while on how the Department of Defense's rulebook (colloquially known as DoD5000 for the series of policy directives that implement it) requires the system to operate. More to say on this below.
The analog of assembly line production in information systems is sound modularization. Modularization is a tacit feature of Industrial Age assembly lines such as automotive lines -- we don't expect engine parts to be assembled by the paint crew. But because modularization of information systems seems to be in a comparative infancy, we need to spend some conscious thought on the subject.
The pre-industrial, artisan approach to building information systems is typified by the program manager acquisition approach. A program manager is appointed to deliver an information system (which may indeed be part of a larger platform procurement). In order to meet the control requirements for a program, all sense, decide, act and communications functions are carefully tucked inside the program. This system has no means for even acknowledging the next information system over -- under a different program manager. It should be no surprise that the data from a sensor in System A cannot be passed freely to a weapon in System B -- there is nothing in the acquisition system that would make the two elements interoperable. Think about the present system in terms of exploiting specialization of labor and placing things on an assembly line footing. Doesn't look very good, does it?
The first stage of modularization is to put the sense, decide and act functions (including their security and management needs) in one module and the network in the other. The second stage of modularization within the network is to recognize that there are different specializations at work in
Take advantage of the specializations of labor. Communications systems -- the networks -- should be acquired under programs that have no other requirements. Modularization rules of thumb:
Similarly, applications that use the network should be carefully modularized to use, but not duplicate the network structure. A few telltales:
Just as large industrial systems have a systems engineer who has the 'big picture', information systems need an interoperability architect. The architect should not be concerned with infrastructure -- we have program managers for that. Rather the architect should be concerned with establishing where the modularization boundaries are and how they are to be implemented. Further, there are a couple of issues where cross-program issues are becoming increasingly important. These two issues are clearly rising in importance, but are imperfectly grasped in our programs.
As information systems become more complex, the approach of securing computers, operating systems, networks -- containers for the data -- reach a point of diminishing returns. What becomes increasingly important is security (authenticity, integrity and confidentiality) of the data. In data management terms, the data needs to carry it's metadata, including security tagging and digital signature with it. In networking terms, security measures at layer 7 of the ISO Reference Model are the ones to exploit.
Traditionally, most of these security concerns have been levied on the communicators while we draw enclaves around the end system nodes -- and run everything 'system high'. Note that this approach is a guaranteed way to frustrate interoperability and 'system of systems' structures. Data content security should be implemented in applications and applied to the data, not to the network. Thumb rule: the network should never have to deal with unprotected datagrams.
Many communications links come with their own management infrastructures. Satellite communications systems all do. But these networks are increasingly part of larger internetworks. End to end management across multiple network segments becomes increasingly important relative to management of a specific segment. The networking equivalent of interchangeable parts is a common set of network management protocols and information bases.
Shifting from an artisan to industrial approach to our information systems does not require technology we lack. It requires an industrial approach to managing it.