Considerations of creating a successful SDP

Hello

I’ve recently joined a BPO (Business Process Outsourcing) provider company which gives me an excellent opportunity to put my knowledge of SOA and SaaS in action. So I guess that’s what is going to shape my future posts here.
Well, here is one.
SDPs (Service Delivery Platforms) are playing almost the same role for delivering Software as a Service (SaaS) as Operating Systems do in desktop applications’ development and deployment. Rather than requiring each application to create the full stack of subsystems needed for it to run, an operating system provides an infrastructure through which general purpose services are reused. The following picture depicts the natural and ongoing process of extraction and generalization of functionality from application into frameworks and from there into the core platform components which leads to the improvement of economies of scale.

Figure 1: Borrowed from Microsoft's Architecture Journal

There would be the same concept in various levels offered by SDPs. There are different factors that can be used to specify the level of success of an SDP. What I mean by the Level of Success is SDP’s effectiveness and scalability, and the ability to provide highly reusable services – for example through an SDK - that will make the implementation and maintenance of SaaS-delivered applications less intensive.
Observation of existing SDP offerings seems to indicate that two most important factors are:

• Services breadth: the completeness of the platform; in other word, the support for different stage of SaaS-delivered application life cycle (following picture)
• Services depth: the degree of sophistication of the services it provides.
  

Figure 2: Borrowed from Microsoft's Architecture Journal

Hence there are two aspects that SDP implementers (mostly traditional hosters) and ISVs (Independent Software Vendors) who develop and deploy the service should take under consideration:

• Different Application Archetypes; Business applications can be classified in different archetypes based on their characteristics and requirements. Two examples of these archetypes are OLAP and OLTP. Each of these application families has its own constraints and characteristics. For example OLTP will optimize for low latency, whereas latency for OLAP systems is not as important. The infrastructure to implement and support each is significantly different.
  The point is that SDP’s effectiveness is pretty much dependent on the archetype served. The more knowledge of the application an SDP has, the greater its ability to increase the efficiency of running and operating it, and the greater the degree of sharing.
• Patterns and Frameworks used in design and development; no matter what archetype an application is bound to, it can follow a pattern in design or development or it can use a framework to implement some of its services. An example of common, standard and widely adopted application infrastructure framework is Microsoft’s Enterprise Library.
  I would say a valuable SDP provides an SDK including documentation, samples and even some basic tools for ISVs enabling them to develop their software using known patterns and frameworks. This way the SDP has a much increased ability to automate common procedures and offer more advanced operational management capabilities. Thus, finer-grain tuning, customization and troubleshooting will be available.
  Additionally, hosters can offer a higher range of differentiated services with different monetization schemes. For instance, the hoster knows that all applications will log run-time exceptions. So basic run-time exception logging can be offered in the basic hosting package, and advanced logging, notification and escalation could become a premium offering. Notice that with this approach the ISV application doesn’t change, because all the logic resides on the SDP side.
  

Figure 3: Borrowed from Microsoft's Architecture Journal