Arckit Application Inventory

You are helping an enterprise architect create an Application Inventory — a comprehensive portfolio catalog that maps all existing applications, their strategic fit, dependencies, technology landscape, and lifecycle status. This is the foundation for Phase C (Technology Architecture) decisions and application rationalisation.

User Input

$ARGUMENTS

Prerequisites: Read Foundational Artifacts

Note: Before generating, scan projects/ for existing project directories. For each project, list all ARC-*.md artifacts, check external/ for reference documents, and check 000-global/ for cross-project policies. If no external docs exist but they would improve output, ask the user.

MANDATORY (warn if missing):

• ADMP (Architecture Vision / Preliminary ADM) — Extract: Scope boundaries, ADM phase inclusions, strategic vision
  • If missing: STOP and ask user to run $arckit-adm-preliminary first. The application inventory must be scoped by the architecture vision.

RECOMMENDED (read if available, note if missing):

• BPCM (Business Capability Map) — Extract: Capability landscape, capability owners, capability-to-business value mapping
• REQ (Requirements) — Extract: System requirements, application migration requirements, integration requirements
• PRIN (Architecture Principles, in 000-global) — Extract: Technology standards, cloud strategy, application portfolio principles

Prerequisites 1b: Read external documents and policies

• Read any external documents listed in the project context (external/ files) — extract existing application catalogues, portfolio assessments, asset inventories, technology register
• Read any enterprise standards in projects/000-global/external/ — extract enterprise technology standards, approved technology stack, technology rationalisation targets
• If no external application docs found but they would improve the inventory, ask: "Do you have any existing application catalogues, portfolio assessments, or technology registers? I can read PDFs, spreadsheets, and images directly. Place them in projects/{project-dir}/external/ and re-run, or skip."
• Citation traceability: When referencing content from external documents, follow the citation instructions in .arckit/references/citation-instructions.md. Place inline citation markers (e.g., [PP-C1]) next to findings informed by source documents and populate the "External References" section in the template.

Instructions

1. Identify or Create Project

Identify the target project from the hook context. If the user specifies a project that doesn't exist yet, create a new project:

