The Infrastructure Oriented Approach
The objective of infrastructure-oriented computer programming is to produce a tangible, executable framework at the outset. This holistic, strongly-prototyped, component-based approach allows components to be plugged together like Lego unlike traditional component development, which demands continuous or late integration to persuade the individual components to communicate.
Integration painfully slowly reveals (and often fails to reveal) holistic problems such as deadlocks, race-conditions, log-jams etc., which may have repeat cycles of weeks or even months. Contrast this with the house building industry; if a builder was tasked with building a house, he would not build, plumb, decorate and furnish each room separately and then attempt to 'glue' them together! Yet this is directly analogous to the integration approach (continuous or otherwise) adopted by the software industry at large.
Instead, any builder worth his salt would first construct a solid framework and test its structural integrity. Only then would he consider populating it with doors, windows, carpets, plaster, plumbing etc. Infrastructure-oriented computer programming prescribes the same approach for software.
This approach produces an executable framework early in the project lifecycle and this application is continually and holistically executable from that point forward. The framework provides the flow control for the application and populating the framework involves straightforward integration of pure processing code. This is a substantially more tractable process than integrating many components with each other, where each has their own piece of the flow control puzzle.
In order for the builder to successfully construct a structurally sound framework capable of being populated with the required items without subsequently failing, he follows the prescriptive blueprint produced by his architect. In creating that blueprint, the architect will have considered the requirements of the development and in particular all of the holistic issues (e.g. where to place the header tank to provide enough pressure for the shower). The architect remains in overall control of the design throughout the project development, so that any issues that arise can be dealt with in a holistic manner.
Infrastructure-oriented computer programming also requires a prescriptive blueprint. Produced by the software architect from the project requirements and finely tuned with the customer, this blueprint captures the necessary detail for engineers to code an executable framework without significant further, high-risk inspiration. It not only describes how the components fit together functionally, but also how the fit temporally (timing and scheduling), issues often lead to race-conditions, deadlocks etc.
An intuitive blueprint also provides an excellent vehicle for asking pertinent questions of the customer that they may not have even thought about and which impact their requirements. For example, what happens if a tape drive that is logging data initiates its head-cleaning process? Do you want to block the whole system until it finishes, or start shedding data?
One common drawback of Software Component Based development is re-usability. Software is often intended to be reusable, however, once it has been 'tweaked' to address all of the scheduling aspects that have to be built in, the software becomes tightly-bound to a project. By extracting the processing from the infrastructure, we not only purify the processing but we also make the infrastructure generic (a building is a building, it's not until we populate a room with cookers and sinks, that it becomes a kitchen).