MY FAVORITE line from a lecture was delivered at a relational database conference. The speaker was making a point when he blurted out, "I don't have any data for this, so it might even be true."

One of the problems with data and statistics is that they are necessarily backward looking. We all have 20/20 hindsight, but sometimes you simply need to assess all the possible input, inadequate as it might be, and move forward.

I've felt like that for several years now as the need for better integration technologies has mounted and as vendors have stepped up to the many challenges of bringing together disparate enterprise applications. The need is definitely there, but all the data on what is the best approach is not. We can, however, make some educated guesses about what to do.

Integrating various enterprise applications is difficult. Unlike the relatively easy integration of, say, sales and marketing applications that share a common database, integrating enterprise business applications frequently spans different business processes, each with its own unique data and network. That kind of integration requires emerging standards and technologies like SOAP and XML (i.e., Web services) that bring together processes, not just data.

In his book, The Rise of the Network Society, sociologist Manuel Castells identifies five primary kinds of networks that correspond closely with the major kinds of enterprise software we work with.

1. Customer networks that link manufacturers, distributors, value-added resellers, and end users.

2. Supplier networks made of subcontractors manufacturing component parts.

3. Producer networks comprising companies that pool their production facilities, financial resources, and human resources to expand their portfolio of goods and services, broaden geographic markets, and reduce risk.

4. Standard coalitions bringing together as many firms as possible in a given field to bind them to the technical standards established by an industry leader.

5. Technology cooperation networks that enable organizations to share knowledge and expertise in the research and development of product lines.

As we move towards better integration of networks, look for the emergence of a very different enterprise software industry business model with the following major attributes:

* two tiers of vendors-developers and publishers. Developers will do what they've always done-and less. The publishers take responsibility for sales, marketing, and some support functions.

* greater reliance on hosted delivery. Publishers will support many thousands of users of standard applications that rely on Web services for customization.

* software vendor revenues become much more predictable as a result. As a practical matter, who wouldn't like to have fewer earnings calls that start with "Oops!"? They don't call it the utility model for nothing.

* reduced cost-of-entry for new software companies. The primary objective of these firms will be to build relevant, working applications that conform to integration standards.

* lower sales costs. Because it will have a relatively captive customer base (similar to your phone or electric company) the publisher will have an instant sales channel for new products and will be able to sell through the channel at a far lower cost than today's software companies encounter.

Many people have noted the seeming lack of some "new, new thing" to propel the tech industry. Some have advocated taking care of the unfinished business of making everything that we already have actually work. But making everything work doesn't mean hanging on to the status quo. The new, new thing is a new business model based on an architecture that really can promote interoperability. That's a worthwhile challenge and one that will propel us forward.