Salesforce Summer 12 and Disco Mirrorballs

My friend's house is never finished. An extension, new kitchen, patio on the garden, wires hanging down etc, absolutely lethal. Then knock it all down and start again. He loves it.

This got me thinking about the Salesforce upgrade path over the last few years. One of the reasons I moved to work with the Salesforce platform was because of the constant upgrades, making the platform effectively future-proof. However, after an initial good start, adding useful features such as APEX and better reporting etc, I am losing the faith. The focus on adding new 'look at me' functionality as opposed to developing the core platform is frustrating.

Going back to my friends house, he has recently redone the kitchen and redecorated the bedrooms. Good. Rooms that are often used and every day. He can walk into those rooms and appreciate the work that has been done. I can imagine though that if he had got Mark Benioff free reign to improve his house he would be sitting with a bill for a back garden water amusement park, a carousel in the living room and a lap dancing bar to replace the bedrooms. All very nice, but what about the missing wallpaper in the living room?

There are many ways in which the existing platform could be improved in areas such as build/deployment (too manual+resource intensive), or workflow tools (pales in comparison to Siebel). Since the introduction of Chatter, I think Salesforce have lost the plot a bit, and are focussing too much on whizz-bang new features to grab the attention of CIOs who are moon-walking to the tune of the social enterprise.

Anyway, enough metaphor. Let me get some quantitative proof by rifling through the Summer 12 upgrade release notes. Here is a summary of what is to be delivered, categorised as 'Replace the broken fridge' (useful) or 'Install kitchen disco mirrorball' (less useful). Ok, maybe not quite enough metaphor...

Chatter Messenger: Kitchen Mirrorball
Just get Google Apps - as a collaborative platform it trumps Salesforce.

Additional Chatter Enhancements: Kitchen Mirrorball
Chatter, chatter, chatter. Too much focus on this nice but certainly non-essential activity feed feature. Get me some decent way of creating a fully automated release build of an environment without any manual steps instead please.

Sales Cloud Enhancements - New Fridge
The bread and butter. No qualms here.


Case Feed Enhancements - Kitchen Mirrorball with added smoke machine
Unsure about Case Feed. Again, branching into new territory when the standard Service Cloud could really do with some better routing/queue functionality to bring it closer to Oracle's RightNow in that respect

Service Cloud Enhancements - New Fridge
A bit more bread and butter, but minimal

Salesforce Knowledge Enhancements - Kitchen Mirrorball
Who knows of a client that has the Knowledge module? Why this isn't free is beyond me.

Live Agent Enhancements - Kitchen Mirrorball
Nice but niche

Analytics Enhancements - New Fridge
Now it is going to tell you when it times out which is good. But seriously, some improvements to cross filters etc - I really like what they are doing here and all credit for going back on the initial charging model


Data.com - Kitchen Mirrorball
Lots and lots about this in the release notes. But the use of this is still fairly niche.

Schema builder - Kitchen Mirrorball
Noddy.

Site.com enhancements - New Fridge
I think this has potential, but ultimately any enterprise that wants to build out web facing apps are going to use Heroku. If they really beefed up this offering and made it scalable it could be very useful (abstraction layer on top of Heroku for instance?)


Force.com: Flow / VisualForce / Apex - New Fridge
Unfortunately improvements to the core platform in these areas tend to be quite minimal, but having said that they are certainly welcome. Flow has the potential to be useful if they bolster it a bit to be more of a behind the scenes workflow engine rather than a scripting tool. VisualForce and Apex are incredibly core to the platform, and the increases in limits and improvement developer tools in Summer 12 are welcome.

So I guess I would sum up the Summer 12 release as follows:

False Cloud, Cloudwashing and Dishwashing

I used to be a dish-washer for a restaurant when I was a lot younger. The value of my service was easily quantified - either the plates and pans are clean and the chef always has a good supply, or not and you get torrents of abuse and ladles thrown at you. Ahh, those were the days.

Unfortunately when it comes to Cloud, and specifically cloud-washing, the lack of value in a service is not as obvious. A definition (there are a few) is as follows:

"Cloud washing... is the purposeful and sometimes deceptive attempt by a vendor to rebrand an old product or service by associating the buzzword "cloud" with it"

It also equates to Mark Benioff's 'False Cloud' line, and is important when it comes to judging whether a service does offer the benefits of the cloud model (which have been well documented so not covered here).

The motivation for writing this post was a recent article I read which seems to me either to be a blatant attempt at cloud-washing, or just a demonstration of misunderstanding. This frustrates me because 'cloud' is not a new concept any more and NIST have provided a widely accepted standard definition. Please, have a quick read:

Article charged with Cloud-washing: Case Study: Making Cloud ROI a Reality
Cloud-washing indicators: "Outsourcing made the most sense." "install new off-site servers", "leases physical servers"

What they really mean: Outsourcing and virtualization


It is pretty easy to take the essential characteristics of cloud outlined in the NIST summary and make a judgement against any offering as to whether it it 'true cloud'. So in this instance does the article fit the cloud definition at all? Here goes:

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

No: No indication of putting provisioning in the hands of the consumer


Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

Yes: The capabilities are available over a network


Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand.

No: This is normally the easiest was of judging whether a service is 'Cloud' or not - simply outsourcing does not give you the economies of scale associated with a multi tenant architecture


Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand.

No: No indication that the consumer can scale up and down rapidly. The fact 'leasing physical servers' is mentioned suggests this would not be as easy to scale as a proper IaaS platform such as AWS.


Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability1 at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts).

Yes: The virtualization element here and moving from 50+ servers to 4 suggests this is true


So, I come to the conclusion that although the term 'cloud' is mentioned 17 times in the article, what they really mean is outsourcing and virtualization. Not Cloud. So please, anyone who starts an article on 'cloud', have a quick look at the NIST definition so we are all on the same page. Otherwise I will throw a ladle at you.


- Posted using BlogPress from my iPad

The Multi-Multi-tenant Upgrade Jigsaw

One of the most commonly cited advantages of an app sitting on multi-tenant architecture is the fact it is frequently upgraded so each customer is always on the 'latest version'. Historically the upgrade path for on-premise enterprise software had been a complete pain. Taking the 'one-click' upgrade path was about as effective as throwing a bag of spanners at the thing, as it had been butchered beyond all recognition. Not 'out of the box' anymore, the box had been burned and the ashes whacked repeatedly with a baseball bat. So the standard upgrade routine would basically have a look and then run away laughing.

With a multi-tenant app, the abstraction layer prevents customers from butchering their app to such an extent. This results in a fairly smooth upgrade process, but then a new issue rears its head. The upgrade itself and the timing are forced. It is not possible on a true multi-tenant platform to choose when the upgrade occurs. All customers are upgraded around the same time. So, let's take a couple of multi-tenant examples from my experience:

Salesforce.com : Upgrade occurs to the Production instance every 4 months.

The fun: One month prior to the production instance upgrade, certain sandboxes are upgraded by the Salesforce upgrade fairy. Now, in an enterprise environment you will likely have at least 2 sandboxes - Dev and Test. You may also have a separate UAT sandbox, maybe a Staging sandbox also. You might have a parallel development stream with another Dev and Test. Anyway, the point is that to avoid a sandbox being upgraded early by that naughty but ultra-keen fairy, the only way is to refresh it in a certain window of time, differing depending on what server instance it sits on. This kills the current sandbox and creates a new instance copied from Production. So this needs to be planned well in advanced into the dev schedule to avoid for instance your dev sandbox being on a different version than your test one, and to make sure the release path sandboxes are on the same version as production. And of course if you are midway through your dev schedule when the Production upgrade occurs, and your sandboxes are upgraded at the same time, you need to regression test the in-development functionality. It is also a good idea to have one sandbox upgraded early to regression test current Production functionality against the forthcoming release. To get the refresh schedule right I try to get my head around it all by drawing a couple of timelines. Firstly for the Summer 12 Salesforce release I drew myself this:

And generically as a reminder for the future I summarised the above paragraph into this:

Now lets look at Zuora:

Zuora: Upgrade occurs to the Production instance every month.

The fun: One week prior to the Production upgrade, all Zuora sandboxes are upgraded by the Zuora upgrade pixie. This necessitates a regression test of the current dev cycle, and a regression test against the current production functionality to pre-empt any Production issues. However, outside of this schedule is an absolute avalanche of patch releases by the mini-pixies, which with the best intentions, it is impossible to keep up with. Usually there will be about 1 days notice before the sandboxes are patched, then a few days until production. If you are lucky you get some release notes, but usually not until after the sandboxes are patched.


NOW integrate Salesforce with Zuora, and the solution as a whole has 2 multi-tenant platforms, with sandbox and Production environments upgraded on different schedules. Bloody fairies and pixies running around all over the place. The joy of forced upgrades. Then maybe add on Eloqua, or BigMachines - the more the merrier!

But we choose to enter the multi-tenant world so can't complain. Three points to make:

-When planning your dev/release schedule, review the upgrade schedules and ensure the impact of forced upgrades on resources and release dates is taken into account
-Automate your regression testing to the max to gain confidence in the upgrades quickly, because you will have to! Review release notes and prioritise areas that have changed.
-When cloud platforms prove themselves to be more robust in the future, the need for regression testing may reduce. Maybe.

Upgrades are more likely to have an impact on the more complex implementations which are found in enterprise implementations involving lots of integration, customisation etc, and spanning more functional breadth than smaller implementations. You probably don't need to worry too much about your little standard Sales Cloud thing you stood up for the old lady next door. But who wants to work on a small implementation?

- Posted using BlogPress from my iPad