Jeff Kaplan’s rundown is comprehensive, both in the headline events and announcements as well as in its aim. “Salesforce.com used the event to beat back the recent efforts of Oracle and Microsoft to gain a share of the Cloud Computing market with a new round of initiatives aimed at building on its phenomenal momentum and success.” He also examines the impact of several announcements, including the unveiling of Database.com, demonstrating salesforce.com’s dedication to the maturation of the force.com platform in the developer world.

• Soaring Clouds at Dreamforce

Phil Wainewright examines the impact of Database.com on the competitive marketplace “as Marc Benioff throws salesforce.com’s cloud platform weight around.” Smaller PaaS competitors will have to work harder to differentiate themselves in this new landscape, he notes.

• PaaS Bystanders Squished as Database Giants Spar

A day later, salesforce.com CEO Marc Benioff announced the acquisition of Heroku, the Ruby based application development platform, a move that should add even more developer credibility to the platform.

• News Analysis: Salesforce.com Buys Heroku for $212M – Shows Commitment to PaaS

Quietly, on Tuesday morning, FinancialForce acquired a PSA solution from application builder Appirio. “Importantly, this is the first complete ERP/PSA/CRM solution built on the same platform” and gives service organizations the ability to “run all of their core systems on a single solution.”

• FinancialForce Acquires Appirio PSA

Reid Carlberg, developer evangelist for salesforce.com and excellent tweeter (@ReidCarlberg), delivers his roundup of the event and gives attention to some of the unique touches that made a 30,000 person event feel so personal, including his impromptu one-on-one sessions with fellow platform users, Reid monitoring Chatter to answer questions, and personal code consults, all of which inevitably led to him losing his voice. Reid embodies the enthusiasm and forward-thinking that everyone brings to Dreamforce and makes Dreamforce such a success.

• Once Upon a Dreamforce

The Question Without an Answer

What exactly is “Cloud Computing?”  The term will probably never be fully fleshed out in terms of a common definition, and at the end of the day that’s fine with me. Yes, we need to put structure around the term and the industry, but as we noted earlier in the year with a post about cloud maturity models, we run the risk of painting ourselves into a corner if we try too hard to make things fit neatly into buckets that we can easily classify and categorize. Taxonomy will be key to understanding and adopting cloud computing, but I’ve become convinced that in order to truly embrace the cloud, we must…

Embrace the Abstract

I had the opportunity to speak at Interop Las Vegas this year with Rick Nucci of Boomi and R. “Ray” Wang of Forrester Research, and when I made the statement that “cloud computing is the technical manifestation of Service Oriented Architecture,” I realized that I had found the unifying principle of cloud-based solution design; unifying both in the sense that the promise of SOA finally has the technology behind it to transform it from philosophy to practical design pattern, as well as in the sense that the term “cloud computing” itself was being co-opted in much the same way that traditional software vendors co-opted the entire concept of Service Oriented Architecture to sell middleware throughout the decade.

Cloud computing may mean many things to many people, but in the end its full potential can only be realized if we stop trying to think of it in terms of the “known known” and embrace the the “known unknown.”  More importantly, when we think about the cloud and applying SOA design principles, we cannot continuously innovate and drive value if we are traversing connections inward to rationalize patterns and explain the abstract with the known; we must restructure our patterns and embrace the abstract in an attempt to forge new connections by moving outward beyond our comfort zones. The next generation of system design is less about creating code, and more about assembling services – innovation through extending value in what already exists rather than inventing new sources of value.  In terms of practical application, this means moving up the stack and…

Learning to Describe Rather Than Prescribe

