Initiatives

An Initiative is how Albumi captures a planned change effort that touches the landscape. A CRM replacement, an ERP sunset, a GDPR remediation, a Customer 360 program — these are Initiatives. The entity answers two questions: which applications will this effort affect, and what kind of change does it make to each one. Everything else — project plans, budgets, sprints, milestones, task lists — belongs somewhere other than Albumi.

Initiatives sit apart from the rest of the entity model. They do not realize capabilities, they are not consumed by applications, they do not carry data. They are the time-bound lens through which the portfolio is planned to change.

What an Initiative is

An Initiative is a named, time-bound change effort with a defined architectural scope. The scope is expressed as a set of Applications, each tagged with the kind of change the effort will make to it.

Good examples:

CRM Migration to Salesforce — introduces Salesforce, modifies the web portal and the billing system (new integrations), retires the legacy CRM.
SAP ERP Sunset — retires the legacy ERP and several surrounding satellite systems over eighteen months.
GDPR Remediation — modifies every application that stores personal data, spanning multiple departments.
Customer 360 Program — introduces a new analytics platform and modifies every customer-facing application feeding it.

Non-examples:

A single bug fix or feature ticket. That is ticket-sized work, not a program.
Ongoing maintenance or operational run. An Initiative has a beginning and an end.
A target-state vision with no commitment to execute it. Until a change effort is funded and scoped, it is a strategy deck, not an Initiative.

The signal that something is Initiative-sized is that a portfolio manager, a program sponsor, or an architect would refer to it by name in a roadmap conversation, and that its conclusion would materially change the landscape.

Initiatives are not architectural dependencies

This is the single most important distinction to get right, and it is easy to get wrong.

An Initiative is not a dependency between applications. It does not describe a runtime relationship, a data flow, an API contract, or a shared component. If Application A cannot operate without Application B at runtime, that is modeled as an Integration (data flow) or as a shared IT Component (technology both depend on). An Initiative describes a project-time relationship: “for the duration of this effort, these applications are in scope and will be changed.”

The consequences:

Removing an application from an Initiative’s scope does not change what the application runs on or what it connects to. It only means the program will not touch it.
Two applications being in the same Initiative does not mean they depend on each other. They are simply being worked on together.
An Initiative completing does not remove any architectural link. The architectural facts — integrations, realizations, technology usage — are modeled independently and outlive any particular effort.

Read the entity map on Entities Overview with this in mind: Initiatives deliberately sit outside the structural diagram. They cut across it.

Initiatives are not a project plan

Albumi captures the architectural impact of a change effort, not its execution. An Initiative carries a name, a description, an owning organization, an owner, an optional start and end date, a type, a status, and a set of Applications in scope. That is the whole model.

What is intentionally absent: tasks, sub-tasks, milestones, sprints, deliverables, budgets, RACI matrices, dependencies between tasks, resource assignments, status reports. These belong in a project tracker (Jira, Azure DevOps, Asana, ServiceNow PPM — pick your tool). The integration between Albumi and the project tracker is a human one: the program manager looks at both.

When someone asks to add task tracking, milestone tracking, or budget tracking to an Initiative, the right answer is no. Those concerns belong in the project tool; Albumi’s value is that every other entity on the page — applications, integrations, capabilities, data objects — is also modeled, so the architectural impact can be reasoned about in one place.

Scope: Applications affected by Impact Type

The substance of an Initiative is the list of Applications it touches. For each Application, the link carries an Impact Type that names what the effort will do to it.

Add — the Initiative introduces this application to the landscape. It did not exist before (or was not in use), and will be in use after. Use Add for a new SaaS being rolled out, an in-house system being built, a vendor product being adopted.
Modify — the application exists today and will continue to exist after, but the Initiative changes it in a way the business cares about. New integrations, new capabilities realized, significant data model change, a platform re-hosting. Do not use Modify for minor tweaks that would not appear in a roadmap — it becomes noise.
Remove — the Initiative retires this application. After the effort concludes, the application is no longer in use. This is the architectural counterpart to a decommission plan.

Each Application linked to the Initiative carries exactly one Impact Type. If a program has phases that first Modify and then Remove an application, model it as Remove — record the end state of the application after the Initiative concludes. The intermediate Modify is execution detail that belongs in the project plan.

Impact Type is the bridge between the Initiative entity and the Application entity. From an Application’s perspective, it appears on the “Affected by” relationship — each Application can list the Initiatives that target it and what each one does to it. From the Initiative side, the list is editable: scope is managed from the Initiative.

Type

Every Initiative carries a type that classifies the nature of the effort. The type is descriptive — it drives portfolio filters and reports, not permissions or workflow.

Migration — moving to a new platform, vendor, or hosting model while preserving business function. Data center to cloud, on-premise CRM to SaaS, one ERP to another.
Modernization — re-platforming or significantly upgrading an existing application to address technical debt. Same business function, better technology.
Consolidation — reducing the number of applications that serve the same purpose. Two regional CRMs merged into one.
Expansion — introducing new capability into the landscape. A new market, a new product, a new customer-facing channel.
Decommission — the explicit goal is to retire one or more applications. Differs from Migration in that there is no replacement; the function is being eliminated.

An Initiative has exactly one type. Pick the one that describes the primary intent from the business sponsor’s perspective. A Migration that also decommissions the old system is a Migration, not a Decommission — the outcome the sponsor is funding is the arrival at the new platform.

Status

An Initiative’s status is a simple state field, not the five-stage dated lifecycle that Applications, Integrations, and IT Components use. It reflects where the effort sits right now.

Draft — being defined. Scope is being assembled; the Initiative is not yet committed.
Planned — defined and approved, but not yet started. Scope is set, execution has not begun.
Active — currently being executed. The effort is in flight.
On Hold — paused. Scope remains, but work has stopped; the Initiative is neither advancing nor cancelled.
Completed — concluded successfully. The intended architectural impact has been realized.
Cancelled — stopped before completion with no intent to resume.

Status is set manually. Unlike the lifecycle entities, status is not derived from dates. The start and end dates on an Initiative are informational — they support planning views and timeline reports, but they do not automatically change the status.

Ownership and Organization

Like every other entity, an Initiative has one owner and one owning organization, and they answer different questions.

Owner — the person accountable for the effort. The single human to go to for questions about scope, progress, and architectural decisions. Ownership also governs permissions: owners can act on the Initiative directly; non-owners cannot.
Organization — the organizational unit the Initiative belongs to for classification and reporting. The department funding it, the region running it, the program office owning the portfolio slot.

Organization is classification, not permission. Being part of the owning organization grants no access to the Initiative. There is no separate “sponsoring organization” concept — Initiatives carry the same single Organization link every other entity does, and it means what it means everywhere else.

Every Initiative has an organization. If nothing specific applies, it sits under the workspace root organization. The owner may be unset.

Relationship with Architecture Change Requests

Initiatives and Architecture Change Requests (ACRs) describe different things and operate at different scales. They are complementary, not alternative.

An Initiative names the what and the why of a change effort: what applications are in scope, what kind of impact each one takes, over what time frame, under whose ownership.
An ACR names the how of a single change landing in the model: one proposed edit to one or more entities, submitted, reviewed, and merged as the landscape evolves from its current state to its next state.

A single large Initiative — a multi-year migration, a portfolio-wide remediation — typically produces dozens of ACRs over its life. Each ACR represents one concrete edit: an application added to the catalog, an integration modified, a retired application marked end-of-life, a new IT Component introduced. The Initiative is the thread that runs through them at the program level; each ACR is the individual stitch that advances the model.

An ACR can directly reference the Initiative it serves: the ACR carries an optional initiativeId field, set at creation or update. Use it when the ACR is part of a named program so that later readers can trace backward from the landed change to the Initiative that motivated it; leave it unset for standalone changes.

UI affordances

Initiatives deliberately surface a narrower set of actions in the UI than other entities. The only actions exposed on an Initiative’s detail page are delete and manage permissions. The standard edit and propose-change affordances that appear on Applications, Integrations, and other entities are not shown for Initiatives.

The underlying API endpoints exist, and API clients can use them. The omission in the UI is deliberate: Initiative content — name, description, scope, status, dates — is routinely adjusted as programs evolve, and the overhead of proposing and reviewing every adjustment would not match how programs are actually managed. Editing happens through the same flow as when the Initiative was created.

If you notice that your Initiatives do not show the same edit controls as your Applications, this is why. It is not a bug.

Common modeling mistakes

Using Initiatives to model runtime dependencies between applications. An Initiative is a program, not a dependency link. If A calls B at runtime, model it as an Integration or a shared IT Component. An Initiative that happens to include both A and B says nothing about how they communicate.
Making Initiatives too small. One ticket is not an Initiative. One sprint’s worth of work is not an Initiative. If the effort would not appear by name on a portfolio slide at a quarterly review, it is too small. Small changes belong in ACRs.
Making Initiatives too large. The company’s entire three-year strategy is not an Initiative. A program of programs is not an Initiative. If the scope cannot name a concrete set of applications that it will change, it is too big — split it into the programs that make it up, each with its own scope.
Treating the Initiative as a project plan. Task lists, milestones, and budgets do not belong on the Initiative. Those concerns live in the project tracker. Albumi’s role is to capture the architectural scope and impact, not to replace project management software.
Using Impact Type to describe execution phases. Impact Type captures the end-state change to each application — what the Initiative does to it by the time the effort concludes. Mid-flight phase distinctions (build now, migrate later) belong in the project plan, not the Impact Type field.
Maintaining an Initiative after it is done. Once the effort concludes, the Initiative’s status becomes Completed (or Cancelled). It stays in the catalog as a record, but it is not reopened for new scope. A follow-on effort is a new Initiative.

Applications — the entities Initiatives affect
Architecture Change Requests — the mechanism by which the model is actually edited, often in service of an Initiative
Entities Overview — where Initiatives sit in the broader model
Permissions & Roles — how ownership drives who can act on an Initiative