Applications Inventory and Attributes

Technology Profile

[Multi-Value]

Description — The set of core technologies the application is built on or depends on — including programming languages, application frameworks, database platforms, cloud services, runtime environments, and integration middleware. Each value is a Technology Semantic Identifier referencing a record in the Technologies Inventory.

Benefit(s) — Enables Technology Spread analysis across the portfolio — identifying which technologies are most widely adopted, which are approaching End-of-Life, and which carry the highest concentration risk. This attribute is one of the two primary sources for seeding the Technologies Inventory.

Source — Manually Entered. Each value references or seeds a record in the Technologies Inventory.

Examples — TECH-LANG-APEX, TECH-LANG-JAVASCRIPT, TECH-DB-POSTGRESQL, TECH-CLOUD-HEROKU (Salesforce CRM). TECH-LANG-ABAP, TECH-DB-HANA, TECH-CLOUD-AWS (SAP S/4HANA).

Notes — Minimum one value required at Walk maturity. Values should use Technologies Inventory Semantic Identifiers where the Technologies Inventory exists. Free-text technology names are acceptable at early Walk maturity. Each value in this set that does not yet have a corresponding Technologies Inventory record seeds a new record in that inventory.

Description — The architectural style or pattern used to structure the application: Monolith, Microservices, Serverless, Event-Driven, Service-Oriented Architecture (SOA), or other recognized patterns.

Benefit(s) — Drives migration complexity assessment, infrastructure cost modeling, and scalability risk evaluation. Monolithic applications carry different migration costs, scalability constraints, and operational profiles than microservices-based applications.

Source — Manually Entered.

Examples — Monolith (legacy ERP), Microservices (customer-facing order management platform), Serverless (data processing pipeline on AWS Lambda), Event-Driven (real-time inventory management system)

Notes — Common values: Monolith, Microservices, Serverless, Event-Driven, SOA, Hybrid.

Description — The infrastructure model in which the application is hosted and operated: On-Premises, Private Cloud, Public Cloud, Hybrid, or SaaS.

Benefit(s) — Determines the financial model (CapEx versus OpEx), the operational responsibility model, and the cloud migration pathway for each application. Without Hosting Model, portfolio-level cloud adoption analysis and migration planning cannot be grounded in accurate baseline data.

Source — Manually Entered.

Examples — SaaS (Salesforce CRM — Salesforce-hosted), Public Cloud (custom analytics app — AWS us-east-1), On-Premises (legacy ERP — Chicago data center), Hybrid (ERP core on-premises, analytics layer in Azure)

Notes — Valid values: On-Premises, Private Cloud, Public Cloud, Hybrid, SaaS.

Description — The specific cloud infrastructure provider hosting the application — AWS, Microsoft Azure, Google Cloud Platform, Oracle Cloud, or other — where the application is cloud-hosted or SaaS-delivered.

Benefit(s) — Enables cloud concentration risk analysis, multi-cloud governance, and cost benchmarking by provider. Organizations with significant concentration in a single cloud provider carry vendor dependency risk that is only visible when cloud provider data is captured across the full application portfolio.

Source — Manually Entered. Applicable when Hosting Model is Public Cloud, Private Cloud, Hybrid, or SaaS.

Description — A rating of the application's inherent technical complexity — the difficulty of understanding, modifying, operating, and migrating the application — expressed as Low, Medium, or High.

Benefit(s) — Provides a governance-level abstraction of technical complexity that business and financial stakeholders can use in investment and rationalization discussions without requiring deep technical context. Directly influences migration effort estimates and modernization cost projections.

Source — Manually Entered.

Notes — Valid values: Low, Medium, High.

Description — Whether the application or any component of its technology stack has reached or is approaching vendor End-of-Life or End-of-Support — expressed as No Risk, Approaching (within 24 months), Imminent (within 12 months), or Expired (support has ended).

Benefit(s) — Applications running on End-of-Life or End-of-Support technology carry unresolvable security vulnerabilities and loss of regulatory compliance once the support window closes. Tracking EOL status across the portfolio enables proactive remediation planning rather than emergency response.

Source — Manually Entered.

Notes — Valid values: No Risk, Approaching (within 24 months), Imminent (within 12 months), Expired. When Approaching, Imminent, or Expired, populate End-of-Life / End-of-Support Date.

Description — The specific date on which vendor support for the application or a critical component of its technology stack expires or has expired.

Benefit(s) — Enables proactive EOL risk management across the portfolio with enough lead time to fund and execute remediation. Applications in Expired status should be treated as immediate rationalization priorities.

Source — Manually Entered. Applicable when End-of-Life / End-of-Support Status is Approaching, Imminent, or Expired.

Description — Whether the application exposes a programmatic interface for integration with other systems, and if so, the interface type: REST, SOAP, GraphQL, gRPC, proprietary, or none.

Benefit(s) — Determines integration approach options, automation potential, and the application's capacity to participate in enterprise integration patterns. Applications without API exposure carry higher integration cost and complexity.

Source — Manually Entered.

Notes — Valid values: REST, SOAP, GraphQL, gRPC, Proprietary API, None, Multiple (specify in Notes).

Description — Whether the application is deployed using container technology — specifically whether its deployment artifact is a container image (Docker or equivalent) rather than a traditional server-based deployment.

Benefit(s) — Indicates readiness for cloud-native deployment patterns, Kubernetes orchestration, and modern DevOps practices. Containerization status is a primary input to cloud migration strategy and affects infrastructure cost modeling and operational scalability assessment.

Source — Manually Entered.

Notes — Valid values: Yes, No, Partially.

Description — Whether the application has an active Continuous Integration / Continuous Delivery or Continuous Deployment pipeline governing its build, test, and deployment processes.

Benefit(s) — Indicates the application's engineering maturity and the organization's ability to deliver changes to it safely and frequently. Applications without CI/CD pipelines carry higher deployment risk and slower change velocity.

Source — Manually Entered.

Notes — Valid values: Yes — Full CI/CD, Yes — CI only, No, In Progress.