ITIL Application Management | In-Depth Guide
The IT Infrastructure Library (ITIL) is a popular framework for delivering effective IT services to customers and internal users. Application management is a core part of this, dealing with how we furnish users with the tools they need to carry out defined tasks within internal processes.
Like any other aspect of ITSM, the goal is ultimately to deliver the best quality services to users while minimizing the burden placed on our internal IT resources.
Today, we’re going in-depth on implementing the ITIL framework for application management.
Specifically, we’re going to cover the basics of what application management means and what it achieves before drilling into the specific stages of the lifecycle outlined in the ITIL framework.
We’ll then check out some of the kinds of tools that IT teams can use to support their efforts, before wrapping up by looking at how Budibase makes it easier than ever to deliver and manage internal tools for a vast range of use cases.
Let’s dive right in.
What is application management within ITIL?
In the ITIL framework, application management comprises all activities and processes around providing apps for users - from procurement and development - to hosting, deployment, maintenance, and administration.
More specifically, the focus is on providing a repeatable system for making key decisions across the lifecycle of applications from a technical, financial, and operational point of view.
As we’ll see in more detail, the ITIL framework prescribed a six-stage approach to managing applications across their service life.
For now, we just need to be aware that these stages are:
- Define,
- Design,
- Build & Test,
- Deployment,
- Operation,
- Optimization.
As such, this draws in a range of different responsibilities and mandates within the IT team. This ranges from the CTO all the way down to delivery teams, including technical roles and project specialists.
Implementing ITIL application management means formalizing company-wide policies, processes, and procedures to govern how software tools are procured, managed, and delivered to users.
You might also enjoy our glossary of ITIL processes .
What does application management achieve?
So, why is this important?
The core aim of ITIL is to leverage structure and repeatability in order to minimize risk and maximize efficiency when delivering IT services.
We can break this down into a few key issues.
The first is service quality. We can characterize this as how effectively our services meet the needs of on-the-ground users.
How we operationalize this will obviously vary from service to service.
For example, measuring ticketing systems against first-time resolution rates.
In any case, one of the central benefits of ITIL application management is providing us with a rational framework for determining the most effective way to meet our service objectives with the least resources.
Of course, this also ties in with efficiency. That is, we’re ultimately trying to use ITIL to help us determine the most cost-effective solution for delivering particular services.
Lastly, but perhaps most importantly, we also need to consider risk. This can come in a few key forms for IT teams. Broadly speaking, though, we’re dealing with financial risk or operational risk.
The former is pretty easy to wrap our heads around. An obvious example is avoiding wasting resources on ineffective or unsuitable solutions.
For ITSM, operational risk can relate to data loss, service interruptions, poor process adherence, compliance issues, inefficiencies, human error, and other factors. As we’ll see, one of the key ideas in application management is helping us to predict and manage these risks.
You might also like our round-up of the top ServiceNow alternatives .
6 stages of the application management lifecycle
Now that we understand ITIL application management and its goals, we can explore the six constituent stages we outlined earlier.
Let’s take each one in turn.
1. Define
Like most projects, we start with gathering requirements. In the case of application management, it’s important to note that we’re initially dealing with service-level requirements. We’ll then include more technical requirements later.
So, the first phase is for IT teams to engage with business-line colleagues to define requirements around a target process.
There are a few key priorities here.
One is alignment between IT and business colleagues. Rather than one team’s input taking precedence over the other, the idea here is that we work collaboratively, with IT as a service provider, to define process improvements strategically.
At this point, we don’t necessarily need to have a clearly established idea of the kind of intervention we’re going to make. For instance, a custom development, off-the-shelf tool, or modification to an existing platform.
This comes later.
Instead, by the end of this stage, our goal is to create a shared understanding of the process-level changes that our eventual solution will help to support. As such, some of the key IT roles at this stage include business analysts, systems engineers, and project managers.
2. Design
Next, it’s time to start designing our solution. In the first instance, this means translating the business-level requirements that we defined in the previous stage into technical requirements.
This includes analyzing the total cost of ownership of various types of solutions, including custom builds, COTS tools, or other options. The goal here is to determine which of these can most cost-effectively meet our needs.
Beyond this, our next steps can diverge somewhat, depending on which approach we choose.
In the case of a custom build, we might create wireframes, outline development tasks, begin planning our infrastructure needs, or even start creating prototypes to demo to internal users and seek feedback.
Alternatively, we might begin a procurement process for an off-the-shelf solution, including determining the additional work needed to facilitate this, including patch management, integrations, hosting needs, and more.
In both cases, we’ll also need to plan for deploying our solution, including our infrastructure needs, as well as any training and change management efforts we’ll require.
As ever, design within ITIL application management is an iterative process that requires collaboration between IT, departmental leaders, and end users.
3. Build and test
Once we’ve completed the design stage, we can start to put our plan into practice. The goal here is to actually build the solution we designed in the previous stage and apply any learnings or required changes to it based on testing.
Typically, this is where things are handed over from project to development teams.
Again, the exact steps here will obviously vary from one application project to the next.
We’ll carry out any coding, integration, and UI design work that we identified in the design stage - whether this is to build a tool from scratch or to configure an existing solution.
While many internal development teams still rely heavily on traditional development tools for custom builds, an increasing number are turning to low-code platforms to ship professional, performant solutions in a fraction of the time.
We’ll see what Budibase brings to the table in this regard a little later.
As the build progresses, we might encounter unforeseen problems or requirements, such as additional infrastructure needs or software dependencies that we didn’t account for.
After our initial build, the next step is testing. There are several elements to this, from a technical and business perspective.
The most obvious is unit testing for functional issues. That is, we’ll need to confirm that individual elements and the system as a whole behave as intended. Additionally, we’ll need performance testing to ensure that our system can handle our expected usage.
Besides the technical side of testing, we also need to confirm that our solution is capable of solving the underlying business problem at hand. For instance, identifying fringe cases within the relevant internal process or measuring efficiency gains.
4. Deployment
The next stage in the ITIL application management framework is deployment.
Again, there are a couple of aspects to this.
The first is pushing our solution live, whether this means migrating to a production environment, installing on local machines, or whatever other hosting method we might have chosen earlier.
With careful planning, this should be a relatively easy process, but we’ll still need thorough monitoring to ensure everything goes smoothly.
However, there are additional aspects of rolling out our application that we’ll need to be aware of.
The first is administrative work, including tasks like setting up user accounts and handling permissions.
Then, there’s training. Earlier, in the design stage, we should have identified any upskilling that will be required for colleagues to use our application correctly. Our task now is to deliver this, ensuring that they understand what’s required to carry out tasks within their role.
5. Operation
Operation is the day-to-day management of our application. The goal here is to maintain uptime, cover general admin tasks, provide support, and monitor performance.
The top priority, of course, is to keep our applications live, functioning, and accessible.
This involves routine tasks like uptime monitoring, maintenance, user support, bug fixes, administration, and more. So, we might need the expertise of several teams, including support, development, DevOps, product, and others.
On top of this, we’ll need to monitor and manage performance in terms of the underlying processes that our applications address. For example, in the case of a ticketing system, we’d likely monitor KPIs like first-time resolution rates or user satisfaction.
The goal is to maximize the value that we derive from our applications.
Within ITIL application management, the operation stage can also include certain kinds of changes to our solution. More fundamental or extensive changes will be handled in the next stage.
For now, we’re mainly dealing with things like patch management and updates, as well as any other work required to respond to compatibility or compliance issues.
6. Optimization
Lastly, we have optimization. In the context of ITIL application management, this basically means continuous improvement across our app’s functional, technical, and service-quality performance.
There will often be an overlap between these. For instance, if we improve the technical performance of our applications by improving server response times, we’ll also likely see a corresponding improvement in service delivery.
There are essentially three kinds of optimization we need to consider. The first is monitoring the current application for opportunities to improve any of the three areas we mentioned a second ago.
The second is predicting and planning for how our requirements might change over time, preventing future bottlenecks. For instance, adding new functionality or scaling out usage.
The third is using what we have learned to identify opportunities for improving underlying business processes. For instance, eliminating redundant or menial steps within manual processes through automation.
In all cases, the key is for IT and business-line colleagues to collaborate, ensuring that our internal tools remain fit for purpose well into the future without overly burdening technical resources.
Tools for application management
Now that we’ve seen each of the constituent stages of ITIL application management, we can start to think about some of the technology that helps us to utilize this framework.
Obviously, it goes without saying that traditional development tools like IDEs, DevOps platforms, infrastructure monitoring tools, version management, project boards, and design libraries play a huge role here.
But, the ITIL framework also presents some unique challenges for IT teams.
One is collaborating between IT teams and service users. The tricky thing is handling this across all stages of the application management process without creating excessive administrative work.
So, it’s important to consider how we can streamline communications using dedicated tools such as feature request forms, product surveys, workload managers, ticketing systems, and approval apps.
On top of this, we must be cognizant of big changes in the way teams build internal applications.
Perhaps the most important shift here has been the explosion in popularity of low-code development over the past number of years.
IT teams are under increasing pressure to ship solutions at pace. Low-code platforms help to alleviate this burden by empowering developers and other technical colleagues to design, build, deploy, and manage applications in a fraction of the time.
Let’s see what Budibase brings to the table.
Budibase for ITSM teams
Budibase is the open-source, low-code platform that empowers IT teams to turn data into action.
With intuitive design tools, autogenerated UIs, low-code automations, and extensive customization options, it’s the ideal solution for colleagues, including data professionals, systems architects, solutions engineers, and more, to build professional solutions with totally optional custom code.
Build custom applications on top of any data, with dedicated connectors for directly querying RDBMSs, NoSQL tools, REST requests, spreadsheets, and more - alongside our built-in low-code database.
We also offer cloud deployments, optional self-hosting, custom plug-ins, free SSO, air-gapped deployments, and more.
Budibase is the fast, cost-effective way to build, deploy, and manage internal applications. Check out our features overview to learn more.