All Packaged Up, Nowhere to Go

Computerworld - During the past 10 years, we in IT have done a solid job of weaning ourselves from the notion that custom applications are a good idea.
Packages have replaced our applications of old. When we want something new, our first thought is to look for a product we can buy.
If the goal is simply to provide technology to support the enterprise, that's the right way to go about it. But the game is changing again, and custom applications are returning to the fore.
IT is now woven throughout the enterprise, and there are few job functions nowadays that don't depend on the continuing operation of some IT system. With plant floors receiving materials through the workings of IT systems, even workers on the line depend on IT (even if they don't experience it directly). But the challenge is this: If everyone has the same stuff, how do we differentiate ourselves from our competitors?
In his book Does IT Matter?, Nicholas G. Carr argues that we don't -- and shouldn't. But CEOs disagree.
Bruce Rogow's firm, Vivaldi Odyssey and Advisory, reports that CEOs consider as much as 30% of their businesses to be "dead" -- they're producing products and taking in money, but they have no growth potential and must compete solely on price. CEOs are calling for innovation to produce growth.
But innovation can't be found in the packaged application market. Business processes, problems and methods must become common before a package can find the repeat business needed to make it a successful product (and justify its development costs). Potential clients must be (or be willing to become) similar enough to implement the package and have it fit their needs. What this says is that companies will share a base of common enterprise systems but season those with applications that are unique.
Before jumping up and down with joy ("The fun is back in IT!") or hanging your head in despair ("That's how we blew our budget and credibility before!"), stop and recognize that something else has changed. Service-oriented architectures and the creation of Web services have made creating custom extensions -- even whole new capabilities -- less risky than in the past.
This brings us to the real point of custom code. It should be focused and light, just enough to get the job done.
To get there, we also have to adopt new practices. Start by rigorously separating your requirements from your specifications. Requirements are about the problem you are solving and the work the custom code will