UrbaHive Guide
FR

Map your IT landscape

How the building blocks fit together

On this page

A few rules hold the map together. They decide what you must fill in, in which order you create things, and why a deletion is sometimes refused. Read this page once before you enter your own data.

How the objects connect An application belongs to exactly one program, runs on at most one server and can follow one version of an architecture document. A server sits in at most one infrastructure. A flow goes from one application to another and has one flow type. A process has one or more domains and ordered steps, can realize one capability, and its steps use applications. Capabilities are supported by applications. Processes Process domain typology Process L1 value chain or L2 process map Step Activity, Decision, Event or Sub-process Capability with a criticality Application Editor (vendor) Advancement Status Internal or External Program Other application DAT version Status DAT reference the document Server Infrastructure typology Each flow has one flow type (required) and can be two-way. one or more, one primary realizes at most one supports belongs to exactly one Flow runs on at most one follows at most one version of sits in at most one ordered steps uses Sub-process: another process parent L1, triggers People (members and contacts) Responsible for programs, applications, servers, processes and capabilities. R, A, C or I on steps. required link optional link value from Typologies “Supports” and “uses” carry a role: Primary, Supporting or Data source.

Programs, applications, flows, servers, infrastructures and architecture documents, and where processes and capabilities meet them.

The rules behind the diagram:

  • An application belongs to exactly one program. The program is required.
  • An application runs on one server at most. You can leave it without a server.
  • An application can follow one version of one architecture document (DAT).
  • A server sits in one infrastructure at most.
  • A flow goes from one application to a different one, and has exactly one flow type. Both applications and the flow type are required.
  • Names are unique within an organization for programs, applications, servers, flows and DAT references.

Typologies classify and colour

Typologies are the lists of values your organization shares. They classify elements and give them colours:

  • editors (software vendors) and advancement statuses, on applications;
  • flow types, on flows. Their colour is the colour of the arrows on the map;
  • infrastructures, for servers;
  • statuses, on DAT versions;
  • process domains, on processes;
  • organization roles, next to people.

See Typologies: your reference lists.

Processes and capabilities point to the same applications

Your processes and your capabilities link to the applications you register here. A process step uses applications. A capability is supported by applications. Each link has a relation type: Primary, Supporting or Data source.

That is why one application record serves the map, the processes and the coverage matrix. See Describe a step: RACI, applications and time and Business capabilities.

Build in this order

  1. Typologies: check the values you need, at least one flow type.
  2. Programs.
  3. Servers, with their infrastructures.
  4. Applications, each in a program and, if you know it, on a server.
  5. Flows between applications.

DAT references and their versions can come at any time. Create them before your applications if you want to link each application to its document when you create it.

Deleting: what blocks what

UrbaHive never deletes an element that another element still uses. The deletion is refused with "Cannot perform this action: related record does not exist or is in use." Remove or change what uses it first.

What blocks a deletion While a flow uses an application, the application cannot be deleted; while applications use a program, a server, a document version, an editor or a status, those cannot be deleted; servers block their infrastructure; flows block their flow type; document versions block their status; processes block their process domains. X Y While an X uses a Y, you cannot delete the Y. Change or delete the X first. Flows Applications Programs Servers DAT versions Flows Processes Editors (vendors) typology Advancement statuses typology Infrastructures typology DAT statuses typology Flow types typology Process domains typology Removed automatically with an application: its links to process steps and capabilities, and its additional contacts. A DAT reference is deleted with its versions, so its deletion is refused while an application follows one of them. Only Owners and Editors delete. A refused deletion says: “Cannot perform this action: related record does not exist or is in use.”

An arrow from X to Y means: while an X uses this Y, the Y cannot be deleted.

You deleteRefused whileDo this first
A programit still holds applicationsMove its applications to another program, or delete them.
An applicationa flow starts or ends on itDelete those flows.
A serveran application runs on itSet each application's Server to another one or to None.
A DAT referenceone of its versions is linked to an applicationSet the application's DAT to None. Deleting a reference deletes all its versions.
A typology valueelements use itChange those elements. The Usage column of Typologies says how many there are.

For process domains, the delete icon stays disabled while a process uses the domain. Its tooltip says "Used by one or more processes — remove the link first".

Deleting an application removes, by itself, its links to process steps and to capabilities, and its additional contacts.

Note

Only Owners and Editors delete. A deletion cannot be undone.

Every change is recorded

Each creation, update and deletion of an element or a typology value is written to the audit log. You see it in Logs and in the dashboard's Recent activity. Changes to the definitions of custom fields are not recorded. See Follow changes in the audit log.