As many IT managers and CIOs found over the years, growing from one major application to multiple applications was tough in a broad range of areas such as planning, budgeting, implementation, user training, internal organization transformation management, support, interoperability, and more. Keeping up with applications upgrade was tough enough, but when you are building data warehouses and data marts on top of everything else, and then trying to become more flexible and agile to meet market and supply chain shifts, it just simply got tougher. IT Management started to feel the pressures of managing a system of systems — all these applications and products — inter-operating with each other.
Eighteen (18) years ago I was involved in one effort — a “simple” move to an ERP to consolidate the operations of 13 business units globally. This led to the complex implementation and integration of SAP, Freight Rater, Manugistics, PeopleSoft, a global messaging gateway, and a large number of custom “apps” under/in SAP to meet the firm’s needs, PLUS the implementation of a second SAP instance to handle OLAP since the core system was devoted to high-volume real-time 24X7 OLTP … and OLAP functions killed the OLTP system performance. They not-quite doubled the core system hardware costs with that realization — and synchronization of databases became another major task to do, and manage. There were many other “things” we had to do along the way, and while the goal was simplification, those other “things” added complexity.
Recognized or not, cloud computing was and is very much a form of business process re-engineering, only now it’s what I call IT Systems and Services Re-engineering (ITSSR). With the Cloud vendors offering a broad range of PaaS, IaaS, SaaS, DaaS, and now MAaaS — Mobile Authentication as a Service, and apps that support the seemingly old-fashioned desktop user to the mobile user in virtually any form, the bar has been raised, and perhaps even the stakes have gone up, in the use of Cloud Computing.
Regarding MAaaS, virtually all major application systems now offer remote user/mobile device support, and integrated authentication services. Other firms offer third party solutions. MAaaS simplifies the problems you may have had in maintaining separate authentication services and product features for each application by unifying the authorization for multiple apps/devices into one consolidated service — in the cloud. I have no fundamental objection to the concept other than the consolidation of essentially access information and certain forms of security information in the Cloud, and the on-going issues of ownership of data in the cloud, and where that data might reside country-wise. No disrespect to anyone or any product, but now — IN THEORY — you need only hack one site for access to many user domains simultaneously…but you could do that a number of ways.
I may have missed something (possible), but in all the discussions on Cloud Computing, I have yet to see the issue discussed regarding the evolution of a cloud computing environment (CCE) for a user evolving into a complex System of Systems (SoS). Personally, I have no problem with this having worked on many complex business and government SoS projects in the past. But many of the systems had a logical sequencing of activities that enabled structured operation, and sometimes this point, and effort, seems to be lost in migrating to the new CCE.
If one takes Wikipedia as an authoritative source for definitions, a “System of systems is a collection of task-oriented or dedicated systems that pool their resources and capabilities together to create a new, more complex system which offers more functionality and performance than simply the sum of the constituent systems. Currently, systems of systems is a critical research discipline for which frames of reference, thought processes, quantitative analysis, tools, and design methods are incomplete.” The emphasis is mine.
Recently, I published a book Understanding the Laws of Unintended Consequences, and the narrative takes you on/through the escalating journey of understanding the Laws from their most basic form (i.e., every action as an intended consequence, and quite likely, at least ONE unintended consequence (that you may not even know about or see)), to what happens or can happen in a system of systems. For the occasional humor injected into the book, the subject is quite serious. The discussion of complex and systems of systems unintended consequences should make one think — not stop, but think.
In August, 2008 — before Cloud Computing really gained traction, the US Department of Defense published is Systems Engineering Guide for Systems of System. The publication makes for interesting reading for anyone looking at cloud computing or an in-house system of systems. The US military is built on a system of systems; in fact, so is the US government or any government for that matter. So are most corporations, but the evolution of those corporate SoS environments evolved over time in most cases, and were tuned and controlled as they went along.
Arguably, even major ERPs with their many modules that do different things — many of which can be done independent of other modules, are SoSes. Some firms, driven by acquisition, have lived with SoSes that are inherently incompatible, but found simplistic ways to integrate and operate them effectively, focusing on data as the driver and not apps, for example. One major automotive supplier, with almost 200 plants acquired through growth and acquisition, at nearly as many locations globally, patently refused to try apps standardization and happily used an essential business operations data summary pull-down every day for the operational data it needed. Simple, easy to backstop, efficient — and VERY effective. Inexpensive to implement, very low cost to operate, and 100% accurate 100% of the time (unless some plant was off-line).
But back to the DOD SE Guide. It points out many things, one of which jumped off the page at me, notably about the emergent behavior of systems, an area of significant study now. I know this issue all too well from past experiences where well defined and constructed SOSes suddenly seemed to take on a life of their own. “What the …?” is a phrase I absolutely do not like.
The DOD guide notes on pages 9-10, and all emphasis is mine: “In SoS contexts, the recent interest in emergence has been fueled, in part, by the movement to apply systems science and complexity theory to problems of large-scale, heterogeneous information technology based systems. In this context, a working definition of emergent behavior of a system is behavior which is unexpected or cannot be predicted by knowledge of the system’s constituent parts.
“For the purposes of an SoS, ‘unexpected’ means unintentional, not purposely or consciously designed-in, not known in advance, or surprising to the developers and users of the SoS. In an SoS context, ‘not predictable by knowledge of its constituent parts’ means the impossibility or impracticability (in time and resources) of subjecting all possible logical threads across the myriad functions, capabilities, and data of the systems to a comprehensive SE process.
“The emergent behavior of an SoS can result from either the internal relationships among the parts of the SoS or as a response to its external environment. Consequences of the emergent behavior may be viewed as negative/harmful, positive/beneficial, or neutral/unimportant by stakeholders of the SoS.” 
Key word: HETEROGENEOUS. This whole emergent concept lands squarely on top of the Law of Unintended Consequences regarding a system of systems, which in part states: “In a system-of-systems, the Unintended Consequences may not be detected until it is far too late, but if detected early, more will be assured … that you become aware of. Never trust the obvious …”
It is fundamentally impossible to test all aspects of a SoS. Even an operating system has evolved to an SoS with the innumerable subroutines/processes running in parallel and doing different things for the OS as a whole. Network products are released with high confidence levels they will work, but testing them in all configurations is impossible, as is testing bug fixes to complex problems. This later point – not testing all reported bugs in a major and ubiquitous software product — was made by the head of product testing for a major network products firm on a panel I chaired at a Networking products conference. You could hear 1,000 people in that room suck in all the air as he made that statement. This was news to them. And as some people commented to me later: “Well, that explained a lot.”
Which leads me back to the Cloud. As firms move at measured or rapid pace to Cloud Computing using in-house systems and products migrated to the cloud, or use replacements provided by the Cloud Computing Environment suppliers, the adopters have begun to change the nature of how they conduct their business, from slightly change with direct 1:1 replacements to significantly with new products, services, and tools being bolted on and integrated.
As Cloud adopters use more third party tools and products — SaaS, MAaaS, etc., that inter-operate with or are dependent upon each other, they begin to draw or establish different linkages and connections between their current work environment and their IT. If users wind up using products from different vendors in different clouds — which is quite possible, they have added complexity and risk to the mix in excess of their current exposure. If you’ve decomposed applications and created SOA components, you just added to the mix. Therein lies the “trap,” so to speak. De-linkage creates opportunities for problems that simplify magnify comparable problems that might occur in more tightly linked or homogeneous environments.
But it goes beyond that: many of the SaaS offerings that people are using don’t know about other’s systems/SaaS offerings, and the integration of these into a cohesive working environment can be a challenge. A recent article I read regarding one firm’s adoption of a mobile CRM product indicated they had to “fill in the blanks,” so to speak, and write their own enhancements for the additional features/services they wanted that the CRM package did not [yet] offer. So even while finding a “solution,” it was incomplete and they added to it — and thus added to the complexity of their overall systems management requirements. The app with enhancements worked fine … but it was one more thing to track and manage.
I could go on, but the message is simple: an SoS cannot just spin into existence. It needs to be as well-defined, architected and managed as any other prior-in-house system. If anyone forgets that, they will really find out what the scope of unintended consequences can be.
 Office of the Deputy Under Secretary of Defense for Acquisition and Technology, Systems and Software Engineering. Systems Engineering Guide for Systems of Systems, Version 1.0. Washington, DC: ODUSD(A&T)SSE, 2008. ( Document on line at http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf)