Application Services Library

1. What Is Application Services Library?

Application Services Library, usually shortened to ASL, is a framework for managing business applications after they go live. It gives IT leaders and application managers a structured way to run, maintain, improve, and renew applications over time rather than treating support, enhancement, and lifecycle decisions as separate activities.

In practical terms, ASL sits at the intersection of application support, change delivery, and governance. It helps answer questions such as: Who owns application performance? How should change requests move from business need to release? How do we decide whether to improve, replace, or retire an application? Consultants commonly use it when clients need more discipline around application management in broader information technology improvement efforts.

ASL is best understood as an application management framework, not just a help-desk or infrastructure model. Where other approaches focus on servers, networks, or enterprise-level controls, ASL focuses on the application estate itself and the organization needed to keep that estate useful, stable, and economically sound.

2. Origin and Background

ASL was created and codified in the Netherlands, and it is most closely associated with Dutch practitioner and author Remko van der Pols. It was popularized in the early 2000s through practitioner literature, the ASL Foundation, and later the ASL BiSL Foundation. Some sources emphasize the broader practitioner community behind the model, while others focus more directly on van der Pols and his co-authors; what is clear is that ASL emerged from real-world application management practice rather than from a purely academic setting.

The framework was developed to address a gap that many organizations faced: ITIL had become the dominant reference for IT service management, but it did not fully address the ongoing management of business applications themselves. Companies needed a clearer operating model for application maintenance, enhancement, release coordination, lifecycle planning, and the relationship between business demand and technical delivery.

ASL became widely known first in the Benelux market and then more broadly among organizations with complex application landscapes, outsourced support arrangements, or mission-critical legacy systems. It is often discussed alongside BiSL, which addresses business information management on the demand side, and ITIL, which addresses infrastructure and service operations more broadly.

3. How Application Services Library Works

The core logic of ASL is simple: application management is not one activity. It includes keeping applications stable today, changing them safely tomorrow, and making sound long-term decisions about their future. ASL therefore separates operational work, change work, management controls, and strategic lifecycle thinking into distinct but connected domains.

ASL literature commonly groups its processes into six clusters. You do not need to memorize every process to use the framework well; the value comes from understanding the different kinds of work that must be coordinated.

What makes ASL useful is the connection across those clusters. A recurring incident may reveal a code defect. A pattern of defects may point to weak release discipline. Weak releases may reflect poor prioritization, vendor oversight, or unclear lifecycle direction. ASL helps a team trace problems back to the right managerial or strategic cause instead of treating every issue as a ticket to be closed.

In that sense, ASL is both a diagnostic framework and an operating model framework. It does not merely describe process boxes; it helps organizations decide how responsibilities should be split across business stakeholders, internal IT, application teams, and external suppliers.

4. When to Use Application Services Library

ASL is most helpful when an organization depends on a meaningful portfolio of business applications and is struggling to manage them coherently. Typical situations include fragmented support ownership, growing change backlogs, inconsistent release quality, duplicate applications, rising maintenance cost, or tension between business demand and IT capacity.

It is especially powerful in larger enterprises, regulated industries, and organizations with legacy estates, multiple vendors, or shared-service IT models. In those settings, application failures are costly, accountability is often blurry, and process discipline matters. ASL is also useful when leadership is redesigning application support and change processes as part of broader service management improvements.

To use ASL meaningfully, teams typically need an application inventory, incident and problem data, change and release data, role definitions, service-level commitments, cost information, architecture context, and some understanding of vendor contracts or sourcing arrangements. A quick diagnostic can be done in a few weeks, but a credible redesign of the application management model usually takes longer because the hard part is not drawing the process map; it is validating responsibilities, governance, and metrics.

ASL is not a great fit for every situation. It is less useful for a very small startup with one product and one engineering team, where lightweight product management and DevOps practices may be enough. It can also mislead teams if they apply it mechanically in a fast-moving digital environment and assume every application should pass through the same formal process. Modern practitioners tend to use ASL as a governance and accountability framework, adapting its logic to agile delivery, product-centric teams, and cloud-based operating models rather than implementing it as a rigid bureaucracy.

5. How to Apply Application Services Library: Step-by-Step

1. Clarify the decision and scope. Start by defining the business question. Are you trying to improve service quality, reduce run cost, speed up changes, redesign responsibilities, or make lifecycle decisions about a set of applications? Be explicit about the time horizon and the scope: which applications, business units, geographies, vendors, and support teams are included.

