Category: Learning

Problematic Process Change in the Kitchen – from CMO to FMO

How many process sequences do you think you have stored in your mind? There are many things that each of us does without consciously thinking about it because they are stored procedures that most of us don’t think through step-by-step, we just do them. Some of these processes are so embedded, for me, that I would struggle to articulate what the steps were. For most of us our brains do a fabulous job of storing these things away in our subconscious so that we don’t have to think about them each time we do them.

What are the steps involved in leaving the house? What are the decisions that I am making as I do it? Am I checking that everything is locked, or is someone else still in the house? What don’t I check because I already, subconsciously, know the answer? Have I picked up that thing that I left by the door, so I didn’t forget it?

I hadn’t really given much to this time thought until recently when my normal processes have been disturbed by the installation of a new kitchen. Who would have thought that the refactoring of a single room (or two, I’ll explain later) would impact so many different things?

It’s like the house has had half of its operating manual ripped-up and rewritten.

Let me give you some context. Yes, we’ve had a new kitchen fitted, but that simple statement hides several factors that would be useful for you to know:

  • We used to have a kitchen and a utility, now we only have a kitchen that incorporates the space that used to include the utility.
  • We have moved the oven from one end of the room to the other end.
  • The washing machine that used to be in the utility has moved into a different space in the new room.
  • Nothing is in a cupboard where it used to be – cutlery, crockery, spices, pans, glasses, mugs, utensils everything is now somewhere different.
  • For three weeks we used a makeshift kitchen was in the garage.
  • There is still one vital appliance that is in the garage because of supply issues on its replacement (Brexit? COVID? Who knows?) – this is the fridge.
  • We no longer have a kettle; we have a tap that issues us with boiling water. More about that later.
  • The new layout makes much more sense than the old one – it’s unquestionably better.

I’m involved in process change as part of my job and we regularly have conversations about CMO (Current Model of Operation), TMO (Transitionary Model of Operation) and FMO (Future Model of Operation). We often talk about these different modes as a continuum with each change only impacting a small part of a process, and a few people.

Thinking back through my kitchen experience I’ve had some new insights into how people respond to change. The move out of the kitchen into the garage was one change, the move back into the new kitchen was another change, both changes required us to adapt how we did things. Note that neither change is yet fully completed.

During the TMO (Garage) nothing felt comfortable because it wasn’t better, it was worse. We embraced this time because we knew that something better was coming. We were a little nervous of the new world, but we had chosen that future and were excited to see what it would bring. There are many times when we are expecting people to embrace a change which places them into a worse position for a period of time on the promise that things will get better. Often. though, they haven’t been a part of designing the future world, they don’t have a nervous excitement.

Even the FMO (New Kitchen) didn’t feel comfortable immediately, there are parts of it that still feel uncomfortable. We are in control of much of those new operating procedures though and will make it work for us. Part of the reason that we haven’t fully settled in is because we are still going out to the garage for refrigerated items. That one simple issue is significantly more jarring than the extra nine steps out into the garage would suggest. We are expecting a new future and see it tantalisingly close, and yet, we can’t attain it. There isn’t anything I can do to expedite the delivery of the fridge and that sense of helplessness is remarkably stressful.

It’s not surprising that in a world where people have continuous change thrust upon them that they don’t always embrace it with delight. This is particularly true when the future that they are being asked to adopt isn’t one that they have chosen. Autonomy and mastery are important aspects of people’s motivation, yet we constantly take these away from people as we drive standardisation of tools and processes for an opaque greater good.

Next time: Problematic Process Change in the Kitchen – Rewiring the Stored Procedures

Header Image: This is the view approaching the slightly strangely name The Cage at Lyme Park in Cheshire. Its name, apparently, comes from its use as a holding prison for poachers, I think I would have found a new name for it if I owned it. It just goes to show how difficult change can be.😉

Office Speak: Snowflake

Here’s a word that’s been used in so many different contexts that its primary meaning is in danger of becoming secondary. The characteristics of a physical snowflake – unique, delicate, brittle, intricate, etc. – have made it the go-to metaphoric label for all sorts of things many, probably mostly, negative.

Snowflake as office speak is highlighting those same characteristics but primarily focussed on uniqueness:

  • “This is going to end up as a snowflake server” = “that server is going to be a one-off”
  • “What they are designing is a snowflake solution” = “that solution is going to be a unique design”

Like it’s usage in other contexts the snowflake label isn’t, generally, a positive thing and is often used as a derogatory label. This is certainly true in my own work context of IT solutions.

