Semantic Analysis for CMDB

14-Jul-2018

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:

Cloud deployments and cloud APIs
Multi-device applications communicating over https pipes to common multi-component backends with multiple databases, services, message hubs, etc.
Information categorization and tracking (esp. PII)
Enormous footprint of Open Source Software
Zero-downtime component clustering
Blockchain / distributed ledger technology
Anything-As-A-Service including code repos

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:

Regulators demand for protection of personal data and provenance/lineage of data used for risk analysis
CFOs demand to be able to truly exploit Cloud dynamic scaling
CTOs demand to be able to manage, patch, and EOL-retire an enormous, multi-live-version footprint of open source software
CIOs demand to be able to constructively perform scenario analysis with the business when creating new products and services

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:

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

A reasonable implementation exists using

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

Like this? Dislike this? Let me know