HCS Consulting Group.
We make Complex Systems simple

The long road to the WEB.

By Albert D. Kallal
Monday, July 19, 2010

Before you jump into converting your Access based applications to the WEB, did you ask the right questions?.

It probably seems a little bit contradictory to start an article about converting applications into WEB based applications, then then ask is the WEB really what you are looking for?

 

Are you sure you need the WEB or better connectivity?
 

Often technology solutions can be solved simply by using improved connectivity. Designing and building an  WEB based application is often not the solution.

A WEB based application has great connectivity.

However, often it is JUST the connectivity part that is needed here, and not really the fact that you need a real WEB based application.

The reason why this connectivity option is important to consider is cost. WEB development is very expensive. Some consultants tell me they just add a extra zero to the estimate if the solution has to be 100% WEB based.

Now, I can't say a factor of 10 time cost is fair. However, to convert existing applications to WEB based technologies is costly. An application that may have cost you $4000 in access, can wind up costing you $15,000 or even $20,000 when re-built using WEB based technologies.

Think of this like the difference in transportation costs and solutions. You can use an older car to deliver few packages around town (pizza anyone?). However, now assume you are going to use a helicopter or an aircraft to deliver that same service? This is the kind of quantum leap you're talking about in terms of costs. Now for sure a lot of people choose to fly these days without much thought. And a lot of companies have WEB sites with software running that you can use as a customer.

However, the equipment and personnel and infrastructure you used to fly is certainly much more expensive than your old beat up car that you can drive for years to deliver a simple package to a customer.

WEB applications vs. WEB content.

You have to distinguish between setting up a WEB site with some content or so call static text that your customers can view at their leisure. I don't consider a WEB site with some content about your company name and products a business application. When I speak of a business application, I am talking about a well designed database and software information system that implements and manages some of your business processes. All too often companies and people don't distinguish their WEB site content such as company information and that of an accounting package or software information system that puts together quotes or executes some payroll calculations.

So keep in mind there is two kinds of WEB development. One type of WEB site development is simply content that you place for customers to view. In the context of this article I am talking about WEB applications and software development. So, we taking about taking some software package you've implemented over the years that is to become a WEB based application.

You can type some text into Word. Word now has a save as HTML option that results in text and a page that can be saved on your web site. If you are paying lots of dollars to have simple text updated on your WEB site, find someone else that will provide you with a solution that lets you change that content yourself.  You don't hire outside people to change text in your word documents, so why are you doing the same for your WEB site? That is your content and you should be given tools to modify that content. Modifying context is NOT software development and in fact is a rather non technology process, no more so then editing text in a Word document these days.


Connectivity solutions in place of software development

Failure to consider distinguish between solving connectivity issues, and solving business processes with WEB based software systems is often misunderstood in our industry.

For example lets assume you have a business and a full time accountant. If your accountant breaks his leg and has to spend a week at home, then it would not make sense to rewrite the WHOLE payroll system as a WEB based application just to allow the accountant to work at home on your accounting system.

In this case the solution to this problem is to improve the connectivity for that user. A possible solution would be to set up something like a VPN and then let the accountant remote into his desktop at work from home. In fact before you read on, I'm not going to get into a bunch of technical mumbo jumbo in terms of networking technology. However, as prerequisite for the rest of this article, please take a few minutes to read the following article of mine on how you can use MS access over the Internet:

Using Access over the internet - click here

Please do read the above article on WANS if you're not quite up to speed on some of your options in terms of technology.

The above article is really about improved connectivity. The above article is relative free of technical jargon for the most part. Assuming you just finished reading the above article, you'll now realize that a good solution for accountant to work at home for the week is to use some type of remote desktop technology. This remote desktop software will allow accountant to use his work computer and the all important accounting software just as if he was sitting right in front of that computer at work.

Contrast that to the potential huge investment (perhaps millions) it would cost to re-write the accounting package as a WEB based solution. Keeping in tune with the article on WANS, another suggested solution was to consider installing the Accounting software on the computer at home and connect over the Internet to that backend database.

So in place of some remote desktop software, it might be possible to install the accounting software on the home computer and connect to the database back end at work. So, with a VPN, then the software will be connecting to the database back end at work and can do so over a standard internet connection.

