Useful Things

Useless Things

There’s a saying in aviation – the three most useless things are

1. Runway behind you
2. Air in your fuel tanks
3. Half a second ago.

All of these are about opportunities missed, runway you didn’t use that was available to you, fuel you didn’t take (that might have provided a contingency) and time wasted. This got me thinking:

What are the three most useless things in IT architecture?

In my opinion, these are the top three.

One

The first is a great way to avoid get sorted or doing anything  ” What we need is a really good method to drive this.”

Or shorthand for “I’m too lazy to work out how exactly this should be done“.

Every project is different and will need a different approach. By all means, use a pre-defined method as a template, but adjust to suit the circumstances. Draw on the capabilities and the experience gained in creating the method but think through what really matters for this specific delivery. The technologies chosen should be appropriate to the capability you are building, not a cookie-cutter style.

Two

The second is a real classic. You’re too busy to deal with legitimate needs – “I’ll put it in release two”

Or Shorthand for “I’m ignoring you… will you go away? This can never be implemented”.

Architects are often busy people that don’t want to spend time arguing over whether a capability is required, so they use this shorthand to avoid debate. Instead – often the need is actually only one part of what is asked for. Lift the lid on what is really needed. The “too hard” bit may not be needed at all.  With an Agile approach may be some aspects of the need can be put into a sprint. Allowing a process to agree on what is important to the product is key here. Putting it in release 2 might be a great thing to do – if you are genuinely going to build release 2!

Three

My final choice is the most dangerous of the three –  “It’s on the risk log”

Or shorthand for “I’ve written it down so I don’t need to do anything with it”.

How many designs have you seen with captured risks that don’t ever get actioned? Instead, you should take action – Can you mitigate this risk by preparing for its impact? Can you stop it in its tracks? Early action on risks often reduces the cost – so thinking the problem through is vital. By all means, record it on the risk log – but make sure you know what you are going to do about it.

Better still, can you avoid the risk altogether by designing away the cause of the risk? For example, mitigating the risk of hardware failure by having duplicated redundant systems.

So, what do you think, are there strong contenders for the top three? What really frustrates you? What are your top three?

+++