A continuous delivery model right on time
With continuous delivery, good enough makes things better for business. Changing to this delivery model doesn't alleviate all app problems, but the right implementation means fewer of them.
The majority of business projects -- IT or otherwise -- rely on creating a large change. The team aims for an end result six, 12, 18 or more months away, grappling with many needs to reach that end result.
The end result is needed now -- not in some months' time. An 18-month project solves an 18-month old issue, and that issue may have changed beyond all recognition by then. The 18-month process results in many updates rolled together into one deliverable that requires complex and costly change management that's a burden on end users and help desk staff.
In the world of IT, it is hardly surprising that such projects are seen as a constraint on the modern, dynamic business. Something must change.
Many IT organizations are considering a continuous delivery model instead of this monolithic waterfall approach with rigid plans that result in single deliverables of an application. With continuous delivery, the IT team designs a 'good enough' system (think of it as version 0.8 rather than version 8) that meets all the main requirements. Real, although tame, end users test various builds and provide continuous feedback on what works and what doesn't, what is missing and what could be done better.
The project team makes corrections and improvements along the way; the more people that can use and therefore test the system, the better. Once out in the operations environment, new functionality can be added based on real users' ongoing needs -- not based on a set of requirements written down months ago, or on developers cherry-picking what they see as being the most interesting areas to work on.
A move to a continuous delivery model is a major part of creating a more agile business. The IT organization can add new functionality to existing systems piecemeal, dealing with an immediate issue in the shortest possible time. Continuous delivery also lets the company treat end users the same way consumer applications on personal tablets or smartphones do, with small changes applied regularly that don't require retraining.
Large changes will still exist and still cause issues. A major change is too much to take in without formal training, and the users will be overloaded with trying to find out how to carry out their tasks. But there will be fewer of these large changes, with less need for change management.
The right fit
Continuous delivery best suits organizations that have an open mindset, where IT and the business can buy into the approach, accepting that everything will not be perfect from the point of first implementation. Companies in fast-moving environments, such as high-tech, retail, consumer goods and multimedia are ideal candidates for the continuous delivery model.
Consumer sales website Etsy has used continuous delivery for around six years. Box, the cloud-based information storage, collaboration and sharing platform, embraced continuous delivery around three years ago, and Adobe has been using the approach via its Creative Cloud platform since the software company's inception.
Even slower-moving or highly regulated industries, such as finance, pharmaceuticals and heavy manufacturing, can take up continuous delivery. Aspects of a waterfall project will benefit from being dealt with as continuous delivery components of that larger project. However, companies in these industries may hold back from full continuous delivery and DevOps, which enables the free flow of code from development into the operations environment.
Once that first release version is out in the wild, the feedback loop becomes even more important. What are the users saying? What are the major issues they're reporting through to the help desk? Such feedback must be encouraged, gathered and then used properly.
The project team then works on improvements chosen against a highly prioritized list of issues, picking the issue that is failing the business the most. For example, if the users don't like how the interface for a certain task works, or there is a fault in the business logic. There will also be requests for additional functionality, generally ramping up as the users get accustomed to the first release. Ensure that developers are highly responsive and work on the areas that prove most painful to users today.
In many cases, someone else has done your heavy lifting elsewhere. For example, a lot of functionality is available from software as a service. Creating an equivalent function for in-house software may not be what the organization needs or even wants. A bespoke function requires the IT operations team for management, patches and upgrades, which all can be costly. A standardized, off-the-shelf function comes with predictable costs and known performance -- available for use far more quickly than a function that your organizations has yet to create, test and roll out.
Don't allow chokepoints in continuous delivery. When changes are ready, some teams will want to hold them until someone decides that there are enough changes to make it 'worthwhile' to roll them out to production. This is a mistake. The whole idea of continuous delivery is in getting changes out there as quickly and as often as possible.
Take the phrase 'as quickly as possible' seriously. Continuous delivery cannot be a silver bullet where speed solves all problems.
IT organizations must still test and log every change. Prior to rollout, the update must undergo automated checks to ensure that the operational environment can handle the change -- and the team should carry out remediation wherever possible to make updates smooth. Every change requires a rollback strategy in case it harms something in production. Help desk staff still needs education on the changes and how it will affect them. These checks and balances are even more important within a continuous delivery model than they are in the big-bang update projects.
Continuous delivery changes the perception of the IT department from a group that is preventing the organization from performing at its best to a team that is providing an optimum environment for the organization to compete and grow in its markets.
Tools of the trade
Plenty of software vendors make tools to help organizations implement continuous delivery.
Atlassian offers a full-lifecycle continuous delivery support system, called Atlassian Enterprise, that ties together Jira issue tracking, Confluence collaboration platform and its other products under one manageable system. Electric Cloud release automation tools -- ElectricFlow and ElectricAccelerator -- fully manage continuous delivery. Automic builds on its deep process capabilities to offer solid and wide-ranging continuous delivery capability. Other new players on the block include Xebia, Zend and Heroku.
For those who have the skills, a fully open source approach is possible, using Jenkins, Chef, Puppet, Ansible and other tools. Supported, enterprise platforms built on top of these open source tools come from companies such as Red Hat and CloudBees.
More incumbent vendors are also developing continuous integration offerings. CA Technologies has improved its project portfolio management tools and along with CA Release Automation, has a good approach. IBM also offers useful tools, particularly when you combine the Bluemix app development platform and the delivery tools within its cloud infrastructure of SoftLayer. BMC Software has also updated its IT management and operations tools, and provides software that helps in the continuous delivery journey.
The options are many. Finding the tools that best fit with your organization's and your IT team's needs is how success is defined. Taking newer, all-embracing tools from the likes of Atlassian, Electric Cloud or Automic will provide a better ongoing framework for the long term than trying to bend and re-use existing systems to fit this new approach.
