One Iceberg Model

Frameworks, models, and their visual representation as diagrams, flows, or any other form of graphics, are common sight when working with a system thinking approach.

I'd like here to try and define the Iceberg Model, mainly with the aim of making few assumptions explicit, and in doing so start defining a grammar of sort.

The iceberg model is a metaphorical representation used to explain complex systems and understand the underlying causes and consequences of certain events or behaviours. The model's premise is that much like an iceberg, the majority of crucial information is hidden beneath the surface, with only a small portion visible above the waterline.

The (core) iceberg model typically consists of four layers:

1. Events
   The tip of the iceberg represents visible events or outcomes that are easily observed and measurable.
2. Patterns
   Just below the surface, patterns represent trends or recurring behaviours that can be identified, typically through observation over a defined period of time.
3. Structures
   Deeper still, structures are the systems' policies, and processes that drive patterns and events.
4. Mental Models
   The deepest and least visible part of the iceberg represents mental models, which are the beliefs, values, and assumptions that shape individual and collective behaviour. Mental models influence how structures are designed, and they can perpetuate or hinder change within an organisation.

I'm with those that have a fifth layer, just below the mental models, and  that is:

5. Vision
 Representing long-term (the definition of long-term varying) aspirations,     values, and goals an organisation is aiming at.

Layers: what, when, how, why

Conscious of the simplification I am about to make, the 4 core layers above represent each a different understanding of a system.

Events

These are the evident manifestations of a system's interaction with a wider system - typically this broader system is where the observation of the event takes place; let's call this containing system environment.

Events are facts, physical or digital, typically evident because of their's changing the status of the environment. Events are a way a system communicate to an external actor a change in status.

Events respond to a what question, such as: "What happened to the car?" [e.g. the engine is smoking].

Once again, events are public and evident from within the environment.

Patterns

If events are by definition public and evident, patterns are still public - they are a collection of events over a period of time or any other (similar) context - but evident only upon analysis.

Patterns is the story events tell when measured, clustered, labeled, ordered within a specific period; patterns expose relationships among events, as well as prompting for a deeper exploration. Careful here, while relations and correlations among events can, typically, be observed through patterns, looking here for causality would be a mistake.

Patterns respond to a when question, like: "When started smoking the car?" [e.g. after less than 24hrs after the rent started].

Patterns are public but not evident.

Structures

People, processes, technology, and the way these elements (and others) interact and communicate, as well as the rules governing these relationships, are what structures are made of.

Here is where you look at the mechanics of the system, here is where we look for responses to the how question, as in: "How did the smoke started?" [e.g. from the lack of refrigerating liquid due to the water tank leaking all of its content].

Structures tend to be not evident although they can be public.

Mental Models

Structures are man made (for the type of systems we are interested in), are man run, used, or abused. Mental models is the way those who defined the structures see the environment, their understanding of the environment, that is their interpretations of the aim of the system, is what defines the design of the structures.

Mental models respond to the why question, as in: "Why we let the the water tank leak?" [e.g. we thought cutting on vehicles maintenance was also cutting costs].

Mental models are not public nor evident.

The role of the vision

Finally the fifth layer, the vision. This can be seen as the culture of the organisation, or social group; this is the "environment" where mental models are nurtured and reinforced.

To continue with our example, the vision is what reinforced a costs cutting culture that somehow sponsored cuts in the maintenance of the vehicles for our imaginary car rental company.

It starts with a reaction

The acknowledgment of an event is, similar to the symptoms of a condition or disease, the manifestation of a change in the system affecting the environment we live in.

We may intervene to address the immediacy imposed by the event, as in stopping the car to prevent the engine to burn; this would be an urgent action useful if your aim is taking care of that specific event, or even that single instance only of that type of events.

"Fixing" an event is limited to the event itself and the system component(s) strictly and directly affected, or involved. It's about zooming in at event and component (of a system) level - this is usually about restoring in the environment a pre-event status, as well as (mechanically) correct the affected components what the aim of preventing the event to repeat/produce an undesired outcome.

An event is the starting point to get below the line and look around, starting by investigating events within a defined time frame, the query and the resulting clustering is what the patterns level is: a virtual layer on-demand built to respond to a query.

