DevOps for legacy services – it’ll never happen!

Publish date:

It is not possible to run your legacy services with DevOps teams, but with a bit of care you can mold your service to your team, or your team to the service.

It’s not possible to run a legacy IT estate with DevOps teams.

I would absolutely agree with this statement: throw a bunch of DevOps teams at your legacy services and you’re as asking for trouble, not least because your DevOps teams, while they know much about modern ways of working, are unlikely to know anything about these older, albeit core and vital business services. That’s if you even have such teams ready to deploy.

Hurrah for legacy

Firstly I think there has to be a mind-shift. These services are likely to be at the core of your business proving ongoing business value. Some services you might be able to switch off quietly without anyone noticing, but doing that to most of the services labelled “legacy” would likely cripple the business. So let’s reconsider that meaning of the label – it carries negative connotations that nothing can be done with these services. That’s just not true. A “legacy” is something that the business created before you arrived and then handed it to you (thanks, business). It is as much to be cherished and built upon as ripped apart and discarded. So let’s consider the former.

Life in the old dog

The operation of legacy services via DevOps can bring great benefits for the organization that chooses to invest. You can:

  • Breathe new life into older services – those monoliths can be changed in an incremental way, and using updated tooling. The culture shock of switching to a new service can debilitate an organization, so change the service little by little. Drop the bits that don’t work and build on those that do. And do it with updated tooling where possible.
  • Understand your services better – take advantage of improved real-time monitoring techniques and tooling; improve and update the integration with the rest of the estate – enable access for other services to all that valuable data
  • Control your requirements; improve backlog management – move to agile and more rapid incremental change and enable closer working with your customers (be they internal or external)
  • Shift left QA and use service driven design and development – improving the quality of the output and stability of the service. While your legacy service is likely to be stable, there can be a certain degree of nervousness about making radical change to such a service. Take control of the QA and assure your customers that a DevOps process can manage this risk.
  • Cost savings and efficiency savings, through:
  • Lower operational costs through fewer defects
  • Rapid deployment of resources between operational issues and new development
  • Rapid response to your customers changing requirement
  • Drive innovation – the whole team is exposed to service operations giving larger base for service innovation – and everyone gains exposure to modern tooling
  • Take a step to the cloud – change your teams to DevOps footing and then they, and your service, become more cloud ready.

OK then, given the prize…

I want it now!

As with life, so with DevOps; there is no single destination, you cannot simply force the change and then forget – it is a journey. Once we accept that we must invest time in making our DevOps dreams a reality, it will make it easier to plan our way forward towards our new goal. Plan incremental change within an overall strategy and roadmap. And remember that the journey doesn’t end – a central tenant of DevOps should be continuous improvement. Some suggestions to start might be:

  • Standardization – of process and ‘scripting’ were possible remove the variations that have crept into the service over the years
  • Standardization – of infrastructure, where possible
  • Monitoring: improve system knowledge – this can a relatively straightforward fix – e.g. pull this together via something like Splunk and visualize. The intelligence gained can be invaluable and it also fosters service ownership.

The journey towards DevOps is one you might already be on. For many years now, a number of industries have changed their way of thinking by operating Lean management, focusing on continuous, incremental improvements. An organization that has bought into the ideas that change as positive for business and customer outcomes change should come from those doing the work; and change is measured, are already a good step towards a DevOps culture. Secondly, embracing Agile ways of working is core in the transformation to managing work in a DevOps team; again changing the culture of an organization is key.

Circling the square

Legacy is almost synonymous with waterfall, and the move to an integrate an agile change process operating against a monolithic, aging service is a whole other topic. But without thought about how you can enable this, a move to DevOps can stall. It is possible – I have seen it done successfully in a number of teams that are prepared to think at the level of change that agile requires, or are prepared to think outside the box to change parts of the service that are outside of the service crown jewels, for example via microservices or recognizing what parts of the service can stand this level of change.

Please fasten your seat belts

This is not an easy journey. But on the way, we can try and avoid those pockets of trouble, or at least be aware where the turbulence lies.

  • Clash of old and new technologies – how to introduce new tooling requirements of DevOps while maintaining the level of service?
  • No one wants to change – how to use your champions, and enthuse the detractors? Who will support me?
  • The customer doesn’t want to work like this – how to bring the customer on your journey and to see the benefits to them of moving to DevOps?
  • There’s no time to do this – remember this is a journey not a single step implementation. How to break it into small steps?

DevOps, your way

The answers to each challenge will differ by team and organization depending on the make-up and experience of the team and the culture and commitment of the organization, and the attitude you bring.

It is not possible to run your legacy services with DevOps teams, but with a bit of care you can mold your service to your team, or your team to the service. Or most likely, some of both. The benefits for your people, and your services make it a prize worth chasing.

If you’d like to learn more about how Capgemini can assist with a DevOps journey for your legacy services contact me via LinkedIn.

 

Related Posts

devops

DevGovOps – Key factors for IT governance for enterprises in a DevOps world

Chuks Anochie
Date icon September 27, 2019

IT governance structures need to be better aligned to the idea economy

devops

EvoQE (Evolution of Quality Engineering) – Next-generation quality engineering services

Vivek Jaykrishnan
Date icon September 11, 2019

With new digital era, the need for quality and agility is a top priority across all...

cloud

The Rise of Containers in Enterprise IT

Fausto Pasqualetti
Date icon July 19, 2019

The rise of application containers on enterprise roadmaps is changing the way IT services are...

cookies.

By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.

Close

Close cookie information