An interesting pattern that I observed throughout 2009 is the continuing tendency to try and reinvent the wheel despite the fact that not only has the wheel already been invented, but it’s right in front of our eyes and meets our needs 99 times out of 100.  I saw this over and over with Salesforce CRM and Force.com projects; the value of using Platform-as-a-Service is that someone else (or more accurately, thousands of other people) has already thought about just about everything you could possibly need in a data model, user interface, and business rules.  And not only have they published just about everything you could possibly want in an easily configurable platform, they host it and manage all of the operational details such as backups, upgrades, and security. Yet time and again I encountered teams that thought that their way of doing things was better, and would go down the path of trying to build Salesforce on Salesforce before realizing that the same outcomes could have been achieved by spending a little more time upfront optimizing business processes and making minor configuration changes than going down the path of creating complex custom workflows, classes, and user interfaces to achieve the same end.

Some case studies are extreme, such as the support manager that duplicated Contacts across multiple accounts and assigned multiple portal logins to customers – in one extreme case 101 times – rather than setting up sharing rules properly; I don’t have to tell you what a data quality nightmare that ended up being.  In other cases, it’s simply a matter of building rather than reusing what’s already there, resulting in hard-coding of attributes and logic that should be dynamic and extensible.

What I’ve come to realize is that there is a conceptual barrier that we need to overcome when it comes to metadata and other abstracted entities; because multitenancy architecture and SOA are reaching such a pervasive state, we must shift our thinking to describe what already exists rather than trying to recreate it.  Entities exist once and in perpetuity – for example, there is only one of you in the entire world and you cannot be recreated on demand – thus our ability to provide context necessarily requires us to describe the entity in a manner that provides value to the application; the ability to describe entities with deep domain knowledge and create relationships to other entities that enrich the value of the data set will become an important competitive differentiator.

This will take time and a great deal of trial-and-error until we get it right, but in the end it is the only way to leverage the tremendous potential of core cloud computing architecture patterns; our entire concept of producing and consuming services has to change, which leads me to the conclusion that…

SaaS is Dead…Long Live SaaS

Granted, the title of this blog predicates from the acronym for Software-as-a-Service, but as cloud services mature and the traditional technology stack gets blown up and reassembled, the entire concept of “software” shifts from the self-contained, monolithic packaged application to that of a delivery framework. Software was invented to make hardware useful; hardware is abstracted in the cloud and we no longer write code down to the kernel level – we assemble, configure, and code to the layer of abstraction of the specific cloud platform.  The term “software” will gradually fade from our lexicon.

This was the philosophy that drove the Java language and multi-platform virtual machine concept, and will continue to evolve with next generation rich Internet application frameworks such as Adobe Flex / AIR.  What we will see moving forward is the continuing shift from desktop software that interacts with the cloud, to ubiquitous frameworks that consume data and logic services from the cloud and leverage the processing capacity of the local machine to enhance the user experience.

2009 and its economic and sociopolitical malaise are now behind us, and by all accounts 2010 will be the year of the cloud. While the technology and the terminology of the cloud have permeated the mainstream, it will take significant shifts in thought processes and design patterns before the cloud can be fully leveraged.  Here’s to a great New Year and the hopes that the likes of Microsoft and other relics will accelerate their fade into obscurity and stop trying to steer the cloud discussion back into a box.  Until next time, here are some…

Other 2009 Wrap-ups and 2010 Predictions

Jeff Kaplan: Key Challenges Facing Cloud Computing in 2010 and Beyond
Phil Wainewright: Tips from 2009 for a prosperous 2010
Dave Barry’s year in review: 2009 (Humorous, non-cloud related)

With regards to the testing aspect of Force.com application development and delivery, I have observed some emerging patterns that warrant further study and discussion:

1. Unit testing is real-time and automated.  The Force.com IDE for the Eclipse SDK has been a solid development tool for some time, but the real-time feedback that you get using version 16.0 (Summer ’09) of the IDE with the Eclipse Ganymede release (3.4.x) is of tremendous value.  Granted, the Salesforce API will let you know if there is a problem with your code, but now we’re seeing potential issues called out in Eclipse prior to pushing code to Salesforce.  If you think of unit testing in the traditional sense, where you are testing the validity of snippets of code, the very act of the Salesforce API accepting code that you push to the environment provides immediate validation in an intelligent and automated fashion.  And with the line-item feedback provided by Eclipse, you can catch code validation issues long before saving to the server, significantly reducing the time required to track down and fix invalid code.
2. Integration testing has combined with QA to become a metafunction.  I will be the first to admit that I initially viewed the Apex 75% code coverage requirement imposed by salesforce.com as more of an annoyance than anything.  Now I have come to see test classes not as a necessary evil in deploying apps to production environments, but as a tremendous opportunity to bundle elements of integration testing and end-to-end application QA into a single overarching process.  While most developers dread having to write Apex test classes, we include them in our design specifications as a best practice.  If you think about it, what we are doing is taking the use cases that are fleshed out during the design process and building out test cases from the onset of the development effort; this is a fundamental shift from the traditional role of QA in outdated waterfall-based methodologies that build and execute test cases and QA plans only after development, unit testing, and integration testing are completed.  I have worked with far too many organizations where QA was considered an albatross – the development effort was complete for all intents and purposes, the finish line was in sight, and here comes QA adding weeks, if not months, to the Gantt chart right before that final milestone.  By making QA an iterative process that is tightly integrated with development processes, there are no downside surprises at the end of the development cycle; QA is already done along with integration testing, and it can be argued that the most important aspect of this is that QA is no longer a discreet process – it becomes a living, breathing overlay of the entire development methodology, producing test classes that live alongside the production Apex classes.
3. User Acceptance Testing is a combat sport. What we have found with many Delivered Innovation clients is that if a prototype meets functional requirements, it’s considered “good enough” at that point.  The reality of the situation, 9 times out of 10, is that “good enough” is not quite good enough for a number of reasons.  Namely, demonstrating a prototype in a controlled environment with use cases that are designed to show successful outcomes does not flesh out the true functional capabilities of the app; only when users start beating on an app do we start to see where the stress points are in the functioning of the application.  This is why we encourage what we half-jokingly refer to as “break testing” – we encourage users to “break” the app by any reasonable means.  Realistically, we want this to happen upfront and not two months after production deployment.  Another reason why UAT becomes critically important in the testing process is because the execution of test classes is constrained by governors and limits far more conservative than production governors and limits.  For example, while you can retrieve 10,000 records in a production (non-trigger) SOQL query, you are limited to 500 records when executing tests.  While you may be able to write test classes that execute within governors and limits, once you release the app into the wild you just never know when Salesforce users will find the “unknown unkowns” and use the app in a way that could not have been anticipated…followed by the dreaded ‘Script Exception’ email alert showing up in your Inbox.

How has Force.com, or PaaS in general, impacted your testing and QA processes?

Jonathan takes a somewhat provocative approach to pointing out that cloud computing and situational applications are rendering “traditional” programmers obsolete at an increasing rate.  Derrick Harris at GigaOm lays out a similar scenario for those on the IT infrastructure side of the house as cloud computing pervades mainstream Corporate America.  Both of these posts remind me of something that I had written early last year, “Platform as a Service and the Implications for IT,”  just prior to transforming our business to focus on SaaS design and strategy.

There are compelling arguments on both sides that innovative technologies either create jobs or eliminate them, but I don’t think the discussion is that cut and dried.  What’s inevitable is that cloud computing will certainly change jobs, and I think the bigger point here is that if you are an IT professional, if you have not learned by now that you have to continuously stay on top of new technology and business innovations to maintain your place in the pecking order, you will inevitably be left behind.  Sure you can sit back and hope that Black Swan events such as Y2K will come out of nowhere and suddenly make your 20-year-old programming skills a hot commodity, but the more prudent approach is to evolve with the times and stay relevant.  Cloud computing is here, so those hoping it would just go away are in for a rude awakening.

PaaS Standards and Interoperability Analysis

