Faster than you can say XML, a whole cottage industry has developed to standardize the mechanics of Web services to add to them protocols for things like security and routing and workflow, and even to develop standard XML schemas for business.

For too many, though, Web services are synonymous with service-oriented architecture; many believe that you can't have the latter without the former. While it is cool - this ability for my Visual Basic application to call a Java EJB - it is still just a tactical, marginal improvement in our ability to deliver systems. The real strategy - the big deal that is service orientation - is the systematic eradication of duplication in our systems. For many, this duplication of code and effort is reaching pandemic proportions.

Building enterprise systems is such a daunting task that we usually don't do it. Smaller, departmental solutions are easier, both politically and technically. These stove pipes are usually built soup-to-nuts with their own presentation, business, and data layers. We integrate them when necessary with EAI technology, an enterprise service bus, or with using Web services. We build up an army of point-to-point integrations and never really develop a concept of the enterprise. When it all works we are rewarded and move on. However as good as they might appear, they tend to duplicate each other with impunity. Too often I see things of the enterprise such as customers, products, and agreements built separately, on different platforms and - perhaps the scariest part - even with different rules. It is a level of technical debt that invariably bites you back.

I worked a while ago with a client that had a serious problem because of this type of technical debt. In the face of mounting competitive pressure they needed to drastically change their business model. The very systems that had helped build this successful corporate empire were quickly becoming a burden because they were inflexible and built to enable only the current way of doing business. Adding features was becoming impossibly expensive and their data was out of control. One of their directors estimated that just to adjust their prices for inflation meant that 22 different databases and files needed to be synchronously changed.

Their transformation required service-oriented architecture, but not glitzy things like Web services. It began with a carefully crafted business object model - a finite set of things of their business - that could be built as enterprise-wide reusable components for accessing and storing data. In front of these domain components they planned reusable services to handle enterprise processes like registrations, account management, and billing. These could be shared, extended, and localized by their organizations in different countries. Behind, they planned to implement an EII program to rationalize and modernize their data storage. The plan represents years of incremental change to their systems, but it forms a common vocabulary and a flexible infrastructure with which all of their future systems can be built.

As it is deployed, customers, account reps, and other users will still have their customized experiences, but behind the screen sharing of the services is expected to increasingly improve the company's bottom line. For example, instead of a yearlong effort when one organization wants to sign customers up differently, it's only a few weeks or months. They don't have to build and test new code; they have to use existing code components in a different order. Moreover, its flexibility and component-based design should keep them from accumulating new technical debt.

Next to the more immediate gratification of Web services, service orientation may seem very mom and apple pie, but articles I've read suggest that as much as 75 to 85 percent of corporate IT budgets are spent just running what they have. Individual technologies can at best deliver only marginal improvements in ROI. Our arsenal of tools and technologies and techniques need the guidance of architecture to do better. Done well - and I realize that we may not have yet done this - mom and apple pie means delivering more value and doing it faster with that remaining 15 percent of the budget. That capability becomes strategic to the enterprise.

With the combination of standards and robust platforms like BEA we have it in our grasp more than ever to build enterprise systems. It may be less glitzy than technology, but in the end architecture pays better.