Developing on

The PaaS provides an enormous amount of functionality and flexibility, all of which is driven by the underlying metadata architecture.

There are a number of different ways to develop applications on, ranging from declarative development (click’s, not code) to APEX, which is an object orientated programming language similar to Java.

Depending on your use case you may only need to leverage the declarative development, however for most mid-sized builds the 80 / 20 rule can be applied (80% Click's / 20% Code).

Regardless of your development, there are number of developer good practices and tools that will help set you up for success. This is especially important if you are developing for a shared org (see " Org Strategy").

This article will outline some of the good practices and tools that I recommend:

Integrated Development Environment (IDE)

An IDE is a software application that provides facilities to programmers for software development. This includes a source code editor, build automation tools, debugger and (if you’re lucky) code completion features.

With you have two IDE options:

  1. Eclipse, which can almost be considered the industry standard. It’s cross platform (Windows, Mac, Linux), has a rich community and supports thousands of plugins for many programming languages. have an Eclipse plugin specifically for development, which can be downloaded for free from “”. They also have comprehensive reference library for beginners and experienced developers
  2. MavensMate (my choice) is an open source IDE developed by Mavens. This is quickly becoming the community standard for development due to its integration with the popular text editor Sublime Text. themselves also point people towards MavensMate as an alternative to Eclipse.

If you are developing a mid-complexity application (APEX, Visualforce, etc.) I would certainly recommend the use of an IDE.

Source Code Management (SCM)

A common misunderstanding when developing on is that you don’t need source code management. The reason that I often hear is that “I have no code, it’s all declarative”.

The important thing to remember is that is a metadata driven architecture, therefore metadata describes the data structures in your environment and the declarative functionality implemented on the platform (e.g. your application).

As a result it’s still import to use source code management for version control, even if it’s just tracking the metadata changes.

Personally I always recommend Git, which is a distributed source code management system with an emphasis on speed and data integrity. There are plenty of Git services available, however the most popular are GitHub and BitBucket. It’s here where we store all of the source code (e.g. metadata) for all of the projects that are developing for (just remember to make your repositories private).

Continuous Integration (CI)

Continuous integration is the practice of merging all developer code with a shared mainline on a regular cadence. It enables automated testing and reporting on isolated changes in a larger code base, allowing developers to rapidly find and solve defects.

As a result, continuous integration facilitates the process of agile development, where you are constantly testing your code, ensuing that it doesn’t break the build (small and often).

The industry standard for continues integration is Jenkins, which is an open-source tool. You can host your own Jenkins instance, but I would recommend a cloud-based service such as CloudBees.

Continuous integration will help facilitate the testing process when moving code between environments (DEV, TEST, PRD, etc.)

Development Environments

Every production environment comes with a suite of development sandboxes. These sandboxes can be created ad-hoc and are a direct replica of production (however do not include any data). Test data will need to be loaded post sandbox creation, either manually or via an integration (e.g. MuleSoft, etc.)

When provisioning sandboxes to development teams I recommend the following approach, which includes three sandboxes:

DEV = Main development environment.
CI = Continues integration merge / build test environment.
TEST = Formal user testing environment.

A traditional development pattern would be...

  1. All development will occur in the DEV environment, leveraging an IDE (e.g. MavensMate) and source code management (e.g. GitHub).
  2. The project teams will then build their code (multiple times per day) into the CI environment leveraging continues integration (CloudBees). This will confirm that their development does not break the build.
  3. Finally, any code positioned for a release to the GSO will be moved into the TEST environment (leveraging CloudBees), where formal testing (including UAT) can occur.

This approach ensures the entire development process can be owed and managed by the development team, offering complete autonomy.


In summary, is an amazingly flexible development PaaS, which is extended further if you include Heroku (I’ll save that for another time).

Hopefully this information is useful and as always, please don’t hesitate to comment below if you have any questions.

Docker - Containerisation is the new Virtualisation

I'm a huge advocate of Platform as a Service (PaaS), specifically Heroku.

Heroku enables developers to forget about the infrastructure and middleware, allowing them to focus on their application (simply push code and let the platform do the rest).

The "secret source" of Heroku is the understanding that web apps, databases and worker jobs are just Unix processes and Unix doesn't care about the stack. It's this philosophy that enables Heroku to be cross-language, by focusing on Unix processes and producing environments (via Buildpacks) that can run any server process.

This is where containers come in! Heroku uses lightweight containers called Dynos, which run a single user-specified command. With containers you can very quickly and efficiently run thousands of services on a single virtual machine, each thinking they have their own system.

This is all great and it's a core part of why I love Heroku. However, it's what happens when you expand on this concept that things become really interesting...

Introducing Docker

Docker is an open-source project to easily create lightweight, self-sufficient containers from any application, that will run anywhere.

Let's break that down:

Open Source - Although Docker was created by a commercial company (dotCloud), it's open-source and has a thriving community.

Lightweight - Containers are insanely fast, providing bare-metal access to the hardware. No need to worry about a hypervisor layer.

Self-sufficient - Each container comprises of just the application and its dependencies. It runs as an isolated process in userspace on the host operating system, sharing the kernel with other containers.

Application - Containers package applications, not machines (making it application centric). Unlike traditional virtual machines a Docker container does not include a separate operating system.

Run Anywhere - Run on any machine, with guaranteed consistency, for example: local (OS X, Linux, Windows), Data Centre (Red Hat, etc.) and Cloud Infrastructure (AWS EC2, Rackspace, etc.)

The primary difference between a traditional Virtual Machine stack and a Docker stack, is that the Docker Engine container includes just the application and its dependencies. 

Virtual Machine Stack VS. Docker Stack

Why Docker?

With Docker, developers can build any application in any language using any toolchain. Just like shipping containers, “Dockerised” apps are completely portable and can be loaded anywhere. This provides developers complete flexibility and consistency, when developing applications.

Docker also has an impressive community offering, with over 13,000+ images available on Docker Hub. This enables rapid application development, through the use of pre-built capabilities.

However, Docker is not just great for developers, system admins can use Docker to provide standardised environments for their development, QA, and production teams, removing the challenges of ensuring consistency across different environments.

Get Started

I plan to post a lot more regarding Docker, but the easiest way to learn is to experience it for yourself. I suggest you head over to the official Docker Installation guide and look-up the instructions for your system, you can then grab an image from the Docker Hub (for example, Ghost, WordPress, PHP, etc.) and start playing.

I've already got a number of web application containers up and running across OS X and Ubuntu and I have set-up my own portable "Heroku-like" PaaS using Dokku, all powered by Docker! Org Strategy

As highlighted in my previous article ( Enterprise Application Platform), I have recently spent a lot of time positioning as an enterprise application platform.

This article focuses on one of the first design decisions, the org strategy!

What is a Org?

A fundamental part of the platform is an “organisation” or “org”. 

At a high level, a org is a logical instance of data and metadata for a set of users. An org is bound by both capacity limits (number of users and storage) and execution computing resources (query sizes and API limits). These limits will depend on your agreement with and/or your license type.

Every user working on the platform will do so inside an org.

Enterprise Org Strategy

In a perfect world every company would have just one org for their organisation, however this is not always advisable. There are certain scenarios where a “multi-org” strategy will be required to meet the business need.

One thing that is clear is that you should plan your org strategy from day one! If you don’t it’s possible for your company to unintentionally expand across a number of orgs, which could significantly limit your future deployments, as well as dramatically increase the support complexity.

Single-Org Strategy

Single-Org Advantages:

+ Improved user experience (one login)
+ Simplified integration (data access and movement)
+ Reuse of objects, data and capabilities
+ Simplified collaboration (no cross-org Chatter)
+ Encourages consistency (developer standards and reviews)
+ Simplified licensing model
+ Cost benefits (purchase integrations and add-ons only once)

Single-Org Disadvantages:

- Complex security (one org = many apps / many business units)
- Complex release / code management (e.g. code merging)
- Increased pressure on limits (e.g. governor limits)
- Large data volumes (complicating archiving and backup)
- Requires “good citizen developers” to work in a shared environment

A single-org strategy places an emphasis on consistent global business processes and company-wide collaboration.

The key advantage being reuse of objects, data and capabilities, enabling faster development and reducing the need to replicate functionality across multiple orgs.

The key disadvantage is the complexity of managing a shared environment where multiple business units and developers will be deploying applications (often simultaneously). This creates a complex security model and forces the need for a dedicated DevOps team to manage code movement, merging, etc.

Multi-Org Strategy

Multi-Org Advantages

+ Simplified security (one org = one app)
+ Simplified release / code management
+ Reduced pressure on limits (e.g. governor limits)
+ Smaller data volumes (simplifying archiving and backup)
+ Provides business unit autonomy via a dedicated org

Multi-Org Disadvantages

- Poor user experience (multi-logins, can be mitigated via SSO)
- Complex integration (data access and movement)
- Minimal reuse of objects, data and capabilities (e.g. AppExchange Packages)
- Complex collaboration (cross-org Chatter)
- Risk of design inconsistencies across multiple orgs
- Complicates license model
- Anticipated higher costs

A multi-org strategy is acceptable when business units or regions want autonomy to have direct control, with limited need for company wide collaboration or data sharing.

The key advantage to a multi-org strategy is the autonomy provided for specific business units or regions. This enables them to push enhancements and/or bug fixes with minimal impact on other applications.

The key disadvantage is the loss of efficiency, meaning that any capability you deploy in one org, will need to be individually deployed and managed in all other orgs (often resulting in additional cost). For example, if you deploy an AppExchange package to manage eSignatures, you would need to deploy the same package across others orgs if this capability was needed by other applications.

It should also be noted that cross-org Chatter and data access can be challenging, generally forcing you to purchase and deploy third party services such as Make Positive Passport (cross-org Chatter) and/or MuleSoft (integration platform).


I would alway recommend starting with a single-org strategy, only expanding to multi-org if you have a very specific business need. However, if you are negotiating a contract with, it's worth taking into consideration the potential for multi-org, even if you only plan to use one org. This is to ensure you have flexibility to use your existing user licenses across other orgs, in the event you need to expand (reducing the need for future procurement conversations).

Hopefully, by starting with a single-org strategy, but having the commercial flexibility to expand will provide the best of both worlds. It should also be noted that with every release, continue to expand the capabilities of an org. Therefore some of the disadvantages highlighted above (e.g. governor limits) will likely become less of an issue.

Hopefully this article has helped highlight the advantages and disadvantages of different org strategies. As always, the business need should drive your decision, but at least now you can proceed with your eyes open! Enterprise Application Platform

Marc Andreessen famously said "Software is Eating the World" and I couldn't agree more!

Only last month taxi drivers across London came to the scary realisation that their world is changing due to the dominance of Uber (a software company). If taxi drivers aren't safe from the software revolution, no one is!

I believe many industries are at a critical turning point and therefore must rapidly evolve or face inevitable extinction. Unfortunately this is easier said than done, especially for enterprise businesses which are historically slow moving but now need to compete with highly agile software companies born out of Silicon Valley.

So how can IT help enterprise businesses succeed in this new world? I believe a key part of the answer is placing a strategic bet on Platform as a Service (PaaS) and embedding agile software development into company culture (regardless of the industry).

This is why I have spent the past nine months positioning as an enterprise application platform for a large enterprise.


On the surface, (owned by may seem like an odd choice, why not Microsoft or Google?

In my opinion there are six key areas that answer this question. Reviewed individually, each area could easily be challenged, however when understood as a whole I believe have the most compelling, end-to-end PaaS story for the enterprise.

1. API-Centric Architecture

  • was a pioneer in API-Centric Architecture, meaning every feature and capability has a corresponding API, reducing "lock in" and enabling massive flexibility for developers.
  • API-Centric design is the cornerstone of what is widely accepted as the next iteration of business development, where having a well-developed API is poised to be the way in which business relationships are established and maintained in a online, 24/7 digital economy ( This is especially true in a world where everything is connected (people, devices, apps, data, etc).

2. Rapid Application Development

  • is a true enterprise Platform as a Service (PaaS), which means your developers can focus on creating amazing applications, instead of worrying about the infrastructure, operating system or middleware.
  • Any application built on the PaaS is elastically scalable, secure and compliant, thanks to their industry leading multi-tenant architecture, which handles approximately two billion transactions per day (
  • is the current (JAN-2014) Gartner Magic Quadrant Leader for PaaS.

3. Declarative Development

  • is a declarative development platform, meaning anyone can create complex applications using clicks, not code. This enables the business (not IT) to directly contribute to the creation of applications. It's estimated that 80% of a application can be created using declarative development (the other 20% coming from code).
  • Don't worry if you're a true software developer, has you covered with powerful capabilities such as APEX (JAVA-like language), Visualforce, Mobile SDK and Heroku (which enables endless development opportunities).

4. Social Integration

  • It's clear that the future of collaboration is social. The "working out loud" revolution has already changed the consumer world and it's widely expected that business is next. is social at its core, leveraging a capability known as Chatter to drive collaboration and provide context to data.

5. End Point Agnostic (Mobile Optimised)

  • Thanks to the Aura framework, all applications are end point agnostic, with no additional coding required. For example, if you open a application in the browser on a PC, you'll get served a user interface optimised for mouse and keyboard. However if you open the same application on a tablet or smartphone, the experience will instantly optimise for mobile. Essentially, develop once, use everywhere! 
  • Built using Aura, the Salesforce1 Mobile App delivers a native experience to iOS and Android. This, alongside the powerful Mobile SDK and Wear Developer Pack, guarantees you can build the best customer experience, regardless of the end point.

6. Aggressive Expansion

  • The AppExchange is a rapidly expanding marketplace (2000+ apps) where anyone can submit or install applications built on the PaaS (many for free). This covers everything from specific functionality (e.g. eSignatures, etc.) to full applications (e.g. ERP solutions, etc).
  • are the market leaders in Sales, Service and Marketing, they are also industry pioneers with their multi-tenant, API-Centric Architecture. This, alongside their aggressive growth and acquisitions (Radian6ExactTargetHerokuEdgeSpring, etc), proves that they are not resting on their laurels.

Over the next few weeks I'll dive into some of the details of, specifically the architecture and key design considerations when positioning as an enterprise application platform.

Visualforce and Internet Explorer - Rendering Issue

I recently developed a application using Visualforce.

Just like HTML, Visualforce can integrate with any standard web technology or JavaScript framework, enabling the developer to create unique applications, while still leveraging the native capabilities of the platform.

Like all web development, Internet Explorer remains a constant challenge, especially when using modern web techniques such as HTML5. I have seen countless examples where a page renders perfectly in Chrome, Firefox and Safari, but fails miserably in Internet Explorer.

Normally, the simplest way to resolve this issue is to define the Internet Explorer document compatibility mode (either via the code or web server). For example, using the "X-UA-Compatible" meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=Edge" />

Unfortunately, this is not an option with Visualforce, as the "X-UA-Compatible" meta tag is automatically stripped by and you have no access to the server configuration.

As a result, you are forced to either "hack" your code to work with Internet Explorer (not recommended), or you could use a simple APEX class to force the "X-UA-Compatible" meta tag.

To start, create the following APEX class (called ieCompatibility):

public class ieCompatibility {

public ieCompatibility() {
Apexpages.currentPage().getHeaders().put('X-UA-Compatible', 'IE=Edge');

Once created, switch to your Visualforce page and add the "controller" attribute, calling the "ieCompatibility" APEX class.

<apex:page docType="html-5.0" controller="ieCompatibility" standardStylesheets="false" showHeader="false" sidebar="false">

Once saved, reload the page in Internet Explorer.

If successful, the page should now render as designed. The other great thing about this approach is that you can easily re-use the "ieCompatibility" APEX class, without any negative impact to