Repository: applications, change sets and metamodel

The repository is the single register of everything the organisation’s architecture is made of: applications, technology, business elements, data, motivation and more, each as an ArchiMate 3.2 element with relationships between them. Edits are never made directly. They are proposed in a change set and applied when another architect approves, so the register stays trustworthy. The Metamodel screen explains the types and rules behind it all.

Properties

Properties are extra facts about one element that do not have a field of their own, shown as name and value pairs. For example “Go-live = 01/04/2027” or “Hosting = Cloud”.

• Anyone who can see the element can read them here.
• To add or change them, an architect chooses Edit on the element, types one fact per line as name = value (up to 30), and saves into a change set.
• Saving replaces the existing properties, so keep the lines you want to keep.
• Relationships can carry properties too, from the Properties control on each relationship row.

If there are none, the panel says so and reminds you that they are added when you edit.

Supplies

This card appears on a business actor that is a vendor. It lists the applications and other elements that vendor supplies, each linking to its own record, with its type.

You do not edit it here. The list follows from the Vendor field on each element. To make a vendor, add an element of type Business actor, then choose it as the Vendor when you add or edit an application. Open any listed item to see its details, or open the vendor again to check what it supplies before a contract renewal conversation.

Aliases

Aliases are other names an element is known by, such as a short code or a former product name. Search, imports and the interface loader recognise them, so a search for the old name still finds the element.

1. Open the element and find Aliases.
2. Type the alternative name in Add an alias and choose Add alias.
3. To remove one, choose Remove beside it.

Unlike other edits, alias changes apply at once, without a change set, and are recorded in the audit log. Architects can add and remove aliases. When an import matches a system to an existing application you can tick Remember as alias to save the name for next time.

Relationships

Relationships show how this element connects to others: what it serves, realises, accesses and so on. The table lists each one with its direction, the relationship type, the element at the other end and that element’s type.

To propose a new one, an architect completes Propose a relationship: choose the direction and the relationship type, then enter the other element’s reference, such as APP-0002 or CAP-0010, or a relationship reference to join a relationship to something. The ArchiMate 3.2 rules are checked before anything is queued, so an invalid link is refused with a reason. To drop one, choose Propose removing. Both go into your change set. Use the Metamodel checker if you are unsure which relationship is allowed.

Applications & technology

This is the list of every element type in the repository except capabilities, which live in the capability model. Despite the name it covers business, application, technology, motivation and other layers.

• Search by name, ID or description, and filter by layer, type and lifecycle (active, retired or both).
• Click a name to open the element’s record.
• Architects see Add element, which opens the form for a new element.
• The tiles above the list are also filters: click one to see only the elements with that problem.

Only the first 500 rows are shown, so narrow the filter to see the rest. Everyone with access can browse. Changes made here go through a change set.

Data quality

The tiles at the top of the list count what is in the repository and where the gaps are. Clicking a count filters the list to those elements, so it works as a to-do list.

• Elements and relationships are the totals.
• No owner means nobody is named as responsible.
• No relationships (orphans) are not connected to anything.
• Not reviewed in 12 months are stale, including anything never reviewed.
• Possible duplicates have the same type and name as another active element.
• Invalid relationships break the ArchiMate 3.2 rules.

Work through them in turn and the numbers fall. See also Repository checks in the Metamodel.

Change sets

Change sets list every proposed edit to the repository. Nothing reaches the repository until a change set is approved and applied.

• Use the filters All, Drafts, Waiting and Applied.
• Each row shows the title, the author (you are marked), how many changes it holds, and its status: Draft, Waiting for approval or Applied.
• Open one to see what it contains.

Adding or editing an element automatically adds it to your open change set, so you rarely start one by hand. Only architects see this list. A change set from one architect is approved by a different architect, so a second pair of eyes sees every change. See A change set.

Changes

This table lists everything a change set would do: each row says whether it adds, changes or retires something, what it is, its ID and the detail.

