eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Technology transformation can bring forth life in two different ways. The big-bang plan puts everything in place and only then says, “Let there be light.” The primordial-soup plan takes whatever happens to be on hand and jolts it with the lightning bolts of innovation and competitive self-interest.
Mere mortals have a better shot at success with the latter approach. For example, the PC revolution taught us that we can build tomorrows cities if everyone brings some of the bricks. Im always especially interested, therefore, in technologies that create the greatest possible chance of success with the least need for an all-powerful master planner.
One such technology is JavaSpaces, the descendant of the Linda concurrency model that originated at Yale and enjoys continuing progress there and at the U.K.s
University of York. By creating abstract spaces and connections for relaying information, without the usual constraints of time and format, these models make it possible for different parts of a system to evolve at different rates. Theres no need to limit the development of some parts because their present form is wired into the assumptions made by other parts.
After years in the hinterlands of research, JavaSpaces has surfaced in enterprise-class products such as AutevoSpaces and Autevo MDI from IntaMission, whose U.S. office is in New York. Real clients, including major government agencies and international companies, are doing real work with this stuff today—even if theyre not entirely ready to discuss it, which Ive often found to be the hallmark of people who really do believe theyre on to something thats going to give them an edge.
Having a JavaSpaces foundation makes it possible to tackle the modernization of an enterprise application portfolio in a distributed fashion. It becomes possible to modernize front ends without petrifying back ends by agreeing on an abstract middle layer to which all the actual IT assets can connect without concern for whats on the other side. It lets each center of responsibility make its own decisions about the relative urgency of various goals so that those who have budget accountability also get to decide what will be done when—an essential part of any rational goal-setting process.
Other technologies have come forward, in some cases over decades, with the promise of enabling incremental change and of letting solutions evolve along with changing needs and environments. Expert systems, with their rule-driven architectures, come to mind, but some of the most conspicuous success stories in that realm have instructive epilogues.
The expert system that configured VAX computers for Digital Equipment made a huge splash at an international artificial intelligence conference in 1986, only to be followed the next year by a paper on the even more complex system that had to be built to maintain it. Im not saying that the second chapter turns the first into a story of failure; Im saying that flexibility over the long haul, with attendant reduction of cost and containment of technical risk, requires more than the mere form of modularity. It also requires a match between responsibility and control.
A single, massive, central rule base is in many ways just another kind of monolith, vulnerable to many kinds of failure through inconsistency or omission, while a JavaSpaces architecture actually is a confederation that can robustly tolerate intersecting and imperfectly coordinated efforts. If a massive effort creates something that can only be improved, or even maintained, with an equally massive effort at some future time when resources may not be readily available, then success may be a premature claim; failure may be an inevitable end. A 25-year plan for a mission to Mars is perhaps an example of the wrong way; the alternative Mars Direct proposal is perhaps a better route.
IT likewise needs approaches that get something done today to make something better possible tomorrow.
If you want to remake the whole universe at one go, youd better be able to do it in a week. Mere mortals should ask themselves what they can do within the span of their power to write budgets and make decisions.
Technology Editor Peter Coffees e-mail address is peter_coffee@ziffdavis.com.