• Phil Wainewright: Coghead’s demise highlights PaaS lock-out risk
• Bob Warfield: Coghead Shuttered: Another in a Long Line of Non-Developer Developer Tools
• Sinclair Schuller: Farewall to PaaS Provider, Coghead
• Phil Wainewright: Does PaaS Need Migration Standards or Standard Platforms?
• Jonathan Sapir: The future of situational application platforms like Coghead
• Fredric Paul: The Demise Of Coghead: Collateral Damage When The Cloud Goes Poof
• Eugenio Pace: The need for “standards for application logic” in PaaS. Really?
• Scott Wilson: Rapid web-based app development: good or evil?

PaaS Evaluation and Selection Criteria Analysis

• Jonathan Sapir: Coghead refugees and Dr. Seuss’s Old Hat
• Jane McCarty: Helping Coghead customers
• Oliver Marks: Cloud Bursts as Coghead Calls It Quits
• Rafe Needleman: Coghead refugees to Intuit or Caspio? Fat chance
• Dennis Howlett: PaaS risks
• Krishnan Subramanian: PaaS, Trusting Beyond Its Initial Hype
• Phil Wainewright: Automated PaaS migration now a reality
• John Foley: A Cloud User Switches Clouds
• Fredric Paul: PaaS Vendors Swarm Former Coghead Customers
• Mary Hayes Weier: Coghead Failure Highlights Risks Of Cloud Computing
• Jonathan Sapir: PaaS Pricing…again

Michael Topalovich
Founder and CTO
Delivered Innovation

David is the VP of Marketing for Model Metrics in Chicago.  He and I have discussed the TCO argument ad nauseum, to the point where it’s clear that there really isn’t much of an argument because the numbers just aren’t there to support either side.

David makes some interesting observations that challenge the “conventional wisdom” TCO value proposition that seems to permeate from the SaaS / cloud computing community.  His hypothesis regarding the apples-to-oranges application of TCO data to the broader market is spot on – cloud computing may not be for everyone at this point, but it does make sense in a number of specific situations.  What this tells me is that it’s a futile exercise to try and use one-size-fits-all TCO arguments to justify SaaS and cloud computing purchasing decisions as we have been doing, and focus on integrating the TCO analysis into a more individualized and consultative approach to selling.  Does this approach increase the cost of selling and push sales cycles out?  Absolutely.  But the alternative, which is holding our breath for Gartner or Forrester to release the silver bullet research that crystallizes the TCO argument, is not an effective strategy and will probably never come to fruition.

Our friends at SilverTree Systems have introduced the Situational Application Resource Center, a collection of information that is dedicated to furthering a very compelling cloud computing technology that is being defined as ‘Situational Applications.’

Situational applications are essentially rapidly developed applications that are designed to immediately address a business challenge – i.e. solving a business process inefficiency, extending the functionality of enterprise systems such as CRM or ERP without having to customize the core application, or addressing market and customer opportunities as quickly as possible.  Situational applications also represent an opportunity for ISV’s to develop and market “Long Tail” applications to niche / “micro-vertical” markets that have traditionally been underserved by the broader software industry due to high development costs and prohibitive barriers to entry.  Delivered Innovation partnered with Coghead in early 2008 to take a number of situational applications to market, including the Marketing Lucidity Lead Model and Marketing Budget Management; we are also in the process of delivering the Lead Model and Marketing Budget Management on the Force.com “Platform-as-a-Service” (PaaS) by Salesforce.com.  These are applications that provide highly specific functions for marketing budget and lead generation planning that would not have been viable just two years ago due to the high costs of developing such applications…costs that would have been passed through to our customers and in turn priced out the very customers we built these applications for.

