IT Components

An IT Component is a piece of technology used by Applications. Databases, runtimes, message brokers, identity providers, shared frameworks, middleware platforms — the parts of the stack the business does not name but the architecture depends on. Applications sit on top; IT Components sit underneath.

This page defines what Albumi specifically models as an IT Component. For the lifecycle stages IT Components share with Applications and Integrations, see Lifecycle & Dates.

What an IT Component is

An IT Component is technology consumed by one or more Applications — not a piece of business-facing software in its own right. You track it because an Application’s ability to run, scale, comply, or be upgraded depends on it.

Typical examples:

Database engines — PostgreSQL, Microsoft SQL Server, MongoDB, Redis.
Runtimes and languages — the Java runtime, the .NET runtime, Node.js, Python.
Messaging and streaming — Apache Kafka, RabbitMQ.
Identity and security — Okta, Active Directory, a PKI.
Middleware platforms — an ESB, an iPaaS, an API gateway, a message broker.
Container and cloud platforms — Kubernetes, a Cloud Foundry environment, your AWS account as a tracked asset.
Shared internal technology — an in-house framework, a standard logging library, a common component that several Applications consume.

Non-examples — each of these is an Application, not an IT Component:

Salesforce, Workday, ServiceNow — multi-tenant SaaS products users log into.
An internal billing system, a customer portal — software the business owns and names.
A BI portal exposed to end users — a product, even if it runs on a warehouse.

The test is the same one that decides the Application side: if the business talks about it, plans around it, and assigns an owner to it as “a system”, it is an Application. If it is technology the business relies on without naming, it is an IT Component.

The boundary with Application

Every organization has a fuzzy middle ground. Three cases settle most of it.

Packaged software that users touch. Salesforce is an Application. The fact that Salesforce runs on its own multi-tenant platform is Salesforce’s problem, not yours — do not model the provider’s internal infrastructure. The Application is the unit users and processes depend on.

Open-source technology your Applications embed. PostgreSQL is an IT Component even if it powers fifteen of your Applications. Users do not log into “the PostgreSQL”. Applications use it; they are not it.

Middleware that carries flows. An ESB, iPaaS, API gateway, message broker, or event bus is an IT Component — the technology that transports data. Each concrete data flow it carries is a separate Integration between the producing and consuming Applications. The component captures the technology fact (version, vendor, lifecycle); the Integrations capture the business-meaningful flows. See Integrations for the middleware reference on the integration side.

Tech categories

Every IT Component belongs to a tech category. This is not optional — the component cannot be saved without one. The category is what makes portfolio analysis possible: “how many Applications still depend on technology in the Relational Database category” is a tech-stack question that needs a classification to answer.

The default taxonomy is a two-level tree shipped with a new workspace. Top-level categories and what typically sits inside each:

Software — business-facing software classifications used when an IT Component represents a packaged application treated as technology rather than as a managed Application: Business Application, Analytics & BI, Data Governance, Development Tool, Collaboration, Framework & Library.
Platform — the foundations Applications run on: Integration Platform, Cloud Platform, Container Platform, Application Server, Data Platform.
Middleware — the plumbing between Applications: API Gateway, Message Broker, ESB, ETL / Data Pipeline, File Transfer.
Database & Storage — where data lives: Relational Database, NoSQL Database, Data Warehouse, Object Storage, Cache.
Service — consumption models for technology obtained as a service: SaaS, PaaS, IaaS, Managed Service.

Pick the most specific child category that fits. A PostgreSQL cluster is Relational Database, not just Database & Storage. The top level is for components that genuinely do not fit a child, not a shortcut to avoid choosing.

The taxonomy is editable per workspace — you can add categories, rename them, and reorganize the tree to match how your organization talks about technology. It is a tree, not a tag cloud: a component has exactly one category.

Vendor, version, and license

Three descriptive attributes carry most of the practical questions asked of an IT Component:

Vendor — who produces or publishes it. “PostgreSQL Global Development Group”, “Microsoft”, “Red Hat”, “the Platform team”. Free-text; no central vendor registry.
Version — the version string you are tracking, formatted however you track it internally: “17”, “17.2”, “Java 17 LTS”, “2024.3”. The field is a label, not a parsed semver; it is meaningful because you made it meaningful.
License type — the commercial model: Open Source, Commercial, Subscription, Perpetual, Freemium. A license-cost portfolio view consumes this. All five are optional; set them when you have a reason to report on them.

Relationship to Applications

An Application uses one or more IT Components. One IT Component is consumed by many Applications. The Application detail page lists its IT Components; the IT Component detail page lists the Applications that declare it. The relation itself lives on the Application side — you add and remove an IT Component from an Application’s tech stack, not from the IT Component’s consumer list.

That asymmetry matters in practice: an IT Component does not know it has consumers until Applications declare it. A component with no declared consumers is not invalid — it just is not in use yet (or the Applications have not been modeled).

