Supposed you are working in IT Service Management especially in the field of Service Operations by means of delivering high quality Services to your company’s customer. The Services you’re responsible to monitor and safeguard are crucial and the enterprise you’re with has already established a process that covers all the way from Service composing, publishing, requesting down to implementation and monitoring. Despite many efforts to streamline this lifecycle, a gap may exist in the transition of bridging the more descriptive levels of providing Services from the details that are required for implementing and safeguarding them once reaching the infrastructure level.

As outlined here (→ see Blog) an appropriate way of dealing with this is use additional descriptive elements based on an appropriate Meta Model to be passed to the lower levels. However, as the details defined in the descriptive levels increase – driven by the need to adapt more to the customer’s expectations – the descriptive elements passed down the stack may be subject of misinterpretations because a monitoring objective for customer A may slightly differ from the same objective for customer B. Although there might be a lack in the Meta Model (which defines types, attributes and their associations), adapting the model should not be the first step to go for – there might be a better way. Let’s have a short look at another topic e.g. the “semantic Web” to see how this can be addressed: Annotation.

Annotation helps to realize the full value of information

Let a resource e.g. a web page be annotated with information such as “its target audience” or which “restrictions” apply and many more during the publishing and release process. The result is that the content itself remains the same and can be tagged automatically, filtered by its containing buzzwords but also interpreted by the included annotations. This is known as semantic metadata which is “data about data”. If we return to the topic we came from, adding semantic metadata to the descriptive meta elements will finally realize the full value of information passed down the Service delivery chain. This becomes quite useful if you’re e.g. dealing with 3^rd party providers that take care about parts of your infrastructure or a monitoring objective must be performed a specific way even though many ways exist.

The simplest way to do it is to provide metadata to each of the monitoring objectives by categorizing the objectives into semantically representative groups and/or by applying a suitable tagging or adding just free text individually. This information can be provided to the underlying Systems Management tools (and of course to their administrators) in order to have a means for a more detailed description what to do or even what not to do which also supports compliance initiatives very well.

Let’s recap: Meta Modeling requires having a great understanding of the domain you’re addressing. Within the domain and context of IT Service Management, roles exist that build the basic Meta Model elements (e.g. a Service Model Architect) and those that make use of it (e.g. Service Level Manager or Service Portfolio Manager) in order to build properly decomposed Services to be published in a Service Catalogue and offered to their customers.

Nonetheless it may happen that the model elements used to express are not sufficiently self-explaining. Hence, some more details are required such as what they mean, when or how to be applied or are not allowed to be applied. This information added (usually by annotation) is referred to as semantic metadata.

However, at the bottom-line some facts remain – I guess you are now used to this reoccurring pattern – that may need to be considered or issues left for further investigation:

• Updating the content should also consider altering or updating its assigned metadata
• Metadata (semantically or syntactically) does not know about the consumer which results in a remaining probability of misinterpretation
• Repositories can be referenced to manage metadata and their semantically descriptions to have a better means for compliance

Dirk Clemens, Solution Architect - USU AG