If the payroll package is SQL server based, then it's very possible with VPN the software will run at an acceptable speed. So, in this case you don't even need remote desktop technology. As mentioned if you don't understand these two scenarios, read my above article. In a nutshell it means that perhaps by just moving the database part of your application from access to SQL server, but keeping your existing access application will solve your connectivity issues.

So, often you can move your data out of Access and into SQL server. You simply keep Access application as "is" and it works as a front end to SQL server. This allows you to keep most of your software investment and is far less costly then re-writing the application as WEB based. Note how using a VPN we SOLVE EXISTING connectivity issues and we've not had to rewrite the accounting package or you Access application as an WEB based system. It makes no sense to rewrite a whole payroll system that can be simply solved by improving the users connectivity.

So, why spend millions of dollars rewriting the accounting and payroll system when in 10 minutes of IT support time you can give the accountant use of that application at home or anywhere on the WEB by simply setting up some type of networking or connectivity? So I must stress that often an organization is asking for a WEB based application, when in fact what they are REALLY are looking for is improved connectivity for existing business processes and applications that they have.

Was the application designed for the WEB?

Once again this is a typical question that is often failed to be asked about an existing application. In our mythical accountant and payroll system example, we might want to allow all of the staff/employees to look up how much holiday pay they have owed to them. This holiday pay information would allow employees to schedule and choose when are going to take their holidays during the summer.

Normally the business case here is that each employee simply phones up the accountant. The accountant then brings up the person's record and information using the payroll software. The accountant then tells the employee details such as holiday pay they have coming. The accountant can then asks the employee questions such as when they plan to take holiday time off. The employee typically answers back that he'll have to talk to his wife and family and get back to him. In this typical type of scenario, just 10 phone calls a day at 6 minutes each is 1 hours of labor cost of time spent for your accountant. So the above is a prime candidate for building an employee self serve WEB portal in which they can look up their own holiday pay coming, and they can also schedule when the going to take their holiday and time off.

Not only is this idea a great use of WEB based technology, but you can also be well justified the cost in term of saving the company money and time. One hour of accountant labor per day is a rather large cost number. In other words when it makes sense to adopt WEB based technology, then the case becomes quite simple and clear that the using existing Software System would not be appropriate. It would make no sense to take the existing payroll application and used an increase in connectivity solution and install or allow every single employee to use the payroll application. First of all the payroll applications is going to be far too complex for the average employee to use. The next problem is the payroll package will have never been designed to keep everybody's information separate from everybody else.

 

Keeping it Separate

In fact the payroll system is designed to make it easily look up anybody's information. The instant you let every employee  use an application as WEB based, then the NEW design criteria becomes to keep everybody's information separate. In other words with a WEB based application, you don't want each user of the WEB application to see other people's information.

Now if you have any familiarity with Access or any type of database system, you'll rapidly realize that information as a general rule is simply data sitting in a table. You the developer of this application is responsible for this separation. The database or WEB does does NOT solve this issue for you. You are now responsible for designing and building into your application the ability to keep all of that information separate from each user. If your application does not have this ability to separate each individuals user who visits the WEB site, then your design is not appropriate.  If that payroll package has been designed to let you see all employee's information, then it is likely that the that payroll package would have to be significantly redesigned and reengineered to keep that information separate for each user as an WEB application.

If you ever used user level security in Access, and built an application in which each users information is to be kept separate from each other user of the application in multi-user mode, then you do have an idea of what you are up against. However, if you never written applications that keep users separate, then converting that application to WEB based will NOT SOLVE this issue. It is YOUR software and YOUR design that must keep users separate.

This keeping users data separate is NOT a feature of the database or WEB tools. It is your job. This means eBay or your Access software does not  work any different in terms of information simply being stored in a table. It will be YOUR SOFTWARE that must keep the information separate. So, converting your application to WEB still means you have to solve this challenging problem.

I am just pointing out that you the developer must design the software this way, and it not a feature of the database or WEB development tools. This keeping of each individual users information separate was unlikely EVER an consideration of the original design of the application from the ground up. This is also why just converting an existing application to the WEB use often fails miserably. That accounting package will be hopeless as an WEB based system for each employee.

So, it is somewhat ironic that most Access applications are designed to bring up any record and any information with great ease (that "was" the whole point of the application - ease of getting at some information). For WEB based applications this whole concept and design criteria tends to be 100% reversed. Now the major WEB design is the ability of each individual user to ONLY use and see their own account information in the tables. However back at company headquarters the accountant still wants and needs all of the information to be used as one coherent single system. So, staff and payroll information remain together in one system, but we can't have other employees looking at information like pay rates and spouse information of other employees can we?