(This post is not about snowflake the data platform, if that’s what you were expecting.)

The term snowflake was first used to describe IT servers in the book The Visible Ops Handbook which was published in 2005, so this isn’t a new idea. It’s also not the only metaphor that people have used for this phenomena, another popular one is the idea of cattle v pets. This is how Martin Fowler describes the idea:

it can be finicky business to keep a production server running. you have to ensure the operating system and any other dependent software is properly patched to keep it up to date. hosted applications need to be upgraded regularly. configuration changes are regularly needed to tweak the environment so that it runs efficiently and communicates properly with other systems. this requires some mix of command-line invocations, jumping between gui screens, and editing text files.

the result is a unique snowflake – good for a ski resort, bad for a data center.

Martin Fowler: Snowflake Servers – DZone DevOps

From this initial scope the label has moved beyond servers to all areas of technology. It’s become so ubiquitous that it’s reaching a point of concept entropy.

I work within a product focussed organisation and success, for us, is partially measured by people deploying and using our product as it was designed. What we do is quite complex, there are hundreds of ways of doing similar things, so we constrain what people do to reduce the complexity. What we don’t want are thousands of things that are similar, but different, snowflakes. From this standardisation mindset a snowflake is a problem, it requires extra work, and not just when it’s deployed, for the whole of its life it will be a special case. Operational teams want things to be in a “known good” state, they desire uniformity even if standardisation is suboptimal.

There was a time when people would just call something like this “non-standard”, or “unique”, but the snowflake label appears to have overtaken that.

In reality, though, difference is not only good, it’s essential. The trick is to have uniqueness where it adds value, and to standardise where it doesn’t. Standardisation is great at reducing cost, but it can also significantly reduce value if it’s incorrectly applied. The real value in standardisation, done well, is in removing the nugatory effort that is so prevalent in many organisations, releasing people to focus on the value adding uniqueness.

As a rule, I’m not a fan of labels. Labels have a habit of sticking around long beyond their usefulness. Even when they are removed they often leave behind a sticky residue. I see the same happening with the snowflake label.

I do regard it as a bit of a shame that we have chosen to use one of nature’s spectacularly intricate and beautiful phenomena and turn it into a negative label. Snowflakes are amazing, and not just at the ski resort.

Header Image: This is Buttermere looking back towards Buttermere village on one of those still autumnal days.

“In the universe, there are things that are known, and things that are unknown, and…

“In the universe, there are things that are known, and things that are unknown, and in between, there are doors.”

William Blake

Header Image: This is a view from near Jenny Brown’s point in Silverdale, not far from Walduck’s Wall. It seemed an appropriate picture for the quote, this area always feels like a place if discovery to me.

“Great things are done by a series of small things…

“Great things are done by a series of small things brought together.”

Vincent Van Gogh

Header Image: Enjoying a beautiful autumnal walk along the shores of Derwentwater. Putting several small things together, covering a lot of ground and being rewarded with glorious views.

I’m Wrong (again) – Time to Learn (again)

On several occasions, in recent days, I’ve come to the realisation that something I’ve been taught was wrong.

Take this most recent scenario:

A former colleague retweets this post:

Being of sound mind, I decide to check it out.

Can this be true?

For those of you who haven’t managed to make the link Tuckman Theory is the model for teams that goes through the Forming, Storming, Norming, Performing phases (F.S.N.P.). From experience the whole F.S.N.P. thing appears to work for many of the teams that I’ve been involved in. Teams spend a whole heap of time at the beginning trying to work out who they are, why they exist, and how they are going to work together. Those same teams eventually get to a place where they are highly productive (sometimes).

Time to do a bit of digging into the research. It didn’t take long to find reliable evidence that F.S.N.P isn’t a great model for how teams come together. Bother. I’m wrong. I don’t like being wrong.

How am I going to cope with this news? How am I going to respond?

I suppose I could look to the Kubler-Ross Model with its five-stages of grief. Surely that’s safe? Apparently not, there doesn’t appear to be any evidence for the five-stages either. Bother, bother, I’m wrong, again.

This post isn’t about F.S.N.P., or Kubler-Ross, it isn’t even a post about how all models are wrong, it’s a post about the process of changing our understanding.

How am I supposed to process these, and many other, changes to long held understanding? How do I even know what needs to change, or what to change them to?

