IT needs approaches that get something done today to make something better possible tomorrow.
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 todayeven 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 whenan 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 email@example.com.
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.