Cloud computing platforms such as Coghead and Force.com have set in motion a “virtuous cycle” for SaaS applications and situational applications targeted to business users and companies that traditionally would not have been in the market for such applications because of the costs and technology requirements involved.  Because we don’t have to purchase servers, software, and network infrastructure upfront, we can focus our capital on building very specific and highly robust application functionality.  Because the data model, user interface, and business rules / application logic are all provided as standardized components by the PaaS provider, our development time is slashed by almost 75%, which contributes to our ability to rapidly deliver new value to our customers at a significantly reduced price point.  Because our price point is significantly lower than it would be in a traditional ISV model, we can create new markets for our SaaS applications.  When customers are introduced to the concepts of cloud computing, SaaS, and situational applications, they in turn find innovative new ways to apply the technologies to their businesses, creating value far beyond what we had originally envisioned.  And the customers that understand the game-changing implications of these new technologies want to build new situational applications to accelerate improvement and growth in other areas of their businesses.  All of a sudden, we’re looking at the potential of Service Oriented Architecture (SOA) being fully realized, and companies are applying a building-block philosophy to technology and business processes.  It’s beautiful.

Please visit the Situational Application Resource Center today to contribute to the movement and find ways to deliver value to your customers and the community.

There’s no doubt that Microsoft entering the Cloud Computing game gives the philosophy / movement / model instant mainstream credibility.  But I’m conflicted as to whether this is a good thing; on the one hand, I can see that the day is almost here where I don’t have to spend half of a sales cycle educating clients on SaaS, PaaS, or “The Cloud.”  On the other hand, when Microsoft enters a market, Microsoft doesn’t conform to the market – it tries to mold the market in its own image.  SaaS, SOA, and Cloud Computing are too important to be co-opted by the traditional IT vendor paradigm, let alone be “Microsoft-ized.”

It will be interesting to see where all of this leads.  I am not anti-Microsoft by any means, and I have a lot of respect for the brainshare in Redmond.  Unfortunately the company has a fairly lengthy history of grandiose announcements and aggressive ambitions that overshoot either the company’s ability to execute or the market’s willingness to adopt the Microsoft way of doing what it has already adopted elsewhere.  I still use Microsoft Office on Microsoft operating systems because the former is the bedrock of productivity tools, but I have not seen anything from the company that I could get excited about since the announcement of Exchange 2000 back in the day when I managed a 10,000+ seat Exchange 5.5 organization.  That was almost 10 years ago.

The fanfare surrounding Azure has been a boon for everyone involved in the Cloud Computing space – a “rising tide lifts all boats” scenario – but our take is that this project will take Microsoft years to complete, and in the end it will prove to be too grand a proposition for them to get out the door in the timeframe necessary for it to be truly game-changing.  What we will see in the late 2009 / early 2010 timeframe is a limited framework, scaled back significantly from what was evangelized on the initial Azure roadmap, that provides access to small-scale “widget”-like functionality that marginally extends the functionality of only a handful of core products.  By that time, the thought leaders in the utility computing / Cloud Computing space will be pushing far more compelling envelopes, and the ability to run Office through a web browser and write cool widgets for it will elicit a collective yawn from all but the deeply entrenched enterprise CIO-types that can claim adoption of “The Cloud” in the most conservative (i.e. non-pension-threatening) manner possible.  But hey, thanks for the millions of marketing dollars to help educate the mainstream, Microsoft!  We’ll be sure to ride on those coattails for as long as the checkbook remains open.

Gartner: Microsoft’s Cloud Vision Reaches for the Stars but Is Grounded in Reality

Phil Wainewright: Windows Azure: Microsoft mainstreams the cloud

Dave Rosenberg: Microsoft’s Azure–I remain perplexed

The key takeaway from this posting is that if you focus on being lean and build SaaS applications with the lowest-profit customer in mind, then scaling up to midmarket and enterprise customers will give you more flexibility with regard to pricing, customization, and sales / marketing.  This is a simple yet powerful message, and one that we have built our business around.  One of the primary reasons for partnering with Coghead early on was that we understood the implications of Platform as a Service (PaaS) in changing the economics of SaaS application development and service delivery; by building SaaS applications on PaaS, we eliminated all upfront capital expenditures for IT infrastructure and were able to take our innovative, “Long Tail” niche applications to market quickly and for a fraction of the cost of traditional ISV development efforts.  This in turn allows us to offer SaaS applications with deep functionality that automate common business processes to customers in markets that have traditionally been underserved by larger software companies.  Because of Coghead’s unique multitenancy model, we can also provide our SaaS applications with tiered levels of customization based on our customers’ functionality and integration requirements…all at pricing levels that Mom and Pop shops can easily afford, even in tight economic environments.

