Applications

The Application is the entity every other part of the landscape hangs off. Capabilities are realized by applications. Integrations flow between applications. IT Components are consumed by applications. Data Objects are operated on by applications. Get the application boundary right and the rest of the model falls into place; get it wrong and the rest will drift with it.

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

What an Application is

An application is a piece of business-facing software treated as one unit of planning and ownership. It automates one or more business capabilities, has a single accountable owner, and has a lifecycle the business cares about — a go-live date, a retirement date, a replacement plan.

Three tests, applied together, settle most boundary questions:

Business-facing. Users, customers, or business processes interact with it — directly or through another application. A runtime dependency nobody outside IT names is not an application.
Planned as a unit. It is funded, deployed, upgraded, and retired as one thing. If the business talks about replacing “the CRM”, the CRM is one application even if it is ten services underneath.
Has a single owner. One person or team is accountable for it end-to-end. If two teams each own half with no coordination, the boundary is drawn too wide.

An entity that fails any of the three belongs somewhere else. The next section names where.

The boundary with IT Component and Integration

These three entity types together describe the whole “running software” picture and they are easy to confuse. The rules are:

If it is…	Model it as	Why
Business-facing software with its own purpose	Application	Users and capabilities attach here.
A technology the business-facing software runs on	IT Component	Databases, runtimes, message brokers, identity providers, cloud platforms.
A directed data flow between two applications	Integration	The movement of data itself, not the software that carries it.

Concrete cases:

Salesforce, Workday, an internal billing system, a customer portal — Applications. They automate capabilities; users and processes depend on them.
PostgreSQL, Kafka, Kubernetes, Okta, the Java runtime — IT Components. Applications consume them; the business does not.
ESB, iPaaS, API gateway, event bus — IT Components. The platform is technology; each concrete data flow it carries is a separate Integration between the producing and consuming Applications.
SaaS vendor’s internal microservices — not modeled. The SaaS product is one Application. Its internal architecture belongs to the vendor.
A microservice inside your own system — usually not a separate Application. If the business treats a cluster of services as one deployable with one owner and one lifecycle, model that cluster as one Application. Promote a service to its own Application only when it has its own owner, its own capabilities, and its own lifecycle the business tracks.
A library, SDK, or shared framework — IT Component if you care to track it; otherwise not modeled.
A database or data warehouse — IT Component. The business data it holds (Customer, Order, Invoice) is modeled separately as Data Objects. If the warehouse is exposed to users as a product — a BI portal, a self-service data UI — that product is an Application.

When in doubt, ask what appears on the portfolio slide at the next steering meeting. That list is the Application list.

Granularity

A workable default: one Application per business-facing capability cluster with a single owner and a single retirement plan. Under that default:

An ERP suite is one Application if it is governed as one, even across modules.
An ERP suite is several Applications if each module has its own owner, its own lifecycle, and the business discusses them separately (e.g., ERP Finance, ERP HR).
Microservices inside a single product are one Application. The services are implementation.
Two brands sharing the same codebase but governed and retired independently are two Applications.

The signals that you are modeling too fine-grained are: dozens of applications with the same owner, integrations that are really internal method calls, and capability maps where each capability maps to exactly one application with the same name. The signals you are modeling too coarse-grained are: applications with multiple conflicting owners, lifecycles that cannot be described by a single set of dates, and portfolio conversations that keep having to qualify “which part of it”.

Subtypes

Every Application carries an applicationType that classifies what kind of software it is. The type is descriptive, not governed — it drives filters, reports, and portfolio segmentation, not permissions or workflow.

Type	What belongs here
Business Application	Software that runs a core business process — ERP, CRM, billing, claims, order management. The default.
Data And Analytics	Software whose primary purpose is producing insight — BI tools, data platforms exposed to users, reporting apps.
Collaboration	Software whose primary purpose is communication and coordination — email, chat, meeting, document collaboration.
Customer Facing	Software a customer (not an employee) interacts with — public portals, customer apps, self-service sites.
Other	Explicit bucket for items that do not fit above. Use it openly; do not stretch one of the four to avoid it.

