Objects of affection.

The software world is stampeding toward objects. You could ignore this trend, determining, as some companies do, that making the transition to this technology requires too much up-front investment and that comparatively few programmers have sufficient expertise in the new environment. But to do so endangers your competitiveness.

Because applications software that relies on object technology tends to be reusable, it is faster to write - and, therefore, less costly. Moreover, the technology creates applications that model businesses more closely than conventional programming languages and are easy to change. Companies such as Fidelity Investments Group, Federal Express, Citibank, GTE, Daimler-Benz, Hughes Aircraft, Andersen Consulting, ITT Hartford, American Airlines, CIGNA, GM, and Ford all have mastered the learning curve. All have well-managed investments in object technology.

In the past, our business processes were implemented through the use of software programs, business practices, and organizational policies. The software we used to manufacture products, do accounting, and keep tabs on our customers was either written in-house or purchased from the outside. It was written by programmers who interviewed us to understand the current business policies and rules and who then "hard-coded" those business rules into the applications. Then, when the business changed, we had to patch and rewrite the applications to accommodate those changes. The software becomes brittle and hard to maintain, and eventually, it becomes useless.

Conventional programming languages were designed to communicate a series of instructions to computers. Object-oriented languages, by contrast, were designed to model complex systems. Ideally, you should be able to build a dynamic model of your business, which becomes the programs that run your business. Of course, most of us already have lots of application programs in place. Moving to an object-oriented approach doesn't require that you rewrite everything from scratch. In fact, it provides a framework for integrating new applications with your existing applications.

What exactly is an object? A business object is a business concept, such as a customer, product, price, bank account, insurance policy, or credit rating. The object's description includes the data that characterize the object (for customer: name, address, unique identifier) and the behaviors you expect from the object (customers: buy, request service, ask for information, return things).

The object model includes the relationship between any two objects. Customers have credit ratings, they buy products, they hold insurance policies. So business objects are used to build a dynamic model of the business. At GTE's telephone operations, as management re-engineered the organization, it discovered it had about a dozen core business processes. These 12 processes used a total of about 100 business objects in all: concepts such as "check credit," "check line," "enable service," "send bill." So far, we're talking about business concepts, and about the design of new business processes by business-people. So where do the programmers come in?

As the businesspeople design the business process model and define their business objects, the software developers create software objects to capture these models. Like a business object, a software object is a description of a concept, such as "customer," and a set of attributes, data, and behaviors associated with that concept. The only difference is that it is described in an object-oriented programming language, such as C++ or SmallTalk, and then the same software object is reused every time any application uses the concept "customer." Often, the software object simply retrieves a set of data that already is contained in a variety of existing data bases and applications.

The biggest benefit most companies see from object-oriented development is that they can reuse these objects. Hughes Aircraft and GTE Telephone Operations now are consistently achieving 60 percent reuse of their objects. For each new application they write, they only have to write 40 percent of it. The rest they put together from objects they've used in previous applications. They use small teams of developers (typically no more than eight people on a project). And they are delivering and deploying ambitious applications in about half the usual time (nine months instead of 18 to 24 months). But be aware that to achieve benefits of this magnitude, you must be willing to invest in retraining your programming staff and supporting this transition to object-oriented analysis, design, and development for at least two to three years. It's clean, it's simple, and it's the best way to design, develop, and evolve software today.

Patricia B. Seybold is president and chief executive of the Patricia Seybold Group, a Boston-based information-services firm.