We use patterns to expose what's beneath, the network of relations between the components of the system, the rules and mechanics governing it. The structures level give us access to the map of the system, the more detailed depending on the relevance of the discovered patterns.

To see what's the view of the world of the people that built the territory we mapped at the structures level, we need to get one level down to the mental models layer. Here is where our investigation finally gets to understanding why the system is designed the way it is.

Finally, the vision is where to look for the culture supporting (reinforcing) the mental models we previously exposed.

Now it shouldn't be counterintuitive that the path to enlightenment is a journey deep down into the inner core of a system. In this sense, the Iceberg Model can be seen (and used) as one of  the tools facilitating the exploration of a system.

Sense of the exploration

The movement of the exploration, using the Iceberg Model, is top to bottom from Events to Mental Models (Vision).

To move down the layers, you may find helpful thinking about the questions each layers respond to, these are the questions you should use to move down into the system.

• What happened? - Events
• When is this happening? - Patterns
• How does it work to make it happen? - Structures
• Why it has been made the way it's done? - Mental Models

You can compare the mental models against the vision, and what would you expect to find is a culture that supports those mental models. (1)

• What's the culture supporting it? - Vision

Think of it as a revised Five whys method (大野耐一, Ōno Taiichi), where the whys have become what? when? how? why? - it's not the same thing as root cause analysis, but it's not that alien to the concept either.

Action!

Now an interesting propriety of this particular iceberg is its ability to turn upside down, this is the way we should look at it if our goal is not exploration as instead is about acting on the system.

By acting I'm generically referring to any intervention on the system, from changing the structure, to

For simplicity, here we assume the system's being an organisation such as a private company.

The environment, again a starting point

Starting from where we left off in the exploration phase, we work with the key stakeholders for the definition of the organisation vision, and culture.
What is their understanding and point of view of the environment (e.g. the market they operate in)? Where does it stand the vision, compared to the above understanding? How is it communicated? What's the organisation understanding of the vision? What kind of culture(s) is in place?

In this moment it's strategy level, it's about (sometimes) redefining the vision of an organisation, it's about (re)stating the defining proprieties of an organisation. Here we are in the C-suite (2).

Moving to mental models means shaping the organisation in a way that supports the vision by design; the system (re)design is made here. We are opening the C-suite to a wider audience here, including those in charge with the system's running. (3)

In this moment we are designing the map through the definition of the relationships and the rules of interaction between components of the system,

We are now moving out of the C-suite and onto the floor, we are now down at structures where we work with the interfaces, the actors, the language. This is where we talk about tools and processes, and the people using the tools or part of the processes. (4)

At this point what we are doing is building the pieces, and making the connections we need for our system to work. Here is also where roles are assigned.

Now that we reached the patterns level, our interest is in the flows of information and in connecting all pieces to the network so to enable that flow; this is done (also) by designing pre-defined flows based on known events impacting the system (such as external input from the environment). (5)

... and thence we came forth to see again the stars

Finally we are back out there, in the environment, looking for events. And observing them, and look at the environment for changes and going back at some point in our iceberg and re-tune it again.

In this interpretation of how the Iceberg Model works for me, not saying it is academically correct neither I'm pretending to be particularly original, what I notice is the role of the environment, which is there at three crucial moments in the process I described above.

(events) Environment > Environment (vision) > Environment (events)

A linear journey from the top of the iceberg to the bottom, and back to the top again.

The environment is crucial because, quoting R.L. Ackoff, "(...) the explanation always lies outside [of a system]" - that is, only in understanding the broader (containing) system we are able to see the implications.

The environment here is the same observation point recommended by human-centric design methodologies; understanding the impact of a product or a service on a consumer, or user of as system, and designing/re-designing/tuning accordingly is exactly this.

The motto "The customer is always right" - today stashed below layers of support channels - should be interpreted as an invitation to dig deeper into the meaning of a customer reaction, and not (solely) as a cost efficient and fast problem fixing exercise. The problem (the customer complaining to the call center operator) is just an event.

 - - -

(1). simplifying; let's pretend this is the natural outcome expected.
(2). figuratively; we are purposely not saying anything about who's in that C-suite.
(3). again, we are not talking about what roles nor about their type of involvement.
(4). we are not saying people are defined and considered within the boundaries of the tools they are using or the processes they are part of.
(5). not advocating for it; not central to the point discussed here.