An application has exactly one type. Pick the primary purpose from the user’s perspective. A BI tool that has a chat feature is Data And Analytics, not Collaboration.

Portfolio attributes

An application carries a small set of attributes that exist specifically to drive portfolio decisions. They are all optional, and they do not affect how the application is edited or governed — they feed views, heatmaps, and reports.

Business criticality — how badly the business is hurt if this application is unavailable. Four levels: Mission Critical (revenue or legal exposure within hours), Business Critical (significant disruption within a day), Business Operational (routine impact, degraded but running), Administrative (nice to have). Criticality is about impact of outage, not about how much the business likes the system.
Functional fit — how well the application supports the capabilities it realizes today. Excellent, Adequate, Insufficient. Opinion-based, set by business stakeholders.
Technical fit — how healthy the application is as a piece of technology. Same three levels. Set by the architect or engineering team. Ageing stack, unsupported runtime, poor maintainability all pull it down.
TIME classification — the portfolio decision for this application: Tolerate, Invest, Migrate, Eliminate. Albumi computes TIME automatically whenever both functional and technical fit are set: an application that meets business needs well and is technically healthy is Invest; one that meets the needs but sits on bad technology is Migrate; a solid but unremarkable application on fine technology is Tolerate; an application that fails to meet business needs is Eliminate regardless of how good the technology is. If the fits are not scored, you can set TIME directly to record a decision.
Hosting type — where the application runs: On Premise, Cloud, Hybrid, Saas. The cloud provider field narrows that further when hosting is Cloud or Hybrid.
Data classification — the most sensitive class of data the application handles: Public, Internal, Confidential, Restricted. The GDPR, SOX, and PCI DSS flags are independent booleans; an application can be Restricted without being GDPR-relevant, and vice versa.

None of these are required. Set them when you intend to use the portfolio views that consume them; leave them unset rather than guessing.

Ownership

An application has one owner and one organization, and the two answer different questions.

ownerUser — the person accountable for the application. This is the single human to go to for decisions about it. Ownership is also the governance signal that decides who can edit it directly versus propose a change; a non-owner Contributor must propose the change rather than edit directly. See Permissions & Roles.
organization — the organizational unit the application belongs to for classification and reporting (the department that runs it, the region that funds it). This is not a permission dimension. Membership in the owning organization grants nobody any access to the application.

Every Application has an organization — if nothing specific applies, it sits under the workspace root organization. ownerUser may be unset; organization is always set.

Relationships from an Application

The Application connects to other entities in several ways. Each relationship is owned by the Application page for some edits and by the counterpart page for others.

Realizes → Business Capability. Which capabilities this application delivers. Edited from the Application.
Uses → IT Component. The technology this application depends on to operate. Edited from the Application.
Operates on → Data Object. For each Data Object the application touches, the operations it performs: Create, Read, Update, Delete. Edited from the Application.
Exposes → Interface. Named technical surfaces the application offers — REST, gRPC, Kafka topic, SFTP, JDBC, and similar — with direction, protocol, format, endpoint, and authentication. Interfaces are modeled as part of an Application, not as a separate top-level entity. Edited from the Application.
Source / Target of → Integration. Data flows in and out of this application. An Integration optionally references a specific Interface on each side. Edited from the Integration — an integration needs both ends declared together.
Affected by → Initiative. Change efforts that touch this application, each with an impact type (Add, Modify, Remove). Edited from the Initiative.

Common modeling mistakes

One Application per microservice. Produces a portfolio the business cannot read. Collapse to the deployable the business plans and retires as a unit.
Modeling infrastructure as Applications. Kubernetes, the identity provider, the database cluster — IT Components.
Modeling the middleware that carries integrations as an Application. 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 application has no special rights on it.
Editing status instead of dates. There is no status dropdown. Lifecycle status changes when dates change.
Forcing an applicationType. If none of the four fit, use Other rather than stretching a category.

Entities Overview — the entity map and the full choice framework
Lifecycle & Dates — the five-stage model Applications share with Integrations and IT Components
Integrations — the boundary with flows into and out of an application
IT Components — the boundary with the technology underneath
Data Objects — the data the application reads and writes
Permissions & Roles — how ownership drives edit rights