This is likely the most succinct analysis of the challenges that cloud computing faces in becoming a viable paradigm in delivering technology services that we’ve found anywhere on the Interweb.  M.R. Rangaswami ties together some high-level research from Merrill Lynch on the value of the cloud computing market with adoption challenges and Gartner’s prescriptive view of considerations that we face as companies trying to monetize services in the cloud.

Key takeaways:

1. Cloud computing needs to be defined.  Is this critical on a micro level for providers that leverage the cloud for service delivery in order to drive customer adoption?  Probably not so much – most people buy Salesforce because it’s a great CRM product, not necessarily because it’s “in the cloud.”  Is it critical on a macro level to define cloud computing in a comprehensive yet accessible manner?  Absolutely.  Confusion in the cloud computing message only underscores the immaturity of the space and can impact mainstream adoption.
2. Focus on value.  Explaining the value proposition to those of us that are able to run our entire businesses on SaaS applications that automate the end-to-end “virtual value chain” as opposed to having to hire half a dozen people with comparable functional expertise is preaching to the choir…the value is self-evident to early adopters.  The key challenge is to find the right value proposition for the various tiers of the market; the SMB market that can leverage SaaS to gain access to applications that just 5 years ago had too many zeroes in the price tag see the value immediately (or with minimal nudging), but the enterprise end of the spectrum still bristles at the thought of giving up control of IT resources to providers outside of the walls of the corporation…the thought of not being able to walk into a server room and know that all is right in the world because you can see thousands of blinking green lights is just science fiction in the majority of enterprise CIO’s minds at this point.
3. Figure out how to sell this stuff.  Marketing and selling services in the cloud requires a radically different approach than selling software out of a box.  We know this, but that doesn’t make the prospect any easier.  How do we price it?  How do we position it?  Are competitors really competitors, or are we all complementary and connected in this new world of cloud computing?  What business models will hold up as the everything-as-a-service, pay-as-you-go model gains real traction in the market?  Nobody has the answers.  Yet.

This is a comprehensive overview of Cloud Computing technologies.  The article does a very good job of decoupling the components associated with “The Cloud” and reassembling them in a manner that describes value and enterprise applicability.  Probably won’t single-handedly clear up the market confusion over how to define Cloud Computing, but more pragmatic analysis like this will go a long way towards separating the concept and vision from marketing hype.

This falls into the category of what might be referred to as “purpose-built PaaS” – IBM is introducing a platform based on an existing set of software services that to this point had been offered only in a packaged model.  We love having IBM-sized marketing dollars pumped into educating a large portion of the market in the capabilities of SaaS / PaaS, but we’re not in love with the concept of PaaS as an extension of a core service offering…a la Salesforce.com’s Force.com PaaS offering.  On the one hand, integration is built in and users will already be familiar with the functional aspects of the system, on the other hand if every major vendor starts offering PaaS to simply extend what their packaged software does, we’re going to have dozens of islands of PaaS that will hurt the concept and the market as a whole.  This article is spot-on in its assessment that Big Blue does hold an advantage in selling to an existing customer base, but at the end of the day, vendor-specific PaaS defeats the core value proposition of PaaS from the perspective of creating additional management overhead, forcing organizations to compromise on business process design because of integration and platform capability limitations, and requiring technical resources to learn yet another PaaS / SaaS skillset.  The goal with PaaS is to achieve (relative) ubiquity, not more of the same old and tired IT thinking repackaged as a hosted service.