I once worked with an ERP system that couldn't integrate with anything. It started life as a couple of mainframe applications that were loosely linked. These then were ported over to common server platforms where the applications ran in a terminal emulator (disguised as a window). The database was a truly bizarre multidimensional "relational" database with some of the logic in the application and some contained in the data structure. Processing essentially was done in batch mode even though it appeared interactive.

There was an ODBC connection to the database that worked, but there was a caveat–and a problem. The caveat was you were not allowed to write to the database outside of the context of the ERP system. Not only was this verboten, but it also violated the license agreement and would cause all support to be immediately terminated–and this was a system that needed support. The problem (remember: one caveat, one problem) was even when you connected to the database, you never were certain what you were looking at. There may have been a data map at one time, but it must have gotten sent to the laundry by mistake because no one ever was able to determine definitively what data you were working with. The ERP system itself dealt with "views" of the data, and the vendor's "views" never equated to anything we were able to pull.

The ERP system itself really wasn't all that bad–it more or less did what it was supposed to do. But it was an island, and an aging island at that. What could rescue this system from an imminent demise would be to wrap it in a nice Web services blanket that not only would protect it from the world changing around it but would expose all of its useful functionality to the world through Web services. For each something the system did, we needed a Web service that would perform that something. Expose a function that takes customer ID as a parameter and returns customer information in an XML stream that can be consumed and interpreted by something outside of terminal world. That seems like a rather modest proposal. In fact, the manufacturer of this ERP system has been dangling that carrot in front of its customer base for some time. Unfortunately, it never seems to get beyond the carrot phase.

Which brings me back to our retailer with the mad passion for jumping into the wholesale world. There may be a compelling reason for some of the acquisitions to abandon their current IT systems, but I suspect there isn't. In this case, the companies were acquired because they were successful. That is not to imply only successful companies are acquired; in fact, I suspect most are gobbled up because they are not performing up to par. So, these successful companies probably have information systems that have performed well enough to get them where they are. What the acquiring company is looking to do is build a world-class e-commerce system on top of this collection of business units. And that doesn't necessitate killing existing systems. Let them keep their vendor-specific or anti-vendor-specific platforms and confront the real challenge.

Our wholesale market wannabe should design and build its killer e-commerce platform based solely on best practices for its target market. At the same time, a technology-neutral marshalling or brokering tier should be architected and built. The marshalling tier has two functions:

1. Expose a layer of Web services functions that will be complete and sufficient to provide all the data needs of the e-commerce layer.

2. Fetch the data it provides to the e-commerce layer from the individual business unit.

That's it. Corporate designs, builds, and implements the e-commerce platform and a piece of middleware that feeds e-commerce. It becomes the responsibility of the individual business units to create their own Web services that will be consumed by the middle layer. Standard functionality with clearly defined behaviors and expectations will be described for the middle tier. Each business unit will expose these functions as Web services for consumption by the middle tier. At times, it may make sense for the middle layer to normalize and consistently format data before passing it on, but probably not. It is possible to design just the e-commerce platform to pull its own information from the other business units, but then we are building a system with built-in obsolescence. If we truly want to create reusable and distributed information systems, we need to learn to broker data exchange and functionality through shared and reusable resources.

That is what service-oriented architecture is all about or what it should be about. The vendors provide us with a platform (a Web services platform) that allows reuse of functionality at a micro level (think object). Service-oriented architecture takes that to a macro level to allow us (or other vendors) to build applications that can expose the services provided by that application. We cannot expect Sun or IBM or Microsoft to understand our business enough to provide us with a ready-made platform that is prepopulated with all the functionality we need to run our enterprises.

Certainly, there are various organizations (ACORD, for example) that take the creation of industry standards very seriously, and these are standards to be reckoned with. But the real truth about SOA and enterprise application integration is every enterprise probably is going to require a custom solution.

When we think IT or corporate governance, we tend to think Sarbanes-Oxley or data integrity or maybe even keeping e-mail out of the hands of the regulators, as in "All corporate e-mail will be deleted after 90 days." If you are an MBA with a specialty in information technology, you probably know all about that stuff–and corporate security and service-level agreements and other such interesting esoterica.

I propose the real goal of IT governance should be establishment of a codified SOA for the enterprise. To do that, we need to use actual computer geeks or, more correctly, a subset of the species–to wit, computer geeks with a thorough understanding of the business model. Yes, they do exist. The SOA master plan for an organization will define the basic set of services that will be made available throughout the enterprise. The same Web service the customer service unit uses to validate a customer's address will be used by the online order-entry system as a customer submits her order.

We collectively have been flapping our lips at software reuse for the last 15 years. Whether we called it modular or component based or object oriented or just good programming practice, we consciously have striven to quit reinventing the wheel. Platforms such as Windows gave us a slick and easy way to use APIs that allowed us to at a least reuse someone else's code. I know software shops I worked in always strive to reuse code and create components that provide basic functionality with the stated intention that module or library will be used and reused.

Nevertheless, it always seems to me we keep doing the same things over and over again. Maybe we are losing sight of what reuse really is. Maybe we are so intent on writing code for a particular project we fail to make it generic enough to be truly reusable. Perhaps having a corporate "standard" to code to would navigate us around those rocky shoals. But it also may make us miss a deadline. And it sure as heck isn't going to work in an "agile" environment where every software developer gets to decide just what it is he wants to do today.

There is a direct inverse relationship between creativity and oversight. Over-management of a development team is a certain way to kill productivity. On the other hand, the benefits of SOA are so overwhelming it needs to be implemented. We need our software teams to see the value of coding reusable services. And as managers, we need to allow the time and the freedom for the guys in the trenches to get it right. And as corporate executives, we need to ensure that the standards for services are there–and that they are used.