Technology Asset Management

Metadata

• Practice ID: TECH-TAM-01
• Status: Draft
• Version: 1.0
• Owner Role: Technology Asset Management Lead
• Guild: GL04 Technology Guild
• GitHub Team: @calab-ai/guild-technology

Purpose and Objectives

This practice owns the authoritative registry of applications used across Calab.ai — the inventory layer of the company application architecture. It defines how applications are registered, categorised, classified, and tracked through their lifecycle, from evaluation through production to retirement.

The registry lives under 06 Registry/Applications/ as structured notes. Each application is a note whose frontmatter carries the registry attributes (vendor, category, criticality, lifecycle, data classification), and Obsidian Bases views (Application Registry.base) provide filterable inventories over those attributes.

Application architecture relationships — how systems connect, how data flows between platforms, and dependencies between products — are owned by the diagram hierarchy (L1–L4) under Platform Architecture, using the diagram conventions owned by Knowledge Management. This practice provides the inventory those diagrams draw from; it does not duplicate them.

Scope

In Scope

• The application registry — the single source of truth for applications in use at Calab.ai
• Registry schema and property definitions (vendor, category, criticality, lifecycle, data classification)
• Application lifecycle states and transitions (evaluation, production, deprecated, retired)
• Registration workflow for new applications
• Criticality and data classification assignment for registry entries (informed by Security Management)
• Registry views (Obsidian Bases) for querying the inventory

Out of Scope

• Application architecture diagrams and system relationships (owned by Platform Architecture)
• Security controls, vendor risk assessments, and the data classification scheme itself (owned by Security Management)
• Tool endorsement policy — which tools are endorsed for knowledge work (owned by Knowledge Management); endorsement draws from this registry
• Procurement, licensing, and contract management (owned by Financial Management)
• Hardware and physical asset management

Interfaces

Dependencies (Practices We Depend On)

• Security Management (TECH-SEC-01) — Data classification scheme and security requirements for approved applications
• Platform Architecture (TECH-PLATARCH-01) — Platform context for where applications sit in the architecture
• Knowledge Management (ADMIN-KNOWLDG-01) — Handbook publishing platform for registry notes

Dependents (Practices That Depend On Us)

• Knowledge Management (ADMIN-KNOWLDG-01) — Tool endorsement draws from the approved application registry
• All practices — Teams consult the registry to know which applications are approved and how critical they are

Registry

The registry is structured as follows:

To register a new application, copy the entry template into 06 Registry/Applications/, name the note after the application, and complete the frontmatter. Registry notes publish to the handbook site like any other page; the interactive Bases views are available when the vault is opened in Obsidian.

Registry Schema

KPIs and Success Signals

• KPI 1: Registry coverage — percentage of applications in use that are registered (Target: 100%)
• KPI 2: Registry freshness — entries reviewed within the review cadence (Target: 100% annually)
• KPI 3: Unregistered applications discovered per quarter (Target: trending to 0)
• Success Signal 1: Tool endorsement and procurement decisions trace back to registry entries
• Success Signal 2: Application architecture diagrams draw their system inventory from the registry

Review Cadence

• Practice Review: Quarterly
• Registry Review: Annually per entry (lifecycle state, criticality, vendor details)
• Owner: Technology Asset Management Lead

Change Log