We do a lot of work in the Public Sector, and the buzz phrase du jour is ‘digital transformation’. The Government Digital Service is pushing it, Central Government is encouraging it, and Local Government is digitising more and more citizen services daily. It’s all about modernization and delivering better services to external users (i.e. citizens) while making the jobs of internal users (i.e. staff) more efficient. And there are have been great successes as a result of digital transformation projects within the Public Sector – digital transformation in 2015 saved the government £1.7bn and the GOV.UK transformation alone saved £61.5m (1). This is all a result of making everyday tasks easier with technology – for instance, 98% of driving tests are now booked online, and 85% of self-assessments are filed through online channels – showing a real shift in how services are offered and how citizens can manage their engagement with government.
I was recently asked about what happens when Carrenza embarks on a Digital Transformation project with clients. We say the term ‘Digital Transformation’ a lot, we talk to many customers across the Public Sector about it – but what actually happens when we start working on a digital transformation project? What does digital transformation look like in practice?
The answer can be very different depending on which technology partner you ask, but we feel we’ve got a really good system in place for handling large-scale digital transformation projects. So, I’m going to talk through what digital transformation looks like when working with Carrenza.
Where we start
When we start a digital transformation project, it begins with understanding where you are today and your business need.
We discuss your company’s core values and what services your IT offers, identifying the problems and what you want to achieve.
We bring in our Technical Architect and begin by mapping out your application architecture, alongside starting to build a picture of how your users access those applications and how each one needs to connect with one another. It is at this stage we also identifying third party interventions required at the Carrenza hosting site and how much data you have, where it sits and how it’s handled and processed.
For many organisations, this task alone can be incredibly difficult. A recent client we worked with had so many applications running they didn’t quite know what they were using and what they needed in a post-digital transformation world. And that’s completely understandable. The old way of purchasing servers for applications, letting them run indefinitely in the corner of the data centre because people aren’t sure what will happen if they are turned off, has created a complex web of applications and underlying infrastructure that’s difficult to pick apart. It’s why so many organisations keep with the status quo and continue to pay high outsource costs – because they think it’s safer than changing.
The initial application mapping exercise provides a great opportunity for our customers to go away and look at what they have across their entire organisation. We can do this for them, but it often makes sense to do this in-house to start a practice of ongoing application rationalisation
But why change? Why do we need digital transformation?
Without digital transformation, legacy systems constrain agile development – stopping you achieving faster delivery of services and reducing ongoing costs. Many legacy application infrastructure stacks are unable to scale on demand and don’t allow for the easy setup of test and development environments that can be spun up to mirror live environments. This results in a waterfall based approach to software releases; launching big releases every few months that pose more risk compared with regular, smaller releases which you would expect in an agile environment.
Without transformation, IT teams are therefore always behind the curve. They can’t integrate new ideas, services and tools on-demand – they are at the mercy of their legacy application stack and lengthy release cycles.
We’ve even heard anecdotes of customers having managed service contracts in place with SLAs of 3 months to build a server, with a minimum contract time frame of multiple years. How can anyone develop in an agile way under these constraints? It just doesn’t fit with the flexible and scalable Public Sector that the government is trying to build.
The customer I referenced earlier used 16 applications to deliver just one process prior to their digital transformation. These applications were spread across multiple departments and governmental organisations – resulting in complexity when looking at how to transform their IT. This complexity stopped progress as it was simply too difficult to make a change.
When we started working with the client, we found that they didn’t need all 16 applications, so we could instantly take out a number of apps from that one workflow. We then looked at the processes themselves to see if we could help simplify them so that the application layer could become less complex.
We always look at two areas when considering digital transformation: designing an agile platform and streamlining operational processes.
It comes back to the figures I shared earlier about the changes in how we book driving tests and apply for licences: when starting a process of digital transformation, we need to look at whether a process can be refined, and if there is an agile platform supporting this process so that changes can be easily made in the future.
Is your service provider the problem?
A worrying trend we have seen in the industry, based on our conversations with hundreds of customers, is that the one thing that urgently needs transforming is the commercial relationship that customers have with their current technology service providers.
Many service providers lock their customers into draconian, multi-year contracts with punitive charges. So, when we engage and offer to spin up a test and dev environment that only needs to be used for 10 hours, many clients don’t have the facilities in place to pay for just 10 hours – they are used to paying for ten years!
We can be incredibly flexible from a commercial point of view due to the way we leverage public cloud services within clients’ digital transformation projects. We’re also able to take legacy applications and bring them onto the cloud safely – we’ve done it with complex Oracle stacks and other similar solutions. We look at what can move to the public cloud now, and what needs to be migrated to a more agile platform while continuing to run legacy applications. We call it a Springboard to the Cloud (take a look here if you want to know more: /springboard-to-the-cloud/).
So what does the digital transformation process look like for Carrenza clients?
- Start by mapping out your application architecture and needs in a workshop – we look at what you have currently across your application estate, what services are delivered and what digital transformation means to you.
- We engage our Project Manager in working with your Project Manager, and we engage our Technical Architect to work with your Technical teams so all bases are covered.
- We take your architecture map and lay it across our cloud blueprint. What can be safely moved to the cloud is migrated, and then we look at the gap (the parts that can’t be automatically migrated to the cloud).
- For legacy systems that can’t be migrated or hosted in a modern way easily, we create a ‘Springboard’ and solution to house these workloads allowing you to migrate to a cloud compatible environment hosted in the same location on the same network. This gives you the benefits of flexibility and time to phase out the legacy workloads that were holding you back.
- As part of the process we also identify, design and implement:
- What can be built from new?
- Security: Combining your security requirements and best practices to fully secure your new environment.
- Data handling: Designing how your data is stored, handled, backed up and archived in a secure and efficient way.
- Disaster recovery: Incorporating replication where required to enable you to fail over to a secondary site where business continuity is needed for critical workloads.
- We then execute on the agreed migration strategy and continually innovate and engage with you to keep the process of continual innovation working for more efficient service delivery. Consultation is key at this stage and your migration strategy will most likely consist of different components, with each component having its own migration plan. At this same stage, testing and failover plans are implemented before execution.
Stop, breathe, reflect and repeat
Having executed your migration strategy, it is time to ‘stop, breathe, reflect and repeat’ and review the new solution. Discussion at this stage focusses on lessons learnt and achievements made whilst citing new requirements, enhancements and optimisation for the solution which in turn triggers the transformation cycle again.