Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘saas

Accpac 6 Online

with 6 comments

As we move to finish and release Sage ERP Accpac 6.1A, we are also working to host the Web Version of Accpac at I talked a bit about AccpacOnline and how it hosts Accpac currently as well as some of our plans here, this article looks a little deeper into how we will be deploying the Web version of Accpac Online, how we will be scaling it and how we will manage reliability. Of course as we develop this out, there will likely be some changes from what I am describing here.

The goal is to have an economically profitable hosted solution that can scale with our anticipated growth. Although it would be nice to assume we will be as successful as Facebook and quickly have 750,000,000 users, realistically we won’t and engineering a solution for 750,000,000 users doesn’t make sense. Like most companies you want to engineer your solution for the number of users you anticipate over the next few years and then as that materializes, you engineer for the next step.

Our initial goal is fairly conservative, and that is to host as many users on a web server as we currently host on a Citrix server. The Web server has a number of advantages over the Citrix server; namely it doesn’t run the UIs, so we save all the memory and processing by not having all those VB programs running, there is just the View portion then further the Web Server runs fewer processes and instead individual sessions are threads within a process, so this further saves resources.

Then we have the ability to scale out as many web servers as we need to accommodate our user load. As we move forward then we will work to increase the number of users that run efficiently on each server to make our solution better economically trying to scale to more users per server faster than we need to add servers.

To compare to how we deploy for on-premise installations, have a look at this article.

Below is a high level block diagram of how we will be running. This just shows the main components. I’m not covering everything, for instance this doesn’t show firewalls or other security layers that are present.

Hardware Load Balancer

At the left is a hardware load balancer. Its first job is handle encryption. All external requests come in using SSL. It is the job of this piece of hardware to decrypt all incoming communications and encrypt all outgoing communication. This offloads this onerous function from the actual Web Servers. Then its second job is to distribute incoming connections between however many Web Servers we happen to be running. Due to the way Accpac works we require that once a new connection is sent to one particular Web Server then all subsequent requests for that connection go to the same server, this is called operating with sticky sessions.


From the load balancer un-encrypted requests are routed to one of the IIS’s. If the request is for static content like bitmap images or HTML files then IIS just provides these. If the request is an SData request then it is passed onto Jakarta.


Jakarta is the connector which connects IIS to Tomcat. Besides connecting IIS to Tomcat, this connector has a number of very important jobs in a hosted environment. In our hosted environment we run a number of Tomcat server processes; each one running as a Windows service. Jakarta then acts as a software load balancer distributing requests across the Tomcat processes using sticky sessions again.

So why do we want to run multiple Tomcat processes and why do we want to operate a software load balancer on each server in addition to the main hardware one? The two big reasons are reliability and memory usage.

Accpac is still a 32-Bit Windows application. It runs fine on 64-Bit versions of Windows, but a 32-Bit process can only address 2Gig of RAM. As a consequence each Tomcat process can only allocate up to 2Gig of RAM and this is shared by all the threads running inside that Tomcat process. It’s easy and cheap now to get servers with far more RAM than this. So the way to utilize that RAM is to run multiple Tomcat processes each of which can utilize up to 2Gig of RAM.

The second issue is reliability. Of course we write our software to never crash and to never leak resources or do anything else harmful or bad. But the reality is that bugs happen and they have to be accounted for. If your Order Entry screen crashes, it only affects you and usually you just re-run the screen or at worst re-boot your computer. In a Web environment, something crashing on the server affects all the users on that server and re-booting a server is considered a very long time for a service to be down. Newer versions of Windows Server have gotten very good at isolating problems to an individual process, so when that process crashes, Windows can recover all its resources and happily continue working. So if a thread inside Tomcat (representing one user) crashes then the Tomcat process will crash and all the users using that Tomcat will be affected. Jakarta monitors this and if a Tomcat process crashes it will restart it. It also notes when a Tomcat process isn’t responding and will stop directing new requests to that Tomcat. Additionally you can configure Jakarta to stop using a Tomcat after some period of time (usually some number of days) and then when everyone is logged off it, restart it to recover any leaked resources. Generally the overall health and availability of the Web Server is being monitored and controlled by Jakarta. Of course we do extensive testing so these sort of events are infrequent, but they still need to be handled and recovered from.


Tomcat is a Java application server that runs our Java program that interprets SData requests. Then this Java application will call into the Accpac Business Logic (Views) to do the actual processing. Tomcat runs as a multi-threaded program in which each new request is handled from a pool of worker threads which do their job and then return to the pool. All the classic Accpac Business Logic then runs in the context of this program. As far as Tomcat can tell at this point, it is running as if it was on-premise and it doesn’t know about the other entire infrastructure that is going on around it.

