Distinguish between an Application, a System, a Platform, and a Service

Overview

The terms application, system, platform, and service are used interchangeably in most organizations, creating persistent confusion about what belongs in the application portfolio and what does not. When these terms are not defined, the portfolio either becomes too broad - including everything - or too narrow - missing significant technology assets that genuinely require portfolio management attention. Both outcomes undermine the quality and usefulness of the portfolio as a management tool.

Best Practice

Establish clear organizational definitions for the four terms and use them consistently throughout APM documentation, governance, and communication. An Application is a discrete software solution used to support one or more business capabilities or user functions - it has a name, an owner, a purpose, and a cost. A System is a broader collection of applications, data stores, and infrastructure components that work together to deliver a more complex capability. A Platform is a foundational technology layer on which other applications are built or hosted. A Service is a defined capability delivered to customers or internal users - it may be enabled by one or more applications but is defined from the customer’s perspective rather than the technology perspective. Provide concrete examples from the organization’s own environment for each term.

Microservices architectures complicate the Application boundary specifically: a single business-facing capability may be delivered by dozens of independently deployable microservices, and treating every microservice as its own separate entry in the Applications Inventory would fragment the portfolio past the point of being useful for governance or cost analysis. As a default convention, treat a cohesive set of microservices delivered and owned as a unit — sharing a release cadence, a team, and a business purpose — as a single Application for portfolio purposes, and reserve finer-grained microservice-level tracking for the technical architecture documentation the application links to, not the Applications Inventory itself.

A related term worth distinguishing explicitly is Product — in a product-oriented organization, a Product is a business-facing offering with its own roadmap, ownership, and success metrics, and may be delivered by one or more Applications, similar to how a Service is customer-facing while being enabled by underlying technology. The distinction matters for portfolio scoping: Product roadmaps and Application inventories serve different governance purposes and should not be conflated, even when a single Application and a single Product happen to map one-to-one.

Benefit(s)

Clear definitional boundaries prevent scope confusion that derails portfolio data collection efforts and inventory design. Portfolio stakeholders can consistently classify what they are responsible for without case-by-case arbitration. The portfolio reflects what it is intended to reflect - the organization’s application assets - rather than an inconsistent mix of types that cannot be governed or analyzed as a coherent collection. Governance conversations become more productive because everyone is working from the same vocabulary.