≡ Menu

Does Network Configuration Management Matter?

in Application Discovery, CMDB, ITIL, ITSM, NCCM

With the announcement today or EMC picking up NLayers (who they already heavily OEM’d for their Application Discovery product), Symantec picking up Relicore and IBM picking up Collation, the attention has obvioulsy been on the application and service layer. (where the $$$ is)

There’s been relatively little consolidation in any of the Network Change and Configuration Management (NCCM) plays out there aside from Opsware and Rendition Networks last year. I’m not too sure on the takeup rates of any one vendor’s solution (Voyance, Alterpoint, Intelliden, Emprisa Networks, etc.), but I’ve yet to see anyone really focus on one of these platforms to really complement application discovery and mapping within the CMDB other than the “we integrate with X” statement.

The CMDB of the future will need the same rich level of information just like in the application and service domains – even more so as networks become more complex with many more logical configurations (tunnels, VPNs, QoS, CoS, advanced ACL’s, routing protocols, etc.). The same can be said of security/firewall change and configuration management. (I don’t know anyone playing in this space.) Any CMDB without this type of information will be seriously incomplete.

Today’s networks may have been designed to be transparent to the applications and services they support, but Murphy is always out there and the router jockey’s having free reign in the network can’t be a good thing. The sum of all the parts must be consolidated in the CMDB with equal emphasis on depth and breadth of information, not just on the application layer.

* Another thought to ponder – does EMC/SMARTS have plans to get into the CMDB business or would they just lump this into the whole Information Lifecycle Management (ILM) story.

Comments on this entry are closed.

  • Thanks for the comments. I can’t seem to get comments on your blog to work?

    I hope you did see what I was poking at in my post. I’m certainly a huge supporter of NCCM and fought tirelessly in my past life to bring in your solution. (I actually beta tested one of the very early releases.)

    Something has to give way soon to really move from the integration strategy to the consolidation strategy to get closer to that “Uber-CMDB”. Everyone’s doing it at the application/system layer, when’s the network get it’s turn?

  • Gerard Puoplo

    Re. Doug’s Comment –> “does EMC/SMARTS have plans to get into the CMDB business or would they just lump this into the whole Information Lifecycle Management (ILM) story.”

    I say the functionality of Federate CMDB is fairly evolved already within SMARTS product from its builtin CIM structure. With SMARTS internal data structure based on CIM, using CIM broker strategy to aggregrate to higher and higher levels of abstractions, with addition of more and more levels of discovery mechanism, and backend standard/native interfaces already to many element managers, databases and applications provides SMARTS with builtin core Federated CMDB functionality. In a few years when more mature I hope they do package this builtin functionality as a addon FrontEnd CMDB package.

    The CIM strategy gives the relationship and key property attributes models in a standard object based format which is a real strength. A CIM broker strategy only needs backend interfaces to other 3rd party systems which SMARTS has to some degree already. The problem like everyone else is implenting all the needed backend interfaces if the backend systems don’t support a standard like WBEM/CIM or the evolving DCML.

  • Thanks for joining the conversation Gerard.

    One thing that always concerned me in my past life was understanding the value of CIM across the industry. I’ve just not seen the take up with CIM or DCML across a majority of vendors in any space, wheter network and systems management or the CMDB market.

    Would SMARTS have to open up the secret codebook sauce to federate and share relationships, dependencies and topologies? (It’d certainly be a good thing for their customers!)

    Why hasn’t take up been broader? Is CIM too complex? (I’ve certainly heard that it is!) Is it the vendor “NIH” syndrome?

    I’m trying to get some information on what’s happening with this CMDB Federation Consortium to see what they’re thinking about. I can’t believe they’d start completely from scratch here.

    nLayers is certainly a good technology and acquisition for EMC/SMARTS. It’ll be interesting to see how it’s used across everything they’re working on. I am curious about just how far the deep packet inspection, fingerprinting and probe approach can go.

Next post:

Previous post: