Innovation Architect – making it cheap enough to not worry about being right

Across the software development and IT professions there are so many uses of the word Architect. You’ve got your Enterprise Architects, your Solution Architects, your Application Architects and, my favourite, the Ivory Tower Architect. With the exception of the last one they do each have their place. In general they provide an elevated viewpoint of how a particular development fits into a wider picture and provide a balance between immediate demands and the longer term ambitions of an organisation. They are predominately worried about being right – that is, making decisions that when looked at over a longer time period other people will view as being sound.

For big, expensive and difficult to change decisions, an Enterprise Architect can be worth their weight in gold. Unfortunately, and paradoxically, when it comes to innovation the standard approach of Enterprise Architecture does not work.

To understand why, we first need to define what we mean by innovation and how it specifically differentiates from normal software delivery. If you’re in delivery mode you know what you need to build – the question of “should we build this?” has already been answered. In contrast, innovation is about finding out if it’s even a good idea. Using Lean Startup as a basic principle, we’re trying to answer three questions:

  • Is there demand?
  • Can we do it?
  • Is it worth it?

I’ve often found that technology professionals are predominately focussed on the “can we do it?” and want to rush off and build a system. It’s important to see these three questions as a journey from low certainty to higher certainty. It doesn’t make sense to rush ahead in only one of these questions. Instead they should be tackled in lock-step. Therefore the tech build element of this journey often becomes about “just enough”: How do we build just enough to test demand? How do we build just enough to gain the confidence that this will technically work? How do we build just enough to start understanding our economics and estimate the cost to build a full system?

The second part is to see this from an enterprise point of view. How do you manage risk and “get it right” when you’re fundamentally trying to do things that are too early to tell if they’re right? The answer is borrowed from the venture capital world and can be summed up by a single work: Portfolio.

If we view innovation a set of bets or experiments in a portfolio, we see that we don’t need every innovation to succeed. We set the expectation that a high proportion will fail. So at the portfolio level it’s about maximising the number of bets and reducing the cost to find out if we’ve got a winner – the phrase “fail fast” neatly encapsulates this.

So now we’re full circle back to the role of an Innovation Architect. Like every other sort of technology architect their role is to provide that elevated viewpoint and balance immediate demands with longer term ambitions of an organisation. In the innovation regime, this means explicitly avoiding big and expensive decisions, doing “just enough” and, fundamentally, making it cheap enough that you don’t need to be right. By reducing the cost of each bet we can afford to have more bets in our portfolio. In the early stages this is undoubtably our best way of boosting our odds.