Suites vs. best of breed

The leading back-office application companies--SAP, PeopleSoft, Oracle and J.D. Edwards--have extended their products into adjacent market segments. No longer content with selling financials, human resources and manufacturing software, these companies now market supply-chain, customer-relationship management, procurement and e-store products, to name a few. For the first time, a reasonably complex company could run an entire business on the application suite from a single software maker.

In each case, none of the back-office companies has a category leader in every segment. But that may not be required. The complexity and cost of integration may be enough to persuade some customers to forego the last dozen items on the feature checklist to get a pre-integrated package. Customers have spent billions with systems integrators and integration-software companies to integrate applications that weren't designed to work together. There are no standards for data models, programming languages or structured programming methodologies and only low-level standards for interfaces (moving from proprietary interfaces to XML).

Of course, the job of integrating heterogeneous software from different companies is never done. Applications always change, as do their interfaces and data models. Consequently, the integration backbone must constantly be upgraded to accommodate these changes. There is no synchronized release schedule for the software industry, so the timing of the changes is somewhat random from the customer's perspective.

If the integration framework doesn't yet support the new release of an important application, the customer must wait for the EAI vendor to provide an adapter or write one on its own. There are often good reasons for suffering through the pain of integration. Best-of-breed specialists are usually the companies that pioneered a segment and have more feature-rich products.

Users may prefer the best-of-breed product that addresses their daily tasks more completely and may not really care about how it's integrated with other applications in the business. Customers may be able to enjoy a time-to-market and productivity advantage by going with the market-leading, best-of-breed product while the application-suite makers are in catch-up mode.

But the suite makers tend to get there over time and deliver viable products; that's the history of the industry. Ten years ago there were still companies that sold only human resources software or general ledgers and that evolved to ERP. Twenty years go there were companies that sold only accounts receivable packages and that segmented into a collection of financial software.

The functions were procedurally related, and customers grew tired of building the data bridges between them. Innovators expanded their packages across these functions and passed the best-of-breed companies in those cases, but it took years given the complexity of these products.

Oracle and PeopleSoft may not ever have as many CRM features in their products as Siebel does. But both companies probably have passed a threshold of minimum functionality that is adequate for many customers in many industries. After that, the question is, what's the marginal return of the extra features Siebel can offer compared with the integration costs that will be created?

Centralizing more business functions in a single application suite can also provide more insight into the business. Oracle's single data model for all applications has some value. All data is normalized; for instance, a customer is defined once and can be accessed by all applications. Just defining a customer attribute across heterogonous applications can be a challenge.

If all the data about the customer is centralized and kept in a consistent format, mangers can more easily analyze customer behavior in real time rather than having to export data to a warehouse for cleansing, transformation, mapping and analysis.

Oracle has gotten more press around the one-stop shopping message, but there is no difference in what all the back-office software makers tell customers privately. They all want the customer to standardize on their application suite if possible but have standard interfaces to connect to third-party products where necessary. Oracle has the tightest integration within its software by virtue of the shared data model approach--all applications work off a consistent, shared data model. Everyone else connects components of the suites through interfaces and with separate data models for different components that are sometimes inconsistent and have to be updated with messages or batch updates.

Trade-offs and choices
There are trade-offs each way. Oracle's products have more dependencies on each other but offer a simplified architecture and potentially more information to management. The alternative approach offers more flexibility in how each component is deployed since the components are essentially decoupled.

The best-of-breed companies would argue that PeopleSoft and SAP integrate their own products with the same published interfaces available to i2 Technologies, Siebel and others. However, PeopleSoft and SAP take responsibility for making sure all the components can work with each over time. There's no guarantee that four years from now, Siebel will be as quick to integrate with PeopleSoft version 12.

We don't think any global company can standardize 100 percent on a business application suite; business processes are too diverse and complex. But our surveys show a definite trend toward reducing the number of interfaces and going from dozens of applications partners down to three or four important ones, and that's progress on the cost and manageability front.

The subject is only recently topical because the back-office software makers have only recently delivered credible offerings in all the key cross-industry segments. These companies generally don't address vertical applications that may drive a line of business, and integration in that area will probably always be necessary. It's unlikely that SAP or Oracle will have, for instance, an insurance actuarial system anytime soon--probably not a big enough market, in their view.