Semantic Analysis for CMDB

14-Jul-2018 Like this? Dislike this? Let me know

Today's Configuration Management Databases (CMDB), also known as Configuration Management Systems (CMS), were simply not designed for modern development and deployment. Most of them are rooted in the "one app = one GUI / one set of static codes / one database / one machine" paradigm that began 50 years ago with mainframe computing. Even more contemporary products designed in the late 1990s / early 2000s largely substituted Java for COBOL and added modest capabilities such as naming a host machine and some network configuration. From an information architecture perspective they are woefully underpowered concerning:

The irony is that although cloud provisioning, true distributed system design, and Open Source Software have made it dramatically faster and easier to implement and scale modern solutions, the complexity that arises from all these new interconnections and the "free flow" of data means it is actually more difficult to document and manage the footprint in a way that:

The Solution

Rigid assumptions about "what depends on what" will work for a handful of specific use cases and queries but are almost certain to be challenged by new ways of looking at the data; therefore, an entirely new way of examining the problem is required.

The solution is based on these design precepts:

  1. Fluidly connected software, hardware, and data
  2. Semantic analysis using a well-constructed ontology
  3. A clear and appropriate distinction between the definition of a thing and an instance of it

A reasonable implementation exists using

  1. MongoDB as the triple store, mostly because it does not enforce a single data type on the subject, predicate, or object
  2. Apache Jena as the engine and SPARQL parser

Like this? Dislike this? Let me know

Site copyright © 2014-2018 Buzz Moschetti. All rights reserved