What Is an Application?

This chapter defines an Application, the central governed noun of this document. Every other chapter depends on this definition.

Definition

An Application is a logical, uniquely identifiable software system, composed of a grouping of any combination of technical components, that provides specific capabilities and performs specific functions and services in an automated and highly repeatable manner, and that is deployed (or intended for deployment) to one or more IT Operating Environments, where it is instantiated as one or more in-computer-memory processes.

The Key Elements of the Definition

Each part of the definition does specific work:

• Logical. An Application is a logical entity, not a single physical thing. The same Application may be deployed to development, test, staging, and Production environments at the same time. Each of those deployments is an Application Instance, defined in the next chapter; the Application is the single logical entity they are all occurrences of.

• Uniquely identifiable. Every Application must be distinguishable from every other Application. In practice, this means each Application has a single, unique Application Name and a durable Semantic Identifier in the Application Inventory, as later chapters describe.

• Software system. An Application is a System, as defined in the previous chapter, whose substance is software.

• Composed of technical components. An Application is a grouping of technical components, such as executable code, databases, web servers, message queues, file systems, configuration files, scripts, and other Software Technologies. Those components are parts of the Application; they are not Applications in their own right. A database engine used by an Application, for example, is one of its technical components.

• Capabilities, functions, and services. An Application exists to provide specific capabilities and to perform specific functions and services for its users or for other Systems. Here, “services” in lowercase means the work an Application performs on behalf of others; it should not be confused with a governed Service as defined by Service Management or recorded in a Services Inventory.

• Automated and highly repeatable. Unlike Systems in general, an Application performs its functions in an automated and highly repeatable way. Given the same inputs and conditions, it behaves the same way each time.

• Deployed (or intended for deployment) to IT Operating Environments. An Application is deployed to one or more IT Operating Environments. An Application still being planned or built is already an Application, because it is intended for deployment.

• Instantiated as in-computer-memory processes. When an Application runs, it exists as one or more processes executing in computer memory.

Why Ownership Is Not Part of the Definition

The definition says what an Application is, not how it is governed. Ownership, accountability, and documentation are deliberately left out of the definition, because they belong to the discipline of managing Applications rather than to the nature of an Application. An Application without an owner is still an Application; it is simply a poorly managed one. Ownership and accountability are addressed by the definition of Application Management and by the chapters on roles and responsibilities later in this document.

Applications Regardless of Who Built Them or Where They Run

The definition applies equally to Applications the enterprise builds itself, Applications licensed from a vendor, Applications obtained from an open-source community, and combinations of these. It applies equally to Applications hosted in the enterprise’s own data centers, in its own cloud accounts, and by vendors as Software as a Service (SaaS). Who created an Application and where it is hosted are separate characteristics, addressed in the chapter “Sourcing Type vs. Hosting Model — Who Created an Application vs. Where It Is Hosted.” Neither one changes whether something is an Application.

Best Practice: Apply One Consistent Definition of Application Across the Enterprise

Adopt a single, published definition of Application, such as the one in this chapter, and use it consistently in the Application Inventory, in Application Portfolio Management, in Enterprise Architecture, and in every team’s documentation. When a candidate is unclear, test it against the definition’s elements: Is it a logical software system? Is it uniquely identifiable? Does it provide capabilities, functions, and services in an automated, repeatable way? Is it deployed, or intended for deployment, to IT Operating Environments? If a candidate is really a technical component of another Application, record it as part of that Application rather than as a separate one.

Benefits: A single, consistently applied definition makes the Application Inventory countable and comparable. It stops one team from registering a database as an Application while another team omits a SaaS product entirely, and it gives portfolio decisions, cost allocations, and risk assessments a reliable foundation.

Connections to Related IF4IT Practices and Inventories

The Applications Inventory and Attributes describes the attributes recorded for every Application. The Software Technologies Inventory and Attributes describes the technologies that serve as an Application’s technical components. The Systems Development Lifecycle (SDLC) Best Practices describes the lifecycle every Application passes through.