SaaS Blogs

As usual, Fred Chong has posted another great article, this time directly addressing the space of what he calls an SDP, or “Service Delivery Platform.” In short, an SDP is a platform that allow for the deployment and delivery of a SaaS application. This notion of SDP is what will be one of the driving forces behind SaaS adoption. A good SDP disconnects the delivery model from the application, allowing application developers the ability to concentrate on their application functionality and not SaaS intracacies. Imagine how much it would suck if developers had to write/rewrite kernel or I/O code everytime they wrote an app. They don’t (at least not anymore). Why? Because nowadays, that’s the duty of the operating system. Because of SDPs, more developers and software vendors will be able to realize SaaS as a delivery method, and most likely make it their delivery method of choice.

Fred makes some architectural references in his post. It’s important to realize that the architecture of an SDP will be a defining factor in its success. Generally, I do not take the technologist approach of closely relating success and technological prowess of an offering. After all, we have many examples of junk technology that is popular (MySpace, anyone?) and stellar technology that remains in the deep dungeons of SourceForge. However, the architecture of an SDP is what will really allow aggregation of economies of scale and a “trickle down economics” sort of value to end users that are consuming the application functionality. As the end users absorb the savings dictated by a good architecture, the popularity of the applications will increase, thereby bolstering SaaS as a delivery method.

One other quick note is Fred’s mention of having to modify an application so that it could take full advantage of an SDP. This is important because it outlines the effort required by a vendor to be able to deploy applications on an SDP. Keep this in mind, we’ll revisit the topic of effort in the future.