"Let the vendor do it." Of course! Why should we, the Acme Widget Company, makers of the best widgets in the world, expend our precious, limited resources on building and managing IT infrastructure components? Why don't we buy the IT components we need from vendors that specialize in them? Then we can focus our own internal resources on building better widgets cheaper and faster. Everybody focusing on his or her core business, "sticking to the knitting" as Tom Peters would say.

Of course, this makes a lot of sense when we're talking about a database management system (DBMS) or an accounting application. (There are exceptional cases, even with these.) However, what about something not quite so off-the-shelf, something such as your meta data management system, where a single-vendor solution might not make quite as much sense and a multivendor solution is not straightforward?

In general, "letting the vendor do it" and "sticking to the knitting" are very helpful maxims. However, as with all simple proverbs, they should not be followed blindly, but rather with an understanding of the trade-offs involved. What follows is a discussion of the trade-offs – the potential benefits and the potential risks – involved with leaving it all to the software vendor. Most of the examples in this discussion involve meta data management systems, but you can use these checklists when considering any technology-intensive requirement, not just IT infrastructure.

First we will examine some general considerations regarding a single-vendor proprietary solution. Next we will discuss some additional considerations – pros as well as cons – when the vendor solution involves a closed, proprietary architecture. Finally, we will provide a few recommendations to guide you when architecting a multivendor solution. Let's start by looking at the positive aspects of a single-vendor proprietary solution.

Potential Benefits – Single Vendor

