Skip to main content

Understand Boldo and its knowledge base

Boldo describes the elements of your organization and the connections between them. You maintain this information in a knowledge base, then use inventories and visualizations to examine it from different perspectives.

Understanding this distinction helps you choose where to work. You can update information about an application, draw a diagram containing that application, or explore its dependencies. These actions have different purposes, even when they concern the same asset.

Describe an element with an asset​

An asset represents an element you want to document: an application, a process, a capability, a technology or another element defined by your organization. Its page brings together its name, properties and relationships.

An asset type determines which information can describe that element. For example, an Application type might provide a description, status and annual cost. A Process type can have different properties. The types and their names depend on your organization's configuration; examples in the documentation are not a required model.

A property describes one characteristic. Its format determines the value you can enter: text, a number, a date, a choice or another configured format. Some properties are calculated from other information. A calculated value is not edited like a manually entered value.

The metamodel defines the asset types, properties and relationship types available in the organization. Changing the metamodel changes the structure used to document assets. Filling in an application's cost changes that application's information, not the definition of its type.

Connect assets with relationships​

A relationship connects two assets using a configured relationship type. The type gives meaning to the connection and determines which asset types can participate. Direction matters: read the connection from its source to its target.

For example, your organization could define an Application that supports a Business process. The application and the process are two assets; the support relationship connects them. Its meaning differs from a relationship saying that one application exchanges data with another.

Relationships can also carry properties when the metamodel defines them. A percentage attached to a relationship describes that connection, rather than the application as a whole. Keep this distinction in mind when entering values or reading a chart built from relationships.

A diagram's visual arrangement helps explain connections, but it does not replace the underlying assets. When you need to confirm a stored relationship, inspect the assets and their relationship information.

Read the same information in different ways​

An inventory lists assets of a type. Use it to find assets, compare properties and update the information you are allowed to edit. Opening an asset gives you its detailed page.

A visualization presents selected information for a particular question. A view can show a filtered list; a chart can summarize values; a diagram can explain an architecture. Nested maps, impact analyses and dashboards provide other ways to explore the knowledge base.

For example, you might keep a view of applications to review and a chart showing their costs. An application appearing in both remains the same asset. A filter changes the selection displayed; it does not remove excluded assets from the knowledge base.

The distinction also matters when editing. Changing a visualization's layout affects its presentation. Editing an asset's property affects the underlying asset in the working context used by that action. Check the command and context before assuming a change concerns presentation only.

Distinguish organization, space and scenario​

An organization is the working environment containing the model, data, members and visualizations. Your account can access several organizations with different permissions. Switching organizations opens another environment; it does not transfer the current organization's data.

The catalog organizes visualizations into a Shared space and, for eligible profiles, a Personal space. These spaces concern the visualizations and folders you organize. Placing a visualization in your Personal space does not create a private copy of every asset it uses.

A scenario provides a context for preparing changes separately from real data. Check the scenario selector before editing. Personal space and scenario serve different purposes: one concerns the organization of content, the other the context of changes.

The home worklist and guided reviews follow the selected context for suggestions and completeness. The quality report also follows the scenario’s ownership and completeness. Attestation, re-attestation requests and reminders remain limited to real data.

Understand why two people see different things​

Visibility and editing depend on your membership, account type and assigned permissions. An asset may be visible while one of its properties is hidden or read-only. A shared visualization does not grant access to information that its reader cannot otherwise see.

Being responsible for an asset and being allowed to edit it are also distinct. Ownership supports review and accountability; it is not a general permission to change every field. Follow the available commands and ask your administrator about a missing permission.

Quality indicators add another distinction. Completeness concerns whether expected information is filled in. Attestation records a deliberate check of accuracy; freshness reflects the applicable review policy and attestation state. Filling in a field alone does not attest the asset's accuracy.

Follow one example​

Suppose your model includes an Application named “Order management” and a Process named “Prepare an order”. You record the application's status and cost, then connect it to the process using an allowed relationship.

You can find the application in its inventory, show it beside the process in a diagram and include its cost in a chart. These representations answer different questions using the same documented elements.

Before making a change, identify what you are changing: the asset, its relationship, a visualization or the model itself. Then check the organization and working context. The interface landmarks help you locate each of these entry points.