Operations Savings Over GUI When Deploying With Web Applications

(This document is attached as a PDF at the bottom.)

Sometimes one will over look operations costs that can be eliminated or substantially reduced with deployment of web applications compared to GUI apps. This article includes some formulas that can aid in computing the differences in cost so you can compute out the numbers for your own company/organization.

I write this because often financial decisions thrust upon the client are not a big part of software development strategy/financial analysis. However, these costs are a part that customers (at least the ones doing due diligence) will take into account in determining the use of your application. For internal use, one can use the numbers as leverage for other items and needed equipment/software.

This document is written in the most part to readers considering the web or GUI for application development with Progress Software's OpenEdge development tools. However, often, it can be used in generic terms with other GUI vs web application development systems (such as C++ GUI v C++ web).

Properness of Web Apps

First, before slapping around GUI apps, we should look at scenarios where they are required. Should one be using the CPU power of the computer for user composed illustrations (such as graphics editing, animated computer graphics, etc.) Then of course, the application should reside on the user's computer. Another example can be found for sound – often if one is editing sound or the like, that will need to be done on it's own computer.

However, if the purpose is simply to provide input and output screens, as well reports, based on records usually held on another computer in a RDBMS – often a GUI interface will not be a requirement. A web page can organize information just as easily (if not easier) opposed to a GUI interface.

This especially comes true when some information is shown on a particular page (or screen) for one user compared to another user who might be authorized to see more types of data on the same screen (A/R accountant v Payroll accountant).

Additionally, many other applications are web based, so one can include links on the web based application to other places on the web. This is not as straight forward in GUI apps.

Remote Desktop and Citrix, etc.

One might say, upon reading the arguments below, that one can simply remote desktop [1] into a computer or use a virtual interface like Citrix [2].

I can say Citrix will require additional licenses that are a cost in themselves – and even if there is no cost in licenses, there will be a cost in IT resource time to configure the clients for use.

If the GUI installation is on Apple OS X equipment, or other apps that are providing a virtual machine of some sort on that physical machine to provide Windows operating system compatibility (tablets), one can pretty much figure on the cost of a virtual machine to run it on. This presents us with the formula:

Where:

• VirtualMachineSoftwareCost is the cost of the license;

• InstallationCost is the amount of dollars spent on an IT resource needed to install and configure it;

• The number of machines it will be installed on.

Remember if one is implementing client software such as remote desktop or the like, the equation in EQ 1.0 will pretty much apply also as this variation:

Where

• RemoteClientCost would be the license cost;

• ConfigurationCost is the dollars per installation spent on configuration of remote access by an IT resource;

• And of course the number of machines work is being performed on.

Most operating systems and devices come with a web browser, thus this portion of cost is completely eliminated with web applications.

One might also say “Well, I have a shared drive.” In companies that have multiple buildings, I have encountered different connection speeds between them, which can cause the app to appear sluggish to some people while perfectly fine to others. A shared drive might work out for one building, but if ther are multiple buildings, one should try to work around this problem.

Opportunity Cost

Of course, the web does allow access to systems that the GUI client will not work on – such as OS X and Mobile devices. When selling a GUI application with Progress, you are out of luck on Mobile devices and can ham-fist the client on a virtual machine for OS X [3].

I speak from experience that for many smaller businesses where the original entrepreneur still plays a role, they often have Macintoshes. There are other businesses that are very Mac oriented where the application might play a role (such as time keeping), however, a GUI app will not run on those without a virtual machine.

There is an increasing proliferation of user devices being used – such as Mac and Smartphones – and if one says “Sorry, no go” then the company may very well say the same thing to your sales or internal deployment strategy.

It is no secret that smartphones and tablets are quickly becoming a stand in for laptops in many uses.

A web application allows for sharing of code across many devices, although there will be little bits of difference depending on the device. A Progress GUI application will be a complete failure on these types of devices.

Thus, from a sales point of view the cost is:

Which is pretty straight forward.

From an internal point of view, the cost is:

Where:

• the Savings Operations is that amount saved by use of the application;

• Profits Operations might be the extra productivity that might have been achieved with the application.

Note: SavingsOperations and ProfitsOperations might be different based on the part of the company using the software.

Deployment

So, lets get to the point regarding installation of GUI apps and their costs.

The base deployment formula is the cost of deployment over multiple PCs for GUI is:

Where:

• n is the number of computers;

• Install Time Application refers to the R-Code and configuration (and perhaps third party libraries);

• Install Time Progress refers to the time for installing Progress client on the machine;

• Dollars Per Hour refers to the cost of the person doing the installation and configuration. This can also include libraries that might be required.

I have worked in large organizations with multiple buildings all over multiple cities (a court system) that used a GUI app and we can further modify EQ 3.0 to include a stop at each building for each computer with

Where:

• m is the number of locations

• n is the number of computers in a location described by m. (Note n is dependent of m.)

• TravelTime is basically an average or sum of time between buildings. (This basically falls under the traveling sales man problem [5] if one wants to get to the nitty gritty.)

Deployment Costs of a Web Application

The deployment of a web application is much more simple. One basically needs to construct an email message and collect the email addresses needed. Then send an email to the list with their user id and password (or they can create it with an authorization code and await confirmation of use) [4] as well the URL to add to their book marks in their browser.

As far as traveling to different users desks and in larger organizations, buildings – this is eliminated.

Quite often the department heads can easily build a list of email addresses they want the general release email to go to, removing this burden from the IT department and quickening deployment of the application to the company. This allows the managers to take control of use of the application by their people. It is a decentralized deployment option.

Deployment generally falls under:

Where:

- CostFactor Department is a factor describing the cost for that department across the number of logins. It is a quick way to say some departments might be more expensive than others in terms of talent cost constructing email message lists.

Of course, an application can be written requiring IT to be involved in login.

Uneven Deployment

Uneven deployment means when a major deployment has been done for most people, but a new person is brought on that needs access to the application.

Under GUI, an IT resource will need to be deployed or the computer to be used sent to IT, disabling that user until IT gets the computer back to them. The same equations as above apply plus the cost of user not working.

Of course under a web application, this is as easy as sending them an email with the URL to the application with their user id and password. (One of course will want to force a password change on first login [4].) This can be done as above with an authorization code specific to the employee.

This can be done by a manager or someone in HR without the need of a Progress Administrator for installation of the application on their computer. This can aid in the speed of deploying the new person in the position instead of waiting around for IT to act upon it.

Update

Much like the deployment, upgrades are very much the same formulas and costs as the initial deployment when dealing with GUI applications. One spends all that money and time all over again.

It is equally fast with web applications. In fact, by use of a simple redirect on the web site, updates can be automatic. This usually cannot be done with GUI applications.

Arrrgh! Rollback

One of the major problems for roll back under GUI is that one needs to do the initial work, undo the initial work, and then try doing the deployment again. This multiplies the costs shown in the above equations by 3 – one for each action needed to deploy, rollback, and try again.

As with updates, under a web application one can simply use a redirect on the web site to get people back on the old code. (Of course, one will want to warn people they are going to the old code – this is why one collects email addresses by those logging in to aid in automating message distribution amongst the user base.)

Conclusion

It should be pretty straight forward to create spreadsheets of the costs described by the formulas. One can then compute out the deployment benefits of using a web application compared to a GUI application in terms a potential sales might understand, as well internal if optioned to a company.

Be sure to freely share this paper with colleagues!

About The Author

Scott Augé has worked on multiple SaaS applications, from those for the underwriting in the mortgage industry to those used by the government via contractors. One can follow Scott on Twitter with @ScAuge and see his linkedin.com account at http://www.linkedin.com/in/scottauge.  Email Scott at sauge@amduus.com.

About Amduus Information Works, Inc.

We want your business! Of course we are open to work for hire… but if you have a product and would like to transform it or an idea, we are open to for a fee or for a portion of revenue payment arrangement. Amduus Information Works, Inc. develops enterprise level software for commercial/non-profit organizations and government agencies. Industries include manufacturing, service, health care, judicial systems, law enforcement, e-commerce, and real estate. The company develops software per specification as well runs it's own Software as a Service (SaaS) applications.

Reference

[1] Microsoft Remote Desktop Connection Manager http://www.microsoft.com/en-us/download/details.aspx?id=21101

[2] Citrix http://www.citrix.com/lang/English/home.asp

[3] Parallels Virtual Machine For Mac OS X http://www.parallels.com/

[4] Security options are available in another writing. Contact the author.

[5] Traveling Salesman Problem http://en.wikipedia.org/wiki/Travelling_salesman_problem