The road to automated applications management

Effective management of a company’s full application portfolio is vital to the success of the business, yet it is not an especially glamorous activity within the IT world — and it’s typically associated with high cost, manual processes, human error and ineffective resource allocation. In other words, it’s a perfect candidate for automation. Automated applications management, backed by artificial intelligence (AI) and machine learning, can save a company as much as 40 percent (depending on the current state of maturity) over 3 to 5 years by reducing IT labor costs and improving efficiency and productivity. But companies need to understand that the transition from manual to automated applications management processes can be complex, time-consuming and expensive, at least in the early phases of a project when most of the scoping, planning and startup costs are incurred.

Another key point is that automation is an ongoing process that’s part of a continuous improvement strategy, not a one-and-done activity. The long-term goal is to move from manual labor to a futuristic world of self-adapting robots that take advantage of AI to drive continuous system optimisation.

Automation is transforming IT services

But you have to start somewhere. For most companies, that means taking one step at a time, implementing one discrete project, then evaluating the benefits and lessons learned, before taking the next step.

There are two typical approaches: The company can take on the project on its own or hire a managed service provider to see the project through. 

Service providers typically have pre-integrated platforms or automation solutions that provide advantages in speed to adoption, productivity and outcomes. Customer-developed automation solutions are typically more piecemeal in nature, having evolved incrementally, and thus take longer to realise value due to training needs, tools familiarity, and governance and adoption challenges.

What’s more, organisations that go it alone bear the first-year costs and, once the system is up and running, own the risk for achieving the business case associated with the project — for example, the cost savings, quality or capacity improvement.

In the second option, companies enter into a 3- to 5-year managed service contract whereby that initial financial hit is spread over the term of the contract, and the managed service provider owns the risk associated with achieving the outcomes and takes responsibility for the ongoing management of the application portfolio.

In either case, companies need to be fully aware of the technical and cultural changes required to successfully achieve increased levels of automation in the application management process.

Elements of automation

Here are some of the key steps in the transition from manual processes to automation:

Evaluation: It’s important to identify the sources of time-consuming support activities, also known as toil. This helps define the implementation scope and the respective treatments for the activities taking up the highest proportion of the support effort. Evaluation is both a one-time initial effort and also an ongoing activity that identifies issues and drives increased optimisation.

Time-consuming activities that are opportunities for automation can be identified in these ways:

• Analyse application support tickets for repeating incidents and problems to identify root-cause analysis and resolution. Machine-learning algorithms can be used for pattern analysis to help sort through massive numbers of tickets to identify the most often-repeated events. Value stream mapping exercises can be used to identify instances of the “only Brent knows how to fix this” syndrome, also known as the “hero syndrome.” Or they can identify the situation where handoffs fail between different service providers siloed into separate domains, such as applications, network and infrastructure. These exercises can also identify lack of communication with users, to be sure they are notified when the problem has been fixed.
• Examine unplanned work for opportunities for automation in application development and operations. Capturing metrics around mean time to repair (MTTR) allows businesses to identify a need to use automation to increase quality and consistency.

Onboarding: Before automation tools can be deployed, the application portfolio needs to be evaluated and set up to work effectively with the new tools. This might require coding, modeling, reorganising the application architecture or adding APIs to overcome the lack of automation interfaces.

One potential hurdle to automation that needs to be overcome is the lack of data that’s required to make an informed decision on the return on investment (ROI) for automation and to reap the benefits of advanced analytics. Sometimes data is siloed and not made available to everyone who needs to see it.

Without holistic analytics it is difficult to see the forest for the trees. Analytics are necessary across the entirety of the service domain, which includes monitoring data, change data, incidents, life-cycle management data and automation data. 

Ideally, data from various sources is combined in a data lake where analytical processes can support the identification of repetitive patterns to help identify opportunities for optimisation. An example might be the application of a heat map to see which monitored components are experiencing the most common problems over time.

Applying AI algorithms is possible only with good underlying data. There is no magic here, and without the collation and recording of good data, AI is simply not possible.

Baselining: Once onboarded, it is critical to baseline the applications and their operational environment. The baseline is vital to enable automation to identify when applications are performing worse or better than they do under current conditions. Additionally, future instrumentation is going to rely heavily on the data collected during the baselining process.

