In part 4 of “Memoirs of an Enterprise Architect” I discussed the rules around defining an application as well as the 6 keys to successful Application Portfolio Management. In Part 5, I will discuss integrating with a Configuration Management Database (CMDB).
Feed the Beast
If you have a CMDB I’m certain your organization is not getting as much value out of it as it should. Have you ever used data in your CMDB to make strategic decisions to transform your business? While CMDBs have their value in making business decisions they typically don’t have the complete picture of the connected enterprise. However integrating Troux with a CMDB is a great place to start. How else are you going to answer the following questions:
- How many servers are running in your datacenter on fully depreciated hardware?
- What servers are running non-supported operating systems or current patch levels?
- What is the cost of running multiple versions of database systems?
I could go on and on with key questions like this, but you get the point.
Where to Start?
The hardest part about integrating systems together isn’t the technical solution, but understanding what your stakeholders are trying to accomplish with it. I have listed below some best practices to start you off on the right foot:
- Identify stakeholders.
- Determine what Configuration Items (CI) should be related in Troux as well as what CI’s from Troux should be related in CMDB.
- Bring over the minimum amount of data to be successful.
- Create clearly defined requirements understood and approved by all stakeholders.
Ok, now that you have robust requirements, how do you implement and integrate between Troux and CMDB? With the exception of a native integration, like the bi-directional adapter for HP UCMDB, there are a few approaches that can be taken depending on the size of the source data you are bringing into Troux:
- Create a database view in CMDB including all of the objects, properties and relationships that need to be replicated to Troux.
- If the data is less than 50,000 object instances, use Troux Collection to load data from the CMDB view.
- If the data is greater than 50,000 object instances, create a staging database and use Troux Collection to load only new, updated or deleted data from the staging database.
- Create a database view in Troux for any data that needs to be replicated into CMDB.
As you can see, integration is key for bringing together disparate sources of data into a centralized repository like Troux to empower organizations to make better decisions faster, with maximum agility, minimum cost and risk.
What best practices have you learned by integrating with a CMDB in your organization? Without a native integration or available API’s, what approaches have you taken to create your integration solution?
See you next week, same time, same place where I will continue discussing integration, but this time with Human Resources (HR) data.