Skip to content
Albumi Docs

Onboarding a Landscape

This page is about standing up Albumi at team or organization scale. If you are a single user populating a workspace on your own, see Quick Start or Manual Start instead — those cover the individual path. This page assumes more than one person is involved and the first useful version of the landscape needs to be built in weeks, not days.

The rule of thumb that keeps the rollout under control: go wide before you go deep. A landscape of sixty applications with one paragraph each is more useful than ten applications with every portfolio attribute filled in. Breadth makes gaps visible; depth is easy to add later once the shape is right.

Who to involve

Section titled “Who to involve”

Three roles, filled by one or more people each:

  • EA lead — the person accountable for the landscape as a whole. Owns the workspace, decides the modeling conventions, reviews the first pass. Without an EA lead, the landscape fragments into personal notebooks.
  • Domain experts (SMEs) — one per major business area (Finance, Operations, Sales, Engineering, and so on). They supply the applications and flows for their domain. They do not need to learn Albumi before they start — the EA lead or a proxy captures their input and they correct it.
  • Reviewers — the people who will approve changes once governance turns on. Often the same as the SMEs, plus a portfolio or technology lead. Name them up front so the review workflow has someone on the other side when you need it.

Smaller organizations collapse this to two or even one person. Larger ones expand SMEs into a per-domain working group. Either is fine as long as each role has a real name.

Week 1 — foundation

Section titled “Week 1 — foundation”

Goal: a landscape a stranger can read and recognize.

  • Shape the organizational tree. Create the three or four top-level organizations (departments, regions, business units) that the rest of the landscape will be classified under. Stop there — deeper levels can wait.
  • Capture the core applications. Aim for the twenty or so that would appear on the portfolio slide at a steering meeting. Name, one-line description, owning organization, owner. Skip lifecycle dates, portfolio attributes, and compliance flags for now.
  • Sketch the capability tree — top two levels only. Three to six Level 1 domains, a handful of Level 2 capabilities under each. Do not go deeper; see Business Capabilities for why trees deeper than four levels become unreadable.
  • Link applications to capabilities. For each of the twenty applications, pick the one to three capabilities it realizes. Gaps and redundancies are already visible at this point; do not try to fix them yet.

If you have source documents (wikis, spreadsheets, architecture notes), drive the whole week with an AI agent as described in Quick Start. Otherwise follow the per-entity order from Manual Start.

Week 2 — integrations and data

Section titled “Week 2 — integrations and data”

Goal: the flows between what you already have.

  • Model the integrations between core applications. Focus on business-meaningful flows — nightly exports, real-time sync, batch file transfers. Ignore low-value point-to-point calls; they add noise. See Integrations for direction and operation rules.
  • Introduce data objects. Five to ten core concepts (Customer, Order, Invoice, Product). Link each to the applications that operate on it — who reads, who writes, who creates.
  • Resist the urge to decompose. Address is not a separate Data Object unless multiple applications share a reusable Address book. The common first-week failure is over-modeling the data layer.

By the end of Week 2, an SME from another domain should be able to open the workspace and understand how their area fits.

Week 3 — breadth

Section titled “Week 3 — breadth”

Goal: cover the rest of the portfolio at the same depth as Week 1.

  • Add the remaining applications. From twenty to the full inventory — often fifty to two hundred, depending on the organization. Same information depth: name, owner, organization, realized capabilities. Do not deepen the early ones yet.
  • Add the technology layer. IT Components for the databases, runtimes, messaging platforms, identity systems your applications declare as dependencies. Start with the ten or fifteen that appear most frequently; add the long tail as you discover it.
  • Widen the capability tree if needed. If Week 3 surfaces gaps (applications that do not fit any existing capability), add the Level 2 capabilities that describe them. Still stay at two or three levels.

Week 4 — depth, selectively

Section titled “Week 4 — depth, selectively”

Goal: sharpen the parts of the landscape that drive decisions.

Do not try to deepen every entity. Pick the areas where portfolio decisions are already on the table — a specific migration under discussion, a cost review, a compliance audit — and deepen those first.

  • Portfolio attributes on the applications the business is actively discussing. Business criticality, Functional fit, Technical fit, TIME classification, hosting type, data classification. See Applications → Portfolio attributes.
  • Lifecycle dates on anything with a known go-live or retirement. Dates are what drives status in Albumi — set them and the lifecycle views start working. See Lifecycle & Dates.
  • Compliance flags where relevant. GDPR, SOX, PCI DSS on the applications that are in scope for those regimes; classification and PII / PCI flags on the data objects that warrant them.

Everything else stays at Week 1 depth until a reason to deepen it shows up.

Turning on governance

Section titled “Turning on governance”

Once the landscape has a shape and an initial owner set, governance stops being premature and starts being useful.

  • Assign real owners. Every application, integration, IT Component, and data object should have a named owner. An owner can edit their entity directly; non-owners must propose changes.
  • Set up one review board. Start with a single “Architecture Review” board containing the reviewers you named on day one. Specialized boards (Data, Technology, Portfolio) can come later as review volume grows. See Boards & Sessions.
  • Schedule the first review session. Put a date on the calendar, even if the agenda is empty at first. The existence of the session is what unblocks reviewers acting on it.
  • Announce the switch. From this point on, non-owner changes go through proposals or ACRs. See Change Requests (ACR).

Before this point, editing the landscape is a modeling task — you are still figuring out what is there. After it, editing is a governed operation. Do not turn governance on before the shape is right, and do not postpone turning it on once it is.

Common failure modes

Section titled “Common failure modes”
  • Going deep on day one. Two weeks filling in every portfolio attribute for three applications, while ninety-seven applications remain unmodeled. The landscape produces no value until it has breadth.
  • Single-author bottleneck. The EA lead writes everything; SMEs review, which means they skim. SMEs should own their own entries, even if the EA lead edits for consistency.
  • Modeling edge cases before the base is right. A recently-acquired subsidiary with its own regional Salesforce variations is not a Week 1 problem. Model Salesforce as one Application first; split when the split actually drives a decision.
  • Waiting too long to turn on governance. Three months of ungoverned edits produce a landscape no one trusts, because no one can trace why it looks the way it looks.
  • Turning on governance too early. Governance on an empty landscape produces review friction over trivial setup work. Wait until the shape is visible.
Section titled “Related”