For a change, the detail shows each field with the old value struck through and the new one beside it, including property changes, so you can see exactly what will differ. Relationship changes name the elements they join.

If you wrote the set and it is still a draft, you can remove a single row with Remove, rename the set and add a reason, then submit it. If a row is wrong, remove it rather than discarding everything. Warnings about the set, if any, appear above the table.

Decision

The reviewing architect sees this card on a submitted change set. It is where the set is accepted or sent back.

1. Read the Changes table carefully.
2. Add a note. A note is required to send a set back and optional when approving.
3. Choose Approve and apply to make the changes, or Send back to return it to the author.

The author cannot approve their own set, except where the organisation has only one architect, in which case a sole architect may approve. The author can Withdraw to edit while it is waiting. Approved changes are written to the repository and the decision is recorded in the history.

Metamodel

The Metamodel screen shows the rules Lintel enforces: the ArchiMate 3.2 element types and relationship types, and which relationships may join which elements. It is a reference to explore and a place to check a design idea.

Tabs across the top cover element types, relationship types, rules by element, a relationship checker, derived relationships, repository checks, specialisations, ArchiMate conformance, the TOGAF content metamodel, TOGAF ADM deliverables and the Zachman grid. Everyone who can see the repository can read it. A tenant admin can switch element types on and off, and architects can add specialisations.

Element types

The Element types tab lists every ArchiMate 3.2 element type by layer, with its ID prefix, how many active elements use it and how many other types it can link to.

If you are a tenant admin, tick or untick In use and choose Save element types to hide or offer a type for new elements. Switching a type off only hides it from new elements. Existing elements keep working, and a type with active elements cannot be switched off. Some types are required and cannot be turned off. The counts link to the rules for that type.

Relationship types

This tab lists the ArchiMate relationship types, the single letter each uses in the rules, how many are active in the repository now, and how many element pairs the rules allow it to join.

Use it to see which relationships you actually use and which the model allows but nobody has drawn. Association is allowed between any two element types, so it never needs checking. For the exact element pairs, use Rules by element or Can these be linked?.

Derived relationships

Derived relationships show what follows from chains of relationships already in the repository, following ArchiMate 3.2 section 5.4. Nothing is stored. It shows what you could draw without adding new facts.

1. Open the Derived relationships tab.
2. Type an element reference, such as APP-0001, and choose Show.
3. Read the table: the derived relationship, the element it reaches, the number of steps and the route taken.

Use it for questions such as “what does this application ultimately support?” Each target links to its record. If nothing is shown, no chain leads away from that element.

Repository checks

This tab checks every active relationship against the ArchiMate 3.2 rules and the junction rules, and lists any that break them.

If everything is fine, the page says No problems found. Otherwise each row gives the relationship’s reference and the problem, so you can propose a fix in a change set, for example by removing an invalid relationship or choosing a permitted type. Run it after a large import, or before an Architecture Review Board meeting. The count of invalid relationships also appears in the Data quality tiles.

Specialisations and extension elements

A specialisation is a named variant of an element type that keeps its rules, for example “Cloud service” as a kind of application service. An extension element is for something ArchiMate has no type for, such as a supplier or a contract. Extension elements are not ArchiMate, so they can only be joined to others by association.

The table lists each specialisation, what it specialises, its description, how many active elements use it and whether it is on. A tenant admin can Switch off or Switch on a specialisation. Switching off stops it being offered for new elements, but elements already using it keep it. Choose a specialisation on the element form with Specialisation.

Add a specialisation

Tenant admins use this form to create a new specialisation or extension kind.

1. Open the Specialisations tab.
2. Under Add a specialisation, enter a Name (up to 80 characters).
3. In Specialises, choose the ArchiMate type it is a variant of, or Extension element (not ArchiMate).
4. Optionally describe it, then choose Add specialisation.

It then appears in the Specialisation list when architects add or edit elements. An extension element needs a specialisation to say what kind of thing it is. See Specialisations and extension elements.

