Modular Accountability

A model of ecological governance and how system engineering deals with complexity

The Concept of Operations

In 2007 I wrote a paper (that got a corporate award) “The ConOps in a Self-Similar Scale Hierarchy for Systems Engineering” [PROCEEDINGS, CSER 2007, Stevens Institute of Technology, ISBN - 0-9787122-1-8]. It can also be found on my Academia site.

The paper was one of the culminations of my practice in systems engineering. The other is “Organizational Evolution, Life-Cycle Program Design” [Washington Academy of Sciences, Volume 92, Number 1, Spring 2006]. One source for a free-online copy of that is here. Both papers are foundations for the arguments I make in the Limits to Mobility (LTM) project and are the most nearly-academic reflections of my application of complex-system theory to the ecology.

The Concept of Operations (ConOps) or Operational Concept Definition (OCD) is a standardized process and deliverable in system engineering. For many, including system engineers, the ConOps seems far from a fundamental reflection of complex systems or what I call a kernal of the system engineering process. In practice it is optional or lost in the more elaborate organization of projects. But if we start with Herbert Simon’s “Architecture of Complexity” [1962] and Stan Salthe’s theory of hierarchy [e.g., Evolving Hierarchical Systems, Columbia University Press, 1985; Hierarchical Structures, Axiomathes, Volume 22, Number 3, September 2012 , pp. 355-383] we arrive at the fundamental-modular structure of complex systems within levels of form.

The basic ConOps process for one module within an architecture

In systems engineering we now refer to “architectures” as a form, with protocol standards. The architecture is a formal level of a scale and specification hierarchy and it contains the parts or modules that interact by the common protocols. The hierarchical architecture and modules are the way we decompose and integrate complex systems. I can say that simply in terms of networks that are defined in graph theory as a bipartite set: N = {{V}, {E}} where the set of V (vertices or nodes) are the modules and the E edges or links are the interactions. This whole-part composition is a universal concept of systems and is practically a definition of complexity.

How would an engineer approach such a system, especially if it is occupied by other humans who are expert in, and accountable for, operation of the modules? This is also a question of governance. There is an approach of humility or of arrogance. The humble or democratic-participatory approach is that the engineer can only participate with the “operators” in seeking an improvement that maintains the modular accountability for risk and equity among the participants. The arrogant approach is, well, like Trump or any dictator who asserts the “new, big, beautiful, and improved” regardless of what the little people who have to endure the outcomes think. The two approaches are responses to the general problem that there is no formal definition of what is preferred or better or an improvement. The parts of a complex ecology, and a democracy, develop by interaction in a ruly form. That common form evolves or emerges into protocols of negotiation with others. This is a recursive process and the stability of a mature form (the ecology, the rules) becomes the regulatory concern of common governance, or architectuire management.

The ConOps simply affirms the sovereignty of an operational module within a stable architecture. The module participants have expertise in the operation and accountability for its outcome risks. A lot of my work was in air traffic control (ATC) and other systems (of infrastructure or security) where risk accountability by the operators is paramount. No one can just walk in and say “here is a technology that will improve what you do”. Indeed AI is currently the technology needing caveat in that regard. The ConOps is a process that enables an accountable group to apply technology or just changes in organization and tasks.

My ConOps paper emphasized the alignment of the modular process with complexity and the development/evolution of a system. I use development strictly as how a module changes (presumably to improve under the formal circumstances, meaning the rest of the system) and evolution as a change in form by changes in the modular population or the protocols of interactions. That is closest to the biological;-genomic concepts. The difference is often confused in engineering. The more dangerous confusion is between the formal regulatory role and interference with the modular accountability. That is the confusion of our governance, or us and the rest of the ecology

Dealing with Complexity

My career (roughly 1970 to retirement in 2011) happened to be concurrent with the application of cybernetics (control and communications, dated to Norbert Wiener’s book of 1948) to system engineering and the development of a “science of complexity” as popularized in the 1980’s. In the 1950’s the development of notably complex systems—including the ICBM and the SAGE air defense system—promoted the development of a systems engineering doctrine. There was no longer just a smart designer producing an amazing widget. The SAGE (Semi Automatic Ground Environment) was the prototype of computer-mediated communications for distributed decisions that we would now call the Internet of Things, with AI. It led directly to the digital ATC system I worked in as well as the Intelligent Transportation System (I also worked in) that then and now contemplated autonomous vehicles (AVs). That and some “security” work also emphasizes the role of risk and equity (we preserve a form to reduce risk for all).

By the time I worked on national-scale systems the engineering practice was still catching up with “complex systems” and how to deal with them. Our artificial and computerized systems were considered “complex” but that was a matter of the extent of the operational ecology. All the systems I worked with had expert and accountable operators who were not going to be dictated to by someone expert only in some other method or technology. The only acceptable, and necessary approach was to apply the engineering the same way the system was organized, in modules and levels.