SQL Server

Then off to the right of the diagram we have our pool of SQL Servers. Basically an individual customer’s company will exist on one specific one of these. Basically we manage these in exactly the same way we do for the current Accpac Online. In fact for a given customer, some users could be accessing the SQL Server through all the items in this blog and other users could be accessing it via Citrix and our current VB screens. All co-existing and sharing nicely.


This blog is just meant to give an idea of how we are setting up for running the web version of Sage ERP Accpac, hopefully you found it interesting.

Written by smist08

September 17, 2011 at 11:33 pm

Posted in sage 300

Tagged with , , , , , ,

SaaSifying Accpac

with 4 comments

I talked in general terms about types of cloud solutions in my blog post “Accpac in the Cloud”. In this blog post I’m going to talk more specifically about how Accpac currently runs in our environment and the changes we are making to support running the 6.x Web version as a true SaaS solution. is our current cloud offering for both Sage ERP Accpac and SageCRM. This site hosts Sage products as well as a number of associated ISV solutions. For the current Accpac we use Citrix to run separate sessions for each client logging in. Clients are load balanced across our servers, but any combination of clients can be running on any given server. There is then a separate cluster of SQL Servers to contain all the various customer databases. Below is a diagram of the infrastructure.

When you access Citrix to run Accpac, you first login to Windows then you run the regular Accpac desktop and get the regular Accpac desktop displaying its sign on screen. In the sign on screen you only get the list of your companies (and no one else’s) plus you can only sign on with user ids that are issued to you. So how does keep all the various users of Accpac straight given that several completely unrelated customers’ users can be running Accpac on the same server?

When you install Accpac you have to specify two directories the program files and the shared data directory. The program files are where all the program executables are stored, all the DLLs, OCXs and EXEs. These programs are the same for all customers of AccpacOnline and are shared. However the shared data directory is kept separate so that all the users for a particular customer get their own shared data directory and hence their own preferences, users and companies. But how do we do this? Since technically inclined users of Accpac will know that the location of the shared data directory is stored in the registry under HKEY_LOCAL_MACHINE which is global to all users. Basically we rely on Windows to do this, we install the program files to the regular location on c:, but then we install the shared data to a g: drive. This drive is a mapped drive that points to a different folder for each AccpacOnline customer. So when a user of that customer signs into Windows through Citrix, a login script then maps the G: drive to the appropriate folder for that customer.

This then gets the user up and running with the correct environment. This isn’t a security measure though; all the various folders are additionally protected by Windows security settings so users of a given customer don’t have any sort of access to data belonging to another customer. So even if they could figure out how to map drives to other peoples folders, it still wouldn’t work for their login id.

An alternative approach used by many vendors is to run a separate virtual server for each customer. Basically this model is managed hosting where rather than have a physical server on-premise; you have a virtual server in the cloud. However going this way is more expensive for a number of reasons. With the AccpacOnline model all the users are sharing the same installation, so for us, updating the program files is easy, we don’t need to login in to hundreds of virtual servers to apply hotfixes or product updates. Plus we are only running one copy of the operating system, so the operating system memory and resources are shared. With the managed hosting model each customer has their own copy of the operating system using memory and resources. This means that with the AccpacOnline model we can run many more users per physical server bring down the cost of the service.  The real game of cloud services is how you can architect it, to bring down the cost per user in order to run a competitive service.

Moving to Accpac 6

With Sage ERP Accpac 6 we are rolling out Accpac as a true Web based application. There are many reasons to do this that have considerable customer value. One of the primary reasons to move Accpac to the web is to improve the experience and to reduce the costs to operate to reduce the overall TCO. Basically we are looking to run a modern Internet SaaS business running Accpac. You will access it through the browser like most other Web based applications.

The key to today is that you first login to Windows, this then establishes which customer you are a user for and sets up the environment for you. The key point is that this is a two-step sign on process, first you sign on to Windows to establish which customer (or tenant) you are and then you sign on to a given Accpac user for that customer. In the web world we will do the same thing. Sign on will be a two-step process where first you sign on using the same credentials you would use to sign on to Windows, this will then establish which customer (tenant) you are and connect then present you with the Accpac sign on screen where you select which company you are currently using (and you can only choose from one of your own companies) and your session date. What is happening behind the scenes will be transparent to the user, they will just see nice Web screens where first they type in their user and password then next choose their company and session date.