ArchiMate 3.2 conformance

This tab is a self-assessment of how fully Lintel supports the ArchiMate 3.2 specification, revised with each release. It counts areas met, partly met and not yet met, and shows a weighted percentage with partial counting as half.

Each area has a status and a note about what is and is not covered. It is not a certification claim. Use it to understand the limits of the tool, such as which derivation rules or notation details are still to come, before you rely on it for a particular modelling task.

What a can link to, beyond association

On the Rules by element tab, this table shows what one element type may be linked to. The heading names the type you chose, such as application component.

1. Open Rules by element.
2. Pick the From element type and choose Show.
3. Read the table: each element type it can link to, that type’s layer and the relationships allowed.

Association is always allowed between any two types and is left out. If the type allows nothing else, the page says so. It is the quickest way to find out which relationship to use before you draw one in the modeller or propose it on a record.

Can these be linked?

This tab checks whether ArchiMate 3.2 allows a relationship between two element types.

1. Open the Check a relationship tab.
2. Choose the From type and the To type.
3. Optionally choose a specific Relationship, or leave it on Any.
4. Choose Check.

The result says whether that relationship is allowed, or lists every relationship allowed from one type to the other. It also shows what is allowed in the opposite direction. Use it before proposing a relationship, to avoid a refusal.

An application or technology record

An element’s own page shows everything recorded about it in one place, whatever its type.

The top card gives the description, owner, source, aliases, vendor, last reviewed date and, for applications, TIME disposition, annual cost and contract end. Below it are the properties, aliases and relationships.

Architects can Edit the element, run a Governance assessment against the governance library, or propose retiring it. Retiring also retires its relationships once approved. If changes to it are already waiting in a change set, a notice says so.

Add or edit an element

This form proposes a new element or a change to an existing one. Saving adds it to your open change set. It reaches the repository when another architect approves.

• Type is chosen when adding (grouped by layer) and cannot change later.
• Name is required. Add a Description, Owner and Source.
• Vendor links it to a business actor that supplies it.
• Last reviewed records when someone last checked it.
• Properties hold extra facts, one per line as name = value.
• Specialisation is optional for most types and needed for an extension element.

Choose Add to my change set. Architects only.

A change set

A change set’s own page shows who wrote it, its status and when it was applied. It is the unit of review.

While it is a draft you can rename it, add the reason, remove single changes, Submit for approval, or discard it. Once submitted, the author can withdraw it to edit. A different architect reads the changes, then decides: Approve and apply or send it back with a note. Any reviewer note is shown at the top. After approval the set shows as Applied and keeps a permanent record of who decided and when.

TOGAF content metamodel

This tab sets each entity of the TOGAF 10 content metamodel against the ArchiMate element types that hold it here, with how many active elements the organisation has for it.

An entity with none is a gap in the repository, not an error. Use it to see which parts of an enterprise architecture you have captured and which you have not, grouped by Business, Data, Application, Technology, Motivation and Implementation. Entities are listed with a note where the mapping is not one to one.

TOGAF ADM deliverables

This tab lists the main deliverables of each ADM phase (TOGAF 10) and which part of Lintel supports each one. It totals how many are provided, partly provided or not yet provided, and gives an approximate percentage where partial counts as half.

It is a hand-kept self-assessment, updated with releases, so treat it as a guide to coverage and not a formal claim. Each deliverable shows where in Lintel you would find or build it, which helps when planning engagements. See ADM engagements.

Zachman grid

This tab lays out the Zachman Framework as six perspectives (rows) by six interrogatives (columns). Each cell says which ArchiMate element types hold it in Lintel and how many active elements there are.

“Not held” means Lintel has no element type for that cell. “None yet” means a type exists but nothing is recorded. A number with “held” means the cell is populated. Rows 5 and 6, the tool and working-enterprise perspectives, are largely outside what a modelling repository holds. Use the grid to see how complete your repository is from the Zachman point of view.