Evaluating Third-Party Components

As consultants, we must always be conscious of the time and cost of implementing a customer’s solution. Occasionally, we will have the opportunity to take advantage of components or plugins that are provided by third parties. What are some things to consider when using these custom components?

·         Is the solution written to work with only a particular version of the tool or language that we are working with? Is there an upgrade path provided or will a client’s need to upgrade a software platform require the reimplementation of external components?

·         Has the component been tested in all the different environments in which it may be used? For example, ETL packages developed in SQL Server Integration Services can be executed in a number of ways: through the MS Business Intelligence Development Studio, using the command line tool (DTEXEC), using the Execute Package Utility (DTEXECUI.exe), and as part of a SQL Server Agent job. You may want to stay away from a component that works with one execution method but not others.

·         What are the security considerations? Components that require administrative rights to an OS or database owner rights to a database should generally be viewed with skepticism. Review and audit closely any components that store, access, or produce sensitive data to ensure the value is worth the risk.

·         Who is providing the component? Is it a well-established company or even the tool vendor? Or is it an individual who had some extra time on his hand and cobbled together some code as a learning project? We should always be aware of the source of any code we are introducing into a client’s environment and the track record of the individual or organization providing the code.

·         How widely is this component used? A Google search should provide us with a good indication of its acceptance in the technical community. It also provides us with some feedback of people who have used the component and any pitfalls that they have encountered. Community testing can be quite informative.

·         Does the client have a corporate policy on using custom components? Most clients with a well-established IT infrastructure will have policies on the utilization of custom components. We, as consultants, should be well-versed in these policies before deciding to incorporate the component into our solution.

·         Is the source code for the component available? If source code is available, you will be able to audit and possibly modify the component to fit your specific needs.