Perhaps the easiest thing to do is to ignore the new evidence when it comes up and carry on as if nothing has changed. At one level Kubler-Ross hasn’t had that big an impact on my life, but how would I know? It may have influenced the way that I’ve behaved in situations where a different approach may have resulted in a different outcome. What if this wrong thinking has closed a door that would have stayed open had I approached it in a different way? Every one of these models sit amongst a web of other understanding, they aren’t self-contained boxes of knowledge they each interact with all the others. What if F.S.N.P. together with another untruth create in me an understanding that is outright dangerous?

Ignoring the problem doesn’t sit well with my deep need for truth. Even if it requires work and even if the impact is small, I still need to change my understanding.

This is where it gets a bit tricky, because, as we’ve already seen, I’ve been burnt before. How do I choose a model for change that will work, and is correct? How far do I have to go to convince myself that I’m not just replacing one falsehood with another? What benchmark does the new way of thinking need to reach to be accepted as truth?

There are, as you might imagine, several models for change.

In healthcare there’s the Transtheoretical model (TTM) which talks about six stages of change – precontemplation, contemplation, preparation, action, maintenance, relapse. It accompanies these stages with a defined ten step process for change that includes self-reevaluation, self-liberation and counterconditioning amongst other word gymnastics. TTM does show good results in some areas of behavioural change, but it also has areas where it would appear to be less than effective. Also, I’m not really contemplating outright behavioural change here, I’m wanting to replace one model of understanding with a different one.

Maybe a different field of thought has an answer for me? Change Management? Here we find the Lewin model of unfreezing, changing and refreezing, and John Kotter’s 8 step process, the Proci ADKAR model and many more. These models aren’t that helpful either, they are focussed on organisational change and that’s not what I am wanting to do either.

Perhaps I’m looking in completely the wrong place by thinking about this as change when what I am actually talking about is learning. Understanding how we learn ought to be simpler, didn’t it? Or maybe not, it turns out that theories of learning abound – behaviourism, cognitivism, constructivism, transformative, geographical…

I quite like the idea of constructivism which highlights that we learn by building on to what we already know. We understand new things in the framework of what we already understand – we get to understand algebra through an understanding of basic maths, people who learn a second language can often add a third and fourth relatively easily.

Thinking about constructivism became a bit of a light-bulb moment for me. I’d been approaching my untruths as if they were a problem, which they are, but not the problem I thought they were. I thought that what I needed to do was to get rid of the bad models so that I could replace them with good models. What constructivism allowed me to see was that bad models were gateways to better models. As an example, understanding the Tuckman F.S.N.P. model helps with understanding the variant DAU model. What’s more, understanding the problems with the Tuckman model allows me to critically assess the DAU model and decide whether it’s a better way of talking about team dynamics in the future.

Anyway, I’m off to talk to some people and hopefully I’ll learn something.

PS: One thing I have learned and that’s to be cautious of all models that propose phases of human behaviour which appear to be fraught with dangers. Humans clearly don’t work in phases, which isn’t surprising, we aren’t machines, we are unique highly complex biological organisms. Whatever makes us think that we can simplify our behaviour down to a series of steps especially with something so personal as grief?

PPS: For everyone who’s mind drifted off into thinking about different styles of learning while reading this – that’s also wrong, probably, there’s certainly no evidence for it.

Header Image: The days are starting to get longer around here and my morning walk in the dark is transitioning to be a morning walk in the midst of a sunrise.

A Year in Review – 2021 on grahamchastney.com

There are several ways of doing a review for a year.

I suppose I could talk about the statistics, but that seems a bit dull, just because something is popular doesn’t mean that it was any good.

If I were to do a review by the visitor numbers, I would tell you that the top three posts this year are:

As these were all posts from previous years it may suggest that I haven’t been writing this year, which I have.

The other way of looking at the last year might be to look at the posts that I’ve written and to comment on those.

Perhaps I could talk about the distinct types of post. I’ve written a few “I’m reading…” pieces, but only three. This again might suggest that I’ve only read three books this year which wouldn’t be true (that’s only counting the new books, I’ve also reread some). I tend to write these review type posts when I have something personal to say. There are so many great reviewers around that these books don’t need another one, what I try to bring is my voice.

It was fun writing about these books:

There are also the “Office Speak” posts which make me smile and provoke some of the best reactions. I hope no-one takes them too seriously.

I suppose I could talk about the where I felt provoked to write something. I particularly liked these ones:

There is one post, though, that will stand out for many years to come and that’s because it marked the end of an era for me. I’ve had a goal for several years to complete a set of mountain walks and this year I did:

