ITIL® and ASL® 2 Sound Guidance for Application Management and Application Development White Paper
- White Paper
- Business solutions
- Methods & frameworks
- Service management
February 23, 2016 |
25 min read
- White Paper
- Business solutions
- Methods & frameworks
- Service management
An update of our 2008 White Paper, this paper describes the interfaces between ITIL 2011 and the Application Services Library (ASL), showing similarities and areas of added value in both. The paper explains how both ITIL and ASL define the applications domain and provides an insight into how the frameworks can best be applied.
1. Introduction and conclusions
Introduction and conclusions
The White Paper published in January 2008 compared ITIL® V3 and ASL®. Since then, new versions of both ITIL and ASL have been published, prompting this updated White Paper which reflects the respective changes to the frameworks. The main differences lie in the slightly changed view of ITIL; regarding the scope of application management, the introduction of a couple of new ITIL processes, and changes in the naming of several ASL processes and clusters.
In May 2007, the OGC released a new version of ITIL. Now known as the ITIL Service Management Practice, and commonly referred to as ITIL, it brought together the former practices of ITIL and the new industry practices in IT service management to create a comprehensive service lifecycle.
One of the changes in this version of ITIL was the introduction of the formalized practice of application management into the service lifecycle. Aspects of application management are to be found in all five publications of the core guidance. In 2011, an updated version of ITIL was released by the Cabinet Office in which consistency between the books was improved and new processes were added.
This paper describes the interfaces with another IT framework, the Application Services Library (ASL). There are both similarities and differences between ITIL and ASL with respect to how each portrays the practice areas of application management and application development.
Both frameworks recognize added value in the other and the ASL BiSL Foundation and AXELOS, the custodians of ITIL, have produced this White Paper in order to provide guidance and understanding about the synergy and distinctness of each framework. This paper explains how both ITIL and ASL define and address the applications domain, and provides the reader with an insight into how the frameworks can best be applied.
The most important conclusions are summed up in the following paragraphs:
ITIL approaches the IT service management domain primarily by defining the phases of a service lifecycle. Within this perspective, it uses processes that detail parts of one or more phases. Alongside processes, descriptions of organizational functions and activities are also used to provide guidance.
ASL is primarily a process model, focusing on application management and the maintenance part of application development but with clear interfaces to the adjoining IT management domains of business information management and (IT) infrastructure management.
Much of the content of ITIL is generic, in the sense that it applies to all elements necessary to deliver a service; people, processes, products and partners. ITIL’s focus is on the customer experience of service and describes itself as customer service-focused. In IT service terms, this includes guidance on managing data, applications, infrastructure and the (technical) environment. It also contains detailed descriptions of the principles and gives more attention to subjects that are relevant to the application domain. This changes the previous perception of ITIL that it was primarily intended for infrastructure management, which was the view up to version 3, to the perception that it is intended to support all IT services. Indeed, it can be adopted for all services, IT or otherwise.
The ITIL publications give sufficient guidance for organizations that manage commercial ‘off-the-shelf’ applications but, if an organization maintains the applications and therefore actually modifies the source code, then ASL provides additional and more detailed guidance.
ASL and ITIL use the term ‘application management’ slightly differently. In ASL, maintenance (design, build, test, etc.) of the application is one of the main components of application management. Renewal of existing applications (‘renewal’ is a more radical modification than ‘maintenance’) is also included. In ITIL, maintenance and renewal of applications could be performed by either application development or application management, depending on the size and complexity of the changes. In ITIL, application management acts as a custodian of technical knowledge and expertise that relates to the management of applications, and it considers application development as one of the ways of acquiring functionality, alongside alternatives such as procuring applications from a third party, and utilizing cloud-based applications using software as a service. In this context, application and infrastructure management are elements of service provision, rather than the focus of it.
Mapping the relative value of ASL and ITIL to ITIL’s application management lifecycle shows similarities and areas of added value in both frameworks.
The demarcation between customer (the business) and supplier of IT services is more explicitly drawn in ASL than in ITIL. This gives a different perspective which can be of added value. Other points of interest in ASL are the specific application management/maintenance processes and examples, the dedicated scope (primarily application management/maintenance) and the fact that the language used will probably appeal more to people in the applications domain than those in a generic service management role. ITIL describes processes and activities that are common to both models (such as availability management, capacity management, requirements engineering and management of data and information) in more detail than ASL. Both frameworks address strategic aspects; ITIL addresses the generic service strategy while ASL focuses on the application strategy, using process descriptions.
Key similarities and distinctions exist between ASL and ITIL in their organization of information. This helps to provide context and scope for what parts of ITIL and ASL are similar to each other, and therefore mapped in this paper, and which are distinct.
1.1 Informational Similarities and Distinctions
ITIL and ASL both organize activities within defined layers; strategic, management and operational. ITIL and ASL both organize process activities within stages that, together, depict a lifecycle of sorts. From an application management perspective, both ITIL and ASL use similar stages and terminology to define these:
- Requirements Design
- Build and Test
Within ITIL, these stages exist at a micro level and apply to, for example a service, or at a macro level, service management as a whole, where lifecycle stages are defined as:
- Service Strategy
- Service Design
- Service Transition
- Service Operation
- Continual Service Operation
In contrast, ASL also defines macro level stages, but uses different terminology to describe them:
- Application management organizational strategy
- Application strategy
- Management processes
- Application support
- Application maintenance and renewal.
A key similarity here is each framework group’s processes and technical activities within stages. There is overlap and connectedness across several stages but, for the most part, the defined groupings (or ‘clusters’ as they are known in ASL), are semi rigid, in that the stage has primary ownership of the process area.
ITIL readers will be more familiar with stages and process terminology, while ASL readers will be more familiar with clusters and process terminology. For ease of reference as to which processes from ITIL or ASL are being discussed, see table 1.2 which puts them into comparative context.
ITIL provides guidance for the IT service management domain – which includes application management – and good practice for certain aspects of application development and maintenance. Most of ITIL’s guidance focuses on creating repeatable, measurable practices, processes and organizational functions for the provision of IT services. ITIL revolves around IT services. An IT service often consists of IT components such as infrastructure, data and applications that are produced outside the IT service management domain.
ITIL explains, in the five core publications, how to:
- Determine requirements and which IT services should be provided (ITIL Service Strategy)
- Design, create or change services and service management processes to meet business requirements (ITIL Service Design)
- Validate the utility and warranty of services and transition them into the live environment (ITIL Service Transition)
- Provide the services and support in an efficient and effective manner (ITIL Service Operation)
- Ensure that the services continually address future needs (ITIL Continual Service Improvement).
ITIL is structured around a revolving lifecycle, with five basic stages that flow and interact to manage IT services and support business outcomes, as shown in figure 2.1.
2.1 IT Service Chain
IT service providers provide IT services of value to the business organization. They do this by executing IT service management using an appropriate mix of assets. These include various resources and capabilities: management, organization, process, knowledge, people, information, applications, infrastructure, and financial capital. Internal and external suppliers of IT assets provide the IT service provider with applications, data, infrastructure and a (technical) environment, which the IT service provider assembles into IT services.
According to ITIL, the scope of IT service management extends partially into the domain of the supply of IT assets. The manufacture of standard products such as laptops, servers, operating systems, tooling and generic packaged applications is excluded from IT service management but the production of products made to order is (partially) included. This applies more often to applications than to infrastructural components. In the case of packaged applications that have to be extensively customized in order to be used effectively, the production of the standard application is excluded but any customization is included.
ITIL has defined a number of organizational functions that carry out processes and activities. The functions that are most relevant to this publication are application management and application development. In ITIL terms, the application management lifecycle is found in all areas of the service lifecycle.
It is important to realize that the actual maintenance and renewal (technical design, coding etc.) of applications is part of the service design stage. Part of the testing and validation of the application - internal testing by the application development or maintenance team - is executed at the service design stage as well. More testing and validation is executed at the service transition stage of the lifecycle. The ongoing operational management of the application occurs in the service operation stage of the lifecycle.
Figure 2.2 shows a common application management lifecycle with involvement from both application development and application management. In this diagram it is clear that application development will drive several stages with input from application management. In other cases application management will drive the stage with input and support from application development. Both groups are subordinated to the IT service strategy of the IT organization and their efforts are coordinated through service transition mechanisms and processes.
Application Management Lifecycle According to ITIL
- Requirements stage. The requirements for a new application are decided and brought together, based on the business needs of the organization. This stage is active primarily during the service design stage of the service lifecycle.
- Design stage. Requirements are translated into specifications. Design includes the design of the application itself, plus the design of the environment or operational model, that the application has to run on. Architectural considerations are the most important aspect of this stage, because they can impact on the structure and content of both application and operational model.
- Build stage. Both the application and its infrastructural environment (based on the operational model) are made ready for deployment. Application components are coded or acquired, integrated and tested. For purchased software, this will involve the actual purchase of the application, any required middleware and the related hardware and networking equipment. Any required customization will be done here, as will the creation of any required tables, categories, etc.
- Deploy stage. Both the operational model and the application are deployed. The operational model is incorporated into the existing IT environment and the application is installed on the updated environment, using the release and deployment management process described in ITIL Service Transition. Testing also takes place during this stage, although here the emphasis is on ensuring that the deployment processes and mechanisms work effectively; for example, testing whether the application still functions to specification after it has been downloaded and installed. This is known as ‘early life support’ and covers specialized support for a new or changed IT service for a period of time after its release. Support activities during this period can include review of key performance indicators (KPIs), service levels and monitoring thresholds, and provision of additional resources for incident and problem management. Early life support is covered in detail in ITIL Service Transition.
- Operate stage.IT services operate the application as part of the service delivery required by the business. The performance of the application in relation to the overall service is measured continually against the service levels and key business drivers. It is important to make clear that applications themselves do not equate to a service. It is common in many organizations to refer to applications as services; however, applications are but one component of many needed to provide a service to the business.
- Optimize stage. The results of the service level performance measurements are measured, analyzed and acted upon. Possible improvements are discussed and, if necessary, developments are initiated. The two main goals at this stage are maintaining and/or improving the service levels and lowering cost. This could lead to iteration in the lifecycle or to justified retirement of an application.
Most of the guidance on application management and application development is covered in the ITIL Service Design and ITIL Service Operation publications.
The Application Services Library comprises:
- A process framework for application management
- A dynamic collection of Best Practices that industry partners have contributed
- A maturity model, with a description of five maturity levels for each process
- An organization that offers support (publication, education, consultancy, certification) to those who wish to professionalize their application management.
ASL offers guidance for the application management domain, which is scoped more broadly than the ITIL definition; the domain responsible for all of the tasks and activities that are aimed at managing, supporting, maintaining and renewing existing applications and related data structures. In other words, economically sound support, maintenance and renewal of applications.
ASL emphasizes that business processes should be supported by information systems throughout their lifecycle. This entails managing and maintaining the software, databases and documentation. It includes impact analysis, design, build and testing. It also includes processes that ensure optimum availability, performance and the continuity of the applications with a minimum of disruption to business activities. Great importance is placed on policy-making that sits in line with the business (information) policies, to ensure long term alignment with the business.
ASL is positioned according to the IT management model of Professor Maarten Looijen (Delft University, the Netherlands), who distinguishes three forms of IT management: business information management, application management and IT infrastructure management. Business information management and IT infrastructure management are defined as follows:
- Business information management is the domain responsible for all tasks and activities that support the end user in the use of the application, acting as the customer of the IT organization. It includes defining the requirements for the applications and IT services
- IT infrastructure management is the domain responsible for all tasks and activities which manage, maintain and renew the IT infrastructure of the information system, including the operation of the information system.
The way this terminology differs from ITIL is illustrated in figure 3.1, in which the scope of ITIL’s IT service management is plotted against the way ASL describes the world; in which the scope of ASL corresponds with application management.
BiSL®, the Business Information Services Library, is a public domain framework that describes the primary processes of the business information management function at strategy, management and operations levels. BiSL focuses on the demand and use of information and related technologies, and it interfaces with the processes for the supply of IT services. The relationship of BiSL and ITIL is the subject of a separate White Paper (Meijer, 2013).
The ASL framework consists of six clusters of processes, divided into three levels: the operational and managing processes have a short to medium term perspective whereas the strategic processes look towards a horizon a couple of years ahead.
Application management organization strategy looks at the long term organizational development of the application management function, whether this is within an internal department or a commercial organization. Application management departments are often notoriously conservative and these processes help them think about the kind of application management services they want to provide. The services demanded by the users become so broad that it is difficult for both internal and external application management organizations to provide the full range. This forces a decision about which services should be provided by the application management organization itself and the services where it might be more appropriate to pursue a development partnership. Application management organization strategy prompts the application management department or company to consider not only its customers’ future needs but also its own future.
Application strategy deals with business and IT alignment, developing a long term strategy for the applications, in line with the long term strategies of the business organization. It is approached from two perspectives, that of the individual applications but also from the application portfolio in which all applications are considered in relation to each other. Application strategy looks both at technical issues and business issues, the latter addressing both the sector in which the organization operates as the organization itself – so it has to be done together with business information management. The main task that application management has, according to ASL, is to get these issues addressed.
The management processes ensure that all of the operational processes are integrally managed. Attention is paid to managing human resources, deadlines, revenue and costs, and internal and external quality (service levels).
Application support ensures that the current applications are used in the most effective way to support the business processes, using a minimum of resources, and leading to a minimum of operational interruptions. The primary objective is to keep the applications up and running. The four processes are similar to ITIL processes with the same names and with similar objectives but different content, due to the dedicated scope of application management when compared to the entire service management domain.
Application maintenance and renewal ensures that the applications are modified in line with the changing requirements, usually as a result of changes in the business processes, keeping the applications up-to-date. This is where the modifications to the software, data models and documentation are made. These processes are similar to activities performed during the initial development of applications but there are some fundamental differences between the initial development of applications and maintenance and renewal later on in the lifecycle. Unlike development, maintenance and renewal are affected by a number of complications:
- Heavier demands: a new release often has to be introduced at a set date in order to cope with changed legislation or because new products have to be introduced
- Shorter feedback cycle: the designer and programmer will be quickly confronted with shoddy work, which will have to be tackled promptly
- Fewer options for improvement, due to the restrictions imposed by choices made several years before: changes have to be made within the existing structure and the ideal solution often has to be sacrificed for a creative compromise.
Application support and application maintenance and renewal are closely related as they deal with the same application objects. The two connecting processes deal with transferring changed software and data to application support in a controlled manner. A parallel can be made with the DevOps movement that promotes close collaboration between development and operations.
4. ITIL and ASL
ITIL and ASL
As previously mentioned, ASL addresses both application management and certain parts of application development as defined by ITIL, excluding the development of new applications.
In order to better understand the similarities of and differences between ITIL and ASL, we have analyzed and mapped the ITIL and ASL processes onto each other, using the phases of the application management lifecycle as a structure for the analysis.
- Relevant ITIL processes: business relationship management, service portfolio management, demand management, requirements engineering
- Relevant ASL processes: application strategy cluster, quality management, impact analysis, design.
On a strategic level, the application strategy processes in ASL evaluate the long term alignment of the application portfolio with the business processes. These provide high level requirements and therefore have a strong relationship with ITIL’s service portfolio management.
In ASL, the focus is on realizing the functionality that is specified by the business information management domain and described in change requests. While ASL recognizes the importance of producing an application that also complies with non-functional requirements such as performance, throughput, disaster recovery capabilities and security, ITIL gives more detailed guidance on this aspect. This can be found in the service design technology-related activity requirements engineering.
- Relevant ITIL processes: requirements engineering, management of data and information, design coordination
- Relevant ASL processes: design.
ITIL Service Design covers this stage in detail, with an accent on overall requirements and how an application should fit within the infrastructure. Relevant topics are requirements engineering and management of data and information.
In ASL, the goal of design is to produce a functional design of a new release, which more technically-orientated people can translate into a technical design. Functional design, data model and test specifications are the ASL deliverables.
- Relevant ITIL processes: none
- Relevant ASL processes: realization, testing, implementation.
ASL’s realization process comprises technical design, programming and the initial unit test of the new or changed application component. The testing process tests the additions and changes to the application in a broader context, including performance-testing. The acceptance test is carried out in implementation.
The content of the ASL processes realization and testing is not described by ITIL, although service validation and testing in service transition describe various other kinds of tests. These tests are partly covered by the ASL process implementation.
- Relevant ITIL processes: change management, release and deployment management, transition planning and support, service validation and testing, service asset and configuration management
- Relevant ASL processes: testing, implementation, software control and distribution, configuration management.
ITIL Service Transition describes processes and gives guidance for the implementation of new IT services. These processes cover the integration of IT components such as applications into IT services: testing and other activities related to the transition to the operational phase. This is clearly related to the ASL implementation process.
Software control and distribution controls the physical relocation of software items from development to testing to approval and then to production. ITIL’s release and deployment management focuses mainly on ensuring that not only the software is ready for production, but also the requisite hardware and any non-technical activities. In addition to the actual commencement of production, release and deployment management also includes activities involving planning, design, construction, testing and implementation. As such, it appears to be similar to the maintenance and upgrade realm of ASL, although the emphasis lies elsewhere. This is because ITIL briefly deals with those activities that need to be performed in order to actually modify the software. Any modified software, for which ASL has defined the application maintenance and renewal processes, is approved within the definitive service library and is consequently included in the relevant release. ITIL places the emphasis on the roll out.
A great deal of attention is devoted to the manner in which efforts are made to ensure that the correct version of any software is distributed to the appropriate clients and desktops. ASL’s software control and distribution process deals with the physical make up of a release, ensuring that the appropriate versions are placed in the development, testing, acceptance and production (DTAP) environments, and hence also the roll out of the software. Compared to ITIL, ASL only provides a summary indication of all of these activities and concerns, requiring attention during the roll out of any new software release.
Whereas change management in ITIL addresses all kinds of changes, ASL restricts the scope of change management to changes in the functionality of the applications. For instance: running an extra production job is an ITIL change but not an ASL change.
- Relevant ITIL processes: incident management, request fulfilment, event management, access management, problem management, service asset and configuration management, technical management activities within capacity management, availability management, IT service continuity management, information security management
- Relevant ASL processes: use support, IT operation management, continuity management, configuration management.
The present version of ITIL includes more processes that correspond to the four ASL processes in this cluster than former versions. The scope of the ITIL process incident management has been reduced to handling interruptions and failures. Triggers from hardware and logging-software are processed by event management. Questions and standard changes, which are given to the service desk function, are dealt with by request fulfilment and not change management or incident management, as was the case in previous versions. Use support in ASL deals with all these kinds of ‘service calls’.
The tactical part of capacity management is called demand management and can be found in ITIL Service Strategy. This process doesn’t address the complete needs of the business organization but focuses on the capacity aspects. ‘Demand management’ is therefore a potentially confusing term because it is often associated with managing IT from a business point of view and by somebody representing the business. ASL includes the IT operation management process which covers both the capacity management and the availability management of applications that are in production. Capacity management according to ASL covers both the tactical and operational aspects of ensuring that there is enough capacity to allow the users to work with applications in accordance with the service levels that have been agreed.
ITIL’s IT service continuity management, information security management and access and configuration management (authorizations etc.) are clustered in ASL’s continuity management but are less comprehensively covered.
Availability management within ITIL remains comparable to the availability management activities within ASL’s IT operation management process although ASL focuses on the availability of the applications and refers to the interdependence with IT infrastructure management (and implicitly to ITIL) for availability of the infrastructure.
ITIL’s service asset and configuration management addresses elements of version control (part of ASL’s software control and distribution) and therefore has a relationship with this ASL process and with ASL’s own configuration management.
The ITIL processes are described in depth and often only in generic terms, allowing the guidance to be applied to both infrastructure and application services. In comparison to ASL, ITIL therefore offers added value for the application management domain.
- Relevant ITIL processes: change evaluation, service level management, service catalogue management, the seven step improvement process
- Relevant ASL processes: quality management, contract management, application strategy cluster.
ASL uses the term ‘problem’ to denote (potential) deficiencies in applications, tools, processes and skills. These problems are analyzed and acted on by quality management. ASL’s contract management is generally a source of tactical improvements. As mentioned under requirements, the application strategy processes in ASL evaluate the long term alignment of the application portfolio with the business processes. These provide high level requirements and therefore have a strong relationship with ITIL’s service portfolio management.
ITIL Continual Service Improvement measures the quality and relevance of applications in operation and provides recommendations on how to improve applications if there is a clear return on investment for doing so.
4.1 Additional Analysis
ASL also deals with some topics that are not directly related to stages of the application management lifecycle. These are described below.
Most of ASL’s application management organization strategy activities can be found in ITIL Service Strategy where the service portfolio of the IT service provider is described as well as strategy management for IT services and business relationship management. The service portfolio contains services that are currently provided (service catalogue), services in development (service pipeline) and services that are no longer provided (retired services). Strategy management for IT services defines, maintains and achieves the service strategy and therefore defines new services. In addition to this, ITIL Continual Service Improvement describes how strategic improvements can be achieved by periodical meetings with the customer regarding future developments within the business organization and environment. This topic is also covered by business relationship management. ASL describes these strategic areas in ten discrete processes which provide concrete guidance as to how to create and maintain a service catalogue within the context of a business plan for the applications management organization.
Financial management for IT services (ITIL) extends its scope beyond the IT domain into the business (information management) domain and therefore has a relationship with financial management (ASL) and financial management (BiSL).
ITIL has more processes that relate to services than just service level management: service catalogue management (managing the services that a particular customer can buy; this is part of contract management in ASL) and supplier management (ensuring that suppliers perform adequately; this is covered by ASL in two processes: supplier definition and supplier management).
ITIL doesn’t have separate processes for quality management (ASL) and planning and control (ASL) but ITIL Continual Service Improvement gives more than enough guidance for ensuring long term customer satisfaction and therefore has an important relationship with ASL’s quality management.
5. Appendix: Mapping ITIL to ASL
Appendix: Mapping ITIL to ASL
6. About the Authors
About the Authors
Machteld Meijer is a senior consultant in the field of IT management, an active member of the ASL BiSL Foundation and ASL/BiSL chief examiner.
Mark Smalley is ambassador at the ASL BiSL Foundation, and an IT management consultant at Smalley.IT.
Sharon Taylor is owner of the Aspect Group Inc and ITIL chief examiner.
Cabinet office (2011). ITIL Continual Service Improvement. The Stationery Office, London.
Cabinet Office (2011). ITIL Service Design. The Stationery Office, London.
Cabinet Office (2011). ITIL Service Operation. The Stationery Office, London.
Cabinet Office (2011). ITIL Service Strategy. The Stationery Office, London.
Cabinet Office (2011). ITIL Service Transition. The Stationery Office, London.
Looijen, Maarten (1998). Information Systems: Management, Control and Maintenance. Kluwer, Deventer.
Meijer, Machteld, Mark Smalley Sharon Taylor and Candace Dunwoodie, ITIL® and BiSL®: sound guidance for business-IT alignment from a business perspective, AXELOS White Paper, The Stationery Office, 2013
Van der Pols, Remko (2012). ASL 2 – A Framework for Application Management. Van Haren Publishing, Zaltbommel.
Van der Pols, Remko, Ralph Donatz and Frank van Outvorst (2012). BiSL – A Framework for Business Information Management. Van Haren Publishing, Zaltbommel.