For years, systems delivery was remarkably unpredictable and inconsistent. Development organizations lowered the expectations of customers and generated extended time lines thatcould rarely be met. If they were, product quality suffered.
Object technology developed out of the need to solve these problems and is steering us in another direction, away from broken promises and toward empowering technological leadership in our customers. By encouraging them to think about what could be, expanding their sights, raising their expectations, and then delivering a quality product on time, we're seeing the development process actually become a pleasurable, profitable experience for all involved.
Yet where are the real gains? We already know the apparent benefits: software that's rapid to build, rapid to change, and easy to reuse. But these relate only to the mechanical aspects of development � creating classes, building palettes, designing interfaces, compiling, and debugging. The benefits derived from changes in the way developers work together as people can be even more profound.
Looking deeper, I find two underlying aspects of this technology striking: communication and collaboration. Objects in isolation, while useful, are rarely extensible. By itself, a timer object can track the passing of time � but only that. The same object, however, when collaborating with others, can generate powerful functionality: tracking patient histories, scheduling x-rays, initiating the movement of stocks and securities, providing automatic disaster recovery, managing entire networks. Unless an object is communicating with other objects, its usefulness is bound by what it alone understands and can accomplish.
The same is true for people.
Object technology, by its very nature, pushes development teams toward significant and consistent communication and collaboration. As people communicate and collaborate, their natural strengths and capabilities surface. In the right environment, balancing these qualities between individuals becomes a workable, and, moreover, natural process. But communication and collaboration cannot be treated as secondary or voluntary. These activities and the people involved need an environment that encourages them to become part of object technology: to emulate objects, to communicate and collaborate.
Cross-sectional work groups can facilitate this need, as part of each person's job then becomes communicating with people on other teams.
A natural outcome of this communication is collaboration. By communicating project information, different teams can identify common problems and processes and then collaborate to eliminate duplicate efforts. People in a collaborative environment can leverage the capabilities and knowledge of others, enhance and contribute their own areas of expertise, and produce libraries of distinguishable objects. Special teams of object architects can continually reengineer the software for even greater reusability and applicability across the board.
But how do we apply the vision of this ideal environment to the real world? By implementing several strategies, I have seen development teams � many times with diverse expertise and skill levels � deliver results that are exciting, and, time and again, surprising. Although every organization has its own unique requirements, some of these strategies can be generally applied, such as central-object architecture teams, access to a central object repository from all development sites, project libraries, domain owners steering domain-specific development efforts, and discussion-oriented mail applications.
Importantly, neither a development staff nor a company will realize the full benefit of using object technology if communication and collaboration strategies aren't implemented. Object technology will just become another turn in the long history of innovations � 3GLs, 4GLs, CASE � that turn out to be less than revolutionary.
I have observed many object development efforts. Some fall far short of the promise, while others surpass the objective, accomplishing more than ever expected. When a spirit of communication and collaboration is absent or weak, even a highly skilled team of developers can miss the mark. Often, a group like this delivers the very results they were trying to avoid; using object technology poorly can, for instance, create unmaintainable legacy systems.
But in a true object-oriented environment, familiar symptoms of old problems � budget overruns, schedule lapses, low quality � can fade into the past. People will start to discover they are gaining far more than the elegant, high-quality systems, delivered on time and within budget, for which they've been struggling. Wringing the inefficiencies out of business processes, object technology enables companies to achieve what they've really been seeking all along:
Vince Jordan is vice-president of object technology for SHL Systemhouse. He leads SHL's Object Technology Center, based in Boulder, Colorado. He can be reached at [email protected].