In this environment Accpac is running under a Web Server and all customers are sharing the same pool of Web Servers. So we don’t have fancy Windows drive mappings to keep things separate for us. Back when we developed Sage ERP Accpac 5.6A, we knew this was coming, so we changed the Accpac API so that all calls would reflect the given customer (tenant) and retrieve the correct data for them. So most ISVs that develop third party applications should have adapted to this environment as part of supporting the 5.6A View Template. In the on-premise version of Accpac any older APIs are still present for compatibility. However in the version, these APIs will be removed (usually low level functions missing an hSIB or hPIB parameter).

The new Sage ERP Portal that was introduced in 6.0A is implemented as a common component and as a result keeps its data in separate files and databases from the main Accpac application. As a result it underwent a bit of refactoring to separate out this data by customer and to tie into the new multi-step sign on process.

When running our VB UIs under Citrix, multiple customers are sharing the same operating system running as Citrix users on the Windows Server, but each user is running their own copy of the various Acccpac EXEs and DLLs. Basically Citrix and Windows Terminal Services keeps each user quite isolated from each other and each gets their own running programs. This then becomes quite expensive on memory since each process has its own memory space. Although this is far better than virtualizing each customer, we can do quite a bit better. With the new AccpacOnline we will run far fewer processes. We will pool resources and requests will be processed by worker threads for the duration of the run. This then means each user uses far less memory and other server resources allowing more users per server and again reducing the TCO of the AccpacOnline service.

Of course we will have multiple application servers available to handle requests and then load balance these requests across the servers (as we do today with Citrix).

We won’t be combining client databases into one database like does. Part of what they do is a result of using Oracle as their database where each database requires a database server process running. We will be using SQL Server where we can have multiple databases kept separately within one SQL Server process. Further this allows us to use Accpac’s inherent multi-version support to allow clients to upgrade to new versions when they wish. Most ERP customers want control over version upgrades. NetSuite accomplishes this with separate sets of servers per version, but we can do a bit better than this.

Even though clients can upgrade when they wish, we will be trying to make it as easy as possible to upgrade. We call this frictionless upgrade. We want to reach a state where we can regularly roll out new product updates or even versions where clients are upgraded silently in the night and it just works the next day. We still have a ways to go down this road, but that is the end goal.


We are really excited about clients running Accpac both as an on-premise 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

Written by smist08

June 18, 2011 at 5:11 pm

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

Accpac in the Cloud

with 8 comments