There is no separate “Application → IT Component” entity. The relationship has no attributes of its own (no version-per-consumer, no operation set). If you need to say “App A uses PostgreSQL 14 and App B uses PostgreSQL 17”, model them as two IT Components (see Version tracking below) and have each Application declare the one it uses.

Middleware in integrations

When a middleware platform carries Integrations, model the platform as an IT Component and reference it from the Integration. Examples: an ESB routing invoices from ERP to the finance warehouse; an iPaaS brokering events between a commerce platform and a CRM; an API gateway fronting calls from a mobile app to several back-ends.

An Integration can reference zero, one, or several middleware components — zero for point-to-point flows, one for a single hop through a platform, several for a chain. See Integrations for how the reference behaves on the integration side.

Version tracking

The product does not dictate whether “Java 8” and “Java 17” are two IT Components or one component with a Version field that changes over time. Both shapes are valid; pick the one that keeps the portfolio readable.

The useful rule: split into separate IT Components when the two versions have diverging lifecycles or diverging consequences. Consolidate when they do not.

Split when:

One version is in Phase-Out and the other is in Active. The whole point of the lifecycle is to flag Applications that depend on the retiring version; one combined record hides that.
The security, compliance, or licensing story differs. “Supported” vs “out of support”. “PCI-approved” vs “not”. “Commercial” vs “open source fork”.
Consumers will have to be migrated one at a time. You need to track who is on which side of the migration.

Consolidate when:

The version is an incidental build number that changes every sprint and carries no lifecycle meaning.
The organization has a policy that Applications must stay on a single current version, and that is enforced elsewhere.
Tracking the minor version on every IT Component would multiply the component count by ten without answering any question the portfolio actually has.

Use the Version field as a label, and split into separate records when the label stops being enough.

Lifecycle

IT Components use the same five-stage dated lifecycle as Applications and Integrations. The stages, dates, and ordering rules live on the Lifecycle & Dates page — everything there applies verbatim.

Lifecycle is the reason you track version-level IT Components at all. If Java 8 sits at Phase-Out and Java 17 sits at Active, any Application that still declares Java 8 as an IT Component is visibly exposed: the retirement of the component is a dependency signal on every consumer. Without the split, the signal does not exist; every Application just says “uses Java” and the EOL story is invisible in reports.

The same pattern applies to a database engine version, a runtime version, a commercial product line, or an internal shared framework. Set the dates, let the status derive, and the tech-stack view tells you which Applications need attention before each retirement.

Ownership and organization

An IT Component has one owner and one organization, and they answer different questions.

Owner — the person accountable for the IT Component: who decides whether to upgrade it, who is the single point of contact for questions, who is expected to set the lifecycle dates. Owner is also the signal that decides who can edit the component directly; a non-owner must propose the change rather than edit directly. See Permissions & Roles. Owner is optional — a component may exist without a named accountable human, though it is better not to.
Organization — the unit the IT Component belongs to for classification and reporting (the Platform team that runs it, the Infrastructure department that funds it). This is not a permission dimension. Membership in the owning organization grants nobody any access to the component.

Every IT Component has an organization — if nothing specific applies, it sits under the workspace root organization.

Common modeling mistakes

Tracking every library, utility, or transient dependency. IT Components are for technology that has a portfolio-level lifecycle — things you plan, retire, or report on. A build-time helper library nobody in the organization would rename does not qualify. If you would not notice if it disappeared from the catalog, it should not be in it.
Modeling a SaaS product as an IT Component because it runs on someone’s cloud. Salesforce, Workday, ServiceNow — these are Applications. Users log into them; processes depend on them. The provider’s underlying stack is the provider’s problem.
Keeping one IT Component while the versions diverge. When Java 8 enters Phase-Out and Java 17 is Active, a single “Java” component hides the exposure. Split at the moment the lifecycles diverge, not a year later when the retirement hits.
Modeling cloud provider accounts without the technology they host. “AWS account” as a top-level IT Component, with nothing underneath, answers no question. Either track the specific technologies running in the account (the Postgres instance, the Kubernetes cluster, the object storage) as IT Components, or leave the hosting to the Application’s Hosting Type field. A bare cloud-provider record has no consumers and no lifecycle meaning.
Modeling middleware as an Application. An ESB or iPaaS is technology that carries flows; users do not log into it the way they log into a CRM. The platform is an IT Component; the flows through it are Integrations.
Using organization as access control. Organization is classification. A user in the same organization as an IT Component has no special rights on it.

Entities Overview — the entity map and the full choice framework
Applications — the business-facing counterpart that uses IT Components
Integrations — the boundary with middleware and how flows reference platform components
Lifecycle & Dates — the five-stage model IT Components share with Applications and Integrations
Permissions & Roles — how ownership drives edit rights