As net-centricity becomes a common term and SOA moves into its productive phase we increasing see sets of systems coming together. The tendency is to take the term system and extend it to 'System of Systems' SoS. However, I'll argue that this approach takes the hyper-specified method of defining and engineering a system and imposes it on a set of systems. Gone are the days where the world moved so slowly that requirements stayed put long enough to waterfall a system out. Now that the global village is hyper-connected change occurs in real time. We need a new method by which we conceive of and implement sets of systems. Even sets of systems themselves are being linked together. Organizing principles change as we go up the hierarchy of sets.
If I join 5 systems together I can not do so rigidly like they were built. One system can be built to clearly define its inputs and outputs & its behavior given them. However, once I conjoin several systems I must live with the randomness of their individual operations. It is not random in the sense that it is unpredictable - they are, after all, computer systems. Their individual behavior is random in respect to the goals of the set. This means that the operational rules of the Set of Systems (SetOS) must be at a higher level of abstraction than the individual systems. The SetOS must scavenge resources when it can get them and offer back, to the individual systems, resources as they may take advantage of them. The term loose coupling has been used for this kind of idea, however I believe this term misleads. It is all about the focal point. Loose Coupling puts the focal point back on the individuals systems - which are loose coupled. We need to pan out. We must come up with a language about sets.
Set talk makes people uncomfortable. It is the pluralistic nature of such talk that disarms us. How do we conceive of system operations (a system like Gregory Bateson would use it) that apply to the whole set of constituent systems? An ecosystem is a good model for such things. Sets of individual actors interplay with each other according to operational principles that show behavioral organization at a higher level. Using SOA as an example. We can have individual SOA-based systems but it is only when the aggregate decide to collaborate that you actually see useful cross-program services begin to populate the enterprise registry. A group of ACAT 1 program managers who all, individually, implement SOA will never place one useful service in the enterprise registry. It is only when these individual operate as a set of PMs that we begin to see the benefits of SOA as an ecosystem enabler.
SOA is not dead, but the ACAT 1 acquisition system is trying its hardest to kill it off. SOA will continue to shear at the cultural & programmatic aspects of our acquisition system until the SOA ecosystem arises. There are interesting examples where it is beginning to happen. Portfolio owners are beginning to see that they can organize across their SetOS to drive a higher level benefit. This benefit is almost always to the greater good and echews the hyper-specific needs of individual programs.