It used to be that running in the cloud ( meant using a generic SaaS based web application, but now a days technology advances have offered many choices beyond this basic option. Virtualization technologies have advanced in leaps and bounds. Hosted solutions providers now offer many innovative options based on both regular and virtualized solutions. Plus the capabilities of SaaS web applications have improved quite a bit. Today Accpac has several cloud based solutions available and in the future we will have a full spectrum of solutions. Combining Terminal Services or Citrix with Virtualization is now a very powerful method of economically hosting enterprise applications. It is at the point where you can host your Windows based Enterprise application in the cloud and access it from an iPad (by running the Citrix client application

In some ways this wealth of riches has led to some confusion. There are so many options on how to deploy an application that it gets quite difficult to wade through all the choices and all the various claims being made by various hosting and application vendors. This blog post will attempt to outline the main choices and trade-offs, along with pointing out the various places that Sage ERP Accpac plays now and will play in the future.

Cloud Categories

The cloud usually means that a client is running an application on a remote server via the Internet. There are many ways this can be achieved. Many of the options come down to who owns what (you or the vendor) and what type of application is being talked about (Windows or Web based). However the following are the 4 main categories.

  1. Hosted Server. Server is owned by customer and maintained in a central data center but accessed via the Internet.  This is usually a Windows based application and the customer owns everything (server and software), but is outsourcing the physical care of the server and often other services like backup. A typical company in this area is Rackspace (
  2. Shared Virtual Server. A server farm is owned by the data center vendor and the client owns virtual server images that run on that farm. Here the customer owns the software (usually Windows based), but the data center owns the hardware. Typical of this is the Amazon EC2 service (
  3. Single Tenant SaaS. Vendor owns servers and images. Runs each client in their own image (whether virtual or multiple processes). Here the application is usually Windows based (but often we see web based applications here also). AccpacOnline is a good example of this.
  4. Multi-tenant SaaS. Vendor owns everything, client runs within a shared image or process (usually distributed over many servers).Here the application is always a Web application.

Any of these could be running web applications or desktop applications, but we highlight the most common cases above. The costs and who pays them is different in each situation and there are pros and cons to each. The differences between these are often blurred as companies offer hybrid solutions. Also some vendors try to define a category exactly as they implement it and claim anyone that does it differently is incorrect, but like anything there are always many choices.

Customer Goals

So why are customers demanding cloud based solutions rather than just buying software and installing it on premise? Below are some of the goals that clients are trying to achieve:

  1. Save costs by not having a data center. Save on requiring extra air conditioning, backup power supplies, hard disk backup and space. Save on routine maintenance like performing backups.
  2. Save capital equipment costs by not purchasing hardware which devalues quickly and needs to be replaced often. Have fixed constant monthly expense instead.
  3. Save capital software purchase expenses. Don’t want large up-front purchase, would rather pay much smaller monthly fee. Even if this is more expensive over x years, doesn’t require initial outlay. (Some on-premise software can now be “rented” as another solution to this).
  4. Save HR expenses by not needing to hire IT staff to run and manage corporate hardware and software.
  5. Don’t have to perform software installation or maintenance.
  6. Ability to access their applications safely and securely from anywhere in the world whether through laptops or other mobile devices.
  7. Desire to use a modern web-based application which has the ease of use of Facebook or Amazon.

When considering cloud solutions there are a number of problems that are usually cited that clients try to avoid:

  1. Lack of customization in cloud offerings.
  2. Lack of ability to use/integrate other software.
  3. Lack of owner ship of data. Lack of ability to get their data. What happens if the cloud vendor goes out of business?
  4. Security concerns, how safe and private is their data?

All solutions have an answer to these; customers just have to determine if those answers are sufficient, cost effective and achievable.

Vendor Goals

To be fair, many vendors are pushing cloud solutions quite strongly, and this isn’t for purely altruistic reasons. What are the vendors trying to achieve? Below are the goals that vendors are trying to achieve:

  1. Obtain a more steady cash flow. Steady subscription revenue, rather than relying on less frequent large purchases. Easier for financial planning and more recession proof.
  2. Obtain access to a larger market by being able to server the world from a single location.
  3. Can organize so only need to support one version of the software, reducing costs. Similarly you only need to support one hardware/operating system environment.
  4. Can have more direct contact with customers since you are sharing an operating environment – more control of ECE (Extraordinary Customer Experience).
  5. For hosting only vendors that aren’t software vendors as well, then this is their entire business, so of course they are selling it as hard as they can.

Sage ERP Accpac in the Cloud

Now let’s look at the options for Accpac in the cloud. At the beginning of this article we looked at four cloud categories, now we’ll look into how Accpac serves these four categories.

  1. Anyone can do category 1. This is basically just installing an on-premise application like Sage ERP Accpac 5.6A on a terminal server and then physically moving that server to a hosting provider for care and feeding. Then clients access the server either using RDP or Citrix client.
  2. This option is very similar to category 2, except rather than install on a physical server you install your software into a virtual image either provided or specified by the hosting vendor. Then you transfer this image to the vendor who runs and maintains it. If the vendor is associated with Sage or Accpac already, they may provide a virtual environment with Accpac already installed.
  3. Both Accpac and SageCRM have operated single tenant SaaS environments for some time with and  Accpac operates the desktop version of Accpac in a SaaS manner using Citrix to manage things, but each client runs in their own separate server memory space when running. SageCRM is web based but requires a unique instance of SageCRM running for each customer. Here you pay by the month, can run VBA macros, Microsoft Office and a selection of ISV products.
  4. Sage ERP Accpac 6.x has better multi-tenancy support than the current AccpacOnline because all clients run in the same server processes and share the same server memory. The goal is that once we have moved all the accounting screens to be true web based screens (after 6.1A), then we can deploy them as a SaaS solution. As part of the development of the infrastructure of Accpac 6.x, we ensured we plumbed in the support for a multi-tenanted deployment of this type. Once we enter this world we will be a try true web based application that doesn’t require Terminal Server, Citrix or Virtualization Technologies to run. It will be a modern web based application that you can run either on-premise or as a true SaaS web application.


It used to be that a big competitive advantage of a true web based SaaS solution was a much lower cost by being able to run far more users per server. However with all the advances in Virtualization Technology and Terminal Server/Citrix a lot of this gap has been narrowed, making solutions of this type very cost competitive.

As we can see Accpac already has many options for cloud deployment that achieves many of the customer’s goals in considering a cloud application. Then in the future we go beyond this to offer a true Web Based SaaS solution. As these technologies progress the TCO (Total Cost of Ownership) will come down as we can host more users per server. For clients it becomes easier to get customized solutions in the cloud with all the attendant cost savings, including better usability and accessibility.

Written by smist08

December 4, 2010 at 6:30 pm