Overview of Application Management Best Practices

This chapter introduces Application Management Best Practices: what the document covers, who it is for, and how it is organized. It explains why Application Management matters to the enterprise and sets out the core argument that a properly documented Application is a better-designed and better-governed Application. It also explains how to read and apply the chapters that follow, including the recurring “Establish and Document” pattern, the meaning of a documentation minimum, and the status of every value set and taxonomy in this document as a recommended, customizable example.

Purpose and Scope of This Document

Application Management Best Practices addresses the governance and documentation of an individual Application, from the moment it is first proposed until it is fully retired. It answers a practical question that every enterprise faces many times over: for any one Application, what must be established, who is accountable for it, what must be written down, where must it live, and how is it kept current?

This document deliberately focuses on one Application at a time. The management of defined groups of Applications, such as a business unit’s Applications or the enterprise’s entire Application Portfolio, is the domain of Application Portfolio Management (APM). The management of the underlying Software Technologies that Applications are built on and run within is the domain of Technology Portfolio Management (TPM). Application Management is the per-Application foundation on which both depend: a portfolio can only be as well understood as the individual Applications within it.

The scope includes:

• The core definitions needed to talk about Applications precisely, including System, Application, Application Instance, Application Boundary, and Application Management itself.

• Why Application Documentation matters, including its role in managing enterprise risk and preventing Knowledge Debt.

• The roles, organizations, templates, Digital Libraries, and policies that make complete Application Documentation achievable and enforceable.

• What to establish and document for an Application in each phase of the Systems Development Lifecycle (SDLC), and in every Release as part of the Release Management Process.

• Cross-cutting practices for Application Instances, configurations, dependencies, rules, Issues, vendors, and conditional requirements.

• How each Application is registered in the Application Inventory so that it becomes visible to Application Portfolio Management, Technology Portfolio Management, and the Enterprise Model.

Who This Document Is For

This document is written for three primary audiences:

• IT leaders, such as Chief Information Officers (CIOs), Chief Technology Officers (CTOs), and heads of Enterprise Architecture, Engineering, and Operations, who set policy, allocate accountability, and must be able to trust what their enterprise knows about its Applications.

• IT managers, such as Application Managers, Application Owners, Release Managers, and portfolio managers, who are accountable for individual Applications and groups of Applications day to day.

• IT practitioners, such as architects, engineers, developers, testers, operators, support staff, and Subject Matter Experts (SMEs), who design, build, deploy, run, support, and document Applications.

• Educators who are preparing students who plan to enter into the Information Sciences (IS) / Information Technology (IT) industry, such as faculty that educate in STEM-related IS/IT topics such as but not limited to Software Development (a.k.a. coding), CIS, Software Engineering, data & information, and much more.

• Students who are preparing to enter into the IS/IT industry and who are studying IS/IT related topics like software development (a.k.a. coding), CIS, software engineering, infrastructure engineering, data & information, and more.

Business leaders who own Applications are an equally important audience. As later chapters explain, accountability for an Application, and for its documentation, belongs to business leadership and IT leadership together.

Why Application Management Matters

Most of an enterprise’s business capabilities run on its Applications. Each Application is built or bought once, but it is then operated, supported, changed, secured, audited, and eventually retired over many years, usually by people other than those who created it. Application Management is the discipline that governs that entire span, one Application at a time.

Without it, the same failures recur in enterprises of every size and industry:

• Applications that no one clearly owns, so no one is accountable when they fail or must change.

• Changes that break dependencies no one knew existed.

• Outages caused by certificates, credentials, licenses, or vendor support that expired unnoticed.

• Audits that stall because evidence of control cannot be found or was never created.

• Retirements that never finish because no one can say what still depends on the Application.

A simple test shows whether an enterprise practices Application Management. For any Application it depends on, business and IT leadership should be able to answer the following questions within minutes, from a trusted source:

• Who are its Business and IT Application Owners?

• What does it depend on, and what depends on it?

• Can it be restored, and when was that last proven?

• What regulated data does it hold?

• When do its certificates, licenses, and vendor support expire?

Where the answers are slow, uncertain, or missing, the enterprise is carrying risk it cannot see.

Everything else depends on these answers. Each Application’s documentation populates its Application Record, which feeds the Application Inventory and, through it, Application Portfolio Management, Technology Portfolio Management, Enterprise Architecture, and the Enterprise Model. Risk, security, recovery, and investment decisions made across the portfolio are only as sound as the facts managed for each Application beneath them.

The Core Argument: Well-Documented Applications Reduce Risk and Are Better Applications

This document rests on two related arguments.

The first is about risk. Missing, incomplete, or outdated Application Documentation is not a minor housekeeping problem; it is an enterprise risk. When the people who built or ran an Application move on, the knowledge they carried leaves with them. Months or years later, during an outage, an audit, a security incident, a vendor dispute, or a replacement project, the enterprise discovers that it cannot quickly answer basic questions about an Application it depends on. Finding that information after the fact is slow, expensive, and error-prone, and the gaps accumulate as Knowledge Debt.

The second is about quality. Requiring documentation for every important topic area forces the right questions to be asked while there is still time to act on the answers. A team that must document its Application’s Integrations, dependencies, Security Secrets, backup and restore procedures, and Decommissioning approach must first think them through. The result is Applications that are more thoroughly designed, more stable, and easier to change, operate, and support.

Both arguments lead to the same governing policy, explained in detail later in this document: no documentation, or incomplete documentation, means no Production Deployment.

