Every project has the following steps: business requirements analysis, design, build, test and deploy. Yes, the steps can be mixed and matched and 'agiled', but for our purpose, let's keep it simple.  Let's take a look at each of these steps and see if a SaaS delivery is going to have a major impact on the project timescales.

Business requirements analysis usually takes the same amount of time, regardless of whether the solution is on-demand or on-premise. We need to define what business problem needs to be solved and break it down. In most part this is largely independent from technology.

However, the design phase is likely to be shorter on a SaaS project for one major reason; the ability to drive design through a solution prototype. Of course this is not a new concept, and it has been done with on-premise apps. However, on-premise solutions tend to face tougher challenges, environments are often not ready, configuration takes too long, etc. It is just a pain. So, what we have with SaaS is less time spent messing around with revisions of screen mock-ups and drawings; the concept is to dive in and show the client the application in action from day one. Prototypes give users a real idea of how the solution will look and feel.

The build phase is also significantly faster, where out of the box configuration is used to create the solution. SaaS environments tend to be more stable, and a lot of complexity is abstracted away resulting in rapid configuration which generally 'works first time'. The prototype created during design can be leveraged as a 'quick start'.  However, the magic disappears where custom development (coding) is concerned. This usually takes as long in the SaaS world as it does in on-premise.

Test runs of the solution functionality can take just as long in a SaaS solution as it would in an on-premise solution.  This is because there will be the same number of scenarios which need to be tested to cover user processes.  However, where an issue/error is uncovered, the time taken to make the correction is likely to be significantly lower, owing to the ease of change on SaaS applications.  Also, there is less 'banging head against brick wall' instances due to errors caused by  'server down' issues or failing components, which tend to occur in a new and shaky on-premise infrastructure.

Deployment in SaaS tends to be far more straight-forward than on-premise, as most products do not require any form of installation, just access via a web browser.  SaaS really comes into its own where the application is to be delivered to users spread across multiple locations. Remember that in theory all a user needs to access a SaaS application is an internet connection and sufficient security credentials at their location.  There is no system infrastructure for the customer to support.

So all in all, SaaS implementations are usually delivered in shorter timescales than on-premise implementations.  Timescales can become extended where the solution becomes highly customised, but where possible these customisations should be kept to a minimum to allow for rapid delivery, as well as ease of maintenance down the line for the organisation.  Also, and this can be the big 'gotcha', data migration and integration timelines will not differ too much between SaaS and on-premise projects. The same old issues around cleansing/mapping/connecting occur, regardless, which tend to beef up timescales no end. But on balance, the time savings with SaaS make this a preferred option if comparing 'apples with apples' functionality wise. So what are you waiting for?

Calum Murray is Head of SaaS Practice at Capgemini UK

One of the interesting things about the challenges of Software as a Service (SaaS) brings is not necessarily that new technology brings new problems, but that it offers new spins on the problems we already have.

Take the biggest challenges as examples: integration and data migration. If your SaaS solution needs to interact with systems outside of your SaaS provider's domain, you need to spend some time figuring out how to do that. It is in a SaaS provider's best interest to provide you with multiple options to get data in and out of the system. There are also Integration as a Service options where, as long as both ends of your system can be reached over the Internet, you can extend your integration options further (for a price). There are many options available, but allocate reasonable time and budget to figure out how your SaaS solution is going to fit in with the rest of your application landscape.

Similarly, it's in the best interest of SaaS providers to make it as easy as possible to get your data into their domain. But unless you're starting afresh, don't underestimate data migration (I'd be interested in any stories of your experiences). One of the speakers at the recent Cloudcamp told of their experience of a customer who moved to a SaaS solution as it was the cheaper option, but didn't migrate any data; they just set people up on the new system who presumably were then left to migrate what they needed manually! People are looking at SaaS and other related technology to save money on developing the applications they need; the savings are there to be made but there's no need to throw the baby out with the bathwater.

As with any new technology, whichever SaaS provider you work with, your application developers are going to spend some time adapting to their new environment. Once again, the SaaS provider should do its utmost to make developers feel at home. But multi-tenant environments place limits on what you can do and try and force you into their "best" way of do something. Salesforce.com application developers are probably familiar with forum threads such as this one; and when Google App Engine was first released, not everyone was prepared for the change in mindset required. Understand the limits imposed by your SaaS provider and make sure you're able to do what you need to within those constraints. Otherwise, at best, you'll end up paying more for it.

On that same point, when developing with SaaS or Platform as a Service (PaaS), you're playing in someone else's garden and you need to play by their rules. Give your developers the space to figure out and learn these rules, don't just look at the syntax and assume that because it looks like something else your team already knows, there won't be any overhead.

One thing to keep in mind is what requirements your SaaS provider can and cannot meet. Of the SaaS offerings out there, is there one that is going to meet all of your requirements? What are you options when your SaaS provider doesn't offer something that you need to have? Partner applications can help fill in these gaps, but will usually add to the cost and add another point of integration for your solution.

Finally, there are plain old, boring infrastructure issues. When delivering applications over the Internet, obviously a network connection that is able to cope is essential. It sounds easy, but how many people do you know that have complained about the Internet connection at work? Are you deploying a SaaS solution to increase the mobility of your workforce? If so, are they going to have the necessary connectivity when they need it?

Those are just a few of the technical challenges SaaS can pose, but this post is by no means comprehensive, nor is it meant to be. There are topics I intended to cover, but I'm sure they'll come up over the coming months on this blog anyway. There are also some topics I've avoided altogether, as they'll take up series of postings on their own! More importantly though, I'd like to hear about what challenges you've faced when implementing SaaS solutions - feel free to comment.