A common question we get asked is ‘how do I integrate Ardoq with my CMDB’?

That’s really a question in two parts, and we’ll take a look at each one in turn.

Plug-and-play Integration

The first is a question about technical integration. That’s the physical mechanism for taking data from one application into another.

Ardoq offers a range of options here.

The most sophisticated is our ServiceNow integration. It allows you to map data directly from ServiceNow’s database into Ardoq workspaces.

You can find more information about Ardoq’s ServiceNow integration here.

If you’re not a ServiceNow user, don’t worry! Our REST API gives you plenty of options to build direct app-to-app integrations, or to use a third-party workflow solution like Zapier or Microsoft Flow.

To learn more about Ardoq’s REST API check out our tutorial and documentation.

At the most basic level, our Excel loader will get you up and running fast.

You can learn more about importing your data from Excel here.

Integrating Information Processes

The second part of the question is about process integration or data management, and that's what we'll really focus on here.

Now, many people know that copying data between applications should be minimized if you want to keep them in step. And that may lead to people pushing back against storing the same data in two different places.

For example, if you already have an application list in your CMDB, you may be challenged on the need to load it into Ardoq.

But Ardoq and your CMDB do different things. And it’s important to understand what those are to see how it drives integration between them.

Same Data, Different Missions

CMDBs come from the world of IT Service Management. They are a key component of the ITIL (Information Technology Infrastructure Library) standard and are focused on the day-to-day running of IT systems and the management of IT assets.

CMDBs log or auto-discover applications and infrastructure, monitor their availability and manage IT incidents. They may also perform related tasks such as processing system access requests or IT equipment orders.

So CMDBs are fundamentally concerned with:

  • Detail: The low-level implementation of IT systems
  • Time: The As-Is or current state of IT systems

Enterprise Architecture tools were created to support strategic planning. They analyse the As-Is or current state of your IT landscape to enable planning of transformation to the To-Be or future state (including creating alternative future architectures or scenarios).

Because they are strategic, enterprise architecture tools must understand IT in its high-level business context: How it supports organization-wide operations, the organization’s products and services, and its strategy.

This means Enterprise Architecture tools are concerned with:

  • Detail: How IT systems support the business at a high level
  • Time: Migration to the To-Be or target state of those IT systems

Different Lenses on your IT

Now of course, there’s an overlap between these two sets of data.

Both level of detail and point in time are points on a continuum. It can be hard to draw a line where low-level ends and high-level begins, or where As-Is becomes To-Be.

For example, many CMDBs record IT’s touch-points into the business, while it’s not uncommon for EA tools to store infrastructure data.

So let’s take a practical example.

Imagine we have a CRM Application. Both our CMDB users and our Ardoq users want to know about it, and potentially to change its properties or link it to other data for analysis.

Both may need to know which servers our CRM Application sits on: IT Service Management needs to know so they can manage planned or unplanned application outages; Enterprise Architecture needs to know so they can assess the application’s potential for migration to the cloud.

At first sight, it looks like both roles are looking at the same data.

But because they do have different roles, the data that they are interested in around our CRM Application starts to diverge.

The CMDB holds details of its Service Level Agreement (SLA) or Operational Level Agreement (OLA), as well as which database environments it uses, and who the emergency contact is.

The enterprise architecture tool holds data about its strategic value, its actual or estimated cost and the business capabilities it realizes or the value streams it supports.

The EA tool also holds details about the potential or agreed To-Be state of the CRM Application - for example, a new mobile interface to be developed next year, a new partner integration to be built, or links to a cloud hosting service it may be migrated to - all relationships that exist only in the future.

So it’s not just the properties of the CRM Application itself, but the things it is connected to that can differ between the two systems.

This means instead of asking ‘which system owns the CRM Application?’ we should ask ‘which system owns which information about the CRM Application?’

Planning your Integration

So what does this mean for integration? Well, there are three main implications:

First, you need a standardized description of your data across both your EA tool and your CMDB.

This ensures that when they exchange data, each system (and the team that maintains it) has a common understanding of what that data represents.

More importantly, it also stops them from trying to meet the same requirements in different ways.

That common description is your metamodel. Your first task is to sit with your IT Operations team and agree its shape.

Second, you need to agree which properties will be passed between the two systems.

For the properties identified, you need to identify which are mastered in which system and therefore read-only in the other.

Third, you need to agree when records from one application should be added to the other.

For example, As-Is applications, integrations or technology infrastructure might be added to your EA tool from your CMDB on a continuous basis.

But To-Be applications, integrations or technology infrastructure will probably only go into your CMDB on a periodic basis, once approved by change governance.

Data about the future is by nature volatile and uncertain. Only when changes have been implemented can we be sure which new components need to be added to our CMDB.

Also, bear in mind that both EA tools and CMDBs are just two classes of application in an increasingly rich IT tools environment which includes desgin, DevOps, Security and IT Business Management tooling.

All of these tools potentially store and duplicate similar data.

If that sounds intimidating, don’t panic! The same principles we’ve just talked through apply whichever integrations you’re concerned with:

  • APIs and integrations solve the technical interoperability issues;
  • your metamodel solves the semantic issues (i.e. a common language)
  • the same Time/Detail framework helps you decide where data should be mastered where.

To help you with this, try plotting your tooling onto the framework above to determine the correct integration approach.

Integrating with your CMDB - Key Takeaways

So let’s quickly recap on the key points covered above:

  • There is no 'One Tool to Rule Them All': EA tools and CMDBs have separate functions.
  • Ardoq offers multiple technical options for integrating with your CMDB.
  • A metamodel defines how those tools should interact and which data is mastered in each one.
  • Not just records or components but their individual properties can be mastered in different applications.
  • Master Data has a time dimension (e.g. your EA Tool may be the master for a To-Be application but the CMDB is the master for the As-Is).

If you still have questions or need more information on how to integrate your CMDB with Ardoq, browse our knowledge base or reach out to us from our website or using in-app chat.

Did this answer your question?