Singular Accountability. The single vendor is accountable for the entire solution. The customer avoids the runaround of multivendor solutions where each vendor indicates the problems lie with the other vendor(s). There is no contending with vendor protests of "Not our problem; talk to the other guys." This is not foolproof, however, because the single vendor will invariably – and in part understandably – require that you migrate to the latest release of all their related software before they will willingly sink their teeth into your problem. On rare occasions, this will actually fix the problem you have, without the vendor having to lift a finger. However, more often than not, it becomes a frustrating sequence of jumping through hoops, which conveniently pushes the problem back onto your technical staff rather than the vendor. (Wasn't that the original point of all this?)

Leveraging Vendor Product's Capabilities. Typically software users – of all types of software (from word processors to DBMSs) and all levels of technical sophistication – use only a small fraction of the features and functions of the software they purchased. When users use a single software tool (or suite) for a broad range of daily operational activities, they tend to get more familiar, confident and proficient in it. Consequently, they look for and find features and functions to further exploit. This is far less likely to occur when one has heterogeneous tools and methods available. The bottom line of this phenomenon: Limiting toolset availability results in users squeezing more value out of the single toolset that is available.

Protection from Software Upgrades. The use of a single vendor can mitigate issues of compatibility, configuration or customization when migrating to new releases of their software. This is by no means a sure thing, however. For example, the customer may use a large variety of software products from a large software vendor (think IBM or Oracle); each product has its own release schedule and limitations of upward and downward compatibility with other software products from the same vendor. Frequently the customer's own technical staff is hindered from upgrading to the latest release of the software because of substantial other work involving reconfigurations, customizations or other software installs that must happen first or concurrently.

Now let's look at some potential downsides.

Potential Risks – Single Vendor

Vulnerable to Product Dis-continuity. The vendor's circumstances can and will change – in the marketplace, their technological advantage or position, their key suppliers or developers, their ownership or product strategies, etc. For example, ten years ago many companies built robust enterprise repositories around the BrownStone product suite, cultivating a good relationship with a responsive vendor. Things changed, however, when the small software vendor was bought by a large software conglomerate. Shortly thereafter, the software giant discontinued support of the product and provided little migration support to the designated alternative product (from another repository vendor the conglomerate acquired around the same time).

Uneven Support to Internal Clients. Some users internal to your organization may benefit more from the single vendor's proprietary solution than others. This can create a situation where some user groups within the company develop a sense of alienation or disenfranchisement and do not buy into the designated "enterprise" platform. They may even create their own competing solutions that, in their judgment, are more responsive to their own departmental needs.

Loss of Competitive Motivation. The single vendor has a relative lock on the customer's business, and everybody knows it. Even the most sincere and honest vendor will be affected – at the very least – by some measure of complacency, which will be reflected in pricing and level of service. The less the vendor is concerned about integrity and competitively providing value to the customer, the greater the probability of diminishing price performance, i.e., less bang for your buck.

Loss of Key Employees. Frequently the customer company will have "true believers" who know and love the vendor's products. These key employees can be very credible evangelists and talented service people, in and outside your company. The vendor knows them and loves them. Although most vendors would never blatantly solicit these people for employment due to legal ramifications, they would not hesitate to talk with them should the employees initiate a discussion with the vendor about employment possibilities. Often they will welcome such key employees of the customer with open arms (and stock options).

Limited Functionality. Very few products have all the functions and features needed or desired by a user community, and meta data management tool offerings are no exception. Therefore, a single-vendor solution will limit functionality to what the vendor's tool offers, and nothing more.

Now let's look at some special considerations for a single-vendor solution with a closed architecture. A "closed architecture" is one that does not comply with non-proprietary, published industry standards aimed at enabling software inter- operability among vendors. Conversely, an "open architecture" is one that does.

First let's talk about the advantages of closed architectures, which must not be minimized.

Potential Benefits – Closed Architecture

Software Performance. Typically a closed software architecture means that the software does not comply with non-proprietary, published industry standards aimed at enabling its inter-operability with software from other vendors. A powerful upside to this is the vendor can optimize the software to utilize machine resources very efficiently without needing to go out of its way to meet standards constraining its internal architecture or APIs.

Vendor Responsiveness. Related to the software's performance is the vendor's performance. The software vendor need not expend its human and capital resources trying to build in compliance with open architecture standards. Additionally, new features and functionality can be added without the hindrance of waiting for additional information or resources from third parties and without concern for architectural political correctness. The net effect of this can be the appearance – and the actuality – of greater responsiveness to customer requests for new functionality or improvements.

Potential Risks – Closed Architecture

Reinventing the Wheel. A closed software architecture typically means that the vendor must be more vertically integrated in their market space, i.e., must build more of their own componentry from scratch, rather than partnering with other vendors whose software excels at certain functions. For example, where a tool that has underlying meta data residing in proprietary flat files rather than in SQL-compliant relational tables, the vendor must build its own query browser for the meta data – or else not provide query access at all. In comparison, where a tool has underlying meta data residing in SQL-accessible tables, then the customer may use any third-party SQL-capable tool to query the tool's meta data in ways not explicitly provided for or anticipated by the first vendor.

Lack of Choice in Add-On Tools. Related to reinventing the wheel is the lack of choice with respect to additional software to use in conjunction with the closed-architecture software. When software complies with open-architecture standards, customers can purchase additional tools that have functionality not provided by the first vendor's product set and use them in conjunction with the data or functionality of the first vendor's software. A closed architecture effectively precludes such options.

Limited Extensibility. Often, software customers want to augment the data or functionality of the software provided by the vendor, be it an enterprise resource planning (ERP) solution or a spreadsheet. When software employs an open architecture, it enables the customer (and other software vendors) to add additional data or functionality without vendor intervention. For example, a repository tool may use a third-party relational DBMS as its underlying data management platform and have published, robust application programming interfaces (APIs). Those are two aspects of an open architecture which allow the customer to add new meta entities to the underlying repository meta model and new functions to the tool's application layer. Substantial extensions of both data and functionality are feasible with no vendor assistance (or even awareness) and usually with few (if any) release migration issues.

We have looked at the potential advantages and disadvantages of single-vendor technical solutions for open and closed architectures. In some cases, the positives appear to outweigh the risks, so a single-vendor solution may make good sense. In other cases, the potential risks may tilt the scales away from a single-vendor solution. In that case, what are your options? At that point, you are looking at architecting your own solution to leverage one or more vendor products and/or homegrown components. If that is your position, here are a few additional considerations.

Custom- Architected Solution

As Open as Possible. Stick with as open an architecture as possible – the more open the better. For example, use standard structured query language (SQL) and open database connectivity (ODBC) interfaces where feasible. Or, if using a proprietary architecture, select one that is quasi-open, i.e., that numerous other vendors subscribe to, such as Informatica's MX2 meta data exchange architecture.

Keep the Solution Simple. "KISS," another oft-quoted maxim, applies here. Be very conservative in the initial scope you attempt to implement. Focus on the bare bones, the most highly valued pieces of information or functionality, and have a general strategy and architecture for selectively extending it once you've proven the concept and worked the bugs out of the basic system.

Minimize Products. Minimize the number of vendor products involved in your architecture. Where politically possible, decide on one vendor product in each category as the preferred (if not standard) tool. For example, in the case of a meta data management system: one extract, transform and load (ETL) tool; one data modeling tool; and one query tool.

Stay in Charge. Do not "sub" the architecture, planning and implementation out to a tool vendor or a consultant closely related to a tool vendor. (See the first half of this article.)

Expect Some Difficulty. Things may not simply snap into place, despite assurances from all involved vendors and IT support staff. The design and implementation of your architected solution is a project that needs to be planned and managed as conscientiously as any other.

We have looked at the pros and cons of single-vendor solutions and open versus closed architectures. We also reviewed some considerations for an architected multivendor solution. Each of the options has a valid place and role, depending on your requirements and environment. Whether your battle cry is, "Let the vendor do it," "I'd rather do it myself" or something in between, we hope we have helped you sort out your options.

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