If you’ve ever participated in the implementation of a Configuration Management Database (CMDB), you are very aware that they have one of the highest IT project implementation failure rates. They are complicated, they are expensive, and they take a very long time to populate, even with basic data. As a result, most CMDB implementations require many months of time (usually years) before most enterprises can get any real value from them. The reason for this is that most CMDB implementation projects follow a waterfall approach for implementation and they do so because of the fact that most CMDBs are designed around relational database models which are difficult to setup, change and expand.
NOTE: This article touches on the topic of Agile and CMDBs. You can refer to the White Paper: CMDB Use Cases and Case Studies, if you are interested in a broader understanding of the critical requirements that are expected of CMDBs.
Repository-based CMDBs require long Waterfall implementation cycles, just like Data Warehouses
If you are familiar with Data Warehouses that use relational models, you are well aware that their complexity rises (faster than linearly) as you define more Data Types and load more Data Records into them. This rise in complexity makes them difficult to modify, difficult to load, and difficult to maintain. The result is always an extremely high Total Cost of Ownership (TCO) with very long change and implementation release cycles that are referred to as waterfall approaches for implementation.
Repository-based CMDBs are very much like Data Warehouses and most 3rd party CMDBs are repository-based. Setting up new Data Types (Configuration Item Types / CI Types) and new Data Records (Configuration Items / CIs) to load often takes very long release cycles. Changing an existing meta-model (i.e. the schema) often takes even longer. It usually takes significant time to set up new Data Types, master all related Data Records, test them, and then schedule their loading into the CMDB. Also, technology upgrades for the CMDBs, themselves, are often complicated and long.
Sure, you can buy and implement very expensive tools to harvest data and relationships that can be loaded into your CMDB but doing so still requires significant investments in money and time, as none of them magically start working the day you purchase them.
So, if CMDB implementation requires such significant investments in time and funding, while having such a high probability of failure, and yields a very long Time-to-Value, we have to ask the question: Is there a different way to implement a CMDB that offers a lower investment in time and funding, with a much lower probability of implementation failure, and that yields a much shorter Time-to-Value? The answer is “yes” and it lies in the use of Agile CMDBs.
An Agile CMDB allows for many more and shorter release cycles
While Agile is a delivery methodology that espouses short, quick, and iterative release cycles called sprints, Agile tools are the tools that facilitate Agile delivery principles. Therefore, an Agile CMDB is a CMDB that works within and facilitates the short, quick, iterative release cycles (sprints) in an Agile delivery method.
Unlike traditional CMDBs that are repository-based, and that only show real business value after very long release cycles, most Agile CMDBs are compiler-based and have very short release cycles. Compiler-based means the CMDB tool compiles data and automatically generates a fully functional CMDB as its output. This approach is based on an engineering paradigm known as Data Driven Synthesis, which has existed for decades and is now being applied to the generation of complex semantic models, such as CMDBs. Because Agile CMDBs are compiler-based, it also means they support very short, quick, and iterative compilation, deployment, and release cycles. In other words, they facilitate and work with Agile delivery methodologies.
Agile CMDBs require no relational schema definition because they leverage “schema-less architectures” or “flexible data models.” As a result, they can adapt to and adopt new Data Type (CI Type) definitions and load new Data Records (CIs) much faster than most other CMDBs. In fact, they are so agile that, often, very significant changes take no more than just a few minutes.
One very important thing to understand about Agile CMDBs is that, unlike traditional repository-based CMDBs which require you to first clean your data before you load it into them, Agile CMDBs allow you to easily and quickly load dirty data so you can immediately see what’s wrong with it, and quickly correct it… or continue to work with it until you have the means to correct it.
If interested, you can read more about the architecture of an Agile CMDB at: NOUNZ as your Agile CMDB, which provides more information on how compiler-based CMDBs work.
An Agile CMDB facilitates Rapid Prototyping
Because an Agile CMDB allows the business to see and play with changes in data in very short periods of time, usually in just minutes, it means that trial and error feedback loops are very tight and quick. This means that true rapid prototyping work can be performed with, both, the IT and business stakeholders. Data can be changed and, minutes later, stakeholders can see, work with, and provide feedback on the quality and usability of the data, reports, and visualizations. Feedback can be used to go back and adjust or improve the data and, again, enable stakeholders to see, play with and provide feedback, in just minutes. These short rapid prototyping loops are just not possible with traditional repository-based CMDBs because changes to them usually require significant effort and long release cycles.
Agile CMDBs save time by generating their own Relationships between CI Instances
One very important difference between Agile CMDBs and traditional repository-based CMDBs is that Agile CMDBs can easily and very quickly generate their own Semantic Relationships. This means you don’t have to waste valuable time installing 3rd party tools that discover CI Instances and create the Relationships between them or, worse, build your own (like when dealing with non-discoverable CI Types and CI Instances). With simple rules, Semantic Relationships can quickly be identified and created and, if you don’t like the results, you can simply change those rules to regenerate new Relationships that better match the needs of your enterprise. With traditional repository-based CMDBs, this could require long release cycles that span many months of work across multiple people.
Agile CMDBs allow for many more CMDB Instances in different IT Environments
A critical difference between traditional repository-based CMDBs and Agile CMDBs is that Agile CMDBs support a Federated CMDB Model for implementation. In other words, they allow many more people to have and work with their own localized CMDB instances in many different environments, which can be rolled up into bigger CMDBs that are meant to be shared across the broader enterprise.
This means, for example, that many individual developers who work in a specific development team can each have their own CMDB compiler so they can test small quantities of CMDB data that pertain to them. It also means that different development teams can now have their own unique CMDBs in their own Development, Integration Testing, User Acceptance Testing, Production and Disaster Recovery environments. When everything is working at localized levels the data from those localized CMDBS can later be aggregated into bigger enterprise-wide CMDBs with minimal effort.
Having a Federated CMDB implementation model also means that many different organizations, such as different business units can each have their own CMDBs. Again, all data from all localized CMDB instances can be rolled up into larger enterprise-wide CMDB instances.
When to use an Agile CMDB
If you’re a small or mid-sized enterprise, an Agile CMDB is a great way to 1) get your feet wet with a CMDB and 2) save money and time while doing so. Traditional CMDBs are pretty complex and expensive so using a compiler-based Agile CMDB allows you to get your data right much faster and with far less effort, and it allows you to get to an up-and-running CMDB much faster so your end users can get real business value from it as quickly as possible.
If you’re a larger enterprise, you may want to use an Agile CMDB to work with and test prototype data (e.g CI Types and CI Instances) that you want to implement in your bigger repository-based CMDB, in your release cycles. Compiler-based CMDBs make great tools for understanding your data (where it will come from, how it needs to be represented, how it needs to be cleaned and master, etc.). Using a compiler-based Agile CMDB means you can raise the probability of success with your bigger repository-based CMDBs. Using a compiler-based Agile CMDBs also means you can more easily set up and load non-technical CI Types and CI Instances, along with their Semantic Relationships, which is usually very difficult with repository-based CMDBs.
Finally, if you need far more diverse data that goes well beyond the limits of just “technical data,” you may want to consider using a compiler-based Agile CMDB. Since they use schema-less architectures or flexible data models, Agile CMDBs allow you to easily load non-technical data as well as technical data. And, they also help create and maintain millions of semantic relationships (i.e. CI Relationship Data) that most other CMDBs don’t help you with.
Configuration Item (CI) Types for your CMDB
Note, if you are interested in the standard CI Types that are collected and maintained by most enterprises, you can find them in the IF4IT Enterprise Inventory Control Grid (EICG). This downloadable spreadsheet itemizes over one hundred very important CI Types and includes those that can be automatically discovered (i.e. discoverable) and those that cannot be automatically discovered (i.e. non-discoverable).
An Agile CMDB can quickly and easily load and work with any of the CI Types specified in the EICG template.
The Benefits of Using an Agile CMDB
The benefits of using compiler-based Agile CMDBs are multifold…
- They are technically far simpler than repository-based CMDBs. This means far lower Total Cost of Ownership (TCO).
- They are much faster to set up than repository-based CMDBs. This means that in the time it takes to deliver any one release wave with a traditional repository-based CMDB, you can deliver many solid releases with a compiler-based Agile CMDB. This also means far lower change costs and higher probability of implementation success.
- They handle far more diverse Data Types (CI Types) and Data Records (CI Instances). This means true data-diversity, which is a requirement for successful Big Data implementations.
- They include solutions to create and maintain massive quantities of Semantic Relationships. This means you buy and build far fewer tools to do so.
- They usually include advanced visual reporting and analytics.
- They are far less expensive than repository-based CMDBs. This means your Total Cost of Ownership (TCO) for implementation, population, integration, upgrades, operations, and maintenance are much lower.
Agile CMDBs are:
- far simpler to implement and maintain,
- faster to get up and running,
- faster to change (new data types and data),
- lead you to much higher levels of data quality,
- far more Data Diverse and flexiby, and
- much more affordable to own and operate.