their organizations are not threatened by failure or undesirable behavior elsewhere in the coalition.
Socio-Technical Systems
system Complexity
Complexity stems from the number
and type of relationships between the
system’s components and between the
system and its environment. If a relatively small number of relationships
exist between system components and
they change relatively slowly over time,
then engineers can develop deterministic models of the system and make
predictions concerning its properties.
However, when the elements in a
system involve many dynamic relationships, complexity is inevitable. Complex systems are nondeterministic,
and system characteristics cannot be
predicted by analyzing the system’s
constituents. Such characteristics
emerge when the whole system is put
to use and changes over time, depending how it is used and on the state of its
external environment.
Dynamic relationships include
those between system elements and
the system’s environment that change.
For example, a trust relationship is a
dynamic relationship; initially, component A might not trust component
B, so, following some interchange,
A checks that B has performed as expected. Over time, these checks may
be reduced in scope as A’s trust in B
increases. However, some failure in B
may profoundly influence that trust,
and, after the failure, even more stringent checks might be introduced.
Complexity stemming from the
dynamic relationships between elements in a system depends on the existence and nature of these relationships. Engineers cannot analyze this
inherent complexity during system
development, as it depends on the
system’s dynamic operating environment. Coalitions of systems in which
elements are large software systems
are always inherently complex. The
relationships between the elements of
the coalition change because they are
not independent of how the systems
are used or of the nature of their operating environments. Consequently,
the nonfunctional (often even the
functional) behavior of coalitions of
systems is emergent and impossible to
predict completely.
engineers are concerned primarily with building technical systems from hardware
and software components and assume system requirements reflect the organizational
needs for integration with other systems, compliance, and business processes.
Yet systems in use are not simply technical systems but “socio-technical systems.”
To reflect the fact they involve evolving and interacting communities that include
technical, human, and organizational elements, they are sometimes also called “socio-
technical ecosystems,” though the term socio-technical systems is more common.
socio-technical systems include people and processes, as well as technological
systems. The process definitions outline how the system designers intend the system
should be used, but, in practice, users interpret and adapt them in unpredictable ways,
depending on their education, experience, and culture. individual and group behavior
also depend on organizational rules and regulations, as well as organizational culture,
or “the way things are done around here.”
defining technical software-intensive systems intended to support an
organization’s work in isolation is an oversimplification that hinders software
engineering. so-called system requirements represent the interface between the
technical system and the wider socio-technical system, yet requirements are inevitably
incomplete, incorrect, and/or out of date. Coalitions of systems cannot operate on this
basis. rather, engineers must recognize that by taking advantage of the abilities and
inventiveness of people, the systems will be more effective and resilient.
Even when the relationships between system elements are simpler,
relatively static, and, in principle, understandable, there may be so many
elements and relationships that understanding them is practically impossible. Such complexity is called “
epistemic complexity” due to our lack of
knowledge of the system rather than
some inherent system characteristics. 16 For example, it may be possible
in principle to deduce the traceability
relationships between requirements
and design, but, if appropriate tools
are not available, doing so may be practically impossible.
If you do not know enough about
a system’s components and their relationships, you cannot make predictions about overall behavior, even if the
system lacks dynamic relationships
between its elements. Epistemic complexity increases with system size; as
ever-larger systems are built, they are
inevitably more difficult to understand
and their behavior and properties
more difficult to predict. This distinction between inherent and epistemic
complexity is important. As discussed
in the following section, it is the primary reason new approaches to software
engineering are needed.
Reductionism and
software engineering
In some respects, software engineering
has been incredibly successful. Com-
pared to the systems built in the 1970s
and 1980s, modern software is much
larger, more complex, more reliable,
and often developed more quickly.
Software products deliver astonishing
functionality at relatively low cost.
