The latest trend in application delivery is  bit like back to the future – once upon a time, companies that wanted computer processing power used time share or bureau services to access part of a mainframe’s processing power unless they could afford the millions of dollars in capital investment required to buy their own mainframe.    As mini computers became available, more and more organisations could afford their own processing plant on-premise.  Hence the rise of Digital, AS/400, Sequent, Pyramid, Sun….  Then the rise of PCs meant that processing could be split between the client side and the server and further decentralised.

All the talk about cloud computing, software as a service, computing as a utility, on demand all harks back to the timeshare model – you access the processing power that you need on a time-share, pay as you go scalable model.  Except now, it’s not a mainframe at the back end, but data centres full of servers that have been virtualised (another mainframe concept!) to provide these services.

As the quotable Larry Ellison said late last year:  “The computer industry is the only industry that is more fashion-driven than women’s fashion.”

It has been quite interesting over the past few weeks as I have been immersed in delivering salesforce.com extensions in enterprise clients.  While the product initally aimed at the SME world it has gained acceptance at some of the largest companies around particularly in business units that are not prepared to wait for 2-3 years for a new core system to be developed and deployed.

There is no doubt that force.com provides the capability to deliver highly usable, robust applications in  a fraction of the time that it used to take in the ‘olden days.’  At enterprise level however there are still the challenges related to release management and IT governance.  Although the issues of creating multiple development and test environments are now handled by the vendor, you still have to migrate and check what code and configuration exists in each of multiple environments, as well as figure out ways to manage regression testing as you release new capabilities into a live system.   The Force IDE, Metadata API and other tools cover quite a lot of the objects and code that need to be managed, but not all, and this is where some rigour and discipline is required.

Here at dSales we have been developing a set of tools and processes to help our clients manage this situation.

If you have any useful experience in this regard I’d love to hear feedback.

I wasn’t sure what the definition on Sales 2.0 was, so I looked it up  in Anneke Seley and Brent Holloway’s new book Sales 2.0:

“Sales 2.0 is the use of innovative sales practices, focused on creating value for both buyer and seller and enabled by Web 2.0 and next-generation technology. Sales 2.0 practices combine the science of process-driven operations with the art of collaborative relationships, using the most profitable and most expedient sales resources required to meet customers’ needs. This approach produces superior, predictable, repeatable business results, including increased revenue, decreased sales costs, and sustained competitive advantage.”

It’s a fantastic book for any business interested in improving sales enhanced by technology. You can buy it straight from Amazon below:

I’ve recently started working with dSales, a consulting practice specialising in leading edge processes, technology and skills development to increase sales conversion rates, improve resource productivity, and enhance the customer experience across distributed sales and service teams.   We often enable this processes with technology based on salesforce.com.