Use the WEB when appropriate.

So the above payroll scenario is a perfect example where a WEB portal self serve system should be created. The existing payroll application is not going to work on the WEB, but the employee self serve holiday pay WEB portal system can and will certainly integrate data from the payroll system. It makes sense then to create a separate system that solves a business task of allowing the employees to look up their holiday pay, and schedule when they're going to take their holidays.

Shocking your customers technology is a loaded gun!

Designing a custom system for just one streamlined task and application is extremely important here. If your application needs a whole bunch a training to run, how can you throw it up to a WEB based system were supposedly your customers and vendors and whoever else is going to use that website will not have that require training to run the application? You accountant took years to learn and run that payroll and accounting system. You can't let customers loose on such a system without training.

You have to be extremely careful here, because when you allow your customers to use some WEB based application, then you're now allowing internal business processes to become public for everyone to see. You might have the best sales people, you might have the best products in the world, but if you have a really horrifying application that runs on your WEB site that you're forcing a customer's to use, then you completely destroyed the whole customer impression they have of your organization if you mess this WEB application up.

You have to think long and hard about adopting technology, and the impact it'll have on your customers. Your customers don't know or care if your payroll system is a hunk of garbage or not. However, exposing business processes to your customers can really be a huge step.

 About 20 years ago I used sell to some real estate and some insurance firms a system that would allow you to put a bunch of names into a computer, and then fax out to hundreds of customers a sales Brochure or whatever. I don't sell those systems anymore, but at that time going around to businesses and selling them a little software package that would allow them to send out FAX announcements to their customers was quite a little lucrative side business for me. Today I think that type of faxing out is a little bit more associated with junk mail, but nevertheless it was serving these clients quite well as a reasonable business process to implement before things like email became common.

However I remember one customer who was opening up a restaurant in a nice neighborhood. Since all of his friends and businesses were ranting and raving about how great my FAX system was, the owner was sold just on the word of mouth stories about the novelty of being able to send out brochures for free without cost of mailing or even having to print the paper. It was a slam dunk sale for me.

This whole idea seemed like a fantastic idea for the restaurant. They would be able to fax out their menu, and lunch specials and even upcoming events such as Halloween or New Years party. So, they purchased my FAX software and then to purchased a list of local area businesses and fax numbers. Well it turns out in that surrounding area had a significant number of those businesses that were using their fax number as part of their home business number.

As a result, for the next week this restaurant received nothing but horrifying and nasty complaints and phone calls from potential  customers demanding that they stop phoning them at 4 am in the morning and waking up their family to send a a FAX. I'm sure you all know how frustrating it can be when someone's has your wrong number as a fax and attempts to send you a fax over and over. My whole point here is is that a new technology was adopted that INTERACTED with customers.

The critical concept in the above FAX lesson is that the person took some technology and exposed it directly to their customers. So, keep the above lesson in mind if you're going to expose software or some information systems directly for your customers to use. You better GET THIS RIGHT or you can wind up loosing customers over the whole affair. You make this process annoying for your customers, then you loose them. You can have a really rotten and noisy photo copier, but you customers NEVER see or hear it.  Needless to say, that restaurant never used that FAX system again.

The lesson here is exposing technology in direct contact with customers is HUGE leap. So, if that photo copier is to be used by customers, then your reputation is at stake. So while technology like a WEB site sounds great at first, if you don't have the right people, the right user interface, and the right kind of support systems in place, and people who know what they're doing, you better be careful when you expose a WEB system to your customers. Technology is powerful, and so is an exposed electrical outlet. Treat technology with respect.

Additional management issues.

Assuming our mythical accountant application Employee Self serve internal WEB portal was built in which employee can now log on to see their holiday pay and schedule holidays. Now, who is is going to manage things like forgotten passwords and resets and logons? You mean you have a highly expensive accountant who now is not spending his day explaining options for holiday pay or things like retirement contributions, but are now fielding calls as to how passwords can to be changed? And, what is their logon that they forgot?

In other words all of a sudden you taking your highly paid accountant person and turning their job into some kind of help desk who is now dealing with resetting people's passwords and looking up forgotten logons. Who is going to help them the employees or customers use that system? Most companies don't give this WEB issue a whole lot thought. If you going to build a self serve WEB portal, then you better be aware of the issues such a simple things like management of who will issue passwords, forgotten passwords, and how will you manage new signups? So, you better have a clear idea who is going to maintain and handle these all these new issues that the WEB system will surly bring.

