Stephen Smith's Blog

Musings on Machine Learning…

SaaSifying Sage

with 9 comments

Sage is a large company with many products, mostly ERP and CRM for various sized businesses. Sage has many on-premise products such as Sage ERP MAS 90, Sage ERP MAS 500 and Sage ERP X3. Sage has many SaaS cloud/web based products including SageOne, Sage Spark and Pastel MyBusiness Online. Sage has many products that are sold and deployed both ways such as Sage ERP Accpac and Sage SalesLogix.

SaaS strictly speaking stands for Software as a Service and usually refers to companies that host web sites that perform various applications such as NetSuite and Salesforce. These companies try to sell against on-premise vendors siting the following advantages:

  • No upgrade costs, upgrades are transparent and continuous (and no extra cost).
  • Easy per month subscription pricing (no up-front large purchase)
  • Customers don’t need to maintain any infrastructure such as servers
  • You can access their applications from anywhere from any device

On-premise vendors then answer with the following advantages:

  • You own your own data. (SaaS vendors have had customer data auctioned off when they’ve gone out of business).
  • You control data security; your data is never on the Internet.
  • You control when you upgrade, it’s never done unexpectedly and so can’t disrupt your business.
  • You have your own copy of the program that you can customize as much as you like.
  • The cost of direct purchase of the software over the life of the software is cheaper than subscription pricing.

Neither side is perfect at any of these. But it gives an idea of how the debate goes. From a development point of view, SaaS has the appeal of only supporting one version. Right now at Sage we support the current version along with two prior versions. This support takes R&D resources investigating problems and providing updates. There is a lot of appeal to R&D concentrating resources on the current version and ignoring anything that came before (don’t worry I’m not going to be allowed to adopt a one version support policy).

Cultural Change

Here at Sage we want to try to bridge the gap and try to provide products that are the best of both worlds. Most people think that you need to choose the advantages of SaaS OR choose the advantages of on-premise. We want to change that OR into an AND, providing the advantages of both combined. Doing this will be difficult, but technologies and processes are evolving and advancing to a state where we can start to do this in many areas.

But the big change is cultural. We are changing our corporate culture from being an on-premise vendor to being a SaaS vendor. Even for products that will never be SaaS, that will always be on-premise, we will develop them in the same way that SaaS vendors develop products. In this way we will pick up many of the benefits of SaaS without losing the benefits of on-premise.

At the same time we will be developing and releasing many of our products both as SaaS or cloud based solutions and on-premise.

Agile Development Process

As a starting point all R&D groups at Sage have either already adopted or are in the process of adopting the agile development methodology. This is the methodology used by most SaaS vendors to allow them to continuously update their applications. The concept is to develop in small “sprints” which are typically two or three weeks long. Everything started in a sprint must be finished in a sprint. The goal is that at the end of each sprint, the product is ready for release. A good SaaS vendor can actually deploy every sprint end build to their live site. One of the keys to accomplish this is to have a very large and complete set of automated tests that can validate that each build works properly and has very high quality. Accpac has used Agile for about a year to create the 6.0 release. MAS has used it for two years for their 4.45 and 7.3 releases.

With Agile development we don’t accumulate quality debt like the waterfall method, so we don’t have long Q.A. and regression test phases. This makes our development more efficient. Also creating all this automated testing causes bugs to be found much quicker making fixing them much cheaper. Another side effect of all this automated testing has been to improve the general quality of our releases.

Part of Agile is that you have a Product Backlog that consists of a list of everything you want to do with a product. New feature ideas are added here. Then a set of Product Owners order this list by priority and development always takes the item at the top of the list to do next. This way R&D is always working on the most important thing and then if we do more frequent releases with fewer features then there should still be a lot of value since we are doing the most important things for the customer. This also means that for a customer, that if something doesn’t make the cut, they don’t have to wait for a future 18 month later release, then only need to wait for a future 3 or 4 month release.

Ease of Installation

Ideally a SaaS vendor will update their product on a regular basis, perhaps every few months. In an ideal world the only thing the customer notices is suddenly some great new features appear. Otherwise the customer didn’t have to do anything. Practically speaking, many SaaS vendors tend to regularly break customers with features and cause training problems, remove key features or cause bugs. However if a SaaS vendor does this badly they will be replaced by a vendor that does this well in short order.

In the mid-market on-premise world, vendors have the bad habit of relying on their business partners. They (we) put in a great new feature, and it makes upgrading hard. Now we have a choice, we can spend the time to make the upgrade transparent or we can add another new feature. There is far too much temptation to add the new feature and leave it to the Business Partners to deal with the upgrade difficulties. Then we are surprised to hear from customers complaints about large upgrade costs.

As we go to more frequent releases for our on-premise products, we can’t keep this up. We are now spending more resources making installation and upgrade an easier process. For instance a main goal of the new MAS-90 business framework is to allow customization via object oriented programming rather than source code. Moving source code customizations from version to version is hugely expensive and as a result, we are phasing out source code customization in all our products. Similarly Accpac combined our install and data upgrade process into one per release from one per module per release to ease upgrading. Further we are working to make all report and screen customizations completely safe from version to version.

We still have a long way to go, but ultimately we would like our on-premise products to seamlessly download new versions from the Internet, update themselves and continue working without any extra work being required. We would of course allow customers and business partners to control this process, but we would ensure all data is migrated seamlessly along with all customizations. But the goal is to make upgrades as seamless and painless on-premise as SaaS.


