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 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 percent 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 do (or the product it will be). Good requirements talk about how each item in the functions being designed can directly lead to measurement of a business result. (Business cases are developed from these; the proof that value was delivered comes from measuring the results later.) Specifications, on the other hand, are about how the solution is delivered.
Getting the requirements done allows you to know precisely what you are implementing -- and then to do no more than that. (Do you use, or even know the function of, all the buttons on the tool bar in any application? It's wasteful to overbuild.) Freeze these (you're delivering a product, and time to market matters) and get it built. There's always Release 2 for new requirements that emerge later.
Deliver innovative solutions that do "just enough," and become victorious in your CEO's eyes.
Bruce Stewart is a former CEO and one-time senior VP and director of executive services at Meta Group