This perennial problem has never endeared corporate IT departments to the business community as a whole because users always go away with a sense of frustration. We all know the scenario: due to other priorities, any given user's specific project usually winds up somewhere in the middle of a priority list dating back more than 24 months. Users with their own funding turn to outsourcers for a project, only to be caught in a maze of corporate infrastructure standards they didn't know about, leaving them even more frustrated than when they started.
To break this cycle, for almost two decades the software industry has been pursuing concept-to-software component reuse, which in theory would allow a developer to develop a piece of code to perform a specific function; the code could then be reused by others.
A nice idea, but on a practical level it tends to fall apart. You can build a component, but it does not mean someone else can or will reuse it. Typically, components have been built in proprietary languages tied to arcane interfaces that only a subset of the developer population understands. If you overcame that challenge, you had no hope of actually exposing that capability to end users so they could easily incorporate something into an existing application or business process.
But hope springs eternal. With the advent of the first application servers and web services tied to standard interfaces such as XML, SOAP (simple object access protocol), and UDDI (universal description, discovery and integration), we may be coming close to the end of one of the software industry's most enduring quests for the holy grail. If you watch what companies such as IBM, Microsoft the Sun/Netscape alliance, Iona and WebGain, they are all in the process of building a suite of truly integrated tools that allows developers of different skill sets to reuse the same components.
So a hard-core developer who builds logic in Java or C# can then expose that component to another developer who would use a RAD (rapid application development) tool to incorporate that component in a larger application. Taking that concept one step further, systems analysts or even sophisticated end users should be able to take a business process automation tool to create applications by dynamically linking components together.
This capability has the potential to create a new hierarchy in the development community. The need for hard-core developers who continue to create the same piece of logic over and over might be reduced, but the size of the overall developer community should increase as it becomes easier for people to create new applications by linking existing components. This represents a core change to the socioeconomic fabric of the developer community.
But although web services will make it possible to finally accomplish this, none of it will come to pass unless we give developers the incentive they need to embrace rather than resist this change.
Vizard is editor in chief of Infoworld (US). Send email to Michael Vizard. Send letters for publication in Computerworld NZ to Computerworld Letters.