This post doesn’t describe all the significance of achieving the goal, or the changes it’s made in me along the way. What it does do is give me something to look back on and remind myself that “I did that”.

Thank you for being with me on the journey.

Header Image: I’m writing this on the shortest day of the year so thought it was fitting to have a sunrise picture from my local morning walk. I’ve taken this same picture for a few years now – #fromthefencepost – it’s amazing to see the different weather and changing seasons.

Out of Office & Decline All Meetings – using Viva Insights

One of the most popular posts on this site is one that described how to set an out-of-office and decline all your meeting while you are away from the screen using Outlook on the Web.

I’m really pleased with how popular this post is because I’m encouraged that people are taking the appropriate hygiene actions to protect their time away.

The challenge with the original method, for many, is that it was only available in Outlook on the Web, and not within people’s desktop Outlook where much of the world’s email is still processed.

That has all changed recently with Viva Insights now having the Out of Office and Decline All Meetings capabilities.

Viva Insights

If you open Viva Insights, you are likely to see an option to Plan your time away I’ve also seen it show a slightly different widget called Time away:

Plan your time away
Time away

Once you open this widget you are taken through a step-by-step process to schedule time off, clear out your calendar and inform collaborators.

The first step is to schedule your time away, which you need to do before you can move to the next step:

Select dates

Once you have selected the dates you then have a set of actions available:

Time away options

The various actions work as follows:

  • Set automatic replies – this is the good old out-of-office message.
  • Notify collaborators – creates a meeting notice to tell co-workers that you are away. The widget suggests a list of collaborators based on who you regularly communicate with.
  • Resolve meetings – gives you the option to cancel meetings throughout your time away. I love that feeling as your calendar empties.
  • Book time to focus – encourages you to book additional time to focus before you leave and when you return:
Book time to focus

A bit more information over on the Microsoft Viva site.

The only small complaint that I have is that Viva Insights doesn’t respect my local device date format, being British I don’t think in month-day. (Having said that I’ve always been puzzled why anyone thinks that month-day-year is a sensible order 😉.)

Time away is an important part of a productive life, it’s not an optional extra. We need to be intentional about protecting that time away and I’m hoping that even more people will use the tools available to them.

Header Image: Shortly after sunrise over Derwentwater. This is the view from the top of Latrigg on a frosty Autumnal morning looking out towards Derwentwater and down through Borrowdale.

I’m reading…”Team Topologies: Organising Business and Technology Teams for Fast Flow” by Matthew Skelton and Manuel Pais

There are a set of books that I have recommended to people more than any other. I’m a technical leader, but these books aren’t technical, they are all about designing and building teams.

The top three in this collection of books are:

I’m now pondering whether I should start with a different book – Team Topologies. It’s not that Team Topologies says anything different to the three books above, the readers of The Mythical Man Month, Peopleware and Drive will see a lot that they recognise in this book. What Team Topologies does is summarise many of the findings of these books into practical applicable structures, linking them to models and practices that others have found useful.

The basis of this book is a simple question based on Conway’s Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Melvin E. Conway

In other words, your systems will reflect your people structures.

The question that Team Topologies asks is this – if you reverse Conway’s Law does it work the other way around?

In Graham’s overly simplistic phrasing – if you design your people structures will you get the systems that you want?

Spoiler alert: Yes, you will.

What are those people structures? That’s the bulk of the document in which Skelton and Pais outline Team First Thinking, Four Fundamental Team Types and Three Essential Team Interaction Models.

That’s pretty much where I’m going to stop the review of the book because I don’t want to rewrite the book, nor do I want to oversimplify what they have written. This book isn’t a long read after all, it’s only 185 pages without references, etc. If you want a summary, then this graphic is a good place to begin: Team Topologies in a nutshell.

What I will say is this though, this is a book of principles and concepts, types and models, it doesn’t contain team blueprints or a team design handbook. It’s not a Haynes Manual for teams and that’s a good thing. People aren’t components and teams aren’t vehicles.

Whilst there are types of teams, each team needs to be designed in its own way because each team is different. The people within a team make it unique and the context in which that team works makes it unique. The words model and type are there to tell us that these aren’t prescriptions. Prescribing a structure to a team is a folly that will probably cause more damage than good. Looking at a team structure through the lens of a model or a type may give insights into the frustrations that a team is experiencing and from that the next iteration of a team design will emerge, but that’s different to a team blueprint or a business process reorganisation.

