This is part 4 of a series about internet-era CTOs. Catch up with the previous posts:

Part 1: Why hire an internet-era CTO?

Part 2: How to hire an internet-era CTO

Part 3: What does it mean to be good at technology?

Often when we talk to clients about the situation they’re in, we find a tangle of technology. We’ve come to refer to it as “spaghetti”.

“Technology spaghetti” is what you get when your technology, data, commercial arrangements and operating processes get tangled up. It’s not just a problem of having too many pieces in the puzzle, it’s also that the interconnections between them are hard to understand and manage.

Eventually you reach a point where it’s difficult to introduce change, or even to be sure you can provide resilient services.

That just gets worse over time because when technology, data, commercials or processes are overly complex, the easiest thing to do when you want to do something new is to add yet another system. More stuff gets aggregated on top of old stuff. More spaghetti.

As time passes, things get worse still because people leave the organisation and understanding fades; unmaintained systems get forgotten; change gets harder.

Spaghetti represents accumulating risk.

One of the exercises we like to go through with senior leaders—both technical and non-technical—is to have them draw their technical architectures.

That exercise is a good gauge of a few things:

• is there sufficient confidence among those executives to have a go?
• is some understanding of the technology landscape widely distributed?
• how simple is the architecture?
• is there anything in the picture that shows what differentiates the organisation as a whole?

It’s tempting to think that being able to draw a simple picture with a small number of boxes is automatically a healthy situation. Not so: in truth, the full architecture of many leading organisations is often complex to draw, consisting of dozens of specialised components.

It’s not just the number of boxes and lines on a diagram that’s important: it’s whether they describe the reality of your business, and whether you’re in control enough of them to change them easily.

Untangling that spaghetti—giving yourself the opportunity to focus on what really differentiates you and on using technology to deliver value—is an important goal.

Internet-era technology practices include all sorts of techniques that can help you meet it: describing infrastructure in code, a broad range of automated testing tools, and the culture and tools of continuous delivery. They underpin the internet-era ways of working we’ve talked about elsewhere.

The challenge is that they’re a long way from where many traditional IT organisations still find themselves, so it’s useful to have some stepping stones along a path that heads in the right direction. Some of the things we’ve found useful are:

1. Work out how to measure the cost of IT failures (lost productivity, opportunity costs, etc) and set measurable targets to reduce them by improving business resilience and reducing their occurence. A culture of blameless post-mortems and clear responsibility helps a lot here.
2. Build and proactively manage a register or map of all technologies in use that describes, for each one:
   • What its purpose is
   • Who the responsible named owner is for it
   • Any relevant commercial arrangements
   • What else it integrates with (what depends on it?)
   • How it is operated and how a change is made (e.g. software-as-a-service from a third party, fully run by in-house team, customised third-party software)
   • When it was last updated
3. Have, and work through, a remediation plan for anything that hasn’t been updated in more than a year
4. Encourage different teams to take charge of integrating new products and services with existing IT, and identify and remove anything that stops them doing that independently using self-service APIs

It’s important to remember that none of these objectives can be met overnight, and none of them is ever really finished. A clear focus on them for a while, with an iterative approach to measure and adapt as you go, is a good start.

(If you want to go a bit further, Dave Rogers has a great set of principles in his post on Toxic Technology, but we think these are a good start.)

In a healthy internet-era organisation there will always be change, and there will always be cycles where complexity grows and then diminishes. That’s ok if it’s recognised, and if there’s both culture and processes for responsible ownership of technology.

For many there’s a lot of detailed work to do to get to that point. Accepting the reality of technology spaghetti and committing to untangling it is the best first step.