Northwise

Feature Reference

Landscape

Last updated 2026-07-03

Available on all plans

The Landscape module is where your ArchiMate model lives. Every element your organisation uses — applications, business processes, technology nodes, actors, capabilities — is stored here with its full ArchiMate type, lifecycle, ownership, and relationship graph. Landscape is the foundation; everything else in Northwise (Principles, Plumbline assessments, Tech Discovery drift) references Landscape elements.

What it does

  • Stores the full ArchiMate 3.x element vocabulary across all layers (Business, Application, Technology, Implementation & Migration, Motivation)
  • Records typed relationships between elements (Serving, Realization, Composition, Aggregation, Triggering, Flow, and all others)
  • Renders the Layered viewpoint — a stack view from Business down to Technology — as an interactive SVG
  • Imports from AMEFF (ArchiMate Model Exchange File Format), the open standard supported by Archi, BiZZdesign, Alfabet, and others
  • Provides a reader view permalink for every element — shareable with non-architect colleagues

When to use it

  • You are building or migrating your enterprise architecture model from scratch
  • You are importing an existing model from another EA tool (Archi, Sparx EA, BiZZdesign HoriZZon)
  • A delivery team asks "which application owns customer data?" — you look it up in Landscape
  • You are linking a Principle to the specific applications it governs
  • You want to see the technology footprint for a business domain at a glance

How it works

The element

Every entry in Landscape is an element with:

  • ArchiMate type — the full 3.x vocabulary (Application Component, Business Service, Technology Node, Data Object, Business Capability, etc.). See the Glossary for definitions.
  • Statusdraft, proposed, approved, deprecated, superseded. Only approved elements appear in Plumbline assessments and Tech Discovery mappings by default.
  • Scope — domain and market tags that slice the model for different teams.
  • Owner — the architect or architecture responsibility accountable for keeping this element current.
  • Lifecycle stageplanned, in_build, live, declining, retired. Separate from status: an element can be approved-and-retiring at the same time.
  • Criticalitylow, medium, high, critical. Used for prioritising assessments.
  • Last reviewed — a datestamp the owner marks after confirming the element is still accurate. Stale elements surface as a gap signal on the Standards overview.
  • Properties — a type-specific JSONB bag. An Application Component has component_kind (saas/inhouse/cots/legacy) and hosting_kind (cloud/on_prem/hybrid). A Technology Node has node_type and host.

Relationships

Relationships connect two elements with a typed ArchiMate link. The type constrains what's semantically valid — you can't realize a Business Actor from a Technology Node. Northwise validates relationship types against the ArchiMate 3.x rules and warns (but does not block) on unusual combinations.

The most important relationships for day-to-day use:

  • Realization (Application → Business): an application component realises a business service
  • Serving (Technology → Application): a node serves an application component
  • Composition / Aggregation: structural nesting within a layer
  • Assignment: links actors to behaviour (roles, processes)
  • Association: catch-all for "related somehow" — use sparingly

The Layered viewpoint

The Layered viewpoint renders your model as a horizontal stack: Business processes and capabilities at the top, Application Components in the middle, Technology Nodes and Infrastructure at the bottom. You scope it to a domain, and the view shows only the elements and realisation/serving relationships relevant to that domain.

Interaction:

  • Click any element to navigate to its detail page
  • Pan and zoom with mouse or touch
  • Hover for a key-facts tooltip
  • Export as PNG or copy as Mermaid markdown

Other viewpoints (Application Usage, Technology, Implementation & Migration) are available as filtered list views in v1 — the right elements, just not yet rendered as a canvas.

Element detail page

The detail page is the architect's full working surface. It has three areas:

Header — name (inline-editable), type badge, status (change in place), owner, scope, criticality, lifecycle stage, last-reviewed date, provenance (authored vs. imported). From here you can also Capture decision (opens a new ADR pre-linked to this element) or Open reader view.

Body — markdown description and type-specific properties rendered as structured key/value pairs.

Side panel (tabs):

  • Relationships — inbound and outbound, with inline add/remove
  • Linked Deliverables — Architecture Visions, SADs, Roadmaps, and ADRs that reference this element
  • Linked Principles — principles linked via the element_principles table
  • Linked Technology — catalogue entries this element uses (feeds Plumbline drift detection)
  • History — full version timeline with per-field diffs

Search and filters

The Landscape list page (/landscape) has a full-text search box and a collapsible filter bar covering type, layer, status, provenance, scope, owner, criticality, lifecycle stage, tag, and staleness. All filters serialise to the URL — bookmark a filter set and share it with the team.

AMEFF import

See the how-to for Git Tech Discovery to add automated scanning alongside the manual model

Northwise imports AMEFF 3.0–3.2 files (.xml or .zip — Archi exports .zip by default). The import:

  1. Parses every element, relationship, and view in the file
  2. Creates new elements for anything not already in your tenant
  3. Updates existing elements when the source changed and you haven't edited them since the last import (non-conflicting)
  4. Flags a conflict when an element was both edited locally and changed in the source — you resolve conflicts one-by-one (Keep authored / Accept source / Manual merge)
  5. Re-creates viewpoints from the AMEFF view definitions

Nothing is ever silently overwritten. The conflict resolution UI at /landscape/import/conflicts shows a side-by-side diff and waits for your decision.

Run the import as a dry run first (toggle on the import page). You'll see the summary — how many creates, updates, conflicts — before anything is committed.

The Free plan can import AMEFF files. The 50 MB / 50,000-element limits are generous for any real-world model, but check your file size before uploading.

Reader view

Every element has a permalink at /r/element/{uuid}. The reader view strips architect controls and ArchiMate jargon, renders the description, and shows the "Relates to" section in plain language. Link it in emails, Confluence pages, or chat threads so non-architects can browse the model without a Northwise account.

Reader-view links require login in v1. Public (unauthenticated) access is on the roadmap.

Configuration

There is no per-tenant Landscape configuration in v1 beyond the element data itself. Scope domains and scope markets are free-form and auto-complete from existing values in your tenant.

Principles — link principles to Landscape elements to govern them

Tech Catalogue — link catalogue entries to Application Components for drift detection

Plumbline — assessments run against the principles linked to Landscape elements

Git Tech Discovery — automated scanning populates the Linked Technology tab