Relationships

A list tells you which applications exist. Relationships help explain what a change could affect. Capture the connection, its meaning and its direction where direction matters.

The Related card on a fact sheet follows the layers of the metamodel: strategy and transformation, business architecture, application and data architecture, then technical architecture. Atlas extensions and other relations appear after those layers. Layers with no related groups are omitted.

Choose the right connection

For an application and a data object, record how the application uses it: create, read, update or delete (CRUD). For an interface, record the data format it carries, such as JSON, CSV or EDIFACT, separately from the protocol that transports it. If you have an admin, architect or app owner role, open the interface fact sheet and choose Edit interface to set or correct its format; the form starts with the saved values.

Keep the business information separate from its storage technology: Customer is a data object; a database is an IT component.

Add an integration

If you have an admin, architect or app owner role, open Integrations and choose Add integration. Pick the source application, which sends the data, and the target application, which receives it. Then give the integration a name, an optional description, the organization that owns it and, if you know it, an owner. Atlas suggests the name "Source to Target" until you type your own. Source, target, name and organization are required; Atlas marks a missing field when you choose Create Integration.

A new integration starts with the type Other and the direction outbound, from source to target. Open its fact sheet and choose Edit interface to set the type, protocol and data format.

Record direction carefully

For a data exchange, identify source and target. Then establish which data is carried and how the exchange occurs. A request travelling one way does not automatically mean the business data travels that way.

If you cannot confirm the direction, record the uncertainty and ask the responsible owner. An incorrect direction can lead to an incorrect impact assessment.

Explore an application's neighbourhood

On the pilot application fact sheet, examine the related integrations, interfaces, data objects, IT components and capabilities. Follow the relevant record to understand the dependency in more detail.

With edit permission, use New on the application's Integrations card to create an exchange with this application preselected as the source. Use Edit on the card to choose a linked integration, or Edit on its row to open that integration's editor. The card's Edit action is disabled when no integration is linked. Creating an integration requires Editing live; unsupported write controls are unavailable while a change request is active.

The Integrations card lists the integrations where the application is the source or the target: the direction as the application sees it (Out, In or Both), the name, the protocol, the other application, the type and the number of data objects. The data objects the integrations carry are shown above the table. Choose an integration's name to open its fact sheet. A link recorded only as an application relation, without an integration record, is listed under relations without an integration record; create an integration when you know how the data is exchanged.

An integration's fact sheet starts with its lifecycle (Plan, Phase in, Active, Phase out and End of life, each with the date it starts) and the Integration flow: the source application with the output interface the data leaves from, the protocol, delivery pattern, data format and frequency on the line, and the target application with the input interface it arrives at. The interfaces the integration uses are highlighted; the applications' other interfaces are dimmed. Below the flow are the type, protocol, data format, authentication, delivery pattern, initiator, direction and frequency, each with its source. Then follow the Middleware the integration runs through, with version, licence and lifecycle, and the Data objects it carries, with classification, personal data (PII) and the operations the integration performs (create, read, update, delete). If you have an admin, architect or app owner role, choose Edit to change the integration, or the pencil on the lifecycle, the flow or a data object's operations. The pencil on the flow edits the card in place: click an interface on either side to bind it (click it again to unbind), choose ? to add a new interface on that application, set the seven attributes under the diagram and choose Done. The delivery pattern says how the data is delivered (request response, fire and forget, publish subscribe, event driven, batch or streaming) and the initiator who starts the exchange (push, pull or event driven). Binding an interface fills an empty protocol and data format from it. The pencil on Middleware opens Edit middleware: every IT component in the workspace is listed on the left with its category and vendor, so search by name, category or vendor and tick the ones the integration runs on; the right side shows what is selected. The pencil on Data objects opens Edit data objects: tick data objects on the left, grouped by data domain, and set C, R, U and D for each on the right. Press Done to save; Undo on the card puts the previous links back, operations and dates included.

Interfaces on an application

An application's Interfaces card lists the points where it receives data (Input) and sends data (Output), for example an event stream or an API. Each interface has a name, a protocol, a data format and a description, and shows the integrations that use it and the data objects they carry. An interface no integration uses is marked Unused. Choose Flow to see which data objects pass through the inputs and outputs.

An integration leaves from an output interface on its source and arrives at an input interface on its target. Record the interfaces on the application first, or choose ? on either side when you edit the integration flow. In SAP LeanIX the integration itself is called an interface; Atlas calls the integration an Integration and the point on the application an Interface, so the two do not get mixed up. Archiving an interface can be undone; integrations keep their reference to it.

In the simple-shell pilot, an IT component's fact sheet shows linked applications and interfaces, what it requires, what requires it, and related user groups. An organization's fact sheet shows different links by kind: a team shows owned applications, owned capabilities, members and child teams; a user group shows applications, IT components and members. An empty card means no link is recorded, not that the relationship cannot exist. Annual cost on an IT component is hidden when your access does not allow financial details; otherwise it is shown in the currency you pick in the top bar, like every other amount. A decision's fact sheet shows its rationale and the applications, capabilities and initiatives it affects; initiatives are reached through those applications and capabilities. An empty card reads Not set.

Data objects

The data object tree groups data objects by data domain. A data object can sit under a parent, for example Campaign audiences under Customer profiles; set or clear the parent with Edit on the data object. A data object cannot be placed under itself or under one of its own children.

A data object's fact sheet shows its domain, owner application, steward, classification, personal data and retention, then Applications (role, lifecycle, criticality, TIME and the operations each performs), Integrations (direction, lifecycle and the operations each performs on the data object) and Capabilities (level, strategic importance and maturity). Each of these cards has its own search. If you have an admin, architect or app owner role, choose the pencil on Capabilities to link or unlink the business capabilities that use the data object; Undo puts the change back. The capability link is an Atlas addition: SAP LeanIX reaches capabilities only through applications.

Edit relationships in a change request

If you select one of your own Draft or Revision requests in the Atlas header, the fact-sheet watermark shows that supported relationship edits are being collected as request items. This includes supported application data-object links and integration or interface relation edits. Review the items through Edit request before submitting; the live relationships stay unchanged until the request is applied or approved. An edit Atlas cannot express as a request item is unavailable while a request is active. See Change requests and review.

Use relationships in a change

Before replacing an application, identify both incoming and outgoing exchanges. Check the supported capabilities and the teams responsible for the affected systems. The result is a scope to verify with owners, rather than proof that every dependency has been discovered.

Continue with Business capabilities.

See also Data objects, IT components and Lifecycle and dates.

Follow the worked example in Integrations and interfaces when you need to trace or troubleshoot a specific flow.