Building robust software with fallible construction

Many of today's systems depend on large, complex software with the need to be built and deployed more rapidly and cheaper than traditional development methods can deliver. Moreover, because organizations depend on these systems, they must be more predictable and trustworthy than traditional development methods can deliver for the available time and cost investments. However this requirement is not quite compatible with the traditional project-oriented view of software development, which is prevalent in the acquisition methods of many organizations. Today's systems are typically integrated from components. These components may themselves contain flaws,originating in specification, design or implementation errors, or in miscommunication between different teams involved in the development. More seriously, the integration process itself may be flawed, as when pre-existing components are used for purposes that their developers had not envisioned, and the integrators misunderstand the detailed behaviour of the components. Interoperability failures between systems belonging to different organizations often are of this form. Attempting to build infallible systems with fallible construction methods may be too stringent an expectation to achieve, but the weaker objective of resilience to failure and outages may be more realistic. Experience with interoperating commercial products, especially in the context of the Internet, indicates that robustness to fallible components and fallible integration can be achieved without centralized predictive coordination. Appropriate software architecture, redundancy in functional alternatives, and enforcement of critical interface standards in middleware in particular appear to be key elements of success. Autonomic computing techniques, such as improved registry and plug-and-play concepts, can help automate integration and reduce configuration problems.