Integration best practices with BMC Atrium CMDB - the Tideway adapter
Following a discussion I had with people asking about how difficult it was to integrate with BMC Atrium CMDB, I thought the points we came up with could be worth a post.
Our product, Tideway Foundation, is the market leading enterprise discovery and application dependency mapping tool. Being the only independent player in this market, our product is of course framework agnostic. And one of our differentiators is that we provide product certified adapters to the main framework vendor solutions (BMC, HP, IBM, etc), not always the case of the other solutions.
As I mentioned in a previous blog, we were building an adapter to Atrium CMDB 2.0. I’m glad to report it was officially released earlier this week. In a nutshell, using the infrastructure data and dependencies automatically indexed by our product, the adapter periodically creates and maintains the corresponding CIs and their dependencies in Atrium CMDB, therefore making the life of configuration managers far simpler.
But today’s subject is not about the lifestyle of configuration managers, even though we really care about you…
Here are a few lessons that we learned while building the adapter:
1-Avoid customization by all means
One thing we’ve learned when designing the adapter is that most customers using an earlier version of Atrium (1.x) had to customize its data model to better fit their business needs. This is still somewhat true with Atrium CMDB 2.0 implementations, though customers are paying much more attention to NOT customize the Atrium data model to ensure easier upgrade paths and lower cost of maintenance.
How did this translated into for us? Well it was clear that we needed to provide an integration that not only supported the standard Atrium Common Data Model but also could be flexible enough to support any modification that customers may need to do. I believe we’ve achieved both requirements.
Here is how: Handling the data mapping between the source and the target data models in a simple way is critical. Our adapter has a powerful engine, which handles the data mapping and transformation. For all Atrium CMDB 2.0 customers using Atrium without modification, the adapter comes with the standard mapping for Atrium Common Data Model 2.0, ensuring compliance out-of-the-box. For all the others that decided to modify the Atrium data model, our adapter allows you to decide, through a very straight-forward configuration, how to map Tideway data to Atrium data.
2-Pushing data is simple, maintaining it is another story
As most configuration managers would tell you, the problem is not to load your CMDB with data, it is to maintain this data over time, especially once the focus shifted to other projects. So when we designed that adapter, ensuring that changes discovered by Tideway would be reported to the correct CI was one of the key requirements. We’ve implemented a robust mechanism by which our adapter ensures that Tideway CIs and Atrium corresponding CIs are always synchronized. This is actually more complicated than it looks like. Both data models differ and the adapter has to deal with 1-n or n-n type of synchronizations. But we’ve managed to do this in a scalable way, a great feature of the adapter. There is also has a very useful side benefit: because it maintains CIs on both side synchronized, Foundation can easily reports on changes between the Tideway discovered data and the Atrium approved data, for which ever scope you are interested in (e.g. I want to see all infrastructure changes on this critical service between Monday and Friday...)
3-Use the right integration technology
BMC offer several types of APIs: C, Java, Web Services. While we’re always considering a SOA approach to our integrations, BMC recommended not to use the web services one as it wouldn’t scale to support large batch exports. So for the adapter, we’ve used the BMC Atrium Java API. The API is well documented and development was quite straight forward. And it turns out that the performance of the adapter are at the level we were expecting (i.e. the adapter not being a limiting factor into exporting data).
4-Don’t do it the cheap way
Building an integration that can scale to production requirements, and that is maintainable over time requires a significant investment. Doing it in a few days may allow you to get your data into the CMDB and demo it, a few weeks and you’ll get a prototype. But to ensure that your integration can handle synchronization, evolving data models and that your maintenance cost to support upgrades and interoperability over time remains low, you’re better off relying on a standard-compliant adapter.
At Tideway, we decided to make this adapter a fully supported product certified by BMC so that customers don’t have to build yet another custom integration. The adapter has passed BMC Validation, a strong guarantee of interoperability as well as an indication of our commitment to maintain it over time. Without a BMC validation, you might question how sustainable any integration might be in the future. Not a problem with our adapter which will be upgraded to ensure support of any new release of Atrium and Foundation. The integration note or inote that you can download from the bmc inote website is the proof of this validation
I hope this helps shed some light on our work. If you have some ideas on how to improve this work or even if you disagree with our approach, please leave some comments below.
RSS
By Allan Mertner on 21 Jun 2007