This is a guest post for the Computer Weekly Developer Network blog written by Simon Poulton of CA Technologies — Poulton is ebulliently vocal about his passions for virtualisation, cloud, mobility and the wilder more exciting realms of the total DevOps arena.
Poulton writes as follows…
So here’s my simple question, what do you think of the terms: DevOps or Continuous Delivery? I could write a whole blog on the taxonomy of these two terms, but it would be a waste of time.
While they are different and mean different things, in this piece I want to talk about adopting a transformative approach to the software lifecycle based on the methodologies that are in fact ‘common’ to both DevOps & Continuous Delivery.
In simple terms, we’re focusing on delivering a great software experience for the consumer through automation, collaboration and other good technology practice, which reduces waste.
Why is Enterprise DevOps different?
While most of us are familiar with applying DevOps to new applications, where you have something built conforming to modern standards, Enterprise DevOps is a far more complex beast.
Not only are we dealing with years of legacy code spanning hundreds or thousands of interacting applications, but also with long established lifecycles based on archaic code deployment and quality mechanisms.
So, why should we care about creating a Continuous Delivery solution for these antiquated systems?
If you want to do GOOD digital business for a customer, you need to have them interact with their core business transactions via the software you provide.
So, if you’re a bank you want your customers to interact with your core banking products (transfer and borrow money, pay for stuff etc.). If you’re a telco you want them to be able to use, add and remove basic functions like phone accounts and broadband, as well as consume OTT services like television, music, messaging and so on. Retailers want people to browse inventory and order using supply chain.
The challenge for many enterprises is that the systems which run the customer’s core transactions sit on legacy architecture. This could be a mainframe, an old UNIX system, C++, or even a combination of modern and legacy technologies connected in SOA.
In this situation, you have two choices:
- Create new innovative front ends and integrate that with all the legacy stuff, or
- Rewrite the whole system on modern architecture and platform (e.g. microservices)
Option 1 is a challenge.
To give an example, a few weeks ago we were working with the development partner for a large high street bank on its mobile platform. Most of the mobile component is new Java/JS and mobile development, but when they really need to change something which affects the customer transaction, they also need to apply changes to the core banking platform on the mainframe. How they co-ordinate the requirements, development, testing and release is obviously now exceedingly complex, so the solution is not just about the digital front end or “innovation” layer, it’s about the whole she-bang.
Option 2 is fine, but if 90% of your transactions are legacy the approach to re-write everything is a 10-year plan at best. If you are going to wait to innovate for 10 years until that migration finishes, then from a business perspective you’re doomed.
So you need something that answers 1 and 2, allowing you to innovate and integrate. This means you’re looking at creating a software factory which allows innovation at pace over complex integrated architecture. This is pretty much the problem set that Enterprise DevOps & Continuous Delivery solves, and why it is different to traditional DevOps & Continuous Delivery.
For this reason, if we care at all about doing digital business with our customers we should adopt such an approach.
Why do it, in the first place?
What is an organisation actually investing in?
For me there’s four key drivers:
- Time to market – I want to deliver innovation through software faster, to be competitive and avoid market disruption from new entrants, or to capitalise on opportunities created by those new entrants or the market itself.
- Quality – as I deliver faster I want the quality of the apps I deliver to increase, not decrease (delivering crappy apps is suicidal in today’s market).
- Efficiency – In doing the above, I don’t want to have to hire thousands of people, it isn’t scalable or sustainable.
- Compliance – on top of the above I need to make sure that any legal and compliance requirements are considered in the delivery chain.
A good Continuous Delivery solution will satisfy all four of these drivers. The proof of this pudding is in the latest research CA Technologies commissioned with Coleman Parkes, which shows that DevOps is a key driver of business growth. The research found that those organisations adopting advanced DevOps have seen a 38% improvement in speed to market (from 12.4 to 7.7 weeks) as well as an 83% improvement in customer experience.
When you add the fact that advanced DevOps usage increased Employee Productivity and Process Efficiency by 44% and 42% respectively, you can see that a business case can be produced from these drivers for most Enterprise DevOps & Continuous Delivery projects.
CA Technologies’ Poulton will follow this story up with a second piece entitled ‘Why horizontal value streams are the way to tackle Enterprise DevOps’, which is linked here.