To Improve is to Change. To Be Perfect is to Change Often.
Earlier this week I had an opportunity to present some key lessons learnt to date - based on our adoption of cloud services- to an audience of government data leaders. I have presented this to a few difference audiences and it has always sparked lots of conversations. A few people have asked for a copy of my presentation so I have uploaded it here.
The nature of what organisations want & need from their IT systems has well & truly changed. It used to be all about efficiency & automating repeatable business processes; now its about creating whole new products, services and customer experiences using technology. It used to be all about cost; now its about agility & speed to market.
Of course in reality the world isn’t that black & white; like everything else its a balancing act. A range of different platforms is needed to support the efficient and effective operations of a modern organisation - especially if the organisation has legacy systems.
We are adopting what we’ve dubbed the ‘hybrid platform’ approach. That means making use of a range of on-premise, public cloud and SaaS based platforms. This gives us maximum flexibility, forces standardisation in areas where it makes sense and frees us up to put most of our effort into the things that are truly unique (differentiators) to our organisation.
Using a mix of platforms means we have to put in place some foundational building blocks such as identity & access management which supports a federated model, operational & security management tools which traverse traditional system boundaries and processes & practices that support service aggregation & federation. Additionally we need to know which platforms we want to use and will actually work for us. We often refer to these - and other building blocks - as the ‘orchestration and governance’ layer.
Using a range of platforms means we can go at whatever ‘speed’ we need to. We can maintain a core of legacy master data (slow moving) whilst connecting it to a chatbot service (fast moving) to provide end users with self-service functionality in a matter of days, not weeks or months.
Public cloud services and SaaS offerings form the basis for most of our new application development however at the same time we have a fleet of legacy business applications which would need to be re-written/re-factored to operate in a pure cloud environment. For those we need platforms that support a more traditional, tiered architecture. For the bulk of our applications we utilise a mix of virtualisation and containerisation.
Our data centre infrastructure is part of what enables us to operate at these different speeds. VMWare and AWS recently announced a partnership which allows organisations to fuse their on-premise and AWS platforms. The idea is that we can continue to utilise the tools & processes we have in place whilst taking advantage of the services and functionality offered by AWS, all whilst seamlessly spanning data centre facilities anywhere in the world (in our case Wellington and Sydney). This enables the hybrid model and also simplifies any migrations to the public cloud by allowing you to stage & manage them better.
A few weeks ago we completed a proof of concept of the VMWare on AWS offering and we able to successfully create a Software Defined Data Centre (SDDC) environment which delivered on the promise of the hybrid model. The POC passed on all the test scenarios & success criteria we set out and gave us the confidence that the hybrid platform architecture we want to build is possible, scalable and cost effective.
Careful application portfolio management (another discipline you need to develop) will allow us now to decide how we tackle modernising our legacy IT systems. For some we may choose to rewrite them, however for others it may simply be a matter of replatforming them onto our hybrid platform.
The days of standardisation and ‘one size fits all’ are over. Modern organisations need a range of platforms to enable their business. I think this applies to both technologies and practices - it’s one of the reasons I believe the traditional PMO approach is well and truly dead (did it ever actually work for anyone?!?).
Understanding the drivers for each part of your organisation and what ‘speed’ they need to go at will allow you to respond to (and sometimes even preempt) the platform needs of your organisation.
Disclaimer - I’m not advocating for or promoting any product or vendor in this post, rather the intent is to share thinking & experiences so others can build on those/factor them into their own activities (or not). As always I would suggest you do your own research and figure out what will work best for you.
Over the past couple of years we have helped and advised a range of organisations (both public and commercial) in relation to cloud adoption, largely based on our experiences in that space to date. At the recent AWS ReInvent there was a lot of chatter amongst exec about the approach to cloud adoption - unsurprisingly most organisations still seem to follow the ‘lift and shift’ approach to getting out into the cloud.
Broadly speaking there are two pathways to cloud - one is the lift & shift and the second is re-engineering for cloud. Each pathway comes with its own set of considerations as well as risks & benefits. We have experience with both approaches and I thought it might be useful to capture highlights from each approach here.
The lift and shift approach requires little up front work and can get you into the cloud faster. On the downside this pathway can require a fair amount of clean up work. Post shift you will mostly likely need to remediate things like network & security configurations to make best use of cloud environments & tools as well as a bunch of cost optimisation work to ensure you’re getting best bang for buck in terms of CPU, storage etc. costs. Looking at things like machine sizes/types, reserved vs non-reserved instances and the like requires someone who understands cloud infrastructure to optimise your application/infrastructure environment.
Problems tend to start cropping up when organisations complete the first part of the lift and shift and then don’t do the follow up actions. You essentially end up with the worst of both worlds, and the benefits of neither. I think a lot of people who are disillusioned with cloud adoption are in this camp. Like I’ve said countless time - cloud adoption isn’t simply about someone else running your infrastructure and yet so many people still seem to get stuck there.
On the flipside a re-engineering for cloud approach requires more time and investment up front. In effect this involves converting the existing application/infrastructure to take full advantage of cloud based technologies such as serverless and ‘as a service’ components such as a databases. This approach simplifies the migration and helps you realise the benefits associated with cloud adoption quicker. It’s also the more future-proof of the two approaches.
Either approach is a valid pathway to the cloud but you need to understand the implications of both pathways and select the one that makes sense for your organisation and strategy. Whichever way you approach it you do need to ensure you have a robust plan and sufficient funding/resources allocated to the effort.
We have kicked off the modernisation of our core line up business application (actually roughly 17 apps in one molithic stack, thousands of lines of Java code, approaching 15 years old) and as part of that we are replatforming the database, implementing a container based infrastructure and converting the monolithic applications to microservices & APIs. This is squarely down the re-engineering pathway.
We are doing all of that on a hybrid of public and private cloud but operating under a ‘cloud first’ principle. The plan is to modularise the application to create more choices (some of the modules might for example be replaced by SaaS offerings) before modernising components and eventually rebuilding the UI/UX elements.
Part of this modernisation will include a move towards a more DevOps-style operating model and and adoption of continuous integration and continuous delivery (CI/CD). We are investing a lot in building capability in that space and helping people & teams transition from the current operating model and tools to the future operatng model.
Modernisation of a legacy application is always inherently risky (and expensive) - you only need to look at other modernisation efforts like Kiwi Bank to see examples of that. Utilising cloud-based technologies helps us accelerate the change and trial/test options to find the best way through the modernisation effort.
We expect our modernisation efforts to take between 18-24 months and they are an integral part of our wider organisational digital transformation efforts. We will continue to migrate other workloads, and builds new applications, on public cloud infrastructure during that time.
We’re always looking for opportunities to improve the experience our customers have with our products & services.Each year we deliver services to around 160,000+ (mostly) digital natives which presents a whole new set of challenges around the way we design our services and meet ever increasing user expectations.
One thing we learned very early on is that in the modern ‘app economy’ speed to market is more important than ever before. It’s no longer good enough to release major updates two or three times a year - improvements and fixes need to be a steady stream of activity which challenges traditional development and release processes.
We operate on a fortnightly release cycle which in our sector is actually pretty darn good but I know that moving forward that just isn’t going to cut it. We are probably never going to do hundreds or thousands of releases a day (we aren’t Amazon or Facebook) but having the ability to do a daily release feels like a good goal to set ourselves.
To that end we have been investing in automation - putting in place continuous integration/continuous delivery processes & tools as well as test automation. We still have some way to go but we have put in place most of the components required to implement a CI/CD pipeline.
The adoption of cloud technologies has allowed us to see speed from another whole perspective - it’s not about automating & accelerating current processes but rather having the opportunity to re-engineer how we deliver from the ground up. A recent example demonstrated the power of this opportunity for me.
Like many organisations a large chunk of our customer contact via telephone relates to routine tasks (account information, password reset etc.) - the opportunity to automate and streamline these interactions is a no-brainer but if you’ve ever worked with traditional voice/IVR solutions you’ll know they are cumbersome and expensive to set up.
We had a look around at what cloud/SaaS options existed to deliver those services and it just so happens that Amazon Web Services recently released their Connect service which provides basic contact centre/IVR functionality. Using the Connect service (connected up with other AWS services and functionality) we were able to stand up a working solution within just 60 mins! Anyone can ring in and - based on the number they are calling from - can access their account information any time of day or night without the need for any human intervention.
Now what impressed me wasn’t that functionality; that technology has been around for years. No, what impressed me was that it took just 60 minutes from me saying ‘I’ve got this idea…’ to having a working prototype. All at pretty much zero cost, other than people’s ideas and time.
In a world where ‘it’s not the big that eat the small but the fast that eat the slow’ (thanks for the quote Rod) it is this sort of engineering that will give us the best chance of to staying relevant and meeting the expectations and needs of our customers.
I think we will run a hybrid (private and public cloud) environment for the foreseeable future but having cloud-based services which can augment our enterprise platforms means we can dramatically improve our chances of not getting eaten.
Footnote: during the time it took me to write this post the team added a follow up text feature which send the information you heard during the phone call to your phone via SMS - you’ve got to love cloud!
Journey to the Cloud, Start-up Life is Easy