Archive for February 2011
The pace of technological change seems to really be accelerating these days. Here at Sage we want to ensure our products can utilize or integrate to all these new advances. We want to ensure we are ready for any new disruptive technologies that come along.
Product Management normally gathers features by studying the market, by talking to customers, evaluating the competition and generally learning what the market is asking for. This works well for adding business functionality and accounting features, but it tends to not work so well for predicting the impact of disruptive technologies. This is because most of the market isn’t aware of what is coming and describing it can be quite difficult.
What we need is a method to present disruptive technologies to the market in a manner that is understood in the context of their ERP and CRM business applications. Many times, these days, new technologies are presented in how they can benefit say Facebook users, but then it isn’t clear how these ideas can apply to the Enterprise.
Sage ERP Labs is an initiative of the Sage North America Mid-Market ERP (MME) group to provide framework for doing this. We are providing a forum for gathering and sharing ideas, and then a framework for developing Proof of Concept (POC) demos that can be used to evangelize and showcase new technologies in an Enterprise framework. These POCs will be developed across all our products including Sage ERP Accpac, Sage ERP MAS 90 and Sage ERP MAS 500. We will also be considering ideas around our connected services initiative.
We will then take these POC’s and present them to customers, staff, and analysts to get an idea from the market whether we should then add these to our release roadmap to productize and include in a future release. The goal is to start a conversation with our various stakeholders on how these often esoteric ideas can benefit them. Often the initial ideas won’t work directly, but with some work and lots of feedback can be translated into truly innovative features with real ROI.
To some degree this has been going on already informally in people’s spare time (see the examples below). What we want to do is to nurture this innovation and be able to allocate people’s time to develop these ideas. Basically to become much more enterprising in our endeavors. To make innovation become much more a part of our Normal Operating Rhythm (NOR).
The official Sage ERP Labs initiative is new, but it sprang out of a few POC’s that we did over the last year around Sage ERP Accpac 6.0A.
Social Media is a huge topic these days. So much marketing and corporate customer connectedness is happening via Facebook, LinkedIn, Quora and Twitter. Companies are asking how they can leverage that from their ERP. What does that mean? We created an integration to the Accpac 6 Portal which I blogged on here. This was just done via customization, so people can use this now if they wish. But the main point was to provide some context to start a conversation on what people really want. It’s easy to just add a feature to satisfy a feature sheet check box, but to provide real value takes a deep understanding of people’s problems and how to solve them in a real and meaningful way. So this is just a starting point, and then as we add Social Media to the core product going forwards it should be a much more integrated, holistic and valuable feature, than just adding some links and connections to random web sites.
These innovations don’t need to just target end users. They can also target the developer community. Sage ERP MAS 90 has a plug-in for doing ProvideX development in the Eclipse IDE. Originally for Accpac 6 development you did your coding inside Eclipse, but then a number of other activities in other tools like our screen designer in IE. So why not take the expertise we had from creating the MAS 90 Eclipse plug-in and create an Eclipse plug-in for Accpac? Which was done as a POC and is now part of the standard SDK and blogged on here.
We are currently in an idea generation phase, once we have a good selection of ideas, we will select the best ones to proceed to POC stage. Once we have the POC Demos, we will begin socializing these to get feedback on what really needs to be done (or not done) and then hopefully start including these innovative ideas as real useful features in our core products.
If you see one of these demos, please provide some feedback. You can have a real impact on future releases and a say in the direction.
This initiative has been rolled out to members of our R&D team but if you have an idea, feel free to e-mail me at Stephen.Smith@sage.com and I can enter it into the system.
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).
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.
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.
One of the good things about moving to Web development is how fast things change. When we developed using Visual Studio for Microsoft Windows, there would be a new version every three or four years and things didn’t change that much. At least until .Net came along, then there was one very big change and then things resumed at their usual pace. With the Web world and using the Google Web Toolkit (GWT), there is a new release every three months or so and many of these releases involve fairly major changes. Fortunately we had adopted the Agile Software Development Methodology at the beginning of Accpac 6.0. This gave us a mechanism to live with-in the fast changing world of the Web.
At some point during Accpac 6.0 development we froze taking new versions of GWT. This was part of stabilizing our product, so we could finish all the features and produce a solid release. The version we froze on was GWT 1.7. Part of this was that the next release was 2.0 and we felt absorbing those changes could jeopardize our release date. Now that we are onto Accpac 6.1 development we have moved up to the current version of GWT which is 2.1 and are excitedly awaiting the release of 2.2. We will try to stay current with the newest version of GWT for as long as possible through the Accpac 6.1 Agile development.
This blog posting will talk about some of the new features that we have picked up moving to GWT 2.1. Some of these provide better product functionality and performance. Some of these provide better developer productivity.
New Event Model
The big change for us going to GWT 2 was a change in the event model. Up until 1.7, you added a listener to receive any event. Basically you just registered the object you wanted called when the event happened. This model has been replaced by a handler model. There are quite a few technical reasons that make this a better approach, but for us we gain two main benefits. One is that it sends all the events through a central queue and makes the order that things happen much more predictable. This greatly simplifies things for us and allows us to simplify our code and not worry about so many cases when focus is lots and such. The second thing is that it vastly improves keyboard handling. The keyboard handling is a major concern for the productivity of heads down ERP document entry clerks. With this change, the keyboard handling becomes much better, especially making it uniform across all browsers.
New Table Control
Another big change is to the Table control. Google has re-written the built-in table control from scratch and called it the CellTable. The table control is now much lighter weight and provides better functionality and performance. ERP packages rely heavily on their table control for fast efficient data entry. Google is a pioneer in getting the most power out of Web Browsers. With the new table control they have raised the bar over all competing libraries. For Accpac it is nice to get this extra functionality at very little cost from the core GWT library. The CellTable is part of Google’s new Data Presentation Widgets which introduce a very efficient virtual scrolling scheme that we are taking advantage of. Virtual scrolling is the ability to load just a small window of the total records available into the Browser, but then load additional records as needed as you scroll around.
GWT 1.x had the concept of an image bundle. Here you combined a bunch of small image files into a single large image file. This improved performance by only having to download one file (or check if one cached file has been updated) rather than a whole bunch of small files. Generally reducing the number of round trips to the server. Modern Web Sites are generally composed of many small graphics that provide visual richness with aspects like rounded corners or special shading that HTML doesn’t provide by default. We use this in the current product to help the initial Portal page load quicker. GWT 2 then extends this concept, with client bundles, to let you bundle together other common resources such as XML files, CSS files and more image files (a few specific ones couldn’t be bundled). This then improves our performance further by removing these files from needing to be downloaded separately.
GWT 2 introduced a feature called Deferred Binding, this allows us to build several Accpac screens together as one GWT object. The advantage of this is that it improves caching. You only run what you need for a screen, but then the Browser can cache all the shared bits, so running one screen, will help speed up the running of the next screen. This also saves some disk space (not that this is so important these days). A bigger advantage of this is that is speeds up our compile or build time, since it takes about the same time to build 10 bundled screens as 1 separate screen, so we can get a 10x improvement in build times. This greatly helps us with our continuous build/integration environment to be quickly checking things as we check in new code.
With GWT 2, Google has greatly improved their Eclipse integration. There is now a Google plug-in for Eclipse that adds direct access to a number of tools and wizards. This is nice for developers to have quicker access to a number of things.
In Browser Debugging
With GWT 1, you had to debug using Google’s built in hosted mode debugger. This caused some differences between debugging and running in a real Browser. With GWT 2, you now debug directly in the Browser. Debugging is controlled by a browser plug-in which are available for IE, Firefox, Safari and Chrome. This is nice because now you can check out how style sheet changes work in different Browsers while you debug.
Below is a screen shot of an Accpac screen running in the Chrome Browser stopped at a breakpoint in Eclipse:
At this point we can examine variables, single step through code and do any normal debugging activities. Then we can resume execution:
Better Code Generation
As Google develops GWT, with each version they make the code more efficient, so we get some benefit just by re-compiling with GWT. Plus as Browsers evolve GWT can take advantage of newer features to reduce code size and enhance performance. Especially as various parts of HTML5 start appearing in various Browsers, our programs automatically will use these features where it makes sense. The evolution of the Browser is accelerating again, IE 9 should be released soon, Firefox is planning three releases this year and Chrome is speeding along as usual.
By using the Google Web Toolkit, Sage ERP Accpac is able to gain many advantages from version to version just as a result of using this toolkit. Combine this with the applications features our programmers are adding and we’ll see the speed of Accpac development really accelerate.