Recently in Standards Category

We’re thrilled to see the buzz gathering around our newest announcement - analysts and media alike seem to agree that we’ve added something new and noteworthy to the market. We think this kind of innovation is especially welcome in a market that has little confidence in those larger competitors.

With myCMDB, we’ve really unleashed the power of the CMDB by adding the community features that should logically be part of any project that requires the input from so many different people within an organization. Heck, using email and voicemail for CMDB communication is like using a rotary dial for a smartphone.

Instead, we’ve brought CMDB communications and process into the 21st century, by adding a combination of Facebook interactivity, Wikipedia information quality management, and Google’s searching model. Basically, these features make it easier to get more users involved in its creation and maintenance, which means the CMDB quickly becomes a more accurate representation of the infrastructure, relationships, and services. This allows organizations to use the CMDB to better control the impact of change and move it into a decision support role.

Stay tuned as the buzz continues to build!

It is important for development organizations to stay informed on industry standards and to continually review them (new and old) for applicability to technology selection and problem resolution. Staying knowledgeable of standards is critical for selection of internal software components as well as providing outward interfaces and other benefits for both customers and engineers.

Recently I was reviewing some of the latest Java standards published over the last year to see if any standard resolutions had evolved to a development challenge on which my team was currently working. No dice. As it turns out, many other vendors had met and solved this very same challenge however no approach had been standardized. As a result, I’m now weighting the pros and cons of implementing a solution of our own that I’ve been noodling in my head.

But it got me to thinking even if a standard approach had been adopted, it does not mean that the standard solution would be the best development decision. Why? Because while standards generally do provide many benefits, they can also pose new problems which are what I classify as standards freeze.

If a standard is not open and flexible, it can stunt innovation and provide a speed-bump rather than an expressway to productivity. For example, standards freeze happens when an engineer or product manager finds he or she cannot add a new feature or function without breaking the adopted standard. It leaves the development team in the difficult position of either skipping the new feature or breaking the standard – both of which can have political consequences.

Thinking outside of the box does not always go hand in glove with standards adoption. Developing competitive differentiators many times means thinking outside of the box, and thus outside of the standards. It is crucial to take the time to research and ensure that the standards selected by a development organization or product allow for flexibility within the standards so that the product and/or organization can continue to grow without an expensive and time consuming overhaul.

The next time you feel yourself itching to download that open source project and use it because it will save you a few days, make sure you’re also thinking through the standards it was developed on and ensure that you can think outside of the box while staying within the standards.

-- Adam

CMDB standards, do they exist or not? What about the CMDBf Consortium or CIM with the DMTF? The topic of CMDB is much like discussing religion or politics, volatile and dangerous territory and I find the topic of standards in this arena as annoying as NoVA traffic.

Every so often I run into this question and discussion and I view it as nothing more than fodder because while managing IT infrastructure principally does not change from organization to organization, I have never run into two organizations with exactly the same configurations and the drivers for their CMDB projects especially when an organization is mature enough to apply the CMDB to the services of the organization. So when I’m asked this question I often respond with some of the following questions:

    -- Tell me how you plan to use the standard?
    -- What value do you expect from the standard?
    -- Are you planning to implement their model?
    -- How did you come across this standard?
    -- Are you comfortable with the members of the board?
    -- Do you know who they are?
 
I am normally greeted with the classic “deer in the headlight” stare as most folks have Googled the term or have heard of CIM and CMDBf, but do not truly understand the objectives and the value these models, standards and organizations bring to the table. I do not mean to take the wind out of your sails, but when it comes to CMDB there is no silver bullet standard or model. There are methods, models and processes to leverage (a legal word for plagerism or stealing), but they must be applied to each individual environment.

Gartner has written on the topic of the CMDBf and recommends against waiting on the CMDBf specification for communication / integration to become a standard before implementing a CMDB.  This is a consortium of vendors, but not representative of the whole of the vendor market attempting to define a standard for communication and integration of CMDB’s. I hate to ask a highly controversial question, but wouldn’t you as a consumer like to see these vendors integrate their own software products first and keep them open and able to integrate to other solutions? Just an obvious question from this humble observer.

I find the DMTF as a much more credible standard to leverage as it is a consortium of more than 4,000 active participants, representing 44 countries and nearly 200 organizations. The organization has been around for 15 years and is more of a defacto standards body with participation by more than a select number of vendors and includes end user organizations. However, the CIM model is still not a silver bullet in the arena of CMDB’s either. The down side is the volume of classes and relationships in the CIM model being on the magnitude of a “boil the ocean” project.

In closing I’d like to say that there are no silver bullets in terms of standards, out of the box CMDB’s, however, there are sources that can be leveraged for ideas and starting points. The CIM model is one of those with class definitions with corresponding attributes and allowable relationships. Take what makes sense in your environment and define the base model of relationships as works in your environment starting with a key application or service with high impact to the organization.

-- Michele