Separating Integration from Applications

Thanks for some great responses to last week’s column on plain vanilla ERP. What saddens me is that we have to be having this argument at all. IT is in a mess because we have business processes that are locked into source code that is difficult to change or modify—that’s the real issue underlying the argument. That makes customization a dirty, expensive word. My sense is that a lot of processes change to fit the software because that is the most economically expedient way around the problem. I’m sorry, but I have a hard time believing that preserving old systems and processes always translates into paving the cow paths.

But what if we could change the economics of process change? Maybe I’m drunk on the Service Oriented Architecture Kool-Aid that is poured so liberally at conferences these days, but it seems the way to separate business process changes from the penalties associated with changing the code or creating exit paths from them. I’m seeing companies beginning to build a separate integration layer in their architectures that is independent of the data and application layers. There needs to be a separate layer in the architecture for integration and business process change and coordination. Though web services aren’t always at the core of the layer, the concept of services is. I got into this in more detail in my recent story on enterprise architecture. The idea behind services is simple: Technology should be expressed as a chunk of the business rather than as an arcane application such as ERP or CRM. The service is a composite of different applications and data, all hidden behind a complex interface that is built to make linking to the service easy. Those building the links don’t need to know anything about the applications or data in the service to do their job. Even better, the services are reusable. For example, Lydian Trust’s enterprise architects designed a service called “get credit” that is used by several different product divisions within the company for different loan application workflows (autos, mortgages and so on). “Get credit” is a Web service that seeks out credit ratings over the Internet from the major credit bureaus. Anytime developers at Lydian want to use “get credit” in a new application or workflow, they go to the repository, grab it and build a quick software link to the service interface.

I realize that web services aren’t the complete answer to integration. I hear lingering doubts about security (though standards are fast emerging to take care of that problem) and bloated code that drains resources. But the concept of the separate integration layer and of services as the way to structure it seems sound. Between web services, proprietary middleware and the other tools out there today, it seems possible to build this layer inside your company today. I’d like to write about companies that have done it. Tell us how you’ve done it here, or send me an e-mail at ckoch@cio.com.