Modeling is Hard

If model-driven automation can reduce operational expenses associated with service lifecycle management, then why have we not yet seen universal adoption of the model-driven automation paradigm? I suspect that a large part of the answer lies in the fact that creating the right models is not as easy as it may seem. While modeling activities have been taking place in the Information Technology industry for decades, each Standards Development Organization (SDOs) has created their own models based on the specific business requirements of their target industry. Harmonizing these models has proven challenging. In addition, as far as I know no SDO has approached modeling with a goal of automating service lifecycle management. As a result, many existing models suffer from limitations that make them ill-suited as the foundation for model-driven automation systems.

Here is a list of common modeling “mistakes”:

• Including BSS (Business Support System) concepts into the models. For example, the TMF SID (Service Information Data model) defines two classes of services: customer-facing services that can be purchased by a customer as part of an offering, and resource facing services that are bound to resources. Clearly this distinction is useful for the BSS—it determines whether the service shows up in a product catalog—but it does not belong in the models for an automation system. For purposes of automating the lifecycle management of a service, it makes no difference whether a service is customer facing or resource facing, and the distinction only gets in the way.
• Differentiating between service models and resource models. Many if not most modeling standards make an explicit distinction between service models and resource models. However, whether something is a service or a resource is not an intrinsic aspect of the entity being modeled. Instead, it is an aspect of how that entity is being used, i.e. the role that the entity plays at a given point in time in the context in which it is modeled.  For example, an entity provided as a service by one service provider may be used as a resource for a service provided by a different provider. Depending on which provider is modeling the component, the same component can either be modeled as a service or as a resource.
• Marking entities as either composite or atomic. For purposes of management, some entities can be treated as black boxes: the management system does not need to know about the internals of those entities to configure and manage them. Other entities may need to be treated as complex systems that are built from a set of components, and managing the system requires management of each of these components individually. It is tempting to model black box components as atomic and model systems as composite entities that are in turn composed of atomic entities. However, whether an entity is atomic or composite is not an intrinsic aspect of that entity. In reality nothing is ever atomic, and even atoms aren’t atomic. The distinction between atomic and composite is merely a reflection of the level of detail required by the management systems at a given point of time. That level of detail may change over time, at which point it may become necessary to turn atomic entities into composite entities. This may be impossible to do without recreating entire model hierarchies.
• Encoding domain-specific concepts in the meta model. As shown earlier, automated lifecycle management tools rely on semantics of the meta model to provide automation functionality. If the meta model includes domain-specific concepts, then it will be difficult to use the models for application domains other than the one for which the model was designed. For example, the Kubernetes meta model includes Pods and Containers, which makes it hard to use Kubernetes for network automation.

Any proper modeling approach must avoid these pitfalls in the models. More importantly, it can absolutely not afford to use a meta model that includes these mistakes. Without a proper meta model and without the proper split between what is in the meta model and what is in the models themselves, it is impossible to create an automation platform that can process models in a general purpose, domain-independent fashion.