sometime in the mid 1980s we started to build a lot of systems that should have, but did not, take into account the same questions and issues raised in the ULS study.
===== Elaboration:
(copied from a draft of a new book, Developing Systems) "In, or near, the beginning (1960’s) software developers recognized that they were embarking on the construction of large complicated systems. Advances in modularization and architecture reflected this awareness. Jerry Weinberg was particularly eloquent in advancing a systems perspective. The software community actively looked for ideas and inspiration in General Systems Theory. Structured Analysis methods advocated construction of system models – abstract models of the existing system and the system to be delivered.Unfortunately, most developers, theorists, and academicians missed much of the point when it came to a systems perspective. “The System” came to be understood solely in terms of the automated, computer-based, system. Although relationships between the automated system and the business system in which it was embedded were noted, such concerns were clearly secondary. Attention was focused on how best to produce an artifact – the automated system. Success was defined in terms of delivering an artifact that was merely consistent with the specifications for that artifact.
The metaphor, software engineering, exacerbated the focus on artifacts by equating software and automated systems with bridges and buildings. Specifications equaled blueprints that could mechanically and deterministically be translated into concrete (sometimes literally) artifacts. The epitome of this viewpoint was the intense effort (still ongoing ) dedicated to variations of automatic programming – analysts would create abstract models of the software using tools like Rational (UML-based) and the tool would automatically create correct code that implemented the model. Conversely, it should be possible to parse existing code, generate the abstract model, change the model, and recreate the code.While IT practitioners and computer science theorists were preoccupied with the quest to make software and computer-based systems deterministic, the Santa Fe Institute was pioneering work in non-deterministic (chaotic and complex) systems. The model of a complex system is well suited to describing living dynamic systems – biological, economic, sociological, and cultural. Complex systems exhibit qualities quite different from deterministic systems. Self-organization and emergence (the state of the system at time n is not predictable, even with perfect knowledge, from the state of the system at n-1) are among the most interesting.
A business is a complex system. Each software application must be deployed into, must become a part of, the business system. This implies that even though discrete bits of software are deterministic components, the result of introducing these components into the business should not alter the complex nature of the business.Unfortunately, the trend for the past fifty years has been to architect large scale, complicated, integrated, deterministic systems. This kind of large artifact cannot be introduced into a business system. Instead, the artifact becomes a kind of container, a straightjacket into which the living business system is forced and constrained. The business is not unlike a plant in a pot – the potential of the plant is limited to the growth allowed by the parameters imposed by the pot. In an extremely small number of cases, and with constant attention, the result, like a Bonsai, can be successful. In most cases the result is stunted plant. In a surprisingly large number of cases, it is a dead plant.
One system referred to by the title is, therefore, the complex business system and the resulting concern is how to support, nurture, and enhance those systems."===== Comment:
"The sheer scale of ULS systems will change everything. ULS systems will necessarily be decentralized in a variety of ways, developed and used by a wide variety of stakeholders with conflicting needs, evolving continuously, and constructed from heterogeneous parts. People will not just be users of a ULS system; they will be elements of the system. Software and hardware failures will be the norm rather than the exception. The acquisition of a ULS system will be simultaneous with its operation and will require new methods for control."If we recognize that most of the "mundane" MIS and post MIS systems should have been approached and designed from the perspective of elaborating and modifying a complex business system then the statements about ULS apply equally to those mundane systems.
===== Question:
Might our understanding of ULS be jumpstarted by a retrospective analysis of what we should have been doing in software for the past 20 years at least?- DaveWest