The Challenges of Managing SaaS Projects

Even experienced developers can run into problems developing and deploying custom applications for software-as-a-service platforms because SaaS vendors don't always embrace the accepted corporate processes for build, test and release. The trick is to adapt your configuration management processes to meet SaaS challenges.

Even experienced developers can run into problems developing and deploying custom applications for software-as-a-service  platforms because SaaS vendors don't always embrace the accepted corporate processes for build, test and release. The trick is to adapt your configuration management processes to meet SaaS challenges.

Software as a Service (SaaS) Definition and Solutions

SaaS is popular in part because applications can be made available without the long deployment cycle typical of on-premise development. So a new report can be delivered immediately or a new field can be added to a data entry form on the fly.

But as SaaS offerings such as Salesforce.com have matured into full-fledged development platforms, the complexity of applications has grown dramatically. A salesforce.com application may have features such as real-time Web service integration, automated e-mail and Web feeds, and batch integration to operational systems. This increases the risk that a minor change could impact critical business processes or break the application.

It is often challenging to apply best practices for configuration management in SaaS environments because:

* The application may be supported by business, not IT.

* SaaS administrators may not be familiar with configuration and release management practices.

* SaaS deployment tools are still maturing.

* Deploying an application often requires both manual and automated steps.

* SaaS integrations require synching releases with legacy systems.

* Code, configuration, deployment scripts and manual checklists all need to be checked into the source code repository.

Consider the development of a Salesforce.com application from a traditional developer point of view, with the goal being to manage development in the most controlled fashion to ensure reliability.

The Force.com platform, Saleforce.com's custom development platform, is based upon the Model-View-Controller paradigm. This paradigm can be defined as:

* Model represents the database structure. This is configured via the salesforce.com setup menu that allows administrators to add custom fields to standard CRM data objects, like leads and accounts, or create new data objects with their own custom fields. As soon as a field is defined or modified it can be queried via SOQL, the Salesforce.Com Object Query Language, or SOSL, the Salesforce Object Search Language used for free form text searches.

* View represents the user interface. Salesforce.com has a built in forms editor for "page layouts" that are associated with data objects. Pages can also be developed in Visualforce, salesforce.com's markup language that is tightly integrated with Apex code, Force.com's programming language that is based on Java.

* Controller represents business and application logic. Rules for field validation, workflow and button actions are configured via the setup menu. Custom business logic is developed as Apex code associated with triggers, Salesforce.com's version of stored procedures, Visualforce controllers, or as shared class libraries.

Force.com development uses practices that should be familiar to most Web developers. Salesforce.com allows copying the production environment or "org" to a "sandbox" just as you would copy the production data model and code to a development server. A sandbox can house a full copy of production data, code and configuration, or just configuration.

Development is done using the Force.com integrated development environment (IDE), an add-in for Eclipse that lets developers  create a project linked to a development org, production org or sandbox. A project can be synched to a code repository, allowing check-in and check-out of code.

Apex has a built in unit test framework that requires 75% coverage for all Apex code before it can be deployed. The Force IDE deploys code from a project to a production org.

How to address audit, security and business continuity upfront

Configuration management traditionally looks at production configuration and code as a "baseline," identifies changes that will be released, and incorporates them into a new, auditable baseline once the release is validated. Ensuring reliability for the enterprise involves:

* Limiting which users have a system administrator profile and defining their configuration management responsibilities.

* Putting procedures in place to insure that code, configuration and data for production are checked into the code repository and archived (this may require taking manual snap shots of sharing rules, the role hierarchy and so on).

* Creating manual or automated installation scripts.

* Making sure that there is a plan for backing out production changes if needed.

* Deploying to a sandbox for testing and QA.

* Repeating the deployment to production.

* Validating the deployment in production.

The gotchas

Even senior developers can get lost in the weeds trying to figure out how a feature can be, or might have been implemented, in Force.com. Typical "gotchas" include:

* With numerous configuration options and powerful programming tools there are many ways to implement the same features. Configuration experts and developers run the risk of reinventing the wheel if they do not collaborate closely on solution design.

* Force.com deployment tools do not currently support critical items such as data sharing rules, picklist fields on standard data objects, lead and sales processes, and the management role hierarchy.

* Apex unit tests are impacted by actual org data, so code that passes unit test requirements in the sandbox may not deploy. For example, data queries on objects with more than 100K of data require querying an external ID field. Unit tests that pass in a sandbox can fail in production, killing your deployment.

Success is all in the plan

Getting configuration management under control is much easier if the development and testing teams are on the same page from day one. While typical build/release cycle looks like this:

* Check in code.

* Compile code.

* Run database scripts and deploy code to test.

* Run tests/inspections.

* Deploy to pre-production/production.

* Validate deployment.

The following tasks need to be adapted for Salesforce.com development:

* Check in code and configuration from development.

* Check in task list for manual changes to the code repository.

* Deploy manual code/configuration changes to test.

* Run Eclipse/Ant automated deployment to test.

* Run tests inspections.

* Deploy using same process to pre-production/production.

* Validate deployment.

SaaS software development platforms such as Salesforce.com require a mix of configuration and custom development that can confuse developers and be difficult to deploy. This can be addressed by adapting your configuration management processes for SaaS projects.

Although SaaS offerings are designed to limit the time spent on traditional development, some tweaking is required in order to fully integrate them with enterprise systems. Once you understand how standard programming and configuration management practices apply to a SaaS application it becomes easier to tackle with the traditional approach.

Hamilton is a CRM technical architect at Acumen Solutions, a business and technology consulting firm. Contact him at ghamilton@acumensolutions.com.

This story, "The Challenges of Managing SaaS Projects" was originally published by Network World.

Copyright © 2009 IDG Communications, Inc.

7 secrets of successful remote IT teams