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.

Deployment Environment(s)

[Multi-Value]

Description — The environments in which this application is actively deployed and maintained — Development, Test, Systems Integration Testing (SIT), User Acceptance Testing (UAT), Staging, and Production.

Benefit(s) — Enables environment-level cost tracking, security posture assessment, and compliance scope determination. Applications running ungoverned non-production environments carry security and cost risk proportional to the number and configuration of those environments.

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

Description — A composite assessment of the application's technical quality, currency, maintainability, security posture, and alignment with current architecture standards — expressed as a tiered rating: High Fitness, Adequate Fitness, Low Fitness, or Poor Fitness.

Benefit(s) — The technical fitness dimension of the rationalization assessment matrix. Combined with Business Value Rating, Technical Fitness Score determines which Rationalization Posture is appropriate for each application.

Source — Manually Entered — assessed by the IT Application Owner or Enterprise Architecture function using a defined technical fitness assessment methodology.

Notes — Valid values: High Fitness, Adequate Fitness, Low Fitness, Poor Fitness.

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 — An assessment of the accumulated technical shortcuts, outdated technology, deferred maintenance, and architectural compromises in the application — expressed as Low, Medium, High, or Critical — accompanied by a brief description of the primary debt categories.

Benefit(s) — Technical debt has a quantifiable financial cost that manifests as slower delivery velocity, higher incident rates, increasing maintenance costs, and difficulty attracting engineering talent. Without explicit tracking, technical debt is invisible in portfolio financial analysis and excluded from rationalization decisions where it is often the most important factor.

Source — Manually Entered.

Notes — Valid values: Low, Medium, High, Critical. Include a brief description of the primary debt categories in the Notes / Additional Context attribute when High or Critical.

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.