With modern virtualization technologies we can offer any of our on-premise applications hosted in our data center (i.e. in the cloud). These are then accessed with Citrix client or remote desktop and the client can use these just like they are on-premise but without the expense of buying and maintaining the servers. These are also offered via subscription pricing and common maintenance tasks like database backup are taken care of. With this model customers can move back and forth between cloud and on-premise as they wish, or have some locations access via the cloud and some run on-premise. We also facilitate that customers can take a copy of their databases at any time so they can be re-assured they won’t lose anything. You can even access your application from an iPad using the Citrix iPad application. This option alone gives many of the advantages of both SaaS and on-premise combined.

Then many of our applications are moving to Web interfaces such as Sage ERP Accpac 6. These will also be available via SaaS and on-premise, but the SaaS version will be a true multi-tenant SaaS version similar to our competitors. Here our applications will have true HTML/JavaScript based interfaces that run in any Browser on any device, so you gain all the advantages of SaaS and have many of the options as on-premise.


Today on-premise applications have a huge advantage in customization capabilities over SaaS products. However technology is changing and demands are changing. Many SaaS vendors started with no customization capabilities and have been bolting on customization features ever since. However technology is improving and the ability to customize SaaS is greatly increasing. Plus the trend is for customers to be shying away from such heavy customizations due to the large development and maintenance costs.

All Sage products are built with a customization model to start with. We don’t have to bolt a customization model onto a fixed schema database model (where all customers share the same database schema). So as we move our products to SaaS, all the customization capabilities come with them.

The one change is that for SaaS we have to move away from true source code customization. Where you just modify any source code you like in the system. You can certainly write code and extend our system in an object oriented manner, but you can’t change the underlying objects that make up the core functionality. This is a more disciplined approach, but it allows customization in the cloud and it keeps the costs down for customers, since this allows these source code customizations to be upgrade safe.


Sage is changing to do all software development like an ideal SaaS vendor. We are looking to bridge the gap between on-premise and SaaS based applications. We are pursuing the ambitious goal of combining the best of both worlds.

In much of Sage’s marketing material you see the three columns that we are pursuing through development:

To a large degree this involves improving our current on-premise products, including offering flexible deployment and subscription pricing models and simplifying the upgrade process. Then developing SaaS versions of our key strategic products including full modern Web Based interfaces and then connecting the two worlds with our connected services strategy.

Written by smist08

February 20, 2011 at 8:07 pm

9 Responses

Subscribe to comments with RSS.

  1. […] View original post here: SaaSifying Sage « Stephen Smith's Blog […]

  2. First, I’d point out that most SAAS providers don’t have much of a track record to compare against so it’s easy for them to tout the ease at which they add new features and upgrades.

    I was reminded of this when I recently was reviewing some help desk software that’s very popular — and very SaaS.

    The problem is that that the UI looked confusing and dated (which the publisher freely admitted).

    Ultimately my conclusion was that although this was SAAS — it was MATURE SAAS (having been around many years) and exposed one lethal chink in the armor of these relatively new SAAS players….. 5 or 10 years down the road when the online product is no longer brand new there’s a very real possibility that SaaS will run into the same issues that the more mature on-premises solutions face today (about not wanting to make source modifications that break prior code).

    Also, I applaud this thinking below — I believe strongly that every software publisher should work to make the upgrade process seamless, effortless and an afterthought — even when it means putting VARS out of the “annual $10,000 upgrade” business.

    “We still have a long way to go, but ultimately we would like our on-premise products to seamlessly download new versions from the Internet, update themselves and continue working without any extra work being required. We would of course allow customers and business partners to control this process, but we would ensure all data is migrated seamlessly along with all customizations. But the goal is to make upgrades as seamless and painless on-premise as SaaS.”

    Wayne Schulz

    February 21, 2011 at 1:01 am

  3. […] This post was mentioned on Twitter by Keith Cerny, smist08. smist08 said: Blogged on Sage adopting a SaaS mentality – […]

  4. Good post Stephen and nice to know about the initiatives at Sage. Being a partner of Sage, we all await to see what’s happening and what’s on the plan.

    It’s true that SaaS as a concept is just making its inroad at many developing countries. It is also true that it poses stiff challenges on territorial/geographical sales. But, since the break-even is achieved quickly, many larger software companies who are totally into other revenue segments are keeping an eye on this sector as a non-linear revenue stream.

    The concept has to be understood in total, which is what is missing and rather happens partly in a faster time. Also shakes up the data center business pretty much.

    Sundaresan Ramanathan

    February 25, 2011 at 1:10 am

  5. […] Within Sage we are trying to operate with a SaaS mindset and I previously blogged about that here. Once you have working software, you have a lot of options as to what to do with it. You have far […]

  6. […] installed Web application and as a true hosted Web application. I previously blogged about SaaSifying Sage and a lot of that ties in to how we deliver and operate […]

  7. […] Of course things aren’t quite that rigid anymore. Most development groups (including Sage ERP) have adopted the Agile Software Development Lifecycle where the development team is implementing features in small batches taken from a product backlog. The product backlog is in priority order so the higher priority features are implemented first. A side effect of this is that for lower priority items in the backlog, Product Management can swap these out with other higher priority features as business needs or understanding changes. This then leads to greater flexibility and does allow some newer customer suggestions to make it into a product sooner. I blogged on some aspects of this here and here. […]

  8. […] talked a bit about SaaSifying Accpac and SaaSifying Sage. Today I’m going to talk a bit more about continuous deployment which is one of the end goals of […]

  9. […] to releasing updates on a much frequent basis. I’ve blogged about this before in these articles: SaaSifying Sage and SaaSifying Accpac. This article is really just covering one aspect of this process, namely […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: