What Is an Application Boundary?

This chapter defines the Application Boundary: the line that separates what is part of an Application from everything it interacts with.

Definition

An Application Boundary is the defined limit of an Application’s controlling scope: the set of technical components, functions, and services that the Application’s designers have determined to be part of the Application, as distinct from everything outside it with which the Application interacts.

Why a Boundary Must Be Defined

Without a defined boundary, simple questions become hard to answer. Is the reporting database that receives a nightly extract part of this Application or a different one? Is a shared authentication service part of the Application, or an external dependency? Is a script that migrates data into the Application during cut-over part of it?

The Application Boundary answers these questions. Everything inside the boundary is part of the Application: its own code, its own databases, its own configuration, and the technical components it controls. Everything outside the boundary is something the Application interacts with, through Integrations, Application Programming Interfaces (APIs), and dependencies.

The Boundary Is a Design Decision

The definition places the boundary where the Application’s designers determine it to be. The boundary is therefore a deliberate decision, not a natural fact, and two enterprises may reasonably draw boundaries differently for similar Applications. What matters is that the boundary is drawn deliberately, documented clearly, and applied consistently.

The boundary can also move over time. When part of one Application is split out to become a separate Application, when two Applications are merged, or when a shared component is extracted, the boundaries of the affected Applications change.

Best Practice: Establish and Document the Application Boundary, and Revisit It with Every Release

Establish where each Application’s boundary lies, document what is inside it and what is outside it, and revisit the boundary with every Release. The chapter “Establish and Document the Application Boundary” later in this document describes how to do this in practice.

Benefits: A documented boundary makes ownership unambiguous: the Application’s owners are accountable for what is inside it, and the owners of other Applications are accountable for the rest. It also tells engineers which components a Release must build, test, and deploy, and tells support teams where the Application ends and a dependency begins during an incident.

Connections to Related IF4IT Practices and Inventories

The Integrations Inventory and Attributes describes how connections between Systems are recorded. The Solutions Architecture Best Practices and Framework describes how solution designs define scope and interfaces.