.NET developers love components. The .NET component market is vibrant. There are components for every need from multiple vendors. Some vendors offer a wide variety of products, while others offer products that target a niche. While both approaches have their place in the scheme of things, this article will lead you through some of the pitfalls associated with the accumulation of components from several vendors, albeit for different purposes. There is a definite business risk associated with using components from multiple vendors – one that every organization should carefully consider as part of their component adoption and use strategy.
Consider a fictional, and largely typical, project. It may include a legacy grid component that has been around since the start of the project. Perhaps a chart control, from another vendor, recommended by a consultant who said it was the best thing since sliced bread. Additionally, there is a reporting library from another vendor that allows the application to export data to Microsoft Office file formats. The UI team absolutely loved interface components from yet another vendor. Those components make the application look like the latest and greatest from Microsoft.
While this may seem like a common-place and acceptable scenario, is it really so? To analyze further, let us take a step back and ask ourselves why we use components in the first place.
Most development teams use components to gain productivity and thereby improve the feature set of their product without adding time and money exponentially. If productivity gains are what drive the use of components, then it bears investigating whether the use of components from disparate vendors hinders such productivity gains in any considerable manner. We consider below some of the common issues that development teams run into when they work with components from different vendors.
Integration issues
Integration issues are the most obvious. Toolbars from one vendor may not cooperate well with docking windows from another vendor. Grid controls may not raise just the right notifications for a chart control with related data to get updated. Integration issues can often be complex and hard to work around. In many instances developers end up disabling advanced functionality to reduce the likelihood of problems with integration. This is most definitely not a productivity booster.
Migration issues
Integration issues closely tie into migration issues. When a vendor releases an update to their product, they may mandate system requirements that might contradict the requirements of other components being used. These issues are also quite hard to navigate around, and teams are often stuck with the least common denominator for extended periods of time.
Support issues
When you run into usage issues or bugs, some vendors may be reluctant to support the usage of their components with components from other vendors. In many cases bugs could be unrelated to such usage, but this is a common situation where support teams are usually not willing to go the extra mile if only for lack of familiarity with the other controls, if not for anything else.
Licensing issues
Development teams often buy into a component library based on licensing knowledge they have assumed from working with another vendor. Vendor licensing policies, however, vary widely. Some vendors charge per CPU, some by server, some even charge a royalty per copy of product sold, while others charge based on the number of developers working on the product. If you make incorrect assumptions about the licensing requirements that go with a component, it could end up being very expensive to fix, quickly reversing all gains in productivity.
Source code
Some vendors ship their products with full source code while others do not. This can have an effect on your risk management strategy. You may find that you are unable to react to platform changes as quickly as you would like to without the availability of source code for all the components that you use.
Cost
The cost of individual components can add up pretty quickly. If you have components from several vendors you could end up with a bundle that cost more than it should have initially and is also expensive to license due to ongoing support and subscription costs.
Considering the above it is possible to conclude that it is often not very productive to integrate solutions from different vendors. There may be situations, such as the need for extremely specialized components, where such usage is warranted. If possible, though, such a scenario should be avoided to maximize your productivity gains and minimize risk.
About Syncfusion
At Syncfusion we offer a wide set of components with straightforward per-developer licensing – no per-server, per-CPU, or royalty-based licensing. Syncfusion Essential Studio contains eleven .NET libraries, and we offer components ranging from a grid control to an HTML display control. Our components are available for Windows Forms, ASP.NET and WPF, and they are offered with full source code.
There is no reason to pick and choose from several different vendors. Download our free, fully functional evaluation today and consider standardizing on an industry-standard offering such as Essential Studio from Syncfusion.
Syncfusion, Inc. is a provider of software components and tools for the .NET platform. Based in Morrisville, NC, Syncfusion leads the market with the broadest range of ASP.NET, Windows Forms and WPF software components and tools for building enterprise-class applications. Syncfusion can be reached at 888.9.DOTNET, or on the web at www.syncfusion.com
One package. One vendor. One license. One great price. Contact us today to find out how you can truly gain by standardizing!
|