We’ve learnt how to do iterative design for technical systems, it’s time that we applied that same design approach to the teams that build those technical systems. What Team Topologies tells us is that this Team First approach may have even greater rewards than the effort we spend designing the technical systems.

Header Image: This is Watendlath Tarn on a beautiful frosty autumnal day. My father-in-law was born in a house just to the left of this picture.

I’m reading…”Human kind” by Rutger Bregman


I like to challenge my way of thinking about things.

We each see the world through a complex lens of learning and experiences, some of the learning has been conscious, but so much of it has been absorbed through the subconscious as we go about our day-to-day activities. As an example, I have grown up with the understanding that keeping up with the news is a good thing to do, I happen to read the same paper that my parents do, I tell myself that it’s because it does a reasonably good job of reflecting a correct worldview, but what if it’s the other way around? What if this brand of newspaper is defining my worldview? Take the idea of “keeping with the news”, why is that important to me and is it truly important? What if reading the news regularly is doing me harm?

Human kind is a book that challenges several Western European worldviews – including reading the news on a regular basis. The news isn’t its main target though, that is veneer theory and the underlying assumption that we are all innately selfish, only interested in personal gain and it’s only the veneer of society that is stopping us sliding into anarchy.

The book is based on the difference in thinking between two philosophers – Thomas Hobbes and Jean-Jacques Rousseau. This isn’t the first book to look at these conflicted philosophies, this is a debate that’s been going on for a long time.

Hobbes, to massively oversimplify, believed that people are basically “solitary, poor, nasty, brutish and short”.

Rousseau believed that “People in their natural state are basically good. But this natural innocence, however, is corrupted by the evils of society”.

The Hobbesian argument is characterised by the novel Lord of the Flies which many of us, across western society, read and studied as children. It’s the story of a group of boys stranded on an island and the tragedy that follows. Through it we take in the Hobbesian viewpoint and adopt it as fact. This is the viewpoint that tends to dominate in Western cultures. In Human kind, Bregman investigates whether Lord of the Flies portrays the reality of what would happen by searching for a real-life example of boys stranded on an island, this he finds, and the outcome, it’s fair to say, is more Rousseau than Hobbes.

There are numerous other examples of experiments being undertaken to prove the Hobbesian perspective. Like many books of its type, Bergman, in Human kind, reviews each of these experiments and finds many of them to be wanting.

This book tells stories of television shows that are set up for dramatic conflict that are so full of collaboration that they a dull in the extreme.

There are experiments where people are supposed to have behaved like savages, naturally, where the reality was riddled with manipulation.

The Norwegian Prison system is used as an anti-pattern for most Western incarceration institutions.

There’s a fabulous story of a community peacefully subverting a march by fascists in their town, rather than engaging in the annual fight.

Therein lies the big question of this book. We treat people from a worldview, one that has been influenced by repeated affirmation, by literature, by science, a worldview that tells us that people are out to get whatever they can get for themselves. What if that worldview is wrong? What difference would it make if the opposite worldview was correct and people are generally decent, corrupted, but decent?

Sadly, we are fixated with the negative. Near the end of the book Bregman quotes Richard Curtis, film producer:

If you make a film, about a man kidnapping a woman and chaining her to a radiator for five years – something that has happened probably once in the whole of human history – it’s called a searingly realistic analysis of society. But if I make a film like Love Actually, which is about people falling in love, and there are about a million people falling in love in Britain today, it’s called a sentimental presentation of an unrealistic world.

Richard Curtis

What difference would it make to our world if we stopped spending so much time pushing people away, treating them as potential kidnappers and instead embraced them?

Imagine the impact if our default position was compassion rather than suspicion?

Bergman finishes the book with 10 Rules to Live By of which number 1 is “when in doubt assume the best” and number 7 is “avoid the news” 😉

Throughout this book Berman refers to his upbringing as a preacher’s kid and has a good deal to say about the prevalent Christian worldview, and, in several places, the words of Jesus. Speaking as a Christian, it led me to ponder how much of what I believe is more influenced by Hobbes than by Jesus. Time to do a bit more reading while asking different questions.

If you want to find out more, Bregman’s interview with Daniel Pink is a great listen:


Header Image: The autumn leaves have been fabulous this year. This is a place called Wood Close, just off the Coffin Trail near to Grasmere.

Office Speak: Single Source of Truth – Gold Source: Where do you go to find the correct information? What does Conway’s Law teach us?

