Beyond CRM

If Web 2.0 mashups are the future of the internet, what will the enterprise application look like? The folk at Salesforce.com think they have the answer, in the shape of the winter 06 release of their web application platform – and the introduction of a web service and application directory, the AppExchange.

Salesforce.com has come a long way since it began life as a web-hosted CRM package. Initially giving small and medium sized businesses access to the capabilities of tools like Siebel, but without the cost, it quickly became an enterprise tool. Now quick to customise, and able to link into public web services with a web services API that lets you build it into your own applications, Salesforce.com can be used for more than just CRM.

With its winter release you can build three types of application – pure Salesforce.com applications; composite web applications that mix site code with your own and third-party applications; and client applications that use the Salesforce.com service as a backend.

It's often hard to develop applications running on hosted services. Capacity varies from test to development systems, and test code is often forced to run with limited permissions and a subset of the working data. Salesforce.com now has a developer sandbox, where developers can work with a copy of their existing applications – and even a copy of the corporate data - without affecting live code. Staged releases allow services to be updated in a controlled way, and separate URLs allow new applications to be tested before release. Setting up a sandbox is easy enough. Log on, and set up the site with a couple of mouse clicks. Then just reply to the activation emails.

You can use the sandbox to build your own mashups with services from the AppExchange directory. You can also take advantage of the built-in JavaScript access to web services to quickly add code to include third-party applications. If you're working on applications that need to access internal services, you can work with containers that embed existing code (whether it's ASP, JSP, Cold Fusion or just plain CGI) and even whole sites. As the Salesforce.com libraries handle the containers, you can preserve session IDs and work inside its security model, even though you're using external data and services.

Salesforce.com takes a metadata-driven approach to application development, a familiar approach if you've worked with tools like Access or FileMaker. Tim Knight, who is Salesforce.com's EMEA technical director for AppExchange, points out that such kinds of application are ideal for Salesforce.com - not only are they often critical parts of a business process, they're hard to manage and keep updated. You could, for example, mashup Google Maps with your contacts database.

You start building applications by adding objects to a tab. Each tab is a component in the overall application, and can pass information to and from other tabs. A tab can be a container in its own right, with callbacks to handle display information, giving tabs a common look and feel. Ajax components can work with back-end services without reloading pages.

Once you've completed an application, and want to share it with customers, or even sell it to the rest of the Salesforce.com user community, a few clicks packages up your code and delivers it to the AppExchange directory. You can version your code, add it to a public directory, or only expose it to people who know the auto-generated URL. System integrators can use this approach to deliver quick-starts to customers, getting them up and running with an industry vertical application, before customising it in the Salesforce.com sandbox.

This certainly isn't application development as we know it, Jim. But it works. Metadata-driven development isn't new, but Salesforce.com opens it to a wider audience, and a range of APIs let you make it part of your business process - working just the way you want it to.®