The company or organization that owns the barometerIT tenant.
The enterprise map is the entire set of data objects that are related to the enterprise and are stored in barometerIT. In the graphical map on the user interface, the circles in the map represent systems and companies. Only root systems are displayed because sub-systems and their connections are rolled-up into the root system. The lines between the circles represent connections. Thicker lines indicate multiple connections. On a system or company view, the current entity and the entities that it is connected to are highlighted.
View options for entity sections (box, tree, table, summary, impact)
Depending on the entity items that are listed in the section, two or more of the following options are available for displaying the items:
- Box – displays the hierarchy of the entity items in either a box structure
- Tree – displays the hierarchy of the entity items in either a tree structure
- Table – displays the entity items in a table
- Summary – displays the entity items in a summary view widget that you can customize
- Impact – displays the lifecycle roadmaps for the related entity
- Viewer – displays a preview of a document
The data objects that you define in barometerIT as part of your enterprise map are called entities. The entities are: actors, capabilities, companies, connections, data, demands, deployments, markets, organizations, people, products, skills, standards, strategies, systems, and technologies.
Entities have some common fields such as name, barometer number, content status and so on. You can create associations between entities to show the relationships between them.
Relationship types define the nature of a relationship from the perspective of the current entity. For example, when you create a relationship between an organization and a system, you select a relationship type to define whether the organization owns, supports, or uses the system.
Entity model hierarchies
Some entities (for example, demands, technologies, systems) can be structured in a hierarchy.
For example, you can set up a hierarchy of demand items where a parent program demand item has one or more child project demand items.
The intended use of domains is to isolate different schemas or models of parent-child relationships. In a database schema, a table is the parent of a column (field). In a capability schema, a category or group can be the parent of a process or activity. In both of these cases, you can use domains to isolate one schema or model from another.
If items coexist in one schema or model, then they belong in one domain. Hierarchies
cannot cross domains but other types of relationships can. For example, for a field in a data schema, you can create relationship types to represent when the field is related to, a duplicate of or a source for a field in another data schema.
A discussion is a comment thread that you can add to any entity record. All users who have access to the entity record can view and contribute to discussions on that entity record.
The pivot option switches the view on a table to focus on the selected entity catalog.
Each view is focused on an entity (or collection of entities), and displays lists of the entities that are related to the current entity. From an entity view, you can pivot to change the focus of the view to one of the sets of related entities.
For example, when you view a system, the Related Data section lists the data that is processed and stored in the current system. However, you might like to see what data is transmitted over the related connections of the system. To do this, you click the Pivot button at the top-right of the related connections list. The view changes to a view that is now focused on the set of related connections. In this new view, the Related Data section lists the data that is transmitted over the Related Connections list.