Getting data is one thing, getting good information is another. Good information is vital to decision making but most organisations are riddled with bad information.

There is a whole myriad of ways in which information can be bad, it can be out-of-date, inaccessible or difficult to access, incomplete, duplicated or just wrong.

What people want is one place where they know the information is good – that is what a Gold Source is, also known as a Single Source of Truth.

(This is one of those phrases where people don’t seem to have settled on an acronym, thankfully. Perhaps it’s because the acronym is a bit of a mouthful, however you say it, S.S.O.T. or S. SOT, or even SSOT? Perhaps that’s why people also use Gold Source😀)

A Single Source of Truth should be simple enough to achieve, shouldn’t it? Surely? It’s what everyone wants after all? Not in my experience.

There is a common pattern in IT systems that goes something like this:

  • Team A creates a data store for something with the data they have in it.
  • Team B creates a data store for the same type of thing but with similar, but different data. They talked to Team A about adding the data to their store, but Team A would have taken too long to do what they needed so they created their own. 😃
  • Team C creates a data store for the same thing, again with similarities to the other two but using a different technology because the technology Team A used is far too expensive for what they need.
  • Corporate IT finds out about the three data stores, so sets up a project to create a Single Source of Truth for the information and does so by creating another data store using “enterprise class” technology and a data warehouse. This synchronises data from the other three systems. 🤦‍♂️
  • The Corporate IT system doesn’t do what Team D requires so they set up another data store using a different technology.
  • Team E takes a daily extract of the data from the Corporate IT system and load it into a spreadsheets and links it with an extract of the data from Team D’s data store. They use the workbook for reporting, except when Mary is on holiday because no-one else knows how to do what Mary does. 🤦‍♀️

I could continue but I think you’ve got the trajectory by now.

As technologists, the answer to this problem is, of course, more technology (and more acronyms). There are four common patterns for trying to resolve this problem (with Graham’s overly simple descriptions):

  • Enterprise Service Bus (ESB) – link the systems together via another system.
  • Master Data Management (MDM) – create a system for the data that links the other systems together.
  • Data Warehouse – put all of the data into a big bucket then sort it out.
  • Service Oriented Architecture (SOA) – build the systems in a way that allows other systems to use them.

What we as technologists miss is that the primary reasons for the creation of multiple data sources aren’t technology ones, they are organisational ones, or more specifically, they are communication ones.

Conway’s Law gives a great frame-working for understanding why this might be:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Melvin E. Conway

Using our example to explain, different teams create separate system because their communication structures are different, and those separate systems have different data stores. Whether it knows it or not, the organisation is designed to preclude the creation of a Gold Source.

Fortunately, a Single Source of Truth isn’t always that the right answer anyway. Going back to our example, the approach taken by each team is the right answer from that team’s perspective, and their perspective may be right for the whole business. Each team has undertaken an approach that gives them a significant advantage – autonomy. The rate of change that can be implemented across the disparate systems is much higher than could be achieved by the one system being used by everyone. When systems are used by multiple teams they move at the pace of the slowest team (at best). Coordinating across teams requires a lot of effort and a lot of thinking. There is, however, duplication between the various systems, but perhaps that’s a price worth paying for the increased velocity that autonomy gives.

There are some things for which businesses need a Single Source of Truth, but they aren’t as many as people think.

Header Image: This is Alcock Tarn which sits above Grasmere in the Lake District. It’s a great place to sit and watch the weather go by.

What is the R value in your organisation?

Over recent months many of us have become accustomed to politicians and scientists telling us about the R value for COVID-19.

A thought occurred to me today, what if we defined the R value for various aspects of business life.

What would the R value for email in you place of work tell you?

How about an R value for meetings? Imagine an R value of greater than 1 for meetings, would that be a good thing?

Would the overall R value for interactions during project start-up be helpful? Would a low R value indicate that your start-up has a problem?

What would an overall R value of less than 1 for interactions tell you about employee engagement?

What if an enterprise-social-media platform displayed the R value for a thread? Would you avoid threads with a high R value?

Does the same question apply to our use of technology in our personal lives? What would your R value be for Facebook comments?

Just pondering.

Header Image: Taking in the view after a late summer swim at Loughrigg Tarn.

The Four Ages of Solution Constraint

Solution Architecture is fundamentally the management of constraints. The ultimate constraints are the ones faced by all projects – time and money. Within the sphere of business technology these constraints have manifest themselves in different ways over the years. As each constraint gets solved the need to manage a particular constraint recedes into the background and other constraints comes forward. Managing a constraint that no longer needs management is not only wasteful, but it also takes our attention away from controlling the new opportunity.