In my experience the idea of “architecture” was prevalent only in the 1980’s as the idea of “system evolution” was replacing “design”. In my particular experience with the ATC system (covered in another post) there arose a contention between the “evolutionary” (modular) approach versus the Big Bang (a presumptive formal change by fiat). The difference can be understood as application of the ConOps under an architecture form. My paper was an attempt to clarify the issues and terminology. I argue that the ConOps was system engineering complete, at the modular level. The architecture management was the formal level. Those embedded in all the steps and management organization such as found in the System Engineering Book of Knowledge, or the complete catalog of system engineering standards, have trouble accepting the multi-module, level-pair simplification. But that is the essence of the ecology and any work in it.

Sustainability etc.

The ConOps leads to a general concept of ecological management. I note the increasing and confused use of the terms Sustainability, Adaptability and Resilience. The intent is formal, that some system may persist even if the parts have finite life cycles. Interestingly the attempts to define these terms are based on network analysis of how some integrated function persists despite loss of parts.

I merge the three terms into SAR because they each and all participate in formal persistence. The intent could be restated as “all systems have an architecture and protocols”. SAR operates if each module has a self-interest in persistence and does its part in the whole. Formal management (regulation) operates according to success or failure of the parts. There is no implication that the parts should be “improved” other than how they contribute to formal SAR.

Ecological analysis when applied only to genomic participants (biological species) accepts the genomes as they fit into the formal ecology (the other species and geophysical conditions). The stability (SAR) of the ecological form is analyzed and there are many findings on the role of genomic variety and the mix of interactions (protocols among the genomic types of predation, mutalism and competition). The ecologies we see are the ones that have persisted without design or management. They have self-organized.

The concept of our own society is the same. Yet our governance perpetually wobbles between formal management and unaccountable projects to alter parts. Indeed “regulation” has been ideologically suppressed while “getting things done” has been celebrated and overrides regulations. Current events are illustrative. If we mean SAR then the form of our governance (Constitution) is the essence and must be understood as levels of regulation over interactions that are ruly in terms of SAR. The fallacy is unlimited growth and consumption that produces risk and inequity. That is the threat to us and general ecological SAR. We can read that either in the corruption of our governance or the indifference to ecological damage even to the elimination of its genomic parts.

Where Projects Go Wrong

If my motto is “engineer with complexity” it should be contrasted with the hubris that “we can improve on complexity”. The latter is motivated by having a powerful institution, like the State or a corporation in search of a project that “disrupts” or “improves” what has emerged and would otherwise persist. The institutions themselves are emergent forms and that is the subject of my 2006 paper. The difference between governing the institution and trying to disrupt-by-improvement is visceral to me. It is what I witnessed in the urban destruction by State projects that motivate the LTM work generally. There was no respect for complexity or accountability for the risk and inequity of the projects that destroyed our urban ecology.

The ConOps is a corrective to arrogance and unaccountability. You have to work within an accountable module with its participants. You cannot assume “improvement” absent accountability for the risk and equity of the participants. Clearly this is a lesson for democracy and more generally the ecology once we appreciate all the parts that participate. The fallacy of formal power intruding into the transactions of its contents is just the “transactionalism” we are suffering now.

There is a proper question of whether the rules of interaction (protocols) are properly extensive and adhered to. Much engineering occurs because of the instability introduced by technology. Technology is threat and opportunity, the difference being in how it is accountably applied and that is what the ConOps is about. In a formal transient an architecture may be codified (a task I have worked on) and protocols invented (standards committees). This transient activity should not be confused with the proposition of “it could be better than it is” for a mature and persistent system. That difference is reflected in the “functional orientation” of system engineering. That is embodied in the ConOps: The function is persistent and it is a question of how it can be improved only by accountability to functional risk and interaction with other functions.

In engineering a summary of the wrong approach is “a hammer looking for nails”. This is generally a caveat to technologies applied regardless of risk. This is perhaps the major challenge now, and has been for at least a century. LTM expounds mostly on the automobile technology in the complexity of the urban ecology. The automobile technology literally overrides urban form and accountability. As highway projects it exemplifies just where power abuses the ecology and walks away from the risk and inequity.

The Accountable Urban Module

The idea of urban places or regions as the accountable modules is consistent with how the urban ecology developed (the place modules) and evolved in form over time. Highway projects in my time of fighting them (mostly the 1970’s) agonized over “participation” by the people affected versus the members of the design tasks. It was a basic question of democracy, but that concept was already overridden by the technology and its consumption of urban space.

It is now counterfactual to suppose how our ecology and democracy would have developed and evolved if a true modular-with-rules approach was preserved. I like to think it is what the Constitution intended, because that was an architecture for governance over participatory complexity. It was, however, not cogent enough about what the modules were and how to make them participatory and accountable. It was rather preoccupied with the power of the national State, and we see now how badly that is limited to its proper accountability. It is equally counterfactual to consider what would have happened had the Constitution considered us a complex operational ecology with the modules for a ConOps. But it is worth thinking about now.