How Assets, Products, Services, Systems, Applications, and Solutions Relate to the SDLC - Systems Development Lifecycle (SDLC) Best Practices

How Assets, Products, Services, Systems, Applications, and Solutions Relate to the SDLC

(Chapter 11 of Systems Development Lifecycle (SDLC) Best Practices)

Executive Summary: Chapter Overview

IF4IT

The Bottom Line

Asset, Product, Service, System, Application, and Solution describe different but overlapping governance perspectives. Precise classification improves ownership, lifecycle scoping, Release impact analysis, authoritative inventories, sourcing responsibility, operations, funding, and retirement.

Core Concepts

Concept	Definition & Strategic Role
Governed Object	The named Asset, Product, Service, System, Application, Solution, or other capability to which lifecycle accountability is applied.
Primary Governed Object	The level at which ownership and the Utilization Profile are principally anchored.
Object Relationship	A recorded dependency, containment, support, delivery, or change relationship among governed objects.
Composite Solution	A Solution whose components have different sourcing, ownership, or control boundaries.

Quick Q&A

Question: Are Asset, Product, Service, System, Application, and Solution interchangeable?

Answer: No. They emphasize different governance, value, operating, and technical perspectives, although one capability may fit several classifications.

Question: Can a Release affect more than one governed object?

Answer: Yes. A Release commonly affects multiple Applications, Services, Products, Systems, data, infrastructure, and suppliers.

Question: Should every object level have a separate Utilization Profile?

Answer: No. Profiles should be anchored where accountability is meaningful and should avoid unnecessary duplication.

This chapter distinguishes the principal governed objects to which the SDLC may apply and explains their overlapping relationships, ownership implications, Release connections, inventory representations, and retirement obligations.

Canonical Definitions

Term	Definition
Asset	Anything of value to the enterprise that is owned, managed, used, governed, or depended upon to achieve outcomes.
Product	A governed offering or capability intentionally developed, acquired, managed, evolved, and funded to deliver value to defined customers, users, or stakeholders over time.
Service	A governed means of delivering value or capability through defined outcomes, responsibilities, service levels, and operating commitments.
System	An organized set of interacting or interdependent elements that work together to achieve defined purposes or outcomes.
Application	A software-based Asset designed to provide defined functions, capabilities, workflows, or user interactions.
Solution	An intentional combination of Assets, Products, Services, Systems, Applications, technologies, data, processes, people, and controls assembled or changed to address a defined need or outcome.

How the Terms Relate

The classifications are not mutually exclusive. An Application is an Asset; a Product may include several Applications; a Product may be delivered through Services; a Service may depend on Applications, infrastructure, data, and suppliers; a System may include people, processes, Products, Services, and technology; and a Solution may create or change all of them.

The enterprise should identify the primary governed object and maintain explicit relationships rather than use labels interchangeably.

How Assets, Products, Services, Systems, Applications, and Solutions Relate to the SDLC — SDLC-related Asset, Product… — Figure: SDLC-related Asset, Product, Service, System, Application, and Solution Relationships.

Profile Anchoring and Releases

The Utilization Profile should be anchored where lifecycle accountability, funding, risk, support, and retirement decisions are most meaningful. A Product with recurring Releases may use a Product-level profile; a material Release may use a supplemental profile; a standalone Application or end-to-end System may be anchored directly.

A Release should identify every materially affected governed object, not only its primary Application. Infrastructure, data, APIs, Products, Services, suppliers, and dependent Systems may all require impact analysis and authoritative-record updates.

Inventories and Retirement

Governed Object	Possible Authoritative Record	Retirement Emphasis
Asset	Asset Inventory, ITAM, or CMDB	Remove, dispose, transfer, archive, or terminate the specific Asset.
Product	Product Portfolio	End the offering, migrate users, and close the roadmap.
Service	Service Catalog or Portfolio	Terminate commitments, migrate consumers, and close support.
System	System Inventory or EA repository	Decommission the integrated capability and resolve dependencies.
Application	Application Inventory or APM	Remove software, data, interfaces, access, infrastructure, and support.
Solution	Solution Architecture or initiative record	Transition or retire all resulting components appropriately.

Example

An online claims-submission capability illustrates the relationship among common lifecycle objects. The Product is the digital claims experience offered to customers. The Service is claims submission and status tracking. The portal is an Application supported by APIs, databases, identity services, cloud infrastructure, and integrations with core claims systems. Together, those components form the Solution. The SDLC governs the Solution and its Releases while allowing each underlying Asset to retain its own ownership, configuration, operational, support, and retirement responsibilities.

Common Antipatterns

Enterprises should avoid treating Asset, Product, Service, System, Application, and Solution as mutually exclusive categories. These classifications overlap by design — an Application is also an Asset, a Product may include several Applications — so treating them as mutually exclusive can force an artificial single classification onto something that legitimately belongs to several categories at once, obscuring relationships that actually matter for governance.

Antipattern	Why it fails
Treating Asset, Product, Service, System, Application, and Solution as mutually exclusive categories	These classifications overlap by design; forcing an artificial single classification onto something that legitimately belongs to several categories obscures relationships that matter for governance.

Use Application Portfolio Management (APM) Best Practices and the Applications Inventory and Attributes to clarify enduring ownership, lifecycle accountability, value, cost, risk, and dependency information.

Use Service Management Best Practices and Service Catalog Best Practices to connect lifecycle decisions to service ownership, operational readiness, support obligations, service levels, and continual improvement.

Each Release should read authoritative lifecycle records and update affected inventories, identifiers, relationships, ownership, status, evidence, configuration, and retirement information as governed outputs, per Enterprise Inventory Management Best Practices.

How to cite this page

When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.

Example (informal web citation):

The International Foundation for Information Technology (IF4IT), LLC. How Assets, Products, Services, Systems, Applications, and Solutions Relate to the SDLC | Systems Development Lifecycle (SDLC) Best Practices. https://if4it.org/best-practices/systems-development-lifecycle-sdlc/how-assets-products-services-systems-applications-and-solutions-relate-to-the-sdlc/ (accessed 2026-08-24).

See About Us for content governance and site-wide citation guidance.

Legal Disclaimers