Looking back, I think I’ve lived through four major ages of solution constraint, most organisations have moved from one to the next, but there are many pockets of organisations where people are still managing the constraints of an age long passed.

Age 1: The Hardware Constrained Age

Early in my career I helped a team of people who provided personal computing devices. This service was only offered to a select group who had excessively big budgets. I remember debating with a colleague why anyone would need 20 Megabyte of storage, no one had a budget big enough to buy a Gigabyte of anything, and even if they could there weren’t any systems capable of making that amount of storage available.

I remember being amazed by the capabilities of the very first Macintosh that I saw which I suspect was a 128 Kilobyte version, there weren’t many people that could afford the 512 Kilobyte model.

Where I worked people were doing serious engineering work on MicroVAX 3100 models which had a mind blowing 32MB of memory in them with teams sharing processors that sped along at 25MHz.

Hardware was so expensive that everything had to be built to fit into the footprint that could be afforded.

Solution design was quite straightforward, pick the right hardware for the task at hand, optimise things as much as you could and hopefully, you’d get something that would do the required work in a night. There wasn’t any point in designing too much into the systems because there wasn’t enough hardware available to do anything fancy. Most hardware had one job to do, because that’s all it could do.

Picking the right hardware wasn’t as simple as it might sound today, there was a lot of different hardware to choose from, each UNIX variant was built for specific hardware, each vendor had their own proprietary hardware and operating system. You tended to purchase all the hardware from the same vendor because if you didn’t the integration was your job, and that was a risky business strategy. Evaluating the performance of several types of hardware was serious work that required detailed technical skills.

Age 2: The Connectivity Constrained Age

One of my colleagues in the early days was called Paul and he was famous for the contents of a large wallet that he carried with him everywhere. Inside the contents of this wallet where the entirety of the organisation’s software library. The first version of this folder contained 5″ floppy disks; the wallet evolved through 3.5″ floppy disks and eventually ended up with CDs.

For those of you with a shorter memory than my own, this may seem like a crazy thing to do, why would someone carry a folder of CDs around? Because there was no other way of moving data around. The networks that we use every day, the Internet, home Wi-Fi, 3G/4G/5G cellular networks, didn’t exist. There were a few connections between different computers, but they were slow, and mostly constrained within an organisation. Each of the hardware vendors had their own idea of how a network should work, anyone remember DECLink and token-ring?

Later, organisations created connections between various locations within their organisation, but these were even slower than what you could do within a location. These wide-area networks were supplied by the local telco who were in many locations monopolies that saw this growing trend as a way to make a lot of money.

Teams sprang up whose job it was to make sure that the links between locations were optimised because getting it wrong could be an awfully expensive business. Overcommitting the network pipe between two production locations could have devastating consequences for the production organisation. Much of the time it was still quicker to put the data on a disk and mail it to the other location.

Systems needed to be designed to keep the network connectivity requirements to a minimum. Using devices within the local network was more cost effective than reading the same data across the network multiple times. When I first started working with email systems people regularly deployed small servers all over the network to try and avoid the wide area network costs, these were the days before email was a universally deployed tool.

Small data centres grew up in each location to accommodate the need for local resources.

This was, of course, all changed by the Internet. The availability of a connectivity utility changed things for everyone. The connectivity constraint diminished, and all those local servers disappeared – didn’t they? And all those teams managing the scarce wide-area network capability went on to do more interesting things – didn’t they?

Age 3: The Software License Constrained Age

With the cost of hardware plummeting, and the ability to connect services blossoming we walked into a new constraint – the software license. As the value derived by technology skyrocketed the people providing that technology decided that they needed to get their fair cut from the investments that they were making. How did they protect these investments? Through page-and-pages of license agreements written in legal terms requiring armies of people just to understand them and another army of people to advise people on how to get the best out of the license that they had purchased. We didn’t finish there; we still needed another army to count the number of licences that we were using and to stop the organisation from buying any more.

People designing solutions needed to consider the rules of each individual license to make the best use of the licenses that already existed or minimise the burden of new licenses. Many organisations created central database services just to minimise the license footprint from one database vendor, while at the same time locking themselves into using that vendor for a long time. Other organisations created reporting portals for systems to minimise the people who need a license to use the ERP system.

