SOA – Building The Compliance Infrastructure

I’ve been talking about Web services’ latest incarnation, service-oriented architecture (SOA), since 2001. So imagine my surprise when I heard that Cisco, EMC and a host of network appliance makers claim to be in the SOA business.

After all, SOA is confusing enough without throwing in the kitchen sink of infrastructure. Every day, people confuse SOA with one of its many applications: B2B integration, software as a service, enterprise workflow—you name it. To them I’ve always said, “It’s applications as services, period.”

But guess what? After a couple of years of singing that refrain, I’ve finally stopped being so narrow-minded. The reason? Many (if not most) organizations lack a sufficient motive to establish an enterprisewide SOA as I’ve been defining it. Yet if you broaden SOA to include an application-aware infrastructure, the SOA value proposition becomes more compelling.

The main motives for both the business side and IT to embrace SOA are quicker, cheaper application development and low-cost integration. Instead of writing a component or an application, you can call up that component or application from the app you’re developing and avoid redundancy. In the process, you’ve probably integrated two systems with relatively little pain.

But the payback for the business side can be elusive in the short term. In fact, it actually requires more work to develop applications in a service-oriented way if an enterprisewide SOA isn’t already in place. The problem is that initiatives for the greater good of the organization don’t jibe with the usual application development process. Normally, the business side asks IT for particular app functionality and creates some sort of specification for just the features it needs. They don’t allow for all the other applications that may share the same services, which is how an SOA needs to be designed.

So SOA needs an enterprisewide motive. And what is it that has nearly every organization in a mad scramble? Regulatory compliance. The storage and retrieval requirements of the Sarbanes-Oxley Act and the security demands of the Health Insurance Portability and Accountability Act require both ironclad enterprisewide processes and special infrastructure in the form of storage and security solutions. And without question, that infrastructure will become increasingly application-aware.

The past couple of years have seen a new breed of application-layer, XML-aware security appliances—from the likes of F5, Forum Systems and DataPower—that inspect packets at a deep level and block suspicious traffic. But these companies are going beyond XML firewalling. DataPower, for example, offers a vertical tool that binds Web services security to XML financial schema. And Cisco’s Aon initiative is supposed to result in a new line of XML-aware routers this summer. With real-time inspection of XML traffic, such devices will be able to identify compliance-related content and make sure it’s routed to the correct repositories, such as EMC’s Centerra for write-once archiving. Imagine an application-aware infrastructure that makes enterprise compliance transparent and relatively low maintenance. Most enterprises would give their eye teeth for that.

As a result, the real driver for SOA may come from people who see the value of an application-aware, SOA-connected infrastructure as the best long-term compliance solution. For that to work, of course, enterprise apps need to be part of an SOA. Is this the tail wagging the dog? Maybe so. But fear often turns out to be the best motivator, and if that means compliance and its related infrastructure come first, so be it.