The city is a system of systems...

...and council information systems help keep it alive.

From my limited understanding of systems theory, its key foundations were laid by Bertalanffy and others in the 1950s, and Bertalanffy was a biologist. So whilst I'm looking for ways to systematically understand and analyse information systems, there is this wider established systems discipline that applies as well to organisms, human behaviour or, I'm sure, cities as much as computing systems. 

Original systems theory defined an open system as one that draws inputs from and emits outputs to the environment it's in. In this way, it can avoid running down from entropy and keep operating in a steady homeostatic state, reacting to environmental changes. For organisms, inputs are solar energy and specific chemicals, whilst the outputs that are waste for one organism may become inputs to others. For humans, other social animals and computer systems, information can also be input and output. The city qualifies as a system because it sustains itself through time, absorbing energy, resources and information whilst generating physical and cultural outputs. It can also carry on through changes, from daily and seasonal cycles to changing populations, technology and economic fortunes.

If I try to visualise this schematically, two specific structured diagram standards come to mind:

• IDEF0 function modelling method from the 1980s, 
• and the UML-based process modelling approach of Eriksson and Penker from their 2000 book (also supported by Sparx Systems' Enterprise Architect tool). 

I don't know how closely these approaches were based on classic systems theory, but a simple comparison of their core diagram components is below. All three help show that systems are dynamic, with purposeful behaviour that reacts to changes the environment they're in.

Open System	IDEF0 Function	Eriksson Penker Process

So the city is a system, the council is part of that system, and the council's operations depend on its IT systems; the city is a system of systems. But when engineers talk about a system of systems (SoS), they can mean it has specific characteristics. I can't link a definitive list for these - I learnt from a former colleague, Alan R, and others who'd attended INCOSE meetings. They taught me that the key SoS characteristics are:

• The overarching capability or service delivered by the SoS arises from its independent parts working together; the component systems have connecting interfaces to support end-to-end flow.
• Some level of service can be delivered continuously; components can be swapped out and replaced. This is different to a system delivered by a project, which typically has a step-jump in capability when it goes into operational service.
• Parts of the SoS are developed and maintained by different organisations for their own purposes and independent business models; nobody is in complete control.
• A SoS's behaviour and qualities are emergent, and may not be predictable.

I've seen SoS thinking applied to engineering challenges, for example: search and rescue (from distress beacon pickup to coordinated response), critical national infrastructure security, and environmental science missions (combining space and ground-based sensors). But it applies to city services as well (which themselves overlap), for example: 

• Care delivery - by the NHS, private and public facilities, charities and individuals.
• Education - including school transport and addressing special educational needs.
• Transport - traffic operations, street asset and infrastructure maintenance, improving environmental impact and journey times.

So in conclusion, it's worth keeping systems thinking in mind when looking at the council's IT estate. Specifically, a systematic way to capture how things relate in a dynamic system, like Eriksson and Penker's, is worth keeping handy in the modelling and analysis toolbox. Also, when thinking about an information system's environment, it's worth remembering that it's value is from its operating context in a system of systems, with all that implies. That's especially important when a task becomes focused is on specific project's delivery or change programme's goal.