Proper Meta Modeling helps Safeguarding of Services

Let’s pretend you’re done with modeling (or composing) a Service down to the assets to be assigned to do the job. As you’re skilled, the Service has been properly decomposed into intermediate Service components that where available to be reused and some newly defined Services that cover functionality derived as specific requirements for this particular business case. In case the forecast turns out to be right your Service is in demand and has to be delivered. Keeping in mind, that delivering a Service to a customer also requires managing and maintaining it, additional properties of your Service have to be defined and described accordingly. If it is done in a mature fashion, these parameters relate to several objectives that relate to the nature of the Service which will later be referenced in a contract or any other suitable agreement between the involved parties. However, in this early stage of the lifecycle you neither know about the final infrastructure your Service will be deployed into nor will you be able to guess how the outlined parameters will be gathered and measured. Nonetheless, some objectives have to be described already in order to give a customer the flexibility to request the Service tailored for his business needs. Of course the customer also needs to have a means for measuring and reporting in order to compare if your provided Service has lived up to the outlined expectations. Hence, your Service has to be enriched by e.g. monitoring details that are passed to the responsible Service Monitor within the delivery phase in order to provide the data for future reporting. As a designer you may define what has to be monitored but not how or what kind of tools are used to do it. Now what?

Describe the objectives and let someone else do it!

An appropriate way of dealing with this is to introduce another level of freedom by means of additional descriptive elements (backed up by an appropriate Meta Model à see Blog ) and to let the target infrastructure and resources interpret what and how to do.

As an example: a “Service Parameter” of type “Service Availability” will be assigned to a Service. For each monitoring related type a “Service Monitoring Objective” exist and will be mapped according to the nature of the Service or intermediate Service component. The major advantage is that the Service Monitor knows about the appropriate method to gather the objectives linked to the Service via a typed Service Parameter e.g. the “Availability” of a eMail Service is measured different to a Active Directory Service. Hence, the “designer” does not need to define the specifics and of course the Service Monitor can be extended at anytime independently or even delegate the job to some surrounding tools if he is working as an umbrella to consolidate multiple sources.

Let’s recap: Let the responsible infrastructure or resource interpret what and how to do is a good thing because it helps to hide the lower level implementation during design time. However, at the bottom-line some facts remain that must be taken care of in order to make it work:

• each type of Service requires an appropriate Service Parameter that relates to a specific objective
• Service Parameter types that are used for safeguarding must have a corresponding match in the Service Monitor
• standardization initiatives reduce the amount of different types of Service Parameter
• missing or new types must be mapped automatically to a no-harm-placeholder to be identified later

Dirk Clemens, Solution Architect - USU AG