2. Gather the required inputs and data. Collect the minimum facts before workshoping the model. That usually includes incident volumes, severity trends, change lead times, release frequency, defect rates, application criticality, support costs, SLAs, audit findings, architecture dependencies, and stakeholder interviews. Good ASL work combines hard operational data with qualitative evidence from users, business owners, and support teams.

3. Define the units of analysis. Decide whether you are assessing individual applications, application families, platforms, support towers, or vendor-managed service domains. Many teams fail here by mixing a major ERP platform, a small reporting tool, and a mobile app in the same analysis without adjusting for complexity and business criticality.

4. Construct the current-state ASL view. Map how work actually flows today across the six ASL clusters. Do not start with the official process manual; start with reality. Who handles incidents? Who approves changes? How are releases bundled? Who owns quality, cost, and capacity decisions? Which lifecycle choices are made deliberately, and which are simply drifting?

5. Analyze gaps, handoffs, and root causes. Look for failure points between clusters, not only within them. Typical findings include unclear ownership between production support and development, weak prioritization from the business, redundant approvals, poor defect feedback loops, or no forum for application lifecycle decisions. This is often where weak IT governance becomes visible.

6. Design the future-state operating model. Use ASL to define clearer roles, decision rights, escalation paths, release disciplines, service commitments, and lifecycle forums. For each process cluster, specify what good looks like, who is accountable, what metrics matter, and how the business, application teams, infrastructure teams, and suppliers interact.

7. Translate insights into actions and metrics. Convert the diagnosis into a practical plan: governance changes, process redesign, SLA revisions, tooling changes, vendor-management actions, application retirement candidates, staffing or sourcing changes, and a roadmap for implementation. A framework only creates value when it changes decisions, behavior, and performance.

8. Test assumptions, align stakeholders, and iterate. Pressure-test the design against different demand levels, critical incidents, major release scenarios, and sourcing assumptions. Then socialize it with business owners, application managers, engineering leads, operations, risk, and vendors. Expect debate. A good ASL design usually improves through iteration because disagreements often reveal where accountabilities were unclear in the first place.

6. Example: Application Services Library in Action

The problem

A regional insurer with roughly 180 business applications was experiencing recurring production incidents, slow delivery of small enhancements, and constant disputes between its internal IT team and two application support vendors. Business leaders complained that simple changes took months, while IT leaders argued that demand was poorly prioritized and that legacy applications consumed too much capacity.

Why ASL was selected

The company did not need another broad IT maturity review. It needed a way to understand how application support, maintenance, release management, and lifecycle decisions fit together. ASL was chosen because it focused directly on the application management problem rather than only on infrastructure operations or enterprise controls.

How the framework was applied

The team grouped applications into core policy administration, claims, finance, and peripheral tools. It reviewed incident data, release histories, support contracts, application costs, and interview findings from business owners and technical leads. Using the ASL clusters, the team mapped where operational support was breaking down, where change work was stalling, and where no one was making long-term application decisions.

Key insights

The analysis showed three issues. First, support and enhancement work were being managed by different vendors with weak coordination, so defects repeatedly moved back and forth without closure. Second, the company had no effective forum for application lifecycle decisions, so aging systems kept absorbing enhancement spend. Third, service levels were written around ticket closure, not business outcomes, which encouraged local optimization.

Actions that followed

The insurer created a single application owner role for each major application family, introduced joint release planning, tightened defect feedback loops, and established a quarterly lifecycle review for modernization and retirement decisions. It also paired the ASL redesign with a focused IT service management reset so incident, problem, and release processes worked coherently across applications and infrastructure. Within two release cycles, emergency defects fell and business stakeholders had clearer expectations about what would be fixed, enhanced, or retired.

7. Strengths and Limitations

Strengths

• Brings structure to application management. ASL makes a messy, fragmented domain easier to govern.
• Clarifies accountability. It helps separate operational support, change delivery, management control, and lifecycle ownership.
• Connects short-term and long-term decisions. Teams can link today’s incidents and backlog problems to deeper lifecycle or sourcing issues.
• Works well in complex environments. It is particularly useful where multiple vendors, legacy systems, and high business criticality create coordination problems.
• Creates a common language. Business leaders, application managers, and service providers can discuss the same problems more productively.

Limitations

