The existence of information silos in an enterprise is so well recognized that it’s almost a cliché. There’s now an entire discipline around attempting to break down these silos – Enterprise Information Integration (EII). And this problem is just as true within IT departments as it is within the larger organizations that they support, so it’s unsurprising that a feature offered by most modeling tools is the ability to integrate with other data sources, and this is a good thing. However, just because you can do something, it doesn't mean that you should, nor that you should do it right away.
Summary: the ability to import into or export from a modeling tool is a valuable one, but to make a success of it, it’s worth first performing a few back-of-the-envelope calculations to get some level of the cost-benefit tradeoffs. Issues around data primacy, co-ordination with other groups, and data quality need to be considered.
The first point to make is that not only is integrating your modeling tool driven by the same concerns as formal EII programs, but it faces some of the same pitfalls. First of all, the question of data primacy. Which repository is the canonical one? Or to put it another way, can you make changes to the data that is being imported? If so, what mechanism do you have to bring the two repositories into alignment? If not, how can someone request that data is added into the repository (e.g. addition of a new server)?
This introduces the second consideration, which is one of co-ordination between groups. Usually two different repositories will be performing different functions, and as result there will usually be different teams that own them. This naturally means that a level of integration between the two tools implies some level of co-ordination between the teams that own them. To be sure, this is a potential benefit of integration rather than just a problem – but it’s important to consider what benefits such integration offers, and how such co-ordination can be implemented. As with most initiatives, large or small, it is necessary to consider (even if briefly), what the cost-benefit tradeoff is.
The last point to consider is how much trust to place in the imported data. The reality is that most enterprise repositories contain entries that are out of date. So the question becomes whether the information in the other repository is information that is worth importing at all, and if so, how much of it should be treated as the canonical source.
Coupled with this last point is the need to identify a mechanism to flag errors that are identified in the imported data back to the owner of that repository. Depending on the repository in question and the processes of the organization, this could be as simple as sending an email to the tool owner, to raising a change request. The precise mechanism is not as important as identifying what it is and making a decision on how important it is that errors are flagged and corrected.