The secret of great technology architecture is . . . timing

It’s been fascinating and nerve wracking to watch the journey, unfolding and testing of the James Webb Space Telescope since its launch at the end of 2021. Fascinating because, to a non-expert like me, every time I read about it, the mission seems more complicated than I thought it was. Nerve wracking because the telescope is a very, very long way away (at the Lagrange point L2, about one and a half million kilometres from Earth). This means that, if anything goes wrong, there’s no realistic prospect of sending someone (or something) to fix it (unlike Hubble, which has had five shuttle missions for servicing, upgrades and repairs). Anybody who has been involved in any sort of launch, even of software that has never left a machine, let alone left the Earth, knows that ‘just one last thing’ feeling before the point of no return is crossed.

I find the JWST interesting because it is an extreme example of knowing when to make choices about architecture and design. I must admit that I don’t know the full production lifecycle of the JWST, the manufacturing lead times, or the critical path. But I do know that, once the Ariane 5 rocket was lit, there was no going back.

In technology architecture, we face much less extreme thresholds for our design decisions. We can change our minds before, after and even during launch. In fact, when designing modern software, we should assume that it will be changed many more times after launch than before launch: the pre-launch phase that gets the first working version in production is only a tiny fraction of the change activity that the software will experience in its life.

This means that we face another dimension of choice: not only do we have to make decisions, but we have to make decisions about when we will make decisions.

The traditional waterfall development lifecycle (which we like to think that we have left behind us, but which is always lurking in large enterprises, sometimes in disguise) treats software development like the JWST. We do the design after we have gathered the requirements and before we start writing code. Changes to the design follow the change request process. At some point in the future, there is a big launch date, when everything will work calmly, cleanly and as designed.

In the real world, we have learnt that software development doesn’t work like that. It’s a process of finding out what we don’t know, of making decisions on the basis of experience and inspiration. Every software release is just the next draft of reality, to be modified almost instantly.

How should architects time decision making in this environment? The impulses that drove the waterfall lifecycle still exist: a desire for certainty, for predictably, for avoiding waste. Even if the waterfall approach doesn’t work, these impulses are reasonable and understandable. Furthermore, architects know that there are some choices which transcend the immediate context of a specific change to a piece of software: if there weren’t then there might not be such a thing as architecture. When should we make these choices?

The idea of taking decisions at the last responsible moment has been around for nearly twenty years (it was introduced in Lean Software Development: An Agile Toolkit by Mary and Tom Poppendiek). However, it can be very difficult to know when the last responsible moment is. (The James Webb Space Telescope project was officially started in 2002, and based on thinking from long before that, meaning that there were probably some last responsible moments before the concept was even given that label.) It’s especially difficult when you have multiple stakeholders clamouring at you for certainty: how much is this going to cost? What skills do I need to train for? Should I sign this contract? What tools should I use?

I think that there are many good reasons both to take decisions now and to defer decisions until later. In my next article, I’ll consider reasons for deferral. For now, I’ll consider a couple of concepts which help us to spot the decisions that we need to take now: consequences and clarity.

Consequences are the reasons that we take decisions in the first place: a decision has to result in something, otherwise it is not really a decision at all (and even choosing to do nothing is something). When considering whether a decision is needed now or in the future, I find it helpful to ask myself, ‘what will be different tomorrow if I take this decision today?’ If the answer is that people will behave differently, that contracts will be signed, environments commissioned, training organised - or that work will be cancelled, resources redeployed, direction changed - then the decision is probably needed. If the answer is that everything will stay the same, but a task will be ticked off on a plan, then the decision can probably wait until we know better.

However, there is an important extension to this rule: we must recognise that creating clarity is also a way of making tomorrow’s world different from today. Sometimes decisions are needed because a team or a project is in a state of confusion and uncertainty. Dispelling this confusion and uncertainty may not result in immediate action, but it may enable the team to marshall itself and proceed with confidence. Creating a path which people can follow is sometimes more important than creating a path which is perfect.

One final thought on architectural timing, which I will also explore in a future article: I believe that it is not only the job of architects to take important decisions, but it is also their job to make decisions inconsequential. Our goal should be to make our architectures agile, dynamic and capable of constant change: whenever the ability to change depends on big decisions with profound consequences, then we hinder our agility. But, just like timing, it’s hard to get this right too.

(Views in this article are my own.)