Continue in 2 seconds

Are there any industry standards or best practices on how to handle vendor solutions specifically pertaining to conforming to information architecture standards.

By
  • Sid Adelman, Larissa Moss, Chuck Kelley, Clay Rehm, Les Barbusinski
Published
  • April 02 2003, 1:00am EST
More in

Q:

Are there any industry standards or best practices on how to handle vendor solutions specifically pertaining to conforming to information architecture standards (data model, data object naming standards, formats, etc.). Is it reasonable to assume a vendor would alter their product to match our enterprise standards or should we expect that a vendor solution should be treated as a "contained" environment?

A:

Sid Adelman’s Answer: It’s unlikely that a vendor would match their standards to yours unless those standards were very close or unless the vendor was hungry and you had a lot of money to give them.

Les Barbusinski’s Answer: Almost everyone handles vendor packages the same way: installing them "as is." Most vendors will not customize their software to conform to a customer’s shop standards because it increases costs and complicates maintenance. That leaves it up to each shop to determine whether or not to customize the package, and most shops will choose the easy route: installing the package as is. Why? Imagine having to rename every object in a software package every time a maintenance release or patch is issued! Imagine the testing that would be required to insure that the package still worked! It would turn a relatively simple exercise into a veritable nightmare…with no visible business benefit. Furthermore, imagine how difficult it will be to convince the vendor that the package has a bug once you’ve "tampered" with the application’s internals! The best practice is to install the product "as is" and build interfaces that conform to your shop standards.

Chuck Kelley’s Answer: I would expect the vendor solution to be treated as a "contained" environment. Can you imagine how many different ways that the enterprise standards could be defined and if vendor solutions had to "modify" their products, it would be impossible to support their customers? There are some components of the architecture that I might use to not decide on a vendor solution, but once chosen, you shouldn’t expect them to change.

Larissa Moss’ Answer: In my experience, vendors rarely – if ever – change their products to match anyone’s enterprise standards. And the data models they provide are physical data models, i.e. pictures of their database structures, and not logical data models, which are your company’s business views. In fairness to the vendors, they don’t know your company’s business view, and all they can be expected to provide are their database implementation views. While vendor solutions are unavoidable in today’s fast-moving IT environment, they do create a hurdle for horizontal cross-organizational integration. Unfortunately, treating them all as "contained" environments will only lead to vendor-specific stove-piping. My suggestions are:

  1. Choose vendors whose products come close to your enterprise standards and whose data integration philosophy matches that of your company.
  2. Reverse engineer their physical data model by normalizing it into a logical data model and compare that to your enterprise logical data model. Merge the conforming pieces and add the non-conforming pieces (either selectively or all) by capturing and publishing these exceptions as meta data.
  3. Whenever possible, use the DBMS features of aliases and synonyms to enable your users to use your own standardized data object and data element names. But there is not much you can do about the different formats.

Hopefully these tips about controlling the deviations will help you stay as close to the "single version of the truth" as possible.

Clay Rehm’s Answer: It is not reasonable to assume a vendor will alter their product to match your internal standards. Their product was developed with their own internal standards, and they would have to alter it many times over for every client they deal with. This is not in their best interest in delivering a solution. You need to treat each piece of purchased software as its own environment.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access