Software is a unique asset in the sense that it does not have any moving parts. Hence, it is not subject to wear and tear, which is the main reason any physical asset with moving parts requires maintenance and, ultimately, replacement. Theoretically, the life of a software application is eternal, with it not needing any maintenance at all so long as the hardware platform on which it is running is maintained and is in working condition.
Software can be upgraded to suit changing business needs, almost without limits. There are many examples of this phenomenon. Take the case of IBM mainframe software written in the 1970s—it is still running well into the new millennium. That is, this software is about 40 years old, and there appears to be every reason that it will run for another 40 years. The technique of “windowing,” used in many a Y2K conversion, indicates so. Windowing is when any two-digit figure greater than 50 in a date (that is, 50 to 99) is interpreted as belonging to the 20th century, and any two-digit figure less than 50 in a date (that is, 00 to 49) is interpreted as belonging to the 21st century. For example, if the data contains “49” in a date (as in the date 12/30/49), then the year of that date is interpreted as 1949 (or 12/30/1949). God willing, there will be another dose of software date conversion in the year 2049 to make it compliant to a four-digit year.
This is not to say that software doesn't need any maintenance at all. Ideally, software maintenance should be based on the changing business environment, and should be performed to handle the changed business needs, not otherwise.
The recent trend of building applications for enterprise in a totally Web-centric manner is, in our opinion, beyond reasonable necessity. There is a place for Web-centric software, and a place for client-server and mainframe software. The software industry seems to be falling head over heels in its embrace of Web-based software, and it is forgetting all other technologies, many of which are robust, secure, and much more economical.
Criteria for Selecting a Platform to Run Software Applications
Following are the criteria for selecting a platform—that is, a combination of hardware, system software, and a development platform—for running a software application to fulfill business needs and transaction processing.
1. Software Stability
So long as the original platform remains in the same condition, it can be expected that the application software will continue to work without any issues. This has been proved in the case of mainframes, where the application software has been running for about 40 years with regular maintenance, and upgraded only to cater to the changing business needs.
But software has been changing, moving from mainframes to smaller computers and to personal computers (PCs). PCs were originally thought of as home computers, and were never expected to play the significant role they are playing in business today.
The Internet added a new dimension to the software scenario by bringing the ability to connect computers all over the world at a very affordable cost. However, in some ways the cost has been quite high: software viruses have been released into the World Wide Web with the purpose of causing some sort of damage to PCs. Now, when PCs are connected to the Internet, they are in constant danger of succumbing to new classes of malware, spyware, and worms. Sadly, their operating systems are not equipped to handle these external and unwelcome threats, and we need to install additional software to protect our computer assets from these virtual predators.
Unlike with mainframes, the performance of PCs is unpredictable in terms of the unknown actions of malware and the software that is supposed to protect the PC from the malware. A new virus or spyware is released, and hence, an upgrade to an anti-virus software or spyware-remover is released. Or, perhaps a security patch is made available. All these fixes are applied to the PC, and the next thing that hits you is that the application software, which was hitherto running flawlessly, turns in an error.
In short, the software reliability is affected, not because the software was developed badly, but because of external incidents of which neither the developer nor the user has any control. Worse still, the error may not be detected until an irate customer complains bitterly about the silly error that caused him or her a loss or an inconvenience.
In the case of Web-based software, you cannot buy a product with just a one-time payment; you must enter into a software maintenance contract, out of necessity, even if your business requirements do not change, to be protected from an external event for which you are not even remotely responsible for. The current trend in Web-based software product pricing is a move toward yearly licensing—no longer is the sale a single, cut-and-dried transaction.
With client-server software, you can maintain the system software in its original condition as long as it is kept isolated from the Internet. With mainframes, you are already protected from malware due to their hardware design and mammoth-sized operating system software.
From this standpoint, it is better to go for a mainframe- or client-server–based software than a Web-based software.
2. User Interface Stability
Web-based software is essentially browser-based. A variety of browsers exist: IE Netscape, Mozilla, and Opera, to name a few, each having its own set of die-hard adherents. The browser in a Web-based software dictates the user interface (UI), and different browsers may handle the UI differently. Sometimes, the UI may work on some browsers and not others. One feature common to all browsers is their vulnerability to attack from malware. Therefore, the browsers listed above are continuously being upgraded and patched. These actions have an impact on Web-based software: every time a browser is patched or upgraded, the software needs change.
Client-server software, on the other hand, is not dependent on such external applications as browsers. If a virus attacks it, you simply need to clean the virus away or re-install the client software. Mainfames, of course, are immune to malware, as no viruses have been written so far that can attack them.
3. Software Maintenance
A working software should not need maintenance, as it does not experience the effects of physical wear and tear. If, and only if, there is a change in business requirements, then yes, software enhancement or correction may be needed, not otherwise.
Web-based software needs maintenance irrespective of its platform's stability. You need to maintain and upgrade your software whenever a) your browser is patched, b) your browser is upgraded, c) the third party middle tier is upgraded, d) your operating system is patched, or e) some new and powerful virus is released. This is especially true when the application is multitiered; it is impossible to know which tier is causing the issue, so the application software is what is upgraded.
In addition to application software maintenance costs, Web-based software needs maintenance for the additional protection software components that it requires. Thus, Web-based software not only costs you more initially, but it also costs you extra in maintenance during operation. Nowadays, anti-virus organizations are releasing weekly upgrades to their virus definitions, which goes to show that new viruses are being released through the Internet on a daily basis.
Mainframe and client-server software continue to work as long as the platform remains the same. External events do not influence their software maintenance needs, and upgrade of a browser does not impact them. No third party middleware is needed; they do not need a third tier of software to run their applications or if a new virus is released.
4. Initial Setup
The true cost of the initial setup of Web-based software only becomes apparent once it is discovered that the software cannot be implemented straight out of the box. Commercial off-the-shelf (COTS) software can almost never be used as is, and it almost always needs customization while implementing Web-based systems. On-site customization is the norm rather than the exception in the case of Web-based systems, and this often jacks up the cost.
The vulnerability of Web-based software makes it imperative that you add components to tackle external—and most likely threatening—events. Examples of such components include anti-virus software, firewalls, intruder detection systems, data encryption tools, security systems, and so on. Furthermore, these protective software need yearly maintenance contracts, and sometimes the upgrades to counter external threats come at additional cost.
The software replacement cost of Web-based software must also be factored in, as one never knows when the current standards of the software will be overhauled; this only happens in the case of Web-based software.
Suffice it to say that it is cheaper to have multiple instances of client-server software with synchronized databases than one instance of Web-based software. What's more, the protective components listed above are not needed with client-server or mainframe platforms.
5. Security
In a client-server or a mainframe environment, threats to security originate from internal sources, not from external sources. In other words, threats emanate from known and controllable causes. In a Web-based system, it is unknown where a potential hacker is from; for all we know, he may be in a country far away, where we do not have any influence or recourse for justice. As we strengthen security tools, so are the hackers improving their trade. Thus, it is a constant race between software developers and hackers.
Caught in between are businesses—paying the price, both literally and figuratively.
6. Uninterrupted Operations
A Web-based system can be interrupted for a variety of reasons: a) an interruption to the Internet service, b) a virus attack, c) a failure in the networking hardware or software, d) a newly released software patch that has affected some portion of the software, e) a malfunction in one of the tiers, or f) a hacker has infiltrated the system. In other words, the system can be brought down by external events that are outside the purview of our control.
Mainframe and client-server systems cannot be brought down by external events.
Some Final Words
To be fair, we need to acknowledge some of the more positive facts about today's Internet. The Internet's speed has increased significantly, so much so that any waiting time has all but disappeared. The cost of Internet access has come down substantially. The robustness of middle tiers has improved remarkably. Furthermore, most countries have enacted rules and regulations on Internet access, and are cooperating with each other in the matter of hacking.
The Internet facilitates corporate operations, and has become a very convenient way for carrying on business—no argument about it. Web-based software is a must for interaction with the public. Some of the applications that cannot run without (or that we cannot live without) a Web-based system include hotel reservations, travel, information, the selling of consumer goods, form-filling, public interface—the list goes on. Web-based systems have arrived, and they are indeed here to stay.
However, we must carefully evaluate the business scenario and consider whether Internet connectivity is really needed for enterprise software. No business should blindly conclude it must have a Web-based system. Where one is not needed, a client-server or mainframe system is the better, safer choice.
About the Authors
Murali Chemuturi is a fellow of industrial engineering, with a postgraduate degree in business administration and in computers. His career spans over 30 years in professional organizations, including Electronics Corporation of India Ltd., Tata Consultancy Services (TCS), Metamor (now Ciber Inc.), and Satyam Computer Services Ltd. He is presently leading Chemuturi Consultants (http://www.chemuturi.com), focusing on software products for the software development industry with EstimatorPal and FPAPal (http://www.effortestimator.com) for software estimation, and with PMPal for software project management and metrics. He has conducted a number of in-company training programs on software project management, software estimation, and project management. He can be reached at murali@chemuturi.com.
Udaya Chemuturi holds a postgraduate degree in English literature, and has over 25 years of teaching experience. She is currently a consultant at Chemuturi Consultants. She can be reached at sundari@chemuturi.com.