Salesforce at the FT — Orgs, Objects, and Runways
by Gareth Park
In 2011 the Financial Times made a strategic decision to use the Force.com platform for a number of key initiatives.
Salesforce was already embedded as a CRM (the ‘Sales Cloud’) for a subset of sales users. However, over an 18 month period the scope of this would be increased substantially; with all 2000+ employees having some level of access to Salesforce.
A suite of applications would be built on the Force.com platform supporting a broad church of business processes; from FT online subscriptions….to employee holiday requests ….from print advertising bookings….to cataloging equipment for journalists (such as flak jackets).
The above applications were all developed in parallel with separate internal development teams.
Out of the box Salesforce functionality (Sales Cloud, Service Cloud) would be leveraged, 20+ custom Force.com application would be built from scratch, and a number of third party managed packages would be installed.
Integrations were also required to other internal FT systems (CMS, Finance, HR, FT.com Fulfillment, Newspaper and BI (Redshift)).
How did we do this?
1. Defined our Org Strategy
What is an Org?
“A Salesforce Instance or Organisation (org) is a single area of computing space reserved for your company on the Salesforce public cloud or internet.”
and more importantly….
“An org unit is bound by both capacity limits (number of users and storage) and execution resources (query sizes and API limits).”
Therefore a busier org — without the correct processes in place — will be more susceptible to the errors and limits imposed by a multi-tenanted environment.
Also, from an admin point of view, it could easily fall into a spiral of sprawling role hierarchies, unmanageable profile sets and user search results displaying 1000’s of irrelevant records.
Then why have a single Org?
- It is cost effective — a single license per user
- Improved analytics/reporting — “360” view of each entity
- Shared code base
- Multiple Orgs would also require users to have a separate login for each org. This could create confusion for users, with an increased overhead for Admins.
Our strategy
We decided on a 2 Org strategy. With the 2 orgs eventually containing the below;
The reasoning behind this was that in 2011 the “Ads Org” was already very mature — the Sales Cloud had been extended to provide a suite of additional functionality for the Ad Sales teams.
The “Global Org” was much smaller with minimal customizations — this would allow us to define a model that would be flexible enough to accommodate a range of separate business areas — without having to undertake any major reworks to existing functionality.
2. Defined our Sharing Model
Salesforce provides a number of different tools for defining access to data. Depending on the implementation this can be relatively straightforward or can end up being complicated and unpredictable.
We would be importing millions of contacts into Salesforce, along with regular inputs from internal newspaper and digital fulfilment systems. Multiple business areas would be using the standard objects — it was therefore important to establish who wanted to see what.
A series of workshops were therefore held with stakeholders to discuss various use cases.
In this we conveyed the implications of each approach to the sharing model, and how it would play out in real world scenarios.
From this, it was established that we would require a model that would provide;
Openness — the flexibility for everyone to share contacts and accounts (also stated as — an ability for everyone to see and share all contacts and accounts)
Uniqueness — the system must be set up to discourage duplication of contacts and encourage single view of the customer. A manual process of de-duping records is not acceptable.
Efficiency — the system must be set up to create an efficient user experience for each different department using it — from sales teams in Confidentials and B2B, to the global customer service and data teams. Too much noise in the system could impact user adoption.
After reviewing a number of options it was decided that a private sharing model should be implemented, with sharing rules created for users requiring access to see the accounts and contacts relevant to their role.
Permissions sets were also favoured over profiles. This has made user management a lot easier — with admins able to easily ‘slot’ in permission sets to users to open up access to individual applications.
3. Defined our Development Processes
At the beginning of 2012 we had multiple projects starting concurrently — and were keen to avoid falling into a “wild west” type scenario …. with posses of un-coordinated development teams roaming the orgs, building applications in isolation with regular shootouts as they competed to secure shared resources.
To avoid this, the following processes were put in place;
3.1 Central Governance and Collaboration
A Salesforce technical steering committee was set up in 2011 and meets once a week to;
- define coding standards, best practices, release strategy
- review managed packages, changes to schema, test suites
- monitor the health of the org — reviewing the code coverage, length of deployments, co-ordinating refreshes.
The role of the steering committee would be to ensure consistency across the org and provide a central point for all architecture decisions.
Developers would be free to table issues for discussion at the steering committee either via the Chatter feed,Tech lead or attend if required.
To supplement the steering committee monthly developer gatherings would take place — this would be a place for developers to showcase any new work and discuss any new features available from Salesforce. This provides visibility of development outside the developers program and an opportunity to discuss any current problems.
3.2 Environments (sandbox) Setup
To explain this fully would require a blog post in itself (possibly one for the future). But in essence we are trying to flag up problems or conflicts within code as far upstream as possible.
Development takes place in individual or project sandboxes before being pushed into an Integration sandbox where it can tested against the latest changes made by other development teams.
FT Sandbox Configuration :
An automated continuous integration process has also been introduced (to the “CIGO” sandbox) so that we have an early warning system for failing deployments.
As part of the development process our test teams create automated test suites to run against the Integration environment nightly. This includes using Webdriver to validate certain parts of the Salesforce Setup UI. This gives us regular automated regression for our own deployments, and any changes pushed by Salesforce.
Internal monitoring services have also been created using Nagios to monitor our orgs and alert Duty Ops if there is a degradation in performance.
3.3 Deployment Processes — the Release Runway
Looking at the roadmap in 2012 one thing was clear; there would be regular releases to the production environment for multiple applications. Varying from a simple “patch” release with minor amendments to a single apex class…. to those containing over 100 artifacts with 70+ manual steps to boot.
Salesforce allows us to deploy releases without any downtime — very important as we have a user base spanning London, Manila and New York.
However, as we went through the year, and our suite of test classes increased, deployments (and validations) could take over 2 hours.
Therefore, to make this workable, and to provide accurate release dates to the business deployments would have to organized.
We did this by creating a release runway; there would be 2 release slots available each day between Monday and Thursday.
Development teams were encouraged to book these well in advanced, validating the change set beforehand.
The actual deployment would be carried out by the org admin; following the instructions provided by the development team (via a standardardized release document).
This also prevented the “Salesforce stuck in Organization Administration Locked state” error caused when simultaneous runs of the test classes are attempted.
Conclusion
Salesforce has provided an effective way to develop the small internal applications as well as the large enterprise solutions simultaneously in the same environment.
Last count 2,140 Apex Classes have been deployed to production (Global : 1,760, Ads : 380) along with 760 workflow rules (Global : 415 Ads: 345), and Visualforce Pages 744 (Global : 605 Ads : 139) and validation rules, approval processes etc
But perhaps more importantly we have been able to retire a number of costly legacy systems (ATEX, SalesLogix and Lotus Notes), with a single platform that we have the in house skills to support and enhance. We are now far more self sufficient.
The FT even have an app on the AppExchange that provides industry headlines from the FT seamlessly for your sector into Salesforce.com.
There are still some challenges; we continue to work to streamline our test classes — deploying a change set still takes around 2 hours — however, with the above processes in place we are still able to provide the business with accurate delivery times.
Looking to the future — aside from enhancements to existing apps and developing new ones, we will also look at how we can leverage Salesforce1 to allow our business users to use our apps in a more mobile friendly way. We will also consider other mechanisms (such as ANT) for our deployments and further integration with Gmail so users can access all systems with one login.
At the FT we adhere to principles for driving strong, simple and open technology. So far the components provided by Salesforce have fit well into this model — it will be interesting to see what new features are showcased at Dreamforce 2014 and the following subsequent releases.
