Do you know your system’s hierarchy of needs?
If you’ve ever been on any kind of management course, you’ve probably encountered Maslow’s hierarchy of needs. Defined by Abraham Maslow in 1943, this theory proposes that humans needs can be broadly classified into a hierarchy, with basic physiological needs such as air, water and food at the base, and more exalted needs such as self-actualisation at the summit. (The exact order goes: physiological; safety; love and belonging; esteem; self-actualisation. Maslow also added transcendence to the top of the hierarchy in later versions.)
The idea is that humans don’t care much about higher needs if more basic needs have not yet been satisfied. In a management context, this means that there’s little point in trying to motivate someone by holding out wonderful long term career prospects (self-actualisation needs) if you’re not paying them enough to eat (physiological needs). At the same time, if you have helped people meet the basic needs of survival and safety, you shouldn’t expect them to be content: you should expect them to seek satisfaction of the higher needs.
We remember Maslow’s hierarchy of needs from our management training because it is simple, easy to understand, intuitively right and useful. It’s a straightforward mental model which helps us to understand human behaviour and motivation.
Computer systems don’t count as people (yet), but I believe that systems have a similar hierarchy of needs.
The analogy is most obvious at the bottom of the hierarchy. Systems have physiological needs, but they take the form of compute, storage and networking resources, rather than air, food and water. Similarly, safety is analogous to security: systems are subject to threats, just as we are (indeed, we might say that, just as the environment has generally grown safer over time for human beings, it is growing more dangerous over time for computer systems).
The analogy might seem more difficult to follow at the higher levels of the hierarchy. Is it accurate to talk about love and belonging, esteem and self-actualisation for computer systems, in the same way that we talk about those needs for people?
I believe that there are analogous concepts which work at the higher levels of the hierarchy. If you’re an architect in a large organisation, you probably have some kind of application repository, and you probably categorise applications according to your plans for them: are they targets for strategic investment, or are they targets for retirement or decommissioning? When you apply this categorisation, are you not expressing something akin to love and belonging? Similarly, we regularly choose which systems to invest in, and investment choices can be seen as an expression of esteem. Finally, we don’t build systems for the sake of having systems: we build them because we believe that they have a purpose and value. Attainment of that purpose and value may be seen as a form of actualisation.
So, we might create a hierarchy of needs for computer systems which goes something like this: resource and capacity; security; architectural role; investment; purpose and value.
Indeed, I believe that, not only do the higher levels of this hierarchy apply to computer systems, but that one of the ways we often go wrong in technology architecture is by focusing on these higher levels too early.
New humans may be a product of love and esteem, but it’s pretty obvious pretty early that their first and most important needs are physiological (and they will tell us if those needs aren’t met), and our next instincts are to provide security and safety. It takes some time before new humans have the time or capability to worry about esteem and self-actualisation.
By contrast, when we initially make the case for a new computer system, we usually start with the purpose and value of that system. This is a good thing: unlike humans, it is hard to make the case that computer systems have value in themselves. They are there to do a job.
However, when we come to design the system, we often focus on purpose and value to the detriment of more basic needs.
This is a recognisable anti-pattern in systems development: to give priority to functional requirements without paying sufficient attention to non-functional requirements. But, despite it being a well known anti-pattern, architects, designers and product managers make this mistake again and again.
The idea of the computer system hierarchy of needs may help correct this anti-pattern in two ways. First, while it doesn’t change the work that needs to be done, it does remind us that the most basic needs must be met first: if you have not given your system the resources it needs to run, and have not made sure that it is secure, then its purpose and value will not be realised (at best) and may be subverted by attackers (at worst).
Second, it reminds us that our job as technology architects is not just to satisfy the needs of individual systems, but to create an environment in which those needs can be satisfied. Those of fortunate enough to live securely in stable, developed economies enjoy a world in which our physiological and safety needs are not met by hunting or gathering, building shelter or defending ourselves: the conditions under which they can be met are created by society, by laws, and by economic activity. Of course, no matter how ambitious technology architects are, we can’t create the whole world; but through automation, standards, tools and increasingly through the adoption of platform technologies such as Cloud, we can create a world in which the most basic needs of our systems can be met more easily.
Technology architects often spend their time navigating between needs and wants: we often have to figure out the difference between what our sponsors and customers need, and what they want. We should pay just as much attention to what our systems truly need.
