A systems analysis of systems integration

Most if not all complex issues stated as problems intended to result in new systems may be analyzed using systems decomposition and then constructed by synthesis. Systems decomposition starts with a complex problem that may or may not be obviously solvable and deconstructs that problem into smaller more tractable problems that can be solved. Construction by synthesis treats the smaller solutions as building blocks. The key practical advantage to synthesis is that it permits concurrency of construction. The subsystems may be developed and tested independently in isolation. Not until integration will subsystems need to be brought together. Decomposition and synthesis are the ideal in theory. In practice there can be any number of problems. Potentially the most fatal of flaws can occur during decomposition where errors in abstraction lead to over-idealization of subsystem independence. Over-idealization leads to under-specification, that what is presumed to be independent is not. Once errors in subsystem specification are made, independent development ensures that undetected dependencies will remain undetected. Subsystem dependencies are hidden time bombs, dormant until the subsystems are brought together for systems integration. In systems integration the latent dependencies interact and explode in a manner most combinatorial. The term often used to describe the excitation of dormant dependencies is "emergent behavior". Emergent behavior is but one factor that plagues the integration of large software intensive systems. There have been few published analyses or case studies dedicated to systems integration, in particular analyses deemed useful as "lessons learned" for others to follow. This paper takes a hesitant first step, not towards a "lessons learned" but towards the meta, an estimation of the boundaries of what it might take before one can provide a useful "lessons learned".