Activity development: The final step of automation is creating the equivalent activities that facilitate machine-led processes typically associated with toil. Here are some of the common targets:

1. Application deployment. Automation of the release of application changes and configuration at various stages of the application life cycle, such as build, test, stage and production. These tend to occur once, with minor enhancements over time. Opportunities include automated testing, automated release pipelines, automated code scanning and automated build evaluation.

2. Corrective actions. Development of the necessary code and scripts required to take corrective action when there is a known operational issue. These are the most expensive and are usually unique automations, as they are very specific to the application and the repair.

3. Repetitive actions. Examples include “daily checks” where some form of manual check is undertaken to validate the application’s health.

4. Data manipulation. This occurs where a request is made to transform some data in support of the application process.

5. Operations. These are typically related to stop, start, scaling services up and down, or disaster recovery.

Tooling

To drive improvements in efficiency, investment in next-generation tools is needed. Simply augmenting or upgrading existing tools is not enough and will inhibit the productivity savings that would be possible through a more holistic revamping of the service operational toolset.

The tools should include enhanced monitoring that gives deeper insight beyond infrastructure utilisation. Modern application performance management (APM) tools go beyond basic performance monitoring for a single application to understand the dependencies and relationships among application and application components. Moreover, APM tools have started to incorporate AI to analyse the entire application stack, which facilitates automated root cause identification. This is a major productivity boost that helps alleviate some of the workload associated with manually intensive data crunching and investigation.

Automated resolution requires still more tools that depend on platforms, operating systems and application infrastructure. In addition, there must be runbook orchestrations that can link incidents with resolution. Furthermore, resolution automation requires the availability of programmatic interfaces. If these interfaces do not exist, it’s possible to leverage robotic process automation (RPA) tools that automate human interactions with the applications but can expose a programmatic interface to the business.

Implementation of these tools, plus the necessary development of workflows and scripts, is a key component of the upfront investment required as part of automating applications management.

Cultural change

Cultural change has a huge part to play in effective automation adoption. If change requests are required for every minor change to an environment, this will become a major inhibitor to adoption. Processes, workflows, approval gates — all need to be redefined to ease the adoption of greater levels of autonomous change.

There also needs to be alignment with a DevOps mode of operation where more frequent, smaller changes often result in less risk than a more traditional waterfall release cycle.

In the context of automated workflows, the process of effective testing and demonstration through pilot adoption can build stakeholder confidence and alleviate concerns that unmanaged change will create risk in the environment. Automated approval workflows can apply control gates that incrementally allow adoption to move from a traditional mode of operation to a highly automated one.

Achieving automated app management

The utopian vision for application management automation would be a totally automated, lights-out environment with full autocorrection and self-healing capabilities. Where new applications are being developed using cloud-native technologies, this vision is far easier to achieve. Automation is designed in from the outset with the objective of achieving a zero operations operating mode. However, the typical portfolio contains a mix of legacy, mainframe and software-as-a-service (SaaS) applications that had been developed when the automation technologies were not as sophisticated or designed from the outset to aid in the application operations.

Automating management of these mixed environments promises to:

Increase capacity — by allowing humans to do work not well-suited to machines

Improve quality — by avoiding mistakes and helping augment human decision making by identifying the root causes of problems

Increase speed — by reducing detection times and speeding resolution of incidents and problems, and speeding the deployment of code

Reduce cost — by reducing the manual labor effort required 

Also, it’s important for CIOs to understand that the process of setting up the automated system is itself labor-intensive. For example, putting together an inventory of applications and evaluating the application portfolio involves questionnaires, interviews with key stakeholders and collating datasets.

Deciding what treatments to apply, building the toolset and onboarding applications also require the hard work of human experts in this field. 

The investment in automation creates a sustainable mode of operation, whereby it is possible to avoid a linear increase in the number of support personnel as numbers of applications or complexity in the portfolio increases.

This optimisation creates the opportunity for organisations to reinvest savings in initiatives that create greater business value and see the ratio of effort spent on operations swing far in favor of development projects.

The current demand to reduce costs year over year will only be possible with ground-up automation that is applied as new applications are developed. With DevOps methods applied across a larger proportion of the portfolio, the operations workload will shift from labor-intensive to being highly automated and self-sufficient for those organisations that are most successful in executing this shift.

Learn more about automated applications management.