1. Use Glob to list projects/*/ directories and find the highest NNN-* number (or start at 001 if none exist)
2. Calculate the next number (zero-padded to 3 digits, e.g., 002)
3. Slugify the project name (lowercase, replace non-alphanumeric with hyphens, trim)
4. Use the Write tool to create projects/{NNN}-{slug}/README.md with the project name, ID, and date — the Write tool will create all parent directories automatically
5. Also create projects/{NNN}-{slug}/external/README.md with a note to place external reference documents here
6. Set PROJECT_ID = the 3-digit number, PROJECT_PATH = the new directory path

2. Read Template

Read the template (with user override support):

• First, check if .arckit/templates-custom/application-inventory-template.md exists in the project root
• If found: Read the user's customised template (user override takes precedence)
• If not found: Read .arckit/templates/application-inventory-template.md (default)
• Then, read .arckit/templates/_partials/RENDERING.md and resolve the template's <!-- DOC-CONTROL-HEADER --> marker to the Document Control partial it selects, applying the ${organisation_name} and ${default_classification} substitutions. Remove the marker and its comment from the output — a rendered artefact must never contain either.

Tip: Users can customise templates with $arckit-customize application-inventory

3. Clarify Scope with User

Before generating the inventory, ask the user about the scope of this assessment:

A question to the user: "What is the scope of this application inventory?"

• Options: All applications | Business Unit | Specific Project
• Default: All applications

4. Gather Application Data

Collect application information from all available sources:

• From ADMP: Scope boundaries — which business areas / systems are in scope
• From BPCM: Capabilities covered by each application, capability gaps
• From REQ: Requirements driving application changes — new capabilities, integration points, technology constraints
• From external documents: Existing application catalogues, technology registers, portfolio assessments
• From user: Direct input about known applications, strategic priorities, technology strategy

5. Load Mermaid Syntax References

Read the following Mermaid syntax references for diagrams:

• .arckit/skills/mermaid-syntax/references/quadrantChart.md — Strategic fit matrix (quadrant chart)
• .arckit/skills/mermaid-syntax/references/pie.md — Technology distribution (pie chart)
• .arckit/skills/mermaid-syntax/references/flowchart.md — Dependency map (flowchart)

6. Generate Application Inventory

Create the Application Inventory document following the template structure.

Application Register

For each application, determine and document:

• App ID: APP-001, APP-002, etc.

• Name: Application name / product name

• Category: Line-of-Business, Shared Service, Platform, Customer-Facing, Internal Tool, etc.

• Owner: Business owner and technical owner

• Technology Stack: Primary runtime, framework, database, hosting model

• Lifecycle Phase: Concept / Discovery / Development / Operational / Mature / Declining / Retired

• Status: Active / Deprecated / Planned / Under Review

• Strategic Fit: Score each application using the following framework:

  Strategic Fit Rating	Criteria	Action
  Strategic	Core to business strategy, competitive differentiator, high business value	Invest & Grow
  Critical	Essential for operations but not a differentiator, commodity functionality	Maintain & Optimise
  Support	Supplementary functionality, low business value relative to cost	Rationalise
  Replace	High technical debt, poor alignment with strategy, better alternatives exist	Plan Replacement

Strategic Fit Matrix

Generate a Mermaid quadrant chart plotting applications on:

• X-axis: Technical Debt (Low → High)
• Y-axis: Business Value (Low → High)

Quadrants:

1. Keep & Invest (Low Debt, High Value) — Strategic apps
2. Modernize (High Debt, High Value) — Critical apps needing refactoring
3. Retire (High Debt, Low Value) — Replace candidates
4. Monitor (Low Debt, Low Value) — Support apps to watch

Technology Landscape Heatmap

Generate a Mermaid pie chart showing technology distribution across the portfolio:

• Cloud-Native: Containers, serverless, managed services
• Containerised: Docker/Kubernetes deployments
• Virtualised: VM-based deployments
• Physical: Bare metal / on-premise hardware

Also include a technology diversity analysis:

• Runtime diversity: Number of unique runtimes/languages (target: reduce)
• Platform diversity: Number of unique hosting platforms (target: standardise)
• Vendor lock-in risk: Assessed per application

Application Dependencies

Generate a Mermaid flowchart showing:

• Inter-application dependencies (upstream/downstream)
• Shared services and common platforms
• External / third-party dependencies
• Critical path analysis — which apps, if down, cascade to others

Application-to-Capability Mapping

Map each application to the business capabilities it supports:

• Full coverage: Application is the primary system for the capability
• Partial coverage: Application handles some aspects; other systems also contribute
• Overlap: Multiple applications cover the same capability (rationalisation candidate)
• Gap: Capability has no system coverage

Application Lifecycle

For each application, document:

• Age: Time since initial deployment
• EOL Date: Known end-of-life date for platform/runtime/framework
• Next Major Version: Planned upgrade schedule
• End of Life Plan: Migration/retirement plan

Risk Register

Identify application-level risks:

• Technical: Unsupported technology, security vulnerabilities, scalability limits
• Operational: Single point of failure, lack of skilled staff, poor documentation
• Compliance: Data residency, audit requirements, certification expiry
• Strategic: Misalignment with direction, vendor risk, market obsolescence

Traceability

• Link ADMP → Application scope
• Link BPCM → Capability coverage
• Link REQ → Application requirements
• Link PRIN → Technology alignment

7. UK Government Specifics

If the user indicates this is a UK Government project, include:

• Technology Code of Practice (TCoP): Align application assessment against 13 TCoP points
• GDS Technology Standards: Check against GDS Technology Standards Catalogue
• CloudFirst: Compliance with CloudFirst policy for hosting model
• Spending Control Alignment: Application costs mapped to SR periods
• Cross-Government Services: Identify opportunities for GOV.UK Pay, Notify, Verify, Design System

8. MOD Specifics

If this is a Ministry of Defence project, include:

• Defiance Programme: Cloud migration status and MOD Cloud Programme alignment
• JSP 440: System project management stage alignment
• IAMM Level: Information assurance maturity for each application
• SSE: Single Source Estate compliance for commercial tools

9. Quality Gate

Before writing the file, read .arckit/references/quality-checklist.md and verify all Common Checks plus the APP per-type checks pass. Fix any failures before proceeding.

Additional quality checks for Application Inventory:

1. Register Completeness: Application register must contain ≥3 applications with complete data (ID, name, category, owner, technology, lifecycle, status, strategic fit)
2. Strategic Fit Scoring: Every application in the register must have a strategic fit rating assigned (Strategic/Critical/Support/Replace)
3. Dependency Diagram: At least one Mermaid flowchart showing inter-application dependencies
4. Capability Mapping: Every application must be mapped to at least one business capability
5. Lifecycle Data: Every application must have lifecycle phase and status documented

10. Write the Output

IMPORTANT: The Application Inventory document will be a substantial document. You MUST use the Write tool to create the file, NOT output the full content in chat.

Create the file at:

projects/{P}/ARC-{P}-APP-v1.0.md

Use the Write tool with the complete content following the template structure.

Auto-Populate Document Information Fields

Before completing the document, populate document information fields:

• [PROJECT_ID] → Extract from project path (e.g., "001")
• [VERSION] → Start with "1.0" for new documents
• [DATE] / [YYYY-MM-DD] → Current date in YYYY-MM-DD format
• [DOCUMENT_TYPE_NAME] → "Application Inventory"
• ARC-[PROJECT_ID]-APP-v[VERSION] → Generated document ID
• [STATUS] → "DRAFT" for new documents
• Classification → comes from the resolved Document Control header, not from a placeholder. _partials/RENDERING.md fixes the ladder from the artefact's own regime; ${default_classification} applies only where that regime falls through to user config.

User-provided fields

• [PROJECT_NAME] → Full project name
• [OWNER_NAME_AND_ROLE] → Document owner

Revision History

| 1.0 | {DATE} | ArcKit AI | Initial creation from `$arckit-application-inventory` command |

Generation Metadata Footer

**Generated by**: ArcKit `$arckit-application-inventory` command
**Generated on**: {DATE}
**ArcKit Version**: {ARCKIT_VERSION}
**Project**: {PROJECT_NAME} (Project {PROJECT_ID})
**AI Model**: [Actual model name]

11. Show Summary to User

After writing the file, show a concise summary (NOT the full document):

## Application Inventory Complete

**Document**: `projects/{P}/ARC-{P}-APP-v1.0.md`
**Document ID**: ARC-{P}-APP-v1.0

### Inventory Scope
- **Scope**: [All applications / Business Unit / Project-specific]
- **Applications catalogued**: [N]

### Strategic Fit Summary
| Rating | Count | Examples |
|--------|-------|----------|
| Strategic | [N] | [App names] |
| Critical | [N] | [App names] |
| Support | [N] | [App names] |
| Replace | [N] | [App names] |

### Technology Landscape
- **Cloud-Native**: [N]% of portfolio
- **Containerised**: [N]% of portfolio
- **Virtualised**: [N]% of portfolio
- **Physical**: [N]% of portfolio
- **Technology diversity**: [N] unique runtimes, [N] platforms

### Dependency Analysis
- **Applications with dependencies mapped**: [N]
- **Shared services identified**: [N]
- **Critical dependencies**: [N] (single points of failure)

### Capability Coverage
- **Capabilities covered**: [N] out of [N] (from BPCM)
- **Full coverage**: [N] capabilities
- **Partial coverage**: [N] capabilities
- **Gaps (no system)**: [N] capabilities
- **Overlaps**: [N] capabilities covered by multiple apps

### Lifecycle
- **Active**: [N] applications
- **Deprecated**: [N] applications
- **Planned**: [N] applications
- **Applications approaching EOL**: [N]

### Risk Summary
- **High risks**: [N]
- **Medium risks**: [N]
- **Low risks**: [N]

### Synthesised From
- ✅ Architecture Vision: ARC-{P}-ADMP-v[N].md
- [✅/⚠️] Business Capability Map: ARC-{P}-BPCM-v[N].md
- [✅/⚠️] Requirements: ARC-{P}-REQ-v[N].md
- [✅/⚠️] Architecture Principles: ARC-000-PRIN-v[N].md

### Next Steps
1. Review Application Inventory with technology board / architecture review panel
2. Run `$arckit-application-rationalization` to decide keep/merge/replace/retire
3. Run `$arckit-gap-analysis` to identify capability coverage gaps

### Traceability
- [N] applications mapped to [N] capabilities
- [N] dependencies documented
- [N] risks identified
- [N] lifecycle actions required

**File location**: `projects/{P}/ARC-{P}-APP-v1.0.md`

Important Notes

1. Strategic Fit is Subjective: The strategic fit rating requires business context. Always ground ratings in the Architecture Vision (ADMP) and stakeholder input. When uncertain, flag applications for architectural review.

2. Dependencies Drive Risk: Application dependencies are critical risk factors. Document upstream/downstream relationships, protocol-level dependencies (API, database, file share), and data flow dependencies.

3. Lifecycle Drives Investment: Application EOL dates directly impact investment planning. Flag any applications where the underlying technology reaches EOL within 18 months of the assessment date.

4. Mandatory Prerequisites: ADMP is required as the application inventory must be scoped by the architecture vision. BPCM, REQ, and PRIN are recommended for full context.

5. Version Management: If an Application Inventory already exists (ARC-*-APP-v*.md), create a new version (v2.0) rather than overwriting. Track portfolio evolution across ADM cycles.

6. Integration with Other Commands:

   • Input: Requires ADMP (scope), uses BPCM (capability mapping), REQ (requirements), PRIN (technology standards)
   • Output: Feeds $arckit-application-rationalization (portfolio decisions), $arckit-gap-analysis (capability gaps)

7. TOGAF Alignment: This document maps to TOGAF Phase C (Technology Architecture) outputs: existing technology baseline, technology standards, and application portfolio assessment.

8. Markdown escaping: When writing less-than or greater-than comparisons, always include a space after < or > (e.g., < 3 seconds, > 99.9% uptime) to prevent markdown renderers from interpreting them as HTML tags or emoji.

Suggested Next Steps

After completing this command, consider running:

• $arckit-application-rationalization -- Decide keep/merge/replace/retire for each application
• $arckit-gap-analysis -- Analyze capability coverage from application inventory