What is Model-Driven Automation

In a previous post, I suggested that Model-Driven Automation is a superior automation paradigm for reducing the operational expenses associated with managing the lifecycles of software services. Model driven automation also promises to finally deliver the type of service agility we have been expecting from cloud-based deployments. In this post, I will dig a little deeper into what model-driven automation really entails. 

I believe there are three fundamental aspects to a model-driven automation system:

1. The instance models
2. The automation approach
3. A meta model

I’ll talk about each of these in a little bit more detail.

Instance Models

At the core of any model-driven automation tool is a full representation—in the automation system database—of all deployed service instances and their components. We refer to such a representation as a service instance model.

Note that service instance models are not the actual services themselves. They are representations—or models—of the actual services that are created using resources that are external to the automation system (and that are typically also represented using models in the automation system database). The instance models represent those aspects of a service that are relevant for the purpose of automating service lifecycle management. Service instance models typically contain all the components that make up a service as well as the resources on which these components are deployed. They track configuration values for each component, and they contain status values that represent runtime state for service components. Most importantly, instance models capture relationships that represent dependencies between service components.

Automation Approach

Fundamental to any model-based automation tool is the concept that all service management tasks must be performed by operating on the service instance model first, and then propagating any resulting changes in the model to the external resources or service entities under management.

Similarly, a model-based automation system is responsible for monitoring the state of the external resources or entities and reflecting any changes into the corresponding instance model. These changes may then necessitate actions to be taken by the automation system (e.g. to respond to a failure in an autonomous fashion), which in turn could result in changes to other components in the instance model, which then need to be propagated to the outside world.

Using this approach, the instance model becomes the single source of truth for all information about the services under management. When an automation system needs access to configuration or status values for service components, it can get those values from the instance model rather than having to query the actual external entities or resources themselves.

Meta-Model

This brings us to the most important aspect of a model-driven automation system, which is the meta-model, or the model that governs the instance models themselves. In general, meta models define the rules, the constraints, and the theories for how to create models for a specific application domain. For our domain (which is service automation), the meta-model must define rules and semantics for the creation and manipulation of service instance models, and all instance models must conform to this meta model. The meta model specifies what type of information must be in the instance models and where that information can be found. The meta model also defines the rules and semantics for how the various aspects of the instance models can be changed by the automation system.

Examples of the type of functionality that might be exposed by the meta model:

• Definition of the exact set of configuration values that are required for each specific service component, where in the model these values are stored, any constraints with which these values have to comply, and what the run-time state variables are that must be tracked for a specific service component.
• Definition of relationships that capture how changes in one component may have an effect on other components in the same service (or even on other services that share the same resources).
• Mechanisms for expressing resource requirements for each service component.
• Mechanisms for supporting decomposition of services (such as a decomposition of user-facing services into resource-facing services).
• Hooks for plugging-in component-specific mechanisms for propagating changes to the model of a component into configuration changes in the external world.
• Hooks for plugging in monitoring functionality that can reflect changes to the external state of a service into corresponding values in the model components.
• Event handling logic or policy logic that expresses how changes to component values need to be handled by the automation system.

It is the presence of a meta-model that allows model-driven automation systems to provide automation functionality in a general-purpose fashion without having to rely on domain-specific assumptions or special-purpose automation logic. With a proper meta model we can create service automation systems that are domain-independent which then allows the same automation system to be used across a wide variety of application domains.