Geeks With Blogs

The Lanham Factor The (ir)rational thoughts of a (not-so)mad man

This entry is originally from the Roanoke Valley .NET User Group newsletter.

This month the UG held a luncheon, sponsored by Telerik, about their products.  One of the UG members, George Matzko, mentioned the potential pitfalls associated with using 3rd-party components.  In this month’s newsletter I want to discuss that as it seems to be both an important topic and a topic of recent interest.

The Benefits of Using 3rd-Party Components

·         Time to Market – This is arguably the most obvious benefit.  If you buy a 3rd-party component that exposes the functionality needed then you can reduce the time to market for the overall product. 

·         Maintenance – Instead of you needing to fix defects and provide updates, the vendor does this.  Generally, vendors provide fixes at no charge (although upgrades are usually offered at a cost).  This alleviates the maintenance burden from your team.

·         Research – Vendors are focused on their aspect of your business.  Component vendors, for example, focus on their components to provide a discrete yet robust functionality base.  This allows you to focus on your core business.  Basically, you are buying their research and development effort expended by the vendor.

·         Education – Usually 3rd-party vendors provide sample code for how to use their products.  The samples, however, can also demonstrate good (and bad) coding practices.  This can be an opportunity to educate your team.

The Pitfalls of 3rd-Party Components

·         Vendor Tie-In – Of course, purchasing a vendor product ties you to that product.  If, for example, you purchase a grid control (a fairly common purchase even today) and you use it in several applications, you are essentially bound to that version of that control.  You may upgrade to a new version of the platform (e.g. going from .NET 2.0 to 3.x) and the grid is not supported.

·         Maintenance Contracts – Larger-scale components can ship with maintenance options.  Maintenance contracts are generally priced as a percentage of the cost of the base product.  While a 24-hour turnaround time on issues helps, the contract itself can be costly. 

·         Learning – Instead of learning the intrinsic controls in your platform (such as ASP.NET controls), your team needs to learn the 3rd-party components.  This means that if you hire team members who use the intrinsic controls or components from other vendors, you need to set aside training time for them. 

·         Upgrades & Testing – Just because the vendor (supposedly) tested their software doesn’t mean you can skip testing in your environment.  You need to make sure you have appropriate tests for your applications and that they consider the upgrades to 3rd-party components.

What pitfalls have you experienced?  Do you have success stores for 3rd-party components?  Share your vendor-related experiences with the rest of the NUG!

Happy Alignment!

Posted on Friday, April 18, 2008 1:09 PM SILC - Solution Implementation Life Cycle | Back to top


Comments on this post: Using Third-Party Components

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Brian Lanham | Powered by: GeeksWithBlogs.net