I just came across a nice post from a Force.com developer on his blog, d3developer.com,  that touches on many of the concerns that are being felt throughout the salesforce.com partner and developer ecosystem regarding the company’s recent VMForce announcement.

Three key points:

(VMForce) raises the question of just who Salesforce is competing with.

Salesforce can no longer simply compete with Oracle business applications, can it realistically think to match Amazon or Google to be a leader in a PaaS (Platform as Service) race?

(Salesforce needs to) Articulate more clearly the gameplan to the developer community.

Mr. Gruber makes a number of good points in this post regarding the general tendency in IT to try to commoditize talent within the software development space. While we at Delivered Innovation employ a “factory approach” to development, our philosophy regards the standardization of the delivery process itself, and not the application of tacit knowledge to the process of creating value, as the ultimate candidate for standardization. Glenn is spot on in his assessment that many firms within the outsourcing world try and apply a factory model for the purpose of reducing development expertise to the least common denominator, and this comes at the expense of quality design…and ultimately of quality output.  DI has been brought on to a number of large “cleanup” projects in the Force.com space this year to untangle messes created by these so-called software factories where developers are routinely referred to as “bodies” (as in, “We’re behind schedule, so let’s throw a few more bodies at this”), and in every case the customer ended up spending significantly more on the project using resources that may have cost less on a per-hour basis, but ended up costing more in the long run due to the watered-down skill levels and lack of insight into the big picture design and architecture.

Three key points:

…under the traditional outsourcing model success (i.e. margins) is achieved by trying to break any task down into its most basic components so that those activities can be completed by the most junior and cheapest resources.

Tools and methodologies are more like guiderails to reduce mistakes and help less-seasoned developers accomplish more advanced tasks, but don’t necessarily guarantee well written, high-performance software.

Architecting, designing, building and testing products that are tied to revenue, that require high levels of performance, scalability and resiliency is not a task to be done by lowest-common-denominator individuals.

I’ll substitute “downsides” with “risks” because some of these may be viewed as half empty / half full arguments, but I see the biggest current risks as:

1. Market confusion. As Peter mentioned, it is a mad dash to the cloud right now. And since nobody wants to feel left out, just about every company in the B2B tech space has re-branded itself as a cloud computing company. I’ve heard this referred to as “cloudwashing,” and the result is that companies will find it more difficult to find services specific to their needs, because of the tendency of providers to water down messaging into cloud buzzwords and ignore basic positioning and value statements.
2. Cloud sprawl. With the rapid proliferation of cloud services, IT is struggling to adapt corporate service delivery strategies. The results that we have seen have included duplication and overlap of processes and functions due to services being provisioned directly by business units; loss of control of the billing for services because no single entity within the company is responsible for the procurement and management of them; and the equivalent of “shelfware,” a situation where cloud services are orphaned after the champion leaves the company or the business shifts focus.
3. Lack of cohesive integration strategy. There is no doubt in my mind that the cloud model of service delivery is the one that we will adopt for at least the next 10-15 years of technology cycles, but until the integration of all of the pieces is thought through, the sum of the parts will never add up. My company has standardized our core service offerings around the Force.com platform from salesforce.com to provide the “glue” that holds all of the pieces together, and we “mash up” other cloud services into composite enterprise business systems through API integration, business process orchestration, and data integration using services such as Boomi. But if companies just provision cloud services for siloed requirements up and down the cloud stack (from infrastructure to SaaS), the disaggregation of these services will prove to be a value destroyer.

Please download and provide us with your feedback.

Visio Diagram by Delivered Innovation is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

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)