It would be pretty silly to take a highly trained sales force or people within your organization with great product knowledge, and now turn them into WEB support people in which their resetting passwords and helping customers logon all day long. What this means is, you better build in a very good customer service system in which forgotten passwords and the like will not wind up costing you valuable support and customer time that could be better use helping the customer purchase something from your company.

Security

It is remarkable how many company I've known over the years that have decided it be great to have some type of WEB based system. They add a WEB server to their network. Some of these companies within less than a week were having their WEB server hijacked and turned into gaming servers for use by hackers on the weekend. In other words the wild WEB is a really dangerous place, and to plug in a WEB based application into your existing company network without you realizing and knowing a lot about security is a daunting and dangerous task that best left to the professionals.

So when you say that you want to run a WEB based application have you thought about security ramifications? Are you ready to open up that application and YOUR company network to the World Wide WEB? In fact in just about every single case of the small business implementing their own WEB server, I found after a repeated website defacing, security issues, and simply not being able to afford the security and staff needed to run such a WEB server, they simply stop hosting their own WEB sites, and now purchase hosting. Of course if you purchase a hosted site, then how are you going to move your existing information within your own company from the Accounting system in and out of that website now?

I suspect the stern warning I just given you about WEB based systems will likely end you fake romance that these WEB systems are fun to implement. I bet you now scurrying back into thinking perhaps some improved connectivity is a better road and solution then attempting to deal with security. Security is a very serious matter that you have to consider for WEB based applications, and if you don't have a plan or advice in this area, you might have to forgo WEB based solutions until such time as you can safely address security.

Use the WEB when it makes sense.

Self service WEB portals be the for customers, or internal employees have the greatest potential to save the most amount of money and time. The reason for this is because these WEB portals tend to involve new business processes as compared to connective solutions. So when you're evaluating if do you really do need a WEB based solution, as a general rule if an existing business process or application can be solved JUST by improving connectivity, then it doesn't make sense to redevelop and rewrite your application to allow your accountant to work it home.

However a WEB site to allow your suppliers or vendors to check the status of an order, or perhaps confidential pricing information, or any of the kind of information that many of your skilled people spend time during the day using an application that they are running to pull out information and simply pass it on to the customer by a telephone is a fantastic candidate for WEB based systems.

I believe that when one of the major parcel delivery companies in Canada implemented their online WEB based parcel tracking system, I believe in terms of staff and phone calls and cost reductions, it's saved them over $10 million dollars in the FIRST year! In other words were talking payback times of often just a month or so to save huge amounts of labor.

So self service WEB portals is where the low hanging fruit exists in which you can save your company large amounts of money. If you can find a way to move out some of your business processes out to the WEB and engage your customers with information they need, then you can save HUGE amounts of expensive staff and labor to deliver that business process to those customers.

So, look for solutions and business processes that can't be solved JUST by improving connectivity, but by developing something NEW that allows employees or customers to do data entry and do business tasks and inquire about information that they were not capable before so by doing by hand, but had to go utilize expense of people within your organization.

It's been a number of years since I've talked to a travel agent to book my flight. With great ease I can choose a direct flight that might cost a little bit more, or choose a couple connections that might cost a little bit less but be less convenient for me. I can accomplish this task and have all this information transmitted and utilized by me in Real-Time and do so by using any WEB browser. I don't have to talk to a travel agent anymore. Once again just like the package tracking example, self serve WEB portal systems have enormous benefits to everyone involved. Not only am I getting all the pricing and quotes for my air flights and travel online, but I'm doing so without using any labor costs or human cost on the other end. And I can do it any time of my convenience, even late at night when your business is supposedly not open.

In closing

Keep in mind that often when people are requesting a WEB based application, what they really need is improved connectivity. However if you can identify business processes that benefit by using the WEB, then the WEB is your ticket. It is this very reason why companies are willing to pay me money.

Now what?

Assuming you now clearly understand when and where and why it's beneficial to spend money on building a WEB application, and you are SURE it not just an issue solved by better connectivity, then the next question is where do you start?

I attempt to answer this question in part 2. I can't promise when I finish part 2, but it should be within a month or so of having finished the above article.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

Kallal@msn.com

 

Home