Manual setup

Use a decision you already need to make. The example below uses a fictional CRM replacement; it is a working method, not a claim about a customer.

1. Set the boundary

Write down the question, its owner and the business area involved. For a CRM replacement, begin with sales and customer service rather than every system in the company.

Check that you are in the intended workspace. Open Applications in the navigation available to your account.

2. Capture the applications

Start with the CRM and its closest neighbours: ERP, customer service and reporting. Reuse an existing application record when one already exists.

For each application, establish its name, purpose, business owner and lifecycle. Leave values unknown when you cannot support them. An estimated cost should remain an estimate, with its basis recorded. Link the owner to a person rather than only an e-mail: the Applications list then shows the owner's name and department, which makes the owners to involve easy to see.

In the redesigned Applications pilot, selecting an application opens its fact sheet. The fact sheet brings the summary, related records, sources and activity together. Editing depends on your workspace role.

3. Connect the landscape

Record the business capabilities the applications support. Add the important integrations and the data involved. For each integration, check which application sends and which receives the data. If a capability support link has Active From or Active Until dates, check its state before counting it as current support; an ended link stays visible in relation reads but leaves current support and cost totals.

On the application's fact sheet, the Integrations card lists the integrations recorded so far; choose one to open its fact sheet with the flow from source to target. The Interfaces card lists where the application receives and sends data; an integration runs from an output interface to an input interface. On the integration, the pencil on the flow lets you click the two interfaces to bind them and set type, protocol, data format, authentication, delivery pattern, initiator and frequency in one go. Links that exist only as application relations are listed below the table until you record them as integrations. See Relationships.

On a fact sheet, open the Relations tab to review linked records by metamodel layer, from strategy and business through application, data and technology. Atlas extensions and other relations follow those layers; sections with no related records are omitted. Planned subtypes on the metamodel poster are labelled separately from available subtypes.

To see the application in a generated view, choose Open in view in the fact sheet header. It lists the application's integration map when the application has at least one integration with another application, and the landscape views. On a data object's fact sheet it lists the data object's data lineage once an application or an integration is linked to it. The menu does not appear when no generated view contains the record.

For example, “CRM sends customer updates to ERP” is a useful, directed relationship. “CRM and ERP are connected” leaves the effect of a change unclear.

4. Check the evidence

Use a system list, an integration specification or a conversation with the owner to check the model. Record unresolved questions instead of filling gaps with assumptions.

The Sources and gaps section in the pilot fact sheet helps distinguish supported information from missing information. Read Sources and evidence.

5. Use the result

Walk through the CRM replacement: which integrations, capabilities and owners need attention? If the decision involves a planned effort, open Initiatives to see its type. Existing Must-Win Battle, Strategic Project and Initiative records are shown as Program or Project. The type describes the planned effort; it does not change the application's lifecycle or current relationships. Check the important links with the responsible people before using the model to make an investment decision.

The application's Impact card helps check affected linked applications, capabilities, known owners, sources and uncertainties. Treat Unknown owners and missing sources as questions to resolve with the people responsible; if impact is unavailable, try again before drawing a conclusion. The same analysis appears for existing application targets on a change request.

A useful first result is a bounded landscape, a list of affected dependencies and named questions to resolve. Extend the model when the next decision requires it.

If your architects work in Archi or another ArchiMate tool, open the CRM's fact sheet and choose Export to Archi (ArchiMate) in More actions. The file holds the CRM, the applications it integrates with and two laid-out views; see Applications.

If you already have an inventory or diagram, use the import guide. You can also start with a read-only AI analysis.

Check your first result

Before expanding the model, check that you can:

• State the decision, its owner and the business area in scope.
• Open the CRM and at least one neighbouring application's fact sheet.
• Follow one integration from its source to its target and name the data it carries.
• Identify a responsible owner, or record the missing owner as an open question.
• Show a source for one important fact and list the gaps to resolve next.

The result is ready for an initial discussion when another person can follow this explanation and distinguish recorded facts from open questions.