Minimal Viable Platform – Why the business can’t, won’t, and doesn’t have to wait for Perfection

The art of architecting change into your key IT platforms

Have you ever started something; a DIY project or a challenge like running a 10k, and by the time you have finished it can’t remember the feeling of excitement you had before you began?

That’s pretty much how the business feels at the end of every large IT project.

Projects start because the business needs something new or they are suffering from the pain of something old or ill-suited to their current needs. So, the IT department is tasked with doing something we now call transformation, and there is much excitement in the business.

These new then kick-off a huge check list of activity; requirements gathering, business case building, stakeholder engagement, specification, design stages, high levels, low levels, programme planning, resource planning, transition planning, roll-outs planning, risk analysis, and a list of other things that culminate in the big day when whatever it is they are delivering goes live and into production.

After all that hard work, planning, collaboration, cooperation, agitation, and implementation, everybody stands around scratching their heads and wonders why they started in the first place. 

In consumer technology you walk into a shop buy something new, walk out, and you feel fuzzy and warm. There is no instant gratification in IT projects. In fact, IT projects are the art of self-flagellation, and after a few short months or maybe a year after the new thing was born, the business has changed its mind about what it wanted, and everybody involved prays for the next 3 years to pass so they can start to build or deliver a new thing that can.

Whether the project was successfully delivered or not is not the point; the problem is that the time taken to build out ‘perfect platforms’ or ‘perfect projects’ is too long because business needs are changing too quickly.

And these grand edifices of technology become monuments of frustration.

And then, to cap things off, once the thing that is adding all the value is finally live, the plan to do something really business impacting with it next year, and the year after, and the year after simply isn’t there. How many major IT projects have mountains of paperwork about the project roll-out; but virtually nothing about what happens when the thing being rolled out goes live?

Why? And this is not fault of IT, the platforms we have had at our disposal for the last 30 years have been largely static, difficult to change, and lacking any ability to drive new value once they were in.

Now application developers have adopted the fail-fast, DevOps, minimal viable product methodology; to get something working and see if the business likes it, see if it works, if it delivers on the outcome needed, and if they should go ahead and develop it further. It’s not that application developers are perfect by the way; it’s just they have always dealt in stuff they could re-code if what you built first didn’t work as you wanted. You could fail fast and try again [I am not classing ERP rollouts in this category by the way].

Try doing that with a big campus networks, or a WAN, or a data centre server or storage, or a security infrastructure, or the other big lumps of stuff IT have to deliver as major projects.

With these you couldn’t fail fast; you had to fail really slowly.

Not anymore. The emergence of cloud told us that big lumpy stuff wasn’t big and lumpy anymore. You could stand something up, kick the tyres, and then start again if it didn’t do what you needed.

We now have that same [ish] concept with the big infrastructures that IT are charged with delivering.

Software defined networks and data centres that are driven by policy, that can be adapted at speed, that can change their dynamics at your will, that can have features added to them easily, that can be integrated with other things through open API’s allow IT to deliver change more quickly than before because they don’t need to shoot for perfection on go live day.

These new platforms are defined by software yes, but they are better defined as platforms that can deliver change over time. You can start small, start as a proof of value, start with a basic network refresh or data centre consolidation and then build them out over or change them over time.

And because we have new layers of intelligence such as AI driven Application Performance Management integrated into the DC or cloud platform, or network performance measurement that can adaptively change policy, you don’t even need to know everything a platform has support before you start the process of change. You can get moving.

Like many I have watched the marketing and positioning of things like Software Defined technologies by vendors and held my head in my hands. They position the new stuff and then try to push its adoption through the old model.  They tell you to start a big project that loads in all of the complexities of the old technology and then a few more. And they don’t tell you how to then use it after it has gone live to increase its value over time, so you are paying for change but getting the same old static platforms. Less for more.

So, when you think of these new platforms, think Minimal Viable Platform. Think faster adoption. Think of getting something in that makes the business smile, and then plan what you will do with it the next month, year or five years.

Faster and more agile projects can help drive business transformation and if we make the first few steps feel like a stroll up a hill and not climbing Mount Everest, the business will see benefits sooner and stick with the programme for longer.

And, if you can go faster and architect change in your IT platforms that lasts way beyond the initial roll-out you will help your business not just prepare for change but turn change into an advantage.