Following the release of Mastering Digital Disruption with DevOps, the fourth report in the Disrupt series from Sogeti’s Trend Lab VINT, I wanted to share some insights into how we can all welcome digital disruption, risk and uncertainty, and bring about the innovation needed to create true digital enterprises.
Main Business Challenges
Many businesses operate large and complex IT environments with a variety of distributed applications installed, configured and supported in different ways.
As Thierry Hue of DynamicIQ puts it, the challenges faced by Business today fall into three areas:
- Operational Risk. It is difficult to ensure that applications are stable and that changes are applied efficiently and effectively. This is even more pronounced when dealing with highly configurable applications running on multiple environments which require a high frequency of changes. As a result, mistakes are often made when releasing a new version of an application, which leads to unnecessary production incidents.
- Delivery Delays. It is important to deliver new functionality and bug fixes as rapidly as possible. However, installing and updating applications can be time consuming resulting in long delays in implementing change.
- Resource Drain. Excessive resources are wasted on changes that should be easy to achieve, but which consistently take too much time and effort. These resources are diverted away from value-added activities.
As organizations look to ramp up their ability to deliver applications more and more quickly, unreliable deployments are an immediate bottleneck. Manual deployments based on outdated instructions, or semi-automated deployments using incomprehensible and unmaintainable scripting, are error-prone and time-consuming. Development and testing is stalled, causing frustration and delays.
The age of cascade development and long drawn out software projects is in decline. Businesses have a need for continuous delivery of new functions, and this requires a far more streamlined approach from IT.
Agile development methodologies applied pressure on delivery pipelines by introducing smaller, yet more frequent updates. Then came the business demand for faster and more frequent releases into production due to competitive pressures and market disruption.
Digital Disrupter Traits
Automation vs. Manual
Using the rough and ready definition of manual deployments, it is easy to see where they fail. It is safe to say that any deployment is manual if it is characterised by operators logging into various machines and following written scripts, but this is generally:
- Slow and inconsistent
- Prone to error and failure
- Lacking in visibility and traceability
This final criterion is more complex as it requires a better understanding of what happens to a deployment once the process is “complete.” This is because a deployment process is not a separate and independent event in time; once the deployment is run, team members still need to know what was deployed where, why it was deployed, and who performed the deployment—especially if a failure occurred. For example, if a push-button deployment exists but the system does not provide visibility into the process, team members have to sift through logs on numerous machines to track down the error—which is not just manual but also laborious.
Manual deployments based on outdated instructions, or semi-automated deployments using incomprehensible and unmaintainable scripting, are error-prone and time-consuming. Development and testing is stalled, causing frustration and delays. But even now some companies are still hesitant to automate.
Whether by automation or other means, the mechanisms to deploy the correctly configured service components should be established in the release design stage and tested in the build and test stages. Automation will help to ensure repeatability and consistency. The time required to provide a well- designed and efficient automated mechanism may not always be available or viable. If a manual mechanism is used, it is important to monitor and measure the impact of many repeated manual activities, as they are likely to be inefficient and error-prone. Too many manual activities will slow down the release team and create resource or capacity issues that affect service levels.
- Manual deployments are inherently slow and error-prone.
- Deployment automation used only in development or only in operations may help one silo, but leads to a hand-off where changes to the process may be insufficiently communicated.
- Automated deployments provide superior audit trails.
- An automated deployment infrastructure provides a framework to build upon. Additional activities such as automated functional testing can leverage the deployment infrastructure.
- Deployments standardized across environments must still take into account environmental differences. The environment configuration is a key concern.
This situation seems to lead to a single question, “Is automation really worth the time and effort?” If you ask teams with automated deployments, the short answer will most likely be similar to, “Yes, but it depends on what you mean by automated.” As it turns out, a scripted process is not really an automated process. For those in the business of providing automation, a much higher threshold is set: If the “automation” does not address the patterns of deployment failure, then the process is not automated.
Manual deployments are slow, painful, and fail in production; yet, they are still extremely common in the IT industry. Why? A simple answer may be that until recently, powerful deployment automation tooling was not available. However, even today, there is a great deal of resistance to automating deployments. Deployment teams remain comfort-able with their existing practices. Because they are at the keyboard executing the manual steps, they feel in control.
Manual deployments are broken and cannot be saved by more disciplined deployment engineers. The rote work of executing a deployment should be delegated to an automated system that can execute a process consistently. However, not all automated solutions are alike. Whether you are looking to buy or build a deployment automation system, there are some “must have” goals to keep in mind. A mature deployment system should be characterized by:
- Reliable, highly successful deployments—especially in production
- Easy deployments—encouraging teams to take new builds faster
- Fast deployments—allowing early test environments to be on the newest build as possible
- Complete audit trail—spanning across all environments
- Robust security and separation of duties—controlling who can do what, when, and where
To achieve these goals, an automation solution should contain at least a few key elements:
- The entire deployment should be automated
- The deployment should target specific environments and automatically adapt itself to a target environment
- The files being deployed should come from a controlled artefact repository
- Security and visibility should underpin the entire system
Digital disruption refers to changes enabled by digital technologies that occur at a pace and magnitude that disrupt established ways of value creation, social interactions, doing business and more generally our thinking. Digital Disruption can be seen as both a threat and an opportunity.
According to Gartner, by 2018, 50% of global enterprises will implement application release automation as part of a DevOps initiative, up from less than 10% today.
Providing fast, dynamic support to the business through the provision of continuous delivery of incremental functionality should be the top priority for any head of IT. However, just speeding up the flow of code from development-to-operations is not enough: it has to be fully managed and audited, ensuring that new apps, enhancements and updates are ready to do business. A properly implemented DevOps strategy, led top-down by the business, can enable organisations to be more competitive by delivering richer services to their customers faster.
Things to Remember:
Well-planned and implemented release and deployment management will make a significant difference to an organization’s service costs.
A poorly designed release or deployment will, at best, force IT personnel to spend significant amounts of time troubleshooting problems and managing complexity. At worst, it can cripple the environment and degrade live services!
Application Release Automation (ARA) is a relatively new, but rapidly maturing area of IT. As with all new areas there is plenty of confusion around what Application Release Automation really is and the best way to go about it. There are those who come at it with a very developer-centric mind-set, there are those who embrace the modern DevOps concept and even those who attempt to apply server based automation tools to the application space. One thing is for sure, ARA is a Digital Disruptor.
Application release automation (ARA) refers to the process of packaging and deploying an application or update of an application from development, across various environments, and ultimately to production. ARA solutions must combine the capabilities of deployment automation, environment management and modelling and release coordination.
Relationship with DevOps
ARA tools help cultivate DevOps best practices by providing a combination of automation, environment modelling and workflow management capabilities. These practices help teams deliver software rapidly, reliably and responsibly. ARA tools achieve a key DevOps goal of implementing continuous delivery with a large quantity of releases quickly.
Continuous integration and delivery have emerged as the next set of concepts following the interest in Agile and DevOps. Implemented correctly, the principles of CI can streamline and optimize the software lifecycle from start to finish.
DevOps promises much, and an effectively implemented DevOps strategy can have a powerful positive impact on business performance. Simply speeding up the movement of code from development through testing to operations will result in more errors and downtime. Putting in place a set of automated processes based on solid policies ensures that code flows as it should do. Abstracting systems of engagement away from existing systems of record provides a means of optimising continuous delivery to the business and its users of IT. For many organisations, an approach of ‘refurbishment’ and continuous improvement of the system of engagement will provide the greatest return on investment, leading to a measured migration to a new world of composite applications.
Relationship with Deployment
ARA is more than just Software deployment automation – it’s deploying applications using structured release automation techniques that allow for an increase in visibility for the whole team. It’s the combination of workload automation and release management tools as they relate to release packages and movement through different environment within your DevOps pipeline. ARA tools help you regulate your deployments, how you create and deploy environments and when and how to deploy releases.
The intersection of DevOps with IT operations is a two-way street — even as developers increasingly take on more of operations, IT Ops pros must think more like app programmers.
The technical changes that come with establishing a DevOps culture affect the IT infrastructure even if separate IT operations teams still manage day-to-day matters. New application development practices such as containerization, microservices and release automation, as well as new infrastructure management techniques that require programming skills, mean IT Ops pros must learn new tricks to keep that infrastructure running smoothly.
As DevOps evolves, greater collaboration between Devs and IT Ops will be the order of the day.
Continuous Delivery / Continuous Deployment
If the definition of Continuous Delivery is to make production updates available for production deployment, then Continuous Delivery stops at production’s door. Continuous Deployment is the next step, where approved updates are not just made available for production deployments, they can be automatically deployed into production.
Using Application Release Automation (ARA) means no longer needing to maintain custom scripts for deployment, configuration and provisioning. Users move beyond islands of automation and separate practices for PROD and non-PROD. ARA enjoys the benefits of having release coordination combined with deployment automation across the Continuous Delivery pipeline, including fully compliant PROD deployments across the entire IT and ITSM stack.
Production-proven Release Automation ensures predictability and compliance for both production and lower environments deployments.
Who are the Innovators in the ARA tool arena?
A disruptive innovation is an innovation that disrupts an existing market. The term is used in business and technology literature to describe innovations that improve a product or service in ways that the market does not expect, typically by lowering price or designing for a different set of consumers. Some of the innovators include:
ARA addresses the identified business challenges by:
► Reducing the opportunity for human error, thereby driving down Operational Risk.
► Accelerating change, thus minimising Delivery Delays.
► Reducing the time and effort required to deliver application technology change, thereby eliminating Resource Drain.
Application Modeller ARA Integrated Configuration Environment
As Thierry Hue of DynamicIQ puts it “The idea of the Integrated Configuration Environment is to make a parallel with the IDE (Integrated Development Environment) where you should manage your configuration and environment like you manage your code and binaries.”
Automic Release Automation ARA deployment process
Gartner Market Guide for Application Release Automation Solutions
20 July 2015 | ID: G00275085
Growing demand for faster and even continuous delivery of new and better applications is driving investment in ARA solutions that reduce friction across the entire application development life cycle. Prioritizing automation, environment management and release coordination needs is imperative.
- Prioritize automation, environment management and release coordination capabilities based on an assessment of your current and planned deployment processes.
- Evaluate solutions from smaller, independent vendors as well as those from large IT operations management (ITOM) software vendors to compare best-of-breed innovation with broader DevOps tool portfolios.
- Require time-to-value requirements of three months or less in vendor evaluation.
- Require use-case-oriented proofs of concept (POCs) and active customer references.
Sogeti, ARA and Digital Transformation
Sogeti’s Digital Transformation Services will shorten the time it takes to reduce your Digital Debt and create the foundation for the New Style of IT. Thereby enabling you to implement Application Release Automation in a greatly reduced time frame.
We recommend that you assess your application life cycle management maturity — specifically around your deployment processes — and seek tools that can help automate the implementation of these processes as they are now, and as you intend them to be across multiple development and operations teams and platforms. Helpful next steps include:
- Establish requirements for applications to narrow the scope of evaluation targets and to determine whether one tool or multiple tools will be required.
- Prioritize integrations with existing development and ITOM tooling (especially cloud infrastructure or cloud management platform tools) in product evaluation criteria, with an eye toward using these tools in your broader provisioning and configuration environment.
- Organizations that want to extend the application life cycle beyond development to production environments using a consistent application model should evaluate development tools with ARA features, or ARA point solutions that provide out-of-the-box integration with development tools.
If you are interested to discover how these ideas can become a reality for your business, you can download Design to Disrupt: Mastering Digital Disruption with DevOps here or give us a call on 0330 588 8200.