“Application” Means “Software Application”

The IF4IT Dictionary defines a Software Application as a System that is the result of applying Software to a specific operations or solutions space. Throughout this document, “Application” almost always means a Software Application in this sense; where a different meaning is intended, the text says so explicitly.

How This Document Is Organized

The chapters of this document are grouped into five parts, each made up of one or more subsections:

The document closes with a Glossary of the terms and phrases used throughout. Some terms, such as Release, Deployment, Build, Integration, and Security Secret, are used in early chapters before they are treated in depth. Each is defined in the chapter that covers it, and all are collected in the closing Glossary.

How to Read the “Establish and Document” Chapters

Most practice chapters in this document carry a title of the form “Establish and Document XYZ,” where XYZ is a specific topic such as the Application’s Support Model, its Integrations, or its Disaster Recovery procedures. These titles are deliberate, and they carry two distinct obligations:

1. Establish the solution for XYZ. Make the topic visible, so that a real, working solution for it is actually put in place rather than assumed. For example, “Establish and Document the Application’s Support Model” first requires that a real, working Support Model exists for the Application, with named teams, hours, escalation paths, and responsibilities.

2. Document and share the solution for XYZ. Once the solution exists, ensure it is properly documented, published where stakeholders can find it, and kept current with every Release.

Each such chapter is therefore built in two halves. The “Establish” half describes what a sound solution for the topic looks like for an individual Application, and links to the governing IF4IT discipline document for depth rather than re-teaching that discipline. The “Document and Share” half describes what to capture, where it lives, and who reviews it at each Release.

The two halves exist because each prevents a different, common failure:

• Documented but not real. A document describes a support model, a recovery procedure, or a review that does not actually exist or has never been exercised. The documentation creates false confidence.

• Real but not documented. A capable team has established a sound solution, but it lives only in people’s heads. When those people are unavailable, the solution is effectively lost.

Each such chapter states its central recommendation in the same plain form: it is a best practice to both establish and document the solution for the topic at hand. Where an artifact is owned and maintained elsewhere, such as an architecture model maintained by Enterprise Architecture, the Application Documentation may contain a governed link to that authoritative source rather than a copy, provided the link is maintained and the linked content meets the same standards of completeness and currency. For ongoing records, such as an Application’s Release and Change History, the chapter titles use “Establish and Maintain” instead, because the obligation is continuous rather than one-time.

The Minimum Is a Floor, Not a Target

Later chapters describe a Minimum Application Documentation Policy: the enterprise-defined, stakeholder-agreed set of Application Documentation that every Application must have, and keep current, before any of its Releases may be deployed to Production. That minimum is a floor. It defines the point below which an Application may not go, not the level at which teams should aim. Practitioners should always strive to document their Applications far beyond the minimum, because every gap left undocumented eventually becomes Knowledge Debt that someone else must pay down.

You can create a Crawl, Walk, Run path for your own enterprise…

Or, Crawl, Walk, Run can help better understand where your enterprise sits in comparison to other enterprises of your size in your industry.

This being said, the foundation realizes that the scope of Application Management is significant and, both, accounting for and documenting every detail may be easier in significantly larger enterprises than it is for very enterprises. This should not be taken as an excuse to do the bare minimum but as a statement of pragmatism that acknowledges an enterprise needs to pick its battles given the vast array of responsibilities any IT organization has. The reader will regularly come across the words “Crawl, Walk, Run” as a framework for incremental improvement over time. Starting somewhere is better than nowhere. Continuously improving will improve maturity, quality, and culture.

Every Value Set, Taxonomy, and Template Is a Recommended Example

This document presents many attributes, value sets, taxonomies, classifications, and template structures, such as Sourcing Types, Hosting Models, documentation types, and categories of configurations, dependencies, and rules. All of them are common examples that IF4IT recommends. Enterprises can, and should, customize them to fit their own size, industry, regulatory environment, and existing vocabulary. Where such a value set appears in later chapters, this point is restated, but it applies everywhere in this document whether or not it is repeated.

What should not be customized away is the underlying discipline: every Application should have clear accountability, complete and current documentation, and a governed record in the Application Inventory.

Best Practice: Adopt This Document as a Baseline and Adapt It Deliberately

Enterprises should adopt this document as a baseline for how they manage and document individual Applications, then adapt it deliberately: decide which recommended values, taxonomies, and template sections to use as written, which to rename or extend, and which to set aside, and record those decisions in the enterprise’s own published standards. Adaptation should be explicit and owned, not the result of individual teams quietly ignoring the parts they find inconvenient.

Benefits: A deliberately adapted baseline gives every Application team the same starting point and the same vocabulary, while still fitting the enterprise’s real circumstances. Recording the adaptation decisions explains to future readers why the enterprise’s standard differs from the IF4IT baseline, which keeps the standard defensible during audits and stable as people change.

Connections to Related IF4IT Practices and Inventories

This document builds directly on the Systems Development Lifecycle (SDLC) Best Practices, the IT Operating Environments Best Practices, and the Release Management Best Practices for what happens to an Application across its lifecycle. It connects upward to Application Portfolio Management (APM) Best Practices and Technology Portfolio Management (TPM) Best Practices for portfolio-level governance, and to the Applications Inventory and Attributes, Enterprise Inventory Management Best Practices, and The IF4IT Enterprise Model and Modeling Best Practices for how each Application’s record becomes part of the enterprise’s governed knowledge. The Technical Debt Management Best Practices addresses the related problem of accumulated technical shortcuts.