The Trouble with Third-Party Applications

ArticleID

54549 - Click to preview

Canonical URL

https://www.dbta.com/Columns/SQL-Server-Drill-Down/The-Trouble-with-Third-Party-Applications-54549.aspx

Title

StandOut Url

Author(s)

Kevin Kline

Images

Summary

Third-party applications are a very important part of the IT landscape. Many of us have faced the common dilemma of trying to decide whether to build or buy that next important application our organizations need. (By the way, I'm talking about smaller, specialized applications like an inventory management system for the company warehouse, or a practice management system for a doctor's office. I'm not talking about the huge and incredibly sophisticated ERP systems like SAP and Oracle Financials.)When we buy our applications, we're able to dedicate our in-house development resources to those things which are truly unique to our organization. In addition, we avoid the need to commit resources to the support and maintenance of the application, since the Independent Software Vendor (ISV) will take care of supporting the application, along with future enhancements and upgrades. And, of course, the ISV promises to do all of this at a much lower cost than if we did it ourselves.With alarming regularity, however, I run into a big problem with third-party applications- they just don't work very well. As a performance-tuning specialist who speaks at major conferences all over the world, I frequently encounter DBAs and developers struggling to make a purchased application perform. "Maybe we can add more RAM or CPUs" is a common refrain. The only problem with this approach is that a poorly coded application will exhaust the available hardware capacity no matter how much hardware you have. The reverse of this corollary is that there is absolutely no substitute, in terms of performance, for good application coding.After spending some time under the hoods of many of these ISV applications, I can tell you the GUI and client software often are fairly well-coded. The breakdown almost always seems to happen in either or both the database code (stored procedures, functions, etc.) or in the database schema design (bad or no indexes and keys, etc.). I encounter worst practices on the database side of the application so frequently that it almost seems these ISVs are willfully ignorant of good database design and coding.Some ISVs have defended their database coding practices by saying they code their application to run on several major database platforms, such as both Oracle and SQL Server. However, the truth is that any major SQL-centric DBMS will perform better when its SELECT statements include a WHERE clause and a well-formed JOIN sub-clause. You simply cannot get around that reality, and to claim that heterogeneous requirements are the reason for bad coding is disingenuous.After witnessing this problem so many times, I'm of a mind that we need something like the UL laboratory certifications for consumer products, except for ISV applications! Have you encountered any ISV horror stories? If so, I'd love to hear them!

Newsletter Name	Issue Name	Article Type	Article SubType
DBTA E-Edition	May 2009	Columns	SQL Server Drill Down

Select Content Type

Authors