License vendors created mechanisms to stop customers moving to alternate solutions by signing long-term agreements with significant discounts for those willing to commit.

Some vendors became embedded within the psyche of organisations where significant intellectual capital was invested in a particular technology. Supplanting that technology with a cheaper, better solution was a demanding thing to do and many have failed in their quest.

Although at the latter end of it, we are still in this age. The armies managing licenses still exist, the technology to count the use of the licenses is still being deployed, the vendors are still making good money from the licenses. We still make design decisions on the basis that it constrains the license footprint.

Open source is steadily changing the world of licencing, but it’s going to take a long while for the third age to be completely overtaken by the next one.

Age 4: The Subscription Constrained Age

We used to buy a DVD and keep it forever; we owned the DVD even though we only watched the film once. We don’t do that anymore, we have moved to a subscription model – NetFlix, Disney+, AppleTV+ and on it goes.

The same has happened with technology, you may know it as “The Cloud”. The licensing age was characterised by one-off purchasing decisions, the subscription age is characterised by continuous adjustment of the blend of services being used. Organisations have a growing portfolio of applications and infrastructure they pay for as they use it.

This is where the parallels with media subscriptions gives us some insights into managing this constraint.

Does a single subscription to, say, Netflix give us more content than we could ever consume? Absolutely. So why do we also have a subscription to Disney+? Because we like a show that’s only available on Disney+. Does Netflix have a show that is like the one we like on Disney+? Sure, but it’s not the one on Disney+ and let’s face it the cost of a Disney+ subscription isn’t that big. Is it? But there’s also that new show on AppleTV+ that everyone is talking about.

Most subscription services don’t allow you to just buy the thing you want to buy, and if they can they’ll incentivise over-use of their service. Amazon is the master at this approach with both Amazon Prime and, from a technology perspective with AWS. In the case of Prime it’s all the additional services that you come to depend upon, in the case of AWS it’s the vast array of services blended with the data egress charges creating a huge disincentive to taking data out of AWS.

If subscriptions aren’t going to get out of hand solution designs need to manage the constraints. As a daft example, the best solution for a service may be for the database to be in AWS, the business intelligence to be in Azure, the business logic to be in a SaaS tool like Workday or Salesforce, the search to come from Google and the logging back in AWS. The problem is this service would be expensive and difficult to maintain. Whilst taking all the capabilities from AWS or Google or Azure may be a compromise for each of the individual services, managing this constraint, in this way, will provide a service that is easier to maintain and cheaper. But taking every service from a single cloud provider brings its own problems.

The armies of people managing software licensing in the previous age are rapidly being supplanted by an even larger army of people managing their way through subscriptions.

I used to joke that the best protected asset within software vendors was the licensing algorithm, I now joke that this role has transitioned to the team who create the subscription rules.

It’s Just Evolution

Having written this post, I was struck by parallels with the Wardley Mapping phases of evolution. In each age the constraint is moving up the stack as the elements lower down the stack move into the background as solved problems. The technologies in those lower levels aren’t going anywhere, they’ve just moved out of focus as they shift towards being utilities.

Focussing at the Right Level

I’ve highlighted throughout this post some of the places where people’s legacy practice needs to evolve to keep up with the new age. Teams that are still placing elevated levels of management on hardware in datacentres are likely missing the huge expenditure already taking place with the subscription providers of AWS, Azure and GCP.

Organisations who managed the internal WAN as the primary constraint have, hopefully, realised over the last 18 months how connectivity has moved beyond them.

The software license vendors are busy running around their customers seeking to secure their future revenue. In so doing they are seeking to slow the progress of the subscription providers. Many designs will be constrained by the need to consume these licenses beyond the point where they should have moved into a subscription service.

The subscription providers will continue to evolve at pace, this is the place where we need to be managing our constraints, delivering the best value to our customers for the right price. The model for how to do that is still evolving, but many organisations have already figured most of it out.

I’m not wise enough to know what the next age of design constraint is going to be, but I suspect we are heading into a world where the robots are doing more work and we will need to create systems that work well with the robots. I can also see all sorts of other constraints becoming primary: data sovereignty, privacy, security, cybernetics, skills, emissions. Testing is often a significant constraint on a design. I am glad that my job doesn’t involve predicting the future, many of us still have a hard time staying in the current age.

Header Image: This is a beach in the Outer Hebrides. The Queen used to park the royal yacht in the strait and have the crew row the family over for the day. The locals know it as Queen’s Bay. We also had it to ourselves the day we went.