In the last article, we discussed considering platforms other than the web when deploying an application. In this article, we’ll talk about choosing the right platform.
Making that determination is not always easy. It is rare that one approach stands out as more favorable than another. It is likely that your customers, whether internal or external, will want a complete copy of the entire corporate database that is easy to use. They will also want data entry capabilities on their PDA or cellular phone. In addition, they’ll probably want instantaneous replication of information to and from the corporate office, taking into consideration, of course, that some of the field staff works in areas where there is no cellular coverage.
However, you can organize and prioritize their needs in ways that allow you to give them most of their desired features while keeping the architecture open for future developments. The criteria for most organizations are broken down into three basic needs: connectivity, user experience, and data storage.
When working on a solution where all of the users are in the same building, connectivity isn’t much of an issue. You don’t have to worry about how the users will connect with the server since nearly every organization has had a LAN since the early 1990s. However, if the users are not always in the same building, particularly if they’re out in the field, connectivity can be a real issue.
Connectivity may not be an issue when working from a home office or a client where you can use a high speed connection. In today’s environment of reliable, high-speed connectivity, it’s certainly possible that your solution won’t be constrained by connectivity issues, even when outside of a single building.
However, it is far more likely that you’re deploying applications to field service and sales staff; they may barely have dial-up modem connectivity from the small towns where you sell and deliver your products. You can almost visualize the operator plugging in wires to make connections instead of the phone switches we’re all used to.
In this environment, even getting email can be a painful, hour-long process. Trying to deploy a web application where the staff would need to stay connected for long periods of time would be akin to towing a monster truck with dental floss – it’s not going to work very well. In this kind of an environment, a web site solution just won’t work.
Even deploying smart clients in this environment is tricky since the replication of data to and from the client should work quietly in the background. It must let users know that they are synchronizing with the server, unobtrusively alerting them that replication has completed, thus allowing them to disconnect.
Typically, transmitting and receiving data takes up only a small fraction of the time spent in a connected environment. The user makes a request and waits on an answer; the majority of the connection time is spent waiting for the response. In a smart client environment, users can start a replication process in the background and continue their work while the system saturates the connection until it’s complete. This fully utilizes the connectivity available and helps your staff get offline quicker.
However, even this requires some quiet time in the evening when the staff can sit quietly and do their paperwork. In some situations, this may not be practical. It may mean that neither the home office nor the field staff receives information quickly enough.
For instance, field staff for a utility company may need to check on downed power lines or a possible gas leak. They can’t wait until they come back to the office or until they go home for the evening – they need near time (near real time) connectivity all day. They need to know in a relatively short period of time when something happens.
In environments like this, nearly continuous communication is a must. This typically drives towards mobile devices such as PDAs or other similar specialized devices that are small and powerful. These devices, with their integrated radios, can receive updates all day and transmit responses in near time.
Although this sounds like the ultimate answer, be prepared to pay the price. Applications on PDAs and specialized devices are still relatively expensive to develop, deploy, and maintain. In part, this is due to the relatively poor state of the wireless communications upon which they depend. Extra work must be done to “trickle sync” data from the device to the home office and back. Trickle syncing means monitoring connectivity and finding the opportune moment to synchronize so the device is kept up to date. Even in a city like Indianapolis, which is relatively flat, there are still numerous places where wireless connectivity doesn’t always work.
User Experience Needs
Over the last decade or so, a lot of research has been done on how people think and the kinds of user interface devices that can be used to make software easier to use. Whether you agree with every change or not, using a GUI based computer interface has generally gotten better over the last ten years. The introduction of context menus (generally accessed by a right-click of the mouse), drop down lists, progressive searching, drag and drop placement of objects, etc., has made it easier for users to use the systems we develop.
However, maybe ninety percent of the applications that we build do not need these interface enhancements. The traditional data entry application needs the ability to locate information, enter new information on the screen, and finally, post that information back to the server for storage and processing.
When you’re considering user experience, you need to consider first what controls and techniques you’re going to need in order to develop a user-friendly interface. If a truly rich user environment is necessary, then you may be forced into using a smart client solution.
The second consideration is responsiveness. Smart clients, because of all of the local data, will be more responsive to the user. Posting a search to a server and waiting for a response, however, takes time, regardless of how fast the server is. If the clients want the feel of a local application, you may be forced into using a smart client. Of course, the question is always whether they need the snappy local interface or if it’s simply something that they ask for out of habit.
Conversely, if there are no requirements for a rich user interface with all of the bells and whistles, it may make sense to stick with something simple. Bells and whistles cost time and, ultimately, money; they may not be worth the time or cost.
Every application has its own unique set of data needs. A sales force application may need to send tens of megabytes of detailed customer information so salespeople can instantly call up the order history, support incidents, and current credit balance before critical client meetings. As we become more and more dependent upon automation, we expect to have more and more detailed information available to us.
Therefore, when determining what platform to develop, you need to consider how much data you’ll need in order to be effective. However, that being said, sometimes there are ways to reduce the amount of data that is truly necessary.
At first glance, if you wanted to provide all of the customer information, you may be talking about gigabytes of data. If you add the order history tables from your production database, the support database, and the various other data repositories, you may end up with an even larger number. It’s not uncommon for organizations to have hundreds of gigabytes or terabytes of customer information.
However, in most cases, individual salespeople wouldn’t need all of the details of every customer. They would only need the information for their own customers. Even if the records for a customer take 10 MB and the sales person covers 20 customers, the information on those customers is a far cry from the hundreds of gigabytes or terabytes that all of the customer data might take.
Most applications have similar distinctions that can be made, as well. Field force personnel need the details for any tickets that are assigned to them, and perhaps details of any new unassigned tickets. This is a far cry from having complete information for all of the tickets.
Notebooks today are carrying hard drives in sizes up to 80GB. This effectively removes concerns about the amount of storage on a PC based smart client for all except the most data intensive applications. Even those applications could be served by externally attached hard drives. With IDE hard drives with capacities of 320GB of data, even the most data-hungry application can be served.
The storage capabilities for mobile devices are substantially less; however, they are still expansive by historical definition. It used to be that the storage capacity of PDAs was measured in Kilobytes. Palm OS based PDAs used to come with only a few megabytes of storage. Today, there are compact flash cards with 2GB of storage and Secure Digital cards, roughly the size of a big postage stamp, which can hold 1GB of information. Clearly, the old perception that a PDA doesn’t have the capacity for applications is no longer correct.
The only real problem with the devices is getting the data to them. As you push more and more data to clients, you’ll have to address the need for bandwidth between central servers and the mobile clients.
While it’s certainly true that there are not always clearly defined answers on what the platform for an application will be, it is also true that there are core concepts that you can use to help focus the decision.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert’s more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. You can reach Robert at Robert.Bogue@CroweChizek.com.