Entire series:
Part 1: Delving into the concept of IT "system"
Part 2: Tracing the integration spiderweb
Part 3: Software deployment
Part 4: An integration metamodel
The following question was recently posted to the ITSM list (that’s IT Service Management Forum, http://en.itsmportal.net/content/discussie)
When modeling the CMDB I understand that each distinct piece of hardware (e.g. each host) is modeled as a single CI and also each software package (e.g. Apache Web Server). What I cannot find an answer to is if each instantiation of a software package is also (usually) modeled as a single CI and what the implications of doing so or not doing so are...
One reason I need to have CIs for each instantiation is that the view of the clients overall system is very much in terms of subsystems and that I need to be able to express relationships such as "NFS_client_on_nodeX is-part-of NFS_system" or "Apache_on_hostY is-part-of Network_Monitoring_System".
I also want to be able to link Incidents,Problems and RFCs to particular instantiations as opposed to the packages only.
Can anyone
- tell me if I am on the right track at all?
- tell me how the relatioships between host,package and package instantiation are modeled best
- point me to some *practical* literature an a methodology for these tasks?
Jan
This is a perfect introduction to an essay in the Fundamentals of Integration Metadata series, so here goes:
As with all information modeling tasks, the requirements come first. Jan is quite clear in his statement of them, so he shouldn’t question himself– he is on the right track. We have encountered similar issues in my shop (I lead a metadata and configuration management capability for a $20bn US retailer).
There are several industry standards which provide a rich point of departure for Jan’s exercise. He is working on ground that has been extensively discussed and modeled in detail; my challenge to the ITSM community is stop re-inventing the metadata wheel.
A word on method. I have looked at topic maps and related Semantic Web stuff, and strongly encourage him to address this problem in straightforward object class (Unified Modeling Language) or entity/relationship (ER) modeling. He’ll be able to discuss his issues with a much wider audience if he uses one of these two related approaches. Additionally, the standards I am going to point him to are in UML.
The following material examines two OMG-based approaches: the Common Warehouse Metamodel (CWM) and UML 2. We’ll look at CWM first, and identify some shortcomings.
The Common Warehouse Metamodel is an official standard of the Object Management Group. It is based on a UML core:
Figure 1. UML Core, as represented in CWM. (Click on any image to enlarge.)
The package of particular instance in CWM is Software Deployment:
Figure 2. CWM Software Deployment package
In this representation, we have a slightly different spin on Jan’s problem he might want to think about. He is framing the question as related to deployment – i.e., “Apache_on_hostY is-part-of Network_Monitoring_System.” But why bring in the “on_hostY”? Why not just indicate that the Network Monitoring System has a dependency on Apache, wherever deployed? I assume that this dependency would continue regardless of where Apache was deployed, and tracking this information independent of deployment is probably important.
In terms of the metamodel above, one would have Network Monitoring System (I’ll abbreviate NMS) and Apache as SoftwareSystems (figure 2). It would be tempting to say that NMS is a component of Apache, but components should be directly instantiable (more on this later) and Apache and NMS are peers. Both are logical concepts, composed of various binaries that are not necessarily named Apache. This logical to physical mapping is a recurring theme in application portfolio management.
In order to see how to relate Apache to NMS, one must look to the Dependency object in Figure 1. Since SoftwareSystem indirectly inherits from ModelElement, one can define a Dependency in which NMS is a client of the supplier Apache.
The depth of the inheritance hierarchies is one of the primary challenges in comprehending metadata models capable of representing IT concepts. It’s not limited to the OMG; DMTF metamodels also have very deep inheritance hierarchies.
So, we’ve now defined a dependency at the type level between NMS and Apache. However, how do we also indicate that the particular instance of Apache on hostY is what NMS is dependent on? One would have to deploy the NMS and Apache componentry via the DeployedComponent object, and define a second Dependency object between the DeployedComponents – otherwise, the end user might think that NMS was dependent on every deployed instance of Apache, which is not the case.
Another option would be to define the dependencies using the usedComponents/usingComponents recursive traces on the DeployedComponent entity. However, what if NMS has 4 components and Apache 20? Which Apache components provide the service to NMS? It’s better to handle this at a higher level, encapsulating all of Apache into a logical package and hiding its component implementation from NMS.
The CWM Software Deployment metamodel is not the last word from the OMG, and has some key limitations. For one thing, it does not handle the relationship between logical and physical machines, e.g. clusters or virtual OS partitions. Second, one has to go down to the Component level to represent the problem. What if we don’t know, or don’t care, what Components are in NMS or Apache? Some shops may not be tracking components as CIs, keeping the CI concept at the logical system level. The CWM metamodel falls short here.
A more elegant concept is the UML 2 deployment metamodel. Three views follow, first the basic structure for representing computing resources:
Figure 3. Node and related classes from UML 2 deployment package
Figure 4. Artifacts as manifestations of PackageableElements. (Components are PackageableElements.)
Figure 5. Artifacts and Nodes.
The concept of Artifact is key in UML 2. I would argue that it maps pretty closely to CI:
“An artifact is the specification of a physical piece of information that is used or produced by a software development process, or by deployment and operation of a system. Examples of artifacts include model files, source files, scripts, and binary executable files, a table in a database system, a development deliverable, or a word-processing document, a mail message.” (UML Superstructure 2.0)
It’s critical to understand that the OMG metamodels are highly interrelated, and the above are only fragments. To understand the OMG world, one must download the specs and spend quality time with them, tracing the various associations to understand how the various parts relate to each other.
The UML 2 concepts can more easily meet Jan’s requirements. In discussing them, it’s also important to note that UML 2 does not have the same conceptions as the CWM with SoftwareSystem containing Component. Instead, Component is simply recursively decomposable (self-containing) and given a tag indicating whether it is directly instantiable, i.e. logical “systems” like Apache would not be directly instantiable while physical components (e.g. .jar files) would be. A stereotype of Subsystem can be applied to components, defined as “A unit of hierarchical decomposition for large systems. A
subsystem is commonly instantiated indirectly.”
Since Components logical or physical can be Artifacts, one can deploy them to DeploymentTargets. This supports whatever granularity of CIs your organization desires. You can deploy a logical System like Apache directly to a Node, without worrying about the componentry it contains. Or you can model the componentry in detail, if your configuration management approach requires it.
Additionally, the concept of Node above supports both clusters and OS partitioning. Nodes can contain themselves, and the concept of ExecutionEnvironment allows the bottom-up composition of software services. For example, one might start with a base Node of a physical machine, deploy an operating system to it, and declare a containing Node as an ExecutionEnvironment to contain the results:
Figure 6. Basic Execution Environment
A cluster (virtual OS instance supported by multiple physical servers) could be represented thus:
Figure 7. Clustering
Virtual OS partitioning can be also represented:
Figure 8. OS partitions
So, back to Jan’s original question: we would define NMS and Apache as Components with stereotype Subsystem and IsIndirectlyInstantiated = true. The Components would be realized by Artifacts in turn deployed to ExecutionEnvironments. Any level of granularity might be supported, from logical to physical. Component to Component and Artifact to Artifact dependencies would be realized through the general Dependency object linking NamedElements. Whew!
I’d finally like to note the existence of the important InstanceSpecification metaclass. As I read the spec, this concept fills an important requirement. As we’ve been discussing various metadata challenges in my shop, we realized that we needed to distinguish between software package type (e.g. Apache), deployment (Apache on xyz server), and instance (Apache launched on xyz server at 08:00 2/3/2004 on port 8080 with settings a, b, and c.) This is needed not so much for app servers like Apache, but for heavily generic, parameter-driven applications that might connect to different databases and use different middleware all based on the instance parameters. You think you have configuration management problems now, just wait till you run into these… At a certain point, to be brutally honest with myself, I question how much we can actually model.
This is complex stuff. But the problem domain requires it. Simpler approaches will encounter intractable ambiguities.
-Charlie
Part 1: Delving into the concept of IT "system"
Part 2: Tracing the integration spiderweb
Part 3: Software deployment
Part 4: An integration metamodel
