How can I link contact information to specific CIs? For example, how would I show a relationship between a CI for a specific Windows Server to the Administrator of that server? Or for a particular network appliance to the contact information of the vendor for that appliance?

wearnest@teleflora.com - 20 October 2008 05:18 PM

How can I link contact information to specific CIs? For example, how would I show a relationship between a CI for a specific Windows Server to the Administrator of that server? Or for a particular network appliance to the contact information of the vendor for that appliance?

One way to achieve this is to write a pattern to establish and maintain the relationship. For example, you could write a simple pattern that triggers on a Host and use the pattern to relate the Host to the right Administrator person – perhaps with a lookup table and a “calculated” administrator that is based on some criteria related to the Host or what it is used for.

With this approach, the system will maintain the relationships automatically even as the infrastructure changes over time – and it can of course be extended to describe or maintain any relationship you can think of.

Allan Mertner - 20 October 2008 06:24 PM

wearnest@teleflora.com - 20 October 2008 05:18 PM

How can I link contact information to specific CIs? For example, how would I show a relationship between a CI for a specific Windows Server to the Administrator of that server? Or for a particular network appliance to the contact information of the vendor for that appliance?

One way to achieve this is to write a pattern to establish and maintain the relationship. For example, you could write a simple pattern that triggers on a Host and use the pattern to relate the Host to the right Administrator person – perhaps with a lookup table and a “calculated” administrator that is based on some criteria related to the Host or what it is used for.

With this approach, the system will maintain the relationships automatically even as the infrastructure changes over time – and it can of course be extended to describe or maintain any relationship you can think of.

So instead of maintaining the relationship within the Tideway interface, I can configure the Tideway appliance to “automatically” maintain the relationship, based on a pattern, which I have to manually create, which in turn will monitor some external table that I also manually maintain?

Can you provide any examples of external sources for this contact info?

wearnest@teleflora.com - 20 October 2008 07:32 PM

So instead of maintaining the relationship within the Tideway interface, I can configure the Tideway appliance to “automatically” maintain the relationship, based on a pattern, which I have to manually create, which in turn will monitor some external table that I also manually maintain?

Can you provide any examples of external sources for this contact info?

You can put the lookup table directly into the pattern. I’ve given an example below. In Foundation 7.2, the Data Integration for Patterns feature will allow you to write patterns that pull in data from external databases (for example, your existing asset database) and annotate the Foundation model with that information.

In the example pattern below, the lookup table People contains information on people, and the table Ownership relates hosts to the people that perform different roles for that host.

The pattern triggers whenever a host is created or updated, uses the hostname to lookup the people in the Ownership table, and makes the appropriate relationships to the people. If you modify the pattern (be sure the change the email address suffix!), upload and activate it, and rescan a host, then, browse to view the Host node and look at the “Ownership & Location” section. Links to this contact info should appear.

Hope that helps,
Tim

Note that Tim’s example uses the existing Person nodes and Ownership roles already defined in the Foundation model for this purpose.

You can view the model in the product by going Administration -> View Taxonomy. From here you can view the active taxonomy inline as a HTML page, or download a summary diagram.

If you don’t have the product to hand then there is a copy of the 7.1.5 model as part of the Power Tips.

t.moreton@tideway.com - 21 October 2008 09:05 AM

You can put the lookup table directly into the pattern. I’ve given an example below. In Foundation 7.2, the Data Integration for Patterns feature will allow you to write patterns that pull in data from external databases (for example, your existing asset database) and annotate the Foundation model with that information.

In the example pattern below, the lookup table People contains information on people, and the table Ownership relates hosts to the people that perform different roles for that host.

The pattern triggers whenever a host is created or updated, uses the hostname to lookup the people in the Ownership table, and makes the appropriate relationships to the people. If you modify the pattern (be sure the change the email address suffix!), upload and activate it, and rescan a host, then, browse to view the Host node and look at the “Ownership & Location” section. Links to this contact info should appear.

Hope that helps,
Tim

Tim, thanks for the example. That is exactly what I was wanting to figure out. This certainly doesn’t appear to be a very user friendly way of maintaining the contact information. Importing a list of contacts sounds reasonable, because that information is likely to exist in another location already. Is there not a way to select two CIs in the UI and click a button to assign a relationship?

wearnest@teleflora.com - 21 October 2008 05:27 PM

This certainly doesn’t appear to be a very user friendly way of maintaining the contact information. Importing a list of contacts sounds reasonable, because that information is likely to exist in another location already. Is there not a way to select two CIs in the UI and click a button to assign a relationship?

At present we’ve chosen not to allow administrators to make such relationships manually — the reason being maintainability. Foundation focuses on providing an accurate record of what is out there in your IT infrastructure by building a model based on real observation and the patterns you’ve configured — this will include in future pulling in extra information from other sources of record, such as databases (in a few lines of TPL).

Our experience in the past is that creating links manually (such as to identify ownership) rather than encoding rules to create them in patterns, means that the accuracy of those relationships decays over time. When Foundation discovers that the properties of a host (e.g its name, its OS, its installed software changes), patterns allow it to reason about whether it needs to update those links. Manual links stick — and having that link there when we can’t reason about whether it is still the case or not impacts on how trustworthy users consider Tideway’s data to be. You’ll have seen that data provenance is an important part of how we give confidence in the accuracy of our model.

Further, writing patterns to do this job this rarely involves writing many unwieldy lookup tables, as my example may have suggested. Many customers already encode department or location in hostnames, for example, or the presence of a particular bit of software can be used to associate a host with a particular support team. We find taking this approach is usually simple and effective.

Tim

I understand the logical argument for basing these relationships on observation rather than manual entry. It is in theory a very good design. However, this assumes that every piece of data already exists in an electronic format somewhere and is often not a true assumption.

One of our primary needs in a CMDB solution is to have a centrally accessible location for data regarding our IT systems and how they relate to our business processes. In many cases, a federated model of data discovery works great, but there are many additional pieces of data, which do not already exist in another system, and which a CMDB solution should be able to provide an interface for entering/maintaining this data. These data points may be as simple as attributes added to discovered nodes or other node types with their own attributes as well.

I’m having trouble understanding why some nodes (such as those listed under the Administration section of the Administration tab, like Organizational Unit and Location) allow manual entry, but others do not. This seems to go against the flexibility described in the Foundation Datastore article. Also, if some nodes can be manually entered and maintained within the UI, why not relationships as well? Also, why not provide the ability to manually edit nodes and attributes within the UI? After all, the history of the node is being tracked.

Perhaps the UI should be smarter, so that it is able to trigger based on manual edits and dynamically build a pattern to suit that edit?