A move toward SaaS (software as a service) platforms makes a lot of sense for a lot of reasons. The economics of using someone else's computers and applications in a shared environment, with all the advantages of private access and none of the pain associated with having to manage all the parts and pieces, are undeniable.

But is it realistic to believe that organizations can simply use a major application suite without modification? Whatever happened to all that custom code the IT department's programming staff created to make their version of the applications fit exactly into the company's way of doing business? Is it all simply justification for programming jobs?

To look at what the SaaS vendors present, it would be easy to think that businesses can simply set up an account on a shared instance of a SaaS application and get to work. Certainly the success of an application like Salesforce.com is testimony that there really isn't all that much difference between one implementation of a CRM system and another.

Or is there simply so much flexibility built into the system itself that it can handle any variations users decide they want?

Extensions and APIs go a long way toward allowing enterprises to make SaaS applications work in ways they need them to. But at some point a CRM application is a CRM application. The fact that Salesforce.com is so successful is partly a testimony to its engineering prowess, but it may be equally attributable to the fact that the application is about as generic (though vitally important) as they come.

At the other end of the spectrum is the SaaS-based transaction system that manages applications like EDI. Of course, EDI is a standard data exchange format based on the X.12 standard. But the variations in that standard are infinite. Every retail organization has its own modifications to the standard, and every vendor needs to be able to communicate with the retailers if it wants to be able to accept orders from them. The complexity comes from the fact that suppliers may need to process orders from hundreds of retail customers, each with his or her own version of the EDI purchase order format.

SaaS-based EDI systems exist in the middle of these transaction flows and translate purchase orders into formats acceptable to hundreds of suppliers, then take the shipping transactions from the vendors that fulfill the orders and translate them back into formats acceptable to the retailers. The permutations are seemingly unending. But, in fact, they are finite.

Once a mapping has been developed to handle a retailer's purchase order peculiarities, it doesn't need to be done again. And once a supplier's shipping notice has been mapped to the retailer's format, that job is done as well. In the end, there are only so many customizations necessary. And though retailers change their formats over time, there is only a certain amount of work required to keep up with the changes. One programmer's efforts used by a SaaS-based EDI provider can support hundreds or possibly thousands of customers.

As Jeffrey Kaplan, principal analyst with ThinkStrategies, a SaaS analyst firm, puts it: "Traditional customization has been a black hole for most organizations which has too often failed to achieve its business objectives. SaaS solutions are becoming increasingly flexible. While they will never be as customizable as legacy applications, a growing number of organizations are willing to sacrifice infinite customization for reasonable configuration capabilities, more rapid deployment, lower hidden development/support costs, greater utilization levels, quicker time to value, and higher satisfaction."

Will SasS applications produce a world of homogenized organizations that all use the same data structures and processes? And if it did, would that be a bad thing? Customization is a great thing and, in some cases, a necessity. But if economies and speed of deployment reduce the amount of customization done on enterprise applications, I think everyone wins.

— Scott Koegler was a CIO for 15 years, and has been writing about technology for the last 18 years. He is editor of www.ec-bp.org, a newsletter that addresses supply chain technologies, and EDI in particular. You can contact him at scott@koegler.net.