April 24, 2019
To deliver on digital transformation and improve business performance, enterprises are adopting a “design for operations” approach to software development and delivery. By “design for operations” we mean that software is designed to run continuously, with frequent incremental updates that can be made at scale. The approach takes into consideration the end-to-end costs of delivering and servicing the software, not just the initial development costs. It is based on applying intelligent automation at scale and connecting ever-changing customer needs to automated IT infrastructure. DevOps is the set of practices that do this, enabled by software pipelines that support Continuous Delivery.
The challenge: Design for operations
Products and services pass through various stages of design evolution:
- design for purpose (the product performs a specific function)
- design for manufacture (the product can be mass produced)
- design for operations (the product encompasses ongoing use and the full product life cycle)
Automobiles are a good example: from Daimler’s horseless carriage, to Ford’s Model T and finally to Toyota’s Prius (or anything else that’s sold with a service plan). Including the service plan means the auto maker incurs the costs of servicing the car after it’s purchased, so the auto maker is now responsible for the end-to-end life cycle of the car. Information technology is no different — from early code-breaking computers like Colossus, to packaged software such as Oracle, and then to software-based services like Netflix.
The key point is that software-based services companies like Netflix have figured out that they own the end-to-end cost of delivering their software, and have optimized accordingly, using practices we now call DevOps.
There are efficiencies that can be achieved only with software designed for operations. This means that companies running bespoke software (designed for purpose) and packaged software (designed for manufacture) have a maturity gap, where the liability is greater than the value. If that gap can be closed, delivery can be better, faster and cheaper (no need to pick just two).
It’s essential to close that gap, because if competitors can deliver better, faster and cheaper, that puts them at an advantage. This even includes the public sector, since government departments, agencies and local authorities are all under pressure to deliver higher quality services to citizens with lower impact on taxation.
The reason we 'shift left'
A typical outcome of the design-for-purpose approach is that functional requirements (what the software should do) are pursued over nonfunctional requirements (security, compliance, usability, maintainability). As a result, things like security get bolted on later. In many cases, this lack of functionality starts to accrue as technical debt — that is, decisions that may seem expedient in the short term become costly in the longer term.
The concept of “shifting left” is about ensuring that all requirements are included in the design process from the beginning. Think of a project timeline and “shifting left” the items in the timeline, such as security and testing, so they happen sooner. In practice, that doesn’t have to mean lots of extra development work, as careful choices of platforms and frameworks can ensure that aspects such as security are baked in from the beginning.
A good example of contemporary development practices that support this is manifested when we ask, “How do we know that this application is performing to expectations in the production environment?” This moves way past “Does it work?” and starts asking “How might it not work, and how will we know?”
Enterprises need to adopt a “design for operations” model that includes a comprehensive approach to intelligent automation that combines analytics, lean techniques and automation capabilities. This approach produces greater insights, speed and efficiency and enables service-based solutions that are operational on Day 1.