• Can feel process-heavy. Used rigidly, it can encourage bureaucracy rather than better outcomes.
• Less suited to very small or fast-moving product teams. The full framework is often more than they need.
• Depends on organizational honesty. If roles, costs, or service data are unclear, the analysis can become impressionistic.
• Not a substitute for engineering practices. ASL helps govern application management, but it does not replace sound architecture, testing, or DevOps automation.
• Can be too static if misused. In digital environments, teams must adapt it to agile and product-centric ways of working.

8. Common Pitfalls and How to Avoid Them

• Treating ASL as a compliance checklist. What goes wrong: teams document processes without changing behavior. Why it matters: performance stays the same while bureaucracy increases. How to avoid it: anchor the work in a specific business problem and measurable outcomes.
• Mapping theory instead of reality. What goes wrong: workshops describe how work is supposed to happen. Why it matters: root causes stay hidden. How to avoid it: use ticket data, release data, and examples from recent incidents and changes.
• Using inconsistent units of analysis. What goes wrong: critical platforms and minor tools are assessed in the same way. Why it matters: priorities become distorted. How to avoid it: segment applications by business criticality, complexity, and lifecycle stage.
• Ignoring the demand side. What goes wrong: IT redesigns application management without addressing business prioritization and ownership. Why it matters: change bottlenecks persist. How to avoid it: involve business owners early and define decision rights explicitly.
• Stopping at process design. What goes wrong: future-state diagrams are created, but metrics, governance, and staffing are not changed. Why it matters: the model never becomes operational. How to avoid it: translate every major design choice into roles, KPIs, forums, and implementation actions.
• Forgetting modern delivery methods. What goes wrong: ASL is imposed as if every application uses a traditional release model. Why it matters: teams resist it or work around it. How to avoid it: preserve ASL’s accountability logic while tailoring cadence and controls to agile, cloud, and DevOps contexts.

9. How Application Services Library Relates to Other Frameworks

ASL and ITIL

These frameworks are complementary, not interchangeable. ITIL is broader and stronger on end-to-end IT service management across incidents, requests, changes, and operations. ASL goes deeper on the application management domain: maintenance, enhancement, lifecycle direction, and the organization required to support business applications well.

ASL and BiSL

BiSL is commonly used as the business-side counterpart to ASL. In simple terms, BiSL helps define demand, priorities, and business information needs, while ASL helps the application management organization deliver and sustain the application response. If an organization has weak business ownership of change demand, ASL alone will not solve the problem.

ASL and COBIT or DevOps

COBIT operates at a higher governance and control level. It is helpful when the question is enterprise governance, risk, and auditability; ASL is better when the question is how application management should actually work. DevOps, by contrast, is a delivery and operating philosophy centered on faster flow, automation, and tighter collaboration. In many modern organizations, the best approach is to use DevOps for delivery mechanics and ASL for role clarity, lifecycle governance, and service accountability.

10. Key Takeaways

• Application Services Library is a framework for governing and improving application management across support, change, and lifecycle decisions.
• It is most useful when organizations have complex application estates, multiple stakeholders, or unclear accountability.
• Its real strength is connecting day-to-day incidents and changes to management controls and long-term application strategy.
• ASL works best when supported by solid data, explicit role definitions, and business participation in prioritization and lifecycle choices.
• It should be adapted to agile and product-centric environments, not implemented as rigid bureaucracy.

11. FAQs About Application Services Library

Is Application Services Library still relevant today?

Yes, especially in organizations with a sizable application estate and nontrivial support complexity. Its role has evolved: fewer teams implement it as a formal end-to-end process doctrine, but many still use its logic to define ownership, governance, and lifecycle decisions in agile and cloud environments.

What is the difference between Application Services Library and ITIL?

ITIL is broader and focuses on IT service management across services and operations. ASL is narrower but deeper in application management, especially around maintenance, enhancement, and long-term application direction. If your main problem is the application estate, ASL is often the sharper lens.

Can small or early-stage companies use Application Services Library?

Yes, but they should use it selectively. A smaller company usually does not need the full process model; it can still benefit from ASL’s core questions about ownership, change flow, support expectations, and when to improve versus replace an application.

How long does it typically take to apply Application Services Library in a real project?

A focused diagnostic can often be done in two to four weeks. A full operating-model redesign, including stakeholder alignment and implementation planning, more often takes six to twelve weeks depending on the number of applications, vendors, and business units involved.

What data is needed to use Application Services Library?

At minimum, you need a current application inventory, incident and change data, clear application owners, and a basic view of support costs and service expectations. The analysis becomes much stronger if you also have release performance data, vendor contract details, architecture dependencies, and business criticality ratings.