InformationWeek
Defining The Business Value Of Technology
November 9, 1998
 Print this story |
continued...page 3 of 3
An enterprise architecture may yet prove to be the key to unlocking enterprise reuse. "If you set out to develop a good architecture, you can achieve reuse as a dividend," says Eric Aranow, president of Context Consulting."It's difficult to come up with the grand vision of a reusable component," says Blue Cross' Meyer. The difficulty stems from the project-oriented nature of application development. Blue Cross, like most companies, uses project teams that build the components for their own use in the course of individual projects. Each team is focused on its own needs, but is moving toward the broader goal. "Our project teams have to think about how others would use the components. It comes down to an architecture issue. You have to understand the vision," Meyer says.
Architecture Needed
Developers working with visual tools can knock out components quickly and easily. But without a foundation of good architecture, it's unlikely the components will work for the next application. "If you want reuse to succeed, you need to invest in the architecture first," Aranow says. At the least, organizations will need a systems architecture, business domain architecture, and infrastructure or middleware architecture, he says.
Reuse nirvana, if it exists, will come about when companies have design patterns and an architecture tailored to the business. This will allow developers to spend more time thinking about the business than wrestling with implementation, says McGregor. But even then, the benefits of reuse--better-quality applications, lower cost, faster development, high developer productivity, easier maintenance--won't come quickly.
Commercial software developers are reporting the biggest success with reuse, but even vendors are careful where they focus their component reuse efforts. Vendors like Hewlett-Packard, a leader in reuse, achieve high reuse when development teams strictly focus their efforts, says Harmon. Similarly, consultant Kerth developed some reusable objects for a vendor, which reused the objects 11 times.
Ultimately, a standard architecture may help both vendors and in-house developers solve the reuse dilemma. "What does it matter if we came up with a reusable component architecture on our own?" asks Kent Wreder, corporate director of object technology and information systems at Baptist Health Systems of South Florida in Miami. Vendors can't buy into the individual architecture decisions of all their customers. Standards of some sort are required.
Search For Architecture
Frustrated by finding the same functionality built into dozens of different applications, Wreder signed on early with the Object Management Group to develop object reuse standards, a component architecture that every vendor can adopt. This should allow companies to buy and deploy reusable components that work together. The hospital has begun deploying the first fruits of that effort.
Baptist Health Systems is deploying a Corba-based personal identification service that enables it to search the various unique patient ID systems across five hospitals to come up with a single enterprise-wide ID for each patient. The component is 3M Corp.'s off-the-shelf Master Member Identification component, a proprietary product. But with its standard Corba interface, it gave Baptist Health Systems a way to use it with other components.
For instance, Baptist Health Systems bought a Corba-based transcription component that automatically fills out physician reporting forms with patient data from its records, which it pulls in with the help of the personal ID component. Now Wreder's group is assembling a similar service for chaplains at Baptist Health Systems, who also make written patient assessments.
While Wreder makes it clear that Baptist Health Systems buys reusable components but doesn't build them, its experience with components designed to a standard architecture presents a vital lesson for any development group trying to achieve software reuse: Without an architecture, organizations will not be able to build or even buy consistently reusable components.
But even with an architecture in place, organizations still must choose their targets for reuse carefully, invest in the up-front work, and be prepared to wait. Even then, the payback from code reuse may be far down the road.
return to page 1, 2
Illustration by Dennis Harms
Back to This Week's Issue
Send Us Your Feedback
Top of the Page
