I did a presentation recently in Sydney. It went pretty well, by that I mean I was happy with what I had to say (and so were others).
The topic was “Innovation in Payments” – nothing new in my presentation apart from some of my thoughts on the Australian New Payments Platform (NPP) and “Least Cost Routing”; but along the way I’ve been asked about my thoughts on disruptive technology.
Somewhere along the road I’ve also been involved in discussions around the cloud and its impact on disruptive technology.
Having said all of this I still think that the Gartner predictions are correct – INTEGRATION outside the corporate firewall over the next 24-48 months will be key to the success business’ will need in the future.
In Financial Services there will be for some time a desire to keep things in house. No surprise there. The increasing challenge will be how much of it stays in house and how much can be done elsewhere. What is at the root of this desire though – is it protection of customer data, or is it something else that needs to stay inside, and how much of it needs to stay inside? (By the way, lets stay right away from arguing with regulators – that’s an exercise in kicking yourself in the head; one where you end up with a blood nose and they end up getting new shoes).
Is it the cloud that is nasty? Couldn’t you just say that the cloud is just another name for a ‘hosted’ service, or a ‘managed service’ in much the same way that ‘Digital’ now used to be called ‘online’ and the before that ‘eBusiness’, or ‘e’ this or that. Is it any different? Really? For example, isn’t SWIFT a ‘cloud’ service? and if its not, why not? (or are you going to say that SWIFT is a ‘hosted/managed service’). Leave that debate for later.
For the time being though, lets just call the opportunity then the ‘cloud’. Forgetting about the security concerns (do they really exist anyway?) What will the cloud let us do tomorrow that we can’t do today. What is the advantage that cloud could provide us with?
Lets go through a few topics:
Governance – would that be any different? Maybe – you have different end points and your relationship with the infrastructure provider might be different – and that would take oversight. Data Realms/Sovereignty might be impacted, and Security of data, So I think Governance in the cloud would need to be increased, compared to managing your own infra on site. Maybe the controls are different – maybe thats an opportunity in its own right for a clever security/risk management provider.
Software SDLC – Dev methods would need to change. Software needs to recognise a different way of residing on infrastructure. Older stuff might be okay in terms of ‘living’ on named instances, but one of the benefits of a seemingly never-ending infrastructure capacity is that your software should be able to take advantage of infra when it needs to. Spinning up new web/app/database servers when software demands, and then turning off when not required is truly ‘on demand’. Software needs to know how to do this and more importantly when to do this. Developers need to be building hardware ‘cloud’ abstraction layers inside their apps, or abstraction layers for legacy software in order to do this. So the Software SDLC is impacted also. Unless you don’t care – which in that case don’t do a thing. React to failures in the traditional way and waste your money on traditional incident management. Get it right though and you could argue that you don’t need incident management because the incidents are ‘programmed’ in and are automatically dealt with.
Infrastructure Provisioning and Management – Biggest impact. Why would I want to own a server when I can ‘rent’ a virtual one, and only pay for the time its actually in use. Use of the ‘Cloud’ transfers often huge capex bills every 3/5 years to an opex outlay. That has good and bad aspects to it though. Opex hits your P&L in the year of build. Capex doesn’t. In some countries you can capex and not have the impact hit your P&L (by way of depreciation) until you commercialise – and that could be years away. On other matters, you can use automation tools to clone/copy/spin up new servers in minutes. You can use API’s from the Software SDLC to control them. You can use the same APIs to configure networks/firewalls and other security devices on the fly. You only pay for what you need. Giving Software developers access to infra for their stuff to live on in a timely manner is a HUGE precursor to agile innovations. This gets a big tick – but don’t forget the Governance impact above. How do you define “in the cloud” as an ‘as built’ infrastructure from a documentation level – especially when it can dynamically change so rapidly.
Reliability/Redundancy – Another big impact. Its a bit like ‘use the force Luke’. ‘Let go’, ‘Trust your instinct’. You have to trust that your provider has this in hand. Or build it in another cloud somewhere else. I think the cloud has untapped potential in increasing up time and reliability. Netflix used this to their advantage in the deployment of a Simian army (http://techblog.netflix.com/2011/07/netflix-simian-army.html) that randomly tests their environment for redundancy. Have a read – its a great concept – and they build failure into their daily life. Having to get up at 3am and fix servers and stuff has now gone away. Organisations that build this concept into their infrastructure management plans just ‘deal’ with incidents as they happen without having to worry about key services being down. Everyone should latch onto this initiative. Traditional DR will continue to serve a purpose but get the ‘link’ between hardware and software right in a way that uses the resources properly and your DR will turn into a 1 hour verification rather than a run book that humans can stuff up.
Security – An area with the biggest Question Marks. How can you transfer all of those security appliances and protections to the cloud in the same way as you can with physical. I need to do more research on this, and this is perhaps one area that lends itself to the most innovation from cloud/security appliance providers.
Cost– All of the above. You will increase costs in some areas, and decrease in others. But the decrease should by far out way the increase. Jump on it I say.
Now, thinking about all that, let’s answer the question I posed:
What will the cloud let us do tomorrow that we can’t do today. What is the advantage that cloud could provide us with?
In short:
- We can do everything we do today (or should be able to)
- We should be able to lower the cost of infrastructure, and transfer the context of its impact to the Balance Sheet
- We should be able to build in reliability and redundancy, making applications look like they can ‘self heal’ themselves if part of the infrastructure fails.
- There are questions about security
- We should be able to develop and deploy in a way that fits a modern AGILE environment
- We should be able to do all of this, ideally, at a lower cost.
But wait on, Im still missing something.
Didn’t I talk about the opportunity to do something disruptive?
The cloud itself won’t manufacture disruptive technology. You still need the ‘great’ ideas for that. The cloud however should provide a ‘platform’ for disruptive technology to live. A Launching pad. You still need the great software, the great products – but in the future they will ‘live’ elsewhere.
Enough for now.
Until Later
Leigh
Pingback: Same + Different = Different | Leigh's Blog