This post originated from an RSS feed registered with Agile Buzz
by Steven E. Newton.
Original Post: Build vs. Buy, Part 4
Feed Title: Crater Moon Buzz
Feed URL: http://www.cmdev.com/buzz/blosxom.cgi?flav=rss
Feed Description: Views and experiences from the software world.
Continuing a series examining certain arguments for buying commercial
software an minimally customizing it versus custom-developed software.
Customization
All but the simplest COTS (Commercial, Off-The-Shelf) software will
need customization. While is impossible to accurate assess how much, it
is possible to determine what portion of in-house resources go towards
needed customizations versus integration with other systems. If the
integration is complex and problematic it can take time and expertise
away from providing business-critical customization. If the users go
without their needs addressed because everyone with any expertise is
struggling to make the software talk to the rest of the systems, where
is the value in that?
Programming Interfaces
A critical aspect of vendor application customizability is a powerful,
well-documented, flexible and stable set of APIs that allow the
customer to modify the behavior of the software without introducing
incompatibilities and dependencies that cause problems in later upgrades.
The question to ask is, are they the right interfaces? Are they
sufficient to allow the right customizations without being overwhelmingly
complex? Do they make the common, simple case easy, and still make the
hard things possible? With custom-developed software, the interfaces are,
by design, the ones need to address the business requirements. If the
APIs stop meeting the evolving needs of the application to address user
requirements, in-house developers can refactor them to be more flexible
and useful. For purchased applications, these kinds of changes must go
through the vendor's change process, and a single customer's needs are
not the highest priority except in unusual circumstances.
Previous Topic
