There has been tons of talk over the last few years about Software as a Service (SaaS). Quite frankly, I am not a huge fan of the idea, mainly because I do not like to put that much faith in third-party vendors (TPVs). The idea itself is not bad, I just do not trust them, mostly from my experiences both using them and working for them. For example, this weekend I finally brought my DNS and SMTP servers “in house” (as in, onto my server in my closet) because my ISP was too incompetent to run a DNS or SMTP server capable of looking up “www.techrepublic.com” or sending e-mail to “cnet.com” and “techrepublic.com” addresses. I do trust a TPV to provide a service that is commoditized, can be easily replaced if I have problems with the vendor or their product, and is not an absolutely critical part of my business. This brings me to my point regarding SaaS — well, a point or three about XML and software architecture.

“Ages” ago (circa 2000), what we currently call SaaS vendors were called Application Service Providers (ASPs). There was a huge run up on the stock price of any company claiming to be an ASP. Everyone claimed that ASPs would knock traditional software vendors off of their thrones. And guess what? The ASPs went out of business. The companies that survived provide services, such as code components and databases of data, or sell a component of a bigger system.

When XML came into its own, there were a zillion and one big ideas for it. Remember UDDI? I vaguely do. The idea was that application developers’ stuff would be so standardized through the magic of XML that we could look up a service in a UDDI “phone book,” automatically connect to it, grab the WSDL, and our applications would instantly adapt to a new provider. Our application could pick a vendor in real time, based upon ever-changing factors like feature set and pricing. What a dream. Microsoft shut down its UDDI server recently. No one ever used UDDI.

What we got instead was a smattering of (hopefully) industry standard XML specs, like HR-XML for the human resources industry. The problem is, when all of the input and output your application deals with is defined by the industry, so is your feature set. Just as you cannot write an application that parses the Word format and do something that Word cannot, you simply cannot provide functionality that the industry standard does not support. This kills innovation on the part of the vendors; the only “secret sauce” they can brew up is better processing on their end of the deal, customer service, pricing, etc. In other words, industry standards for XML data exchange drive commoditization. This is a recipe for mediocrity. The alternative is just as bad. If a vendor bucks the industry standard (or does “embrace and extend”), you get a combination of painful integrations and vendor lock-in. Neither of these are things that anyone wants.

After we started seeing vendors moving to providing “services” over XML, there were two new fractures in the industry. The first was the rebirth of ASP as SaaS. The other is “Web 2.0.” Don’t believe me? They both address the problem of being innovative, while reducing the customer’s pain of dealing with something that works outside of the industry standard XML specifications. SaaS basically says, “Hey, forget about integrating with me, just hand over all of your data to me through this Web site, and I will take it from here.” “Web 2.0” (side note: I still have a hard time taking this term seriously) is a different twist: “Since I follow a format that may or may not be standard, just make a reference to me, and not only will I handle the processing, but I will handle the presentation layer too!” To put it another way, SaaS removes the need for integration, and “Web 2.0” makes the integration as painless as possible.

Where does this leave us developers? Well, I think it leaves us in a great spot. If we start taking a serious look at service-oriented Architecture (SOA) at our application/business logic layer, our applications have prime marketplace positioning. We build out our own presentation layer on the SOA architecture and sell SaaS. We can sell the bare Web service (or the components to hook into it for an additional fee) to customers who would rather do the presentation themselves, whether it be a small portion of the functionality or the whole business layer, depending upon the customer’s needs. And we can build “Web 2.0” components that represent individual, discrete functions to be sold to the customers that want zero integration of services without buying the whole application. And for anything that does not need to expose a public interface (the “Web 2.0” and SaaS pieces), we can do our innovation there, unhindered by the need to follow the industry standards for everything.

While I am not too keen on XML for technical reasons (particularly for applications that will never be publicly exposed), it does allow us to provide true services to our customers. As a result, it increases our sales opportunities, provided that the application is carefully architected. Until the boom of the services industry, architecture was primarily a technical concern. But now, the overall system architecture is something that can make or break the sales model. Building your application with SOA principles can leverage your existing code to support sales that a strictly “Web 2.0,” SaaS, or traditional model could never get on their own, and expand your potential market significantly.

J.Ja