To give you good sense of what Platform-as-a-Service would mean I will start with an analogy with a relevant topic.

Say you are FremantleMedia and you are in the business of producing and hosting American Idol. Since your core business is creating and delivering an entertainment programs, building and owning an auditorium/theater probably figures last in your list. Your other choice is to rent the Kodak Theater. With your rental comes all the necessary components you need to create and deliver the show – namely the  studio, the podium, the green room, A/V system, the lighting, the chairs, the ticket booth, the tiered seating, the rest rooms, parking lot.. you get the idea. It even comes with accommodations for the different classes of audience (Think customer segments) children, aged, families, physically disabled audience. So you did what your core competency was created, delivered the program in the theater. You did not have to go through the hassle of building a theater, owning it and incurring the overhead of managing and maintaining it. The theater by itself, might have turned to the electric utility, water district, security companies for delivering the various needs you might have needed. But all that came as a package as part of renting the theater.

Platform-as-a-Service seeks to deliver a similar experience to companies using and creating web based applications, to meet their business needs.

Platform-as-a-Service (PaaS) at its core comprises of a computing platform that facilitates the development and deployment of web application without requiring companies to build, configure and maintain the infrastructure that hosts it.

A best-in-class Platform-as-a-Service must include

1. Application Development Technology Framework: A robust application development technology framework built on a technology that is widely used. Most widely used technology frameworks are built on J2EE, .NET, PHP. The framework must support the management of the entire application lifecycle of design, development, testing, delivery, change control and update of software applications.
2. Ease-of-Use: One of the key selling points of Cloud Computing is that the complexity gets masked from the clients. So PaaS should be no different. A Platform-as-a-Service should come with easy to use WYSIWIG tools with pre-built widgets, canned UI components, drag-and-drop tools and support for some standard IDEs. Eclipse, NetBeans, InteliJ to name a few. It should facilitate rapid, iterative Application Development.
3. Business Process Modeling: A strong business process modeling framework that allows you model your business process and build the application around it. Remember, the new age applications should be built using model-driven, agile methodologies to afford you the ability to quickly adapt to the rapidly changing dynamics in a global business landscape. A good platform must support robust digital and human workflow capabilities and allow for rich collaboration as part of the business transactions that would be conducted in the application.
4. Ubiquitous: Companies these days have extended workforce in the far extremes of the world and they operate round the clock. The platform of choice should be accessible and available (at acceptable service levels).
5. Scalable: Businesses are dynamic and the workforce is elastic with all the M&As, divestitures. The platform should be smart enough to leverage the elastic capacity from the underlying infrastructure, when put under stress of  volume data and/or user load. In addition, it should also address the needs around State Management, Persistence, Caching, Localization, Accessibility, Cross Browser support while abstracting it from the application development team.
6. Adaptive: Technologies change by the day. Mobile is increasingly becoming platform to deliver atomic services. A best-in-class PaaS should provide ability to develop an application and deliver it on multiple run time platforms besides web. Mobile and Rich Client capabilities are becoming increasingly the norm.
7. Secure: Should I say more? The more things we push on the internet the more we offer to the hackers. To effectively combat the threats, the platform should address things like Cross-site scripting, SQL Injection, Denial of Service, Encryption of traffic and make it ingrained into the application development. Additionally the platform must support  single sign-0n capabilities for you to be integrate with your other on-premise applications or any cloud applications.
8. Inclusive: The platform should provide the ability to include/embed/integrate other applications built on the same platform or others. In fact, support for integrating to third party services using REST, Web Services or any other RPCs should be built in should be a minimum requirement in evaluating Platforms.
9. Portable: Business dynamics change and there is a distinct possibility that you might want to move your application from one Infrastructure-as-a-Service provider to another that your acquirer has standardized on. The platform should be agnostic to the underlying infrastructure and allow companies to move the application to another infrastructure. This might also be the case as you scale from a smaller vendor to a larger vendor as your business goes from being a million dollar company to a billion dollar company.
10. On-board Tools: Considering that most companies transition existing applications to the platform, it is fair to assume that they would also like to bring a subset of data with them. To easily and quickly migrate data over from the legacy on-premise application to the application based on Platform, bulk import, transformation tools would be a necessary part of the toolkit that comes with the platform.

PaaS Landscape

If you look at the current landscape, you will find two sets of players – the big kahunas in  Force.com, Microsoft Azure , Google App Engine and some niche nimble successful smaller ones like LongJump, Engine Yard and SaaSGrid.

Who needs it?

The two key consumers of Platform-as-a-Service would be

1. Small ISVs/Startups who work under tight budgets and scant resources. They cannot afford to invest in a dedicated team building a platform. Since majority of them operate on a atomic idea and opportunity window, time to market is critical for them. PaaS provides them a quick way to get their product to market.
2. IT shops laden with the inventory of fragmented legacy apps (i-have-an-app-for-that?) which are band-aided together. Invariably most of those applications will be written in some outdated technologies like ColdFusion or Foxpro. The challenge companies would be facing would be dwindling knowledge about the application and not being able to retain that “special talent” who built that application and finally deciding to re-write them.

As I mentioned in my last post, specialized tasks are best done by a specialist. And that is more apt in the case of Platform-as-a-Service than others.  Building a Application Technology Platform is highly complicated stuff and is not for the regular “Joe the Geek” who hacks some early version of an open source software and creates a small bespoken app.  It takes a lot of foresight and architectural skills to create an adaptive, scalable platform and support it.

So after establishing the virtues of PaaS, let us look at some of the hurdles that are preventing a wider adoption by companies.

1. Transition: Companies have a lot of legacy applications that are currently in use.  For better or for worse, they work and help run business. There is no way to migrate them as is to a Platform without rewriting them. Any new application requires new investment. With IT budgets no longer the same as the glory days, CIOs will have tough time wiggling out a slice of the budget for a new application. Any tools that will have Rapid Application Development and data migration tools that can reduce the upfront work and cost will surely help get past this hurdle.
2. Portability: Each PaaS platform comes with a underlying IaaS platform that they have partnered with. Already finicky, companies that bet on a particular platform would definitely like their applications be portable to other Infrastructure that is either their corporate standard IaaS or internally hosted infrastructure. The PaaS platforms available today are not geared to be  a-platform-to-go. Also of critical importance is ensuring that platform based on a widely used technology. Try getting a Ruby-on-Rails programmer or architect in a offshore country. They are expensive and scant.
3. Viability: Outside of Force.com, there are not many successful PaaS platform companies that have established a track record. Coghead’s PaaSing is still fresh in memory. Google and Microsoft have announced  me-too platforms but it remains to be seen if there is enough focus on it amidst the hundreds of other things they both try to do. The rest are small vendors who will f ind it difficult to get past the corporate attorneys and their terms.
4. Credibility: While there are many vendors claiming their platform as the nirvana for all things application development in future, there are few that case studies of real critical applications being built on their platforms. Without that, a pure-play PaaS vendor will have a tough time convincing the CIOs of expanding their technology footprint to yet another platform. In the case of Salesforce.com, their success can be attributed to the fact that they are a SaaS company, that owns a key business entity in companies – i.e., customer. With that under their management, it is easy to cajole companies to build extension applications around that key entity.
5. Governance: As with all things cloud, the elephant in the room is governance. With SaaS, it is clear whose throat will get choked if things fell apart. With Platform-as-a-Service it gets a little tricky. If things fell apart, is the developer who built on the platform going to be blamed or the platform on which it is built or the third party infrastructure that it is built on going to take the blame. Here are three things that I think the would have to happen to allay those fears
   1. An independent body akin to Better Business Bureau model that grades the platforms for their reliability.
   2. Ownership of SLA by the Platform provider irrespective of who the infrastructure provider is.
   3. Disclosure of the underlying technologies used in the platform that corporate architects or third party reviewers can review to get comfortable. Under strict non-disclosure obviously.

If you are a startup

As Brian Jacobs (@brian_emcap), General Partner at Emergence Capital Partners, pointed out to me, one of the most important considerations for startups thinking of building their application on a standard Platform-as-a-Service is thinking about their eventual exit. Here are couple of things to get you thinking on that front.

1. You might limit of your chances of getting acquired based on the platform you decide to base your application on. For example: A company built on Force.com might not be appealing to a company that has its own platform like Microsoft or Google.
2. The issue of Intellectual Property might get a little challenging. You will have to sort that out before derivative work on the platform is created. How does the ownership transfer happen? Case-in-Point: If SAP acquires a company built on Force.com does it get to take the application and customers to its own platform? or more importantly can it?

In conclusion, there are is a lot of value to be derived from a platform-as-a-service but more questions need to be answered.