Spin On Demand

The industry is abuzz with terms like “on demand”, “software-as-a-service”, “open source” and “service-oriented architecture”. What do all these mean, and more importantly, what does this mean to the future of how we deliver business applications to the enterprise?

Like many questions that seek to understand the road ahead, it’s often helpful to look to the past. Are there any trends from which we can draw insights — clues for how the software model will evolve?

The origins of mainstream business computing can be traced back to the use of mainframes in the mid 1900’s. Interaction first occurred via punch cards, which evolved to dumb, “green-screen” terminals. And while much of this technology will appear nonsensical to today’s Facebook generation, the key concept here is that all the hard work (computation, data storage) was managed by the mainframe. Think centralized, command & control.

The invention of the microprocessor and the advent of personal computers introduced a major power shift to end users. Business analysts were empowered with the ability to process more information more efficiently ever more independently. Think distributed, free-for-all , digital democracy (or anarchy, if you’re an IT administrator).

In simplistic terms, the result was a chaotic, non-standardized, multi-silo’d mish mash of data and processes. As server technology advanced, IT managers united to reign in control, delivering applications using proprietary server-client models in a bid to standardize information management and business processes, not to mention enhance security and asset management. Think centralized, command and… well, you get the idea.

As IT departments struggled against the tide, enterprising 3rd party firms would enter the fray to provide variations of the same theme: to control costs, companies looked to outsource the management of their on-premise infrastructure to specialized IT service vendors (IBM, Siemens). While this maneuver may have impressed investors and worked short-term magic on the balance sheet, in reality, it did little to address the root issue of many organizations – and that was IT’s increasingly deficient ability to respond to rapidly changing business needs.

The introduction of the Internet, accompanied by its death warrant on mass media, only served to deepen this gap. Practically overnight, Sales & Marketing departments were left struggling to understand how the game had changed, let alone know how and where to effectively spend their advertising dollars. Relationship marketing and customer-centric strategies were the names of the game now, and they would need innovative technology to win.

Need a CRM solution, but the IT department is too busy maintaining the ERP, fighting the latest virus, troubleshooting network issues, playing with VoIP and upgrading (read: fixing) servers? (Let alone have the incentives, resources and skill sets to help with a CRM project?) Enter the Application Service Provider (ASP). Having worked for an ASP, specializing in Sales Force Automation (SFA) and Customer Relationship Management (CRM) consultation and implementation, I had a firsthand perspective of how ASPs could add value to the enterprise. Successful engagements always shared the same characteristics:

• The ASP has a deep understanding of the client’s Sales & Marketing business challenges and needs.
• The client’s Sales & Marketing organizations understood the need for change.
• The client’s IT department recognized they needed a partner to deliver innovative, new technology to support this change.

It goes without saying that solid business fundamentals (industry knowledge, strategic vision, operational excellence) are critical for ASP success, but what about the tools? I’m referring to the actual programming tools that we used to build business applications that would serve as the platform for CRM and SFA. If we relied on building our tools from scratch using conventional programming languages (COBOL, C, Fortran), we would run the risk of being just as slow to react to changing requirements as the traditional IT departments we wanted to displace. The answer would be found in RAD tools, short for Rapid Application Development.

Platforms such as IBM’s Lotus Notes/Domino, recognized more for its corporate email, provide a foundation that includes a proven user security model, user interface, mature data synchronization engine and a graphical programming interface (a la Visual Basic). In essence, programmers didn’t have to worry about creating and maintaining these elements included in the platform’s foundation. They could focus more on building and creating the business logic and features demanded by the business.

The benefits of this approach to the client are numerous; the onus of maintaining the underlying infrastructure of these business applications is effectively the ASP’s responsibility. Total cost of implementation is often less expensive than an internal undertaking, with far greater returns on investment. It’s an efficient model, especially if it is supported by a solid framework of incentives. Based on annual service and licensing agreements, the ASP is incented to continually minimize development and infrastructure costs (remember, all the overhead of maintaining servers, ensuring service levels, managing hard disk space, etc. is on the ASP).

This brings us to the present day. We’re inundated with terms like Software-as-a-Service (SaaS) and Service-oriented Architecture (SoA). In fact, SaaS is just a fancy descriptor for many web applications we already take for granted, including web-based email (Gmail) and social networking apps (YouTube, Flickr). From the perspective of the enterprise, successful SaaS examples include web-based CRM tool Saleforce.com, and web conferencing tool WebEx. All of these applications have something in common – they are all delivered over the web, and don’t discriminate over who is using their service.

Despite the emergence of SaaS, there has been minimal impact to ASPs that focus on delivering truly customized, turnkey business solutions. SaaS applications tend to be designed for large, diverse audiences with minimal tolerance for customization. But this is all about to change. Recall that ASPs, especially when experiencing growth, face significant infrastructure costs as customer needs expand (servers, storage area networks, hosting and bandwidth, IT staff, etc.). All of these factors, when stressed, lead to a diminished level of responsiveness to the client. But what if all of these factors could be abstracted? What if, similar to how ASPs removed business application infrastructure from its client, it could be removed from the ASP? What if a 3rd party service provider could enable the ASP with an on demand application development and delivery infrastructure that is more cost effective and has more benefits? This is the essence of Platform-as-a-Service (PaaS), and in my view, represents the next evolutionary step of the business application development and delivery model.

The concept of PaaS is still very new. In fact, at the time of this writing, there isn’t even a Wikipedia entry for it yet. And the very concept of moving to a web-based application development environment almost requires a leap-of-faith of sorts, until you consider the real benefits:

• Scalability: Scaling effectively (instantly, say, from 100 to 100,000 users) introduces logistical and financial challenges for the average ASP.
• Zero Hardware Maintenance: No need for the ASP to maintain an on-premise server farm, maintaining production vs. development vs. testing environments, upgrading software, patching security holes, performing data backups, the list goes on.
• 99.99% up-time: Factors both in and out of the ASP’s control determine up-time and availability. How many ASP’s can claim better up-time vs. Gmail or YouTube?
• Multi-tenancy: Leverage the infrastructure designed to support large-scale enterprise users that number in the hundreds of thousands, for clients of any size. Bandwidth and performance concerns are so last year.
• RAD 2.0: Enhanced Rapid Application Development tools (security model, user interface, etc.) provide ever more flexible, inter-operable features and functionality.

Consider, for a moment, traditional software giant Adobe’s initiative to introduce a web-based version of its flagship product, Photoshop, and the concept of taking traditional application development tools to the web becomes more palatable.

So who are the major players in PaaS? They’re not who you think: it’s not Microsoft. It’s not IBM. It’s not Oracle or SAP. Surprisingly, the only company delivering on the promise of PaaS today is Salesforce.com through their Force.com service offering. But perhaps it’s not that surprising, given that the CRM on demand upstart has the most to gain and the least to lose. Microsoft has a PaaS -like initiative in the works currently dubbed “Oslo“, but it’s years away. IBM’s “Blue Cloud” initiative reads more like a solution for would-be PaaS providers… and it’s years away. Neither of these tech giants are likely to be overly excited about the impending conflict with their existing (and very profitable) traditional software and service models. There’s been buzz of an Oracle buy-out of Salesforce.com, but don’t rule out Google or Microsoft.

Salesforce.com certainly has a sizable head start in the PaaS arena, but look for competitors to emerge as more success stories and noise is generated in the coming months. My recommendations to anyone considering Platform-as-a-Service:

• Put Salesforce.com on your watch list.
• Add PaaS to your technology roadmap and assign a resource to start the process of investigation and education.
• Consider a small-scale pilot project.

ASPs (or any provider of software-based business solutions) will ultimately need to adapt and evolve as PaaS matures. To ignore it would risk irrelevance and displacement by up and coming companies with ever more dynamic and innovative methodologies and.. well, you get the idea.