Poverty: A problem of complexity? Poverty is a global problem that affects our civilisation on a large scale. However, what is poverty? This is an important question, since very often the very definition of a problem guides the process of finding solutions and informs the type of the solutions that are considered.
For the problem of poverty, there are many definitions. Very often these definitions tend to focus on income and money.
We have become increasingly aware that we are living in an interconnected and interdependent world. This is generally related back to the field of study of “Complex Systems” and includes terms such as: complex adaptive systems, emergence, chaos, non-equilibrium systems, network effects, and so on.
An interesting formulation that helps to identify, in soft terms, the nature of complex systems is VUCA, that is systems that exhibit the following properties:
In this post we consider the situation of a long running engineering project and see how taking a hypothetical, but explicitly, model driven approach could help to guide the undertaking to completion.
Firstly, what is a “project”?
This may seem like a obvious question, but the definition is important, because all too often in organisations the colloquial understanding is something like:
A project is a catch all for stuff related to that thing that somebody somewhere wants and that is going to need a bunch of people and time.
Monolithic undertakings tend to fail. This may seem like a harsh statement, but there are many ways for systems to fail:
a system could be built that simply doesn’t meet the requirements of the sponsor. a system could logically solve a problem, but exhibits behaviour that is outside of operational tolerance once deployed in a realistic context. a system could simply remain in development indefinitely and never finish. When the “surface area” of the system is large it simply becomes more difficult to avoid all of these failure modes simultaneously.
When taking a model driven approach to software development, one of the problems that arises is that of how to synchronise the model with the reified implementation.
Why is this a problem? Put more bluntly:
How do we know that the final software accurately implements the model.
Providing a bit more context, while software modelling is not new e.g. UML, MDA, EMF and other TLA approaches, we are focusing on using conventional software languages and tools.
Development of large scale distributed systems is complex. Many of our software systems essentially follow this distributed system pattern, and are therefore complex undertakings.
Complexity takes time. It takes time to evolve in nature, and it takes time to introduce in software. Complexity also introduces risk. This risk can generally be sufficiently mitigated with the inclusion of additional complexity so as to reduce the likelihood of systems failures – but then even more time is required.
Resources are limited. This is in many ways one of the defining realisations of our current age. We have limited oil, limited land, limited water etc.
In general system design this is no different. For computationally backed systems we have limited execution cores, limited volatile memory, limited network bandwidth. The realisation for software engineering is that the systems being built can not be built with the mindset of unlimited resource, but rather with the view that resources are bounded.
Systems can be described in terms of their boundaries and the information that passes across those boundaries. But at some point the system needs to perform activities. In the parlance of the ‘actor model’ we might describe the activities as behaviours that are invoked when a message is received.
However, this doesn’t really help one to get a handle on the causal cascade that could be triggered as a result of this message.
One of the challenges when taking a model driven approach to system development is that we naturally create models of varying levels of complexity but then we need to be able to relate one model to another.
That is, not only do we want to be able to evaluate the model against the reified system, but we also want to evaluate models at higher levels of abstraction with those at lower levels of abstraction.
Seeing Systems When we want to change the world, where do we look to make the change? When we want to change our lives, where do we look to make the change? When we want to change ourselves, where do we look to make the change? Time and again we watch movies, read books and come across stories of great battles. The story of the good-versus-evil. The hero who rises up to meet his nemesis and be the victor over his opponent.