Part 2—Software: Putting It All Together
It's difficult to synthesize such a complex subject as software, but the challenge of supporting e-commerce provides an excellent vehicle for describing how the pieces go together. To close this section, and to prepare you for the next one on networks, the e-commerce example is extremely useful.
Choosing an OS for E-commerce
As noted in the closing section of Part 1, in e-commerce, a request for information enters a computer over a network connection, is passed over the I/O bus to the CPU, and from there goes to software that serves Web pages, and most likely after that to a database system that locates the item or items to be sold, or service to be provided, or whatever. There's more, but let's back up to think about what this means for the OS. Of course, since multiple applications are running at once, it's a good thing that all modern OSs are multitasking. Its sister capability, multiprocessing, requires careful evaluation, however. The reason multiprocessing is important is that it is central to scalability. While desktop computer users are rather unlikely to upgrade their computers, people who own e-commerce servers better hope that this issue comes up—if it doesn't, the business isn't growing. If the server is handling lots of requests for Web pages and/or database requests simultaneously, an OS that can move up to support multiple CPUs is a real asset. Different OSes have different capabilities in this area. An OS that can support multiprocessing efficiently—that supports a high degree of scalability—can be a critical asset.
A second, and complementary, approach is to have an OS that allows "clustering"—lashing multiple computers together to form a single one. This path provides even more scalability as well as greater reliability—something that is essential for a business that is selling things (or providing services or support) over the Web. Remember that you can cluster multiprocessor systems. Reliability also brings up the structure of the OS. A system that is layered, using the kernel/microkernel approach, is not only more stable but also more flexible; though as with multitasking, nearly all modern server OSes have this characteristic. As a final point, a really serious server is a mainframe. These are super reliable. If you find yourself needing one of these quickly, you've done well indeed. However, in today's environment mainframes are used mostly by older organizations with legacy applications. Few systems are scaled up to a mainframe, since clustered high-end servers can provide nearly all of the same capabilities at much lower cost.
Choosing a Database for E-commerce
The array of database offerings for e-commerce today is huge. Whatever the choice, any new database is likely to be based on the relational model, something that permits considerable flexibility and scalability. In the meantime, old-line hierarchical databases will continue to be very successful in running legacy applications in mainframe environments. The object-based approach is still waiting in the wings.
If your goal is getting up to speed quickly in e-commerce, you will want to buy as much off-the-shelf software as possible, since developing and testing software systems is a slow process. You can buy excellent database software from a variety of vendors for a variety of OS platforms. Leaders are Oracle, IBM, Informix, Sybase, Microsoft, Compaq/DEC, and some others. Scalability is a challenge here, however. The more complex, fully featured databases just mentioned usually require more development time and more skilled staff than PC-based software. To be sure, you will likely be able to get up to speed faster with a PC-level database such as Access (Microsoft), Approach (Lotus-IBM), or Paradox (Corel). The disadvantage here is that these programs won't scale to the enterprise level. PC software vendors, as well as an array of third parties, do provide tools for porting the simpler applications to the more complex ones, but not all are equal. Tradeoffs, tradeoffs.
Choosing a Programming Language and Tools for E-commerce
Realistically, you won't be able to build a sophisticated e-commerce system without doing some programming. Database systems require customization, which can usually be accomplished with either a built-in language or with one of the standard languages such as C, C++, Visual Basic, Java, and more. Since we're planning for the e-commerce system described here to be planted in the nourishing soil of venture capital and grow like crazy, and since we're going to have to tie several disparate applications together, let's assume that programming is needed.
A first decision is whether to go to object-oriented technology (OOT) or not. The advantages of OOT are that, once completed, software is likely to be more flexible and adaptable than an equivalent program not using OOT. The disadvantages are a potential one—that programmers aren't familiar with object approaches—and a real one—that the system will run slower than something built with a more efficient language like C. How to decide? Well, first note that there are excellent programming tools—visual development environments, etc.—for all these languages. The e-commerce example, though, really points to a single solution. For this environment, Java, with it's "write once, run anywhere" capability gives you a lot of choice about hardware and OS compatibility in your server "farm" and attached systems. Also, the Java expertise you develop will be useful in creating little Java programs, "applets," that you can download to your clients' machines. Of course, if you're working on the Web, your programmers will need to be familiar with the "markup" languages, and especially with that potent newcomer, XML.
What about Java's slowness? Well, it's real. But the world has changed. In the old mainframe days, doubling your hardware capacity would likely nearly double your hardware costs—and we would be talking really big bucks. But adding a processor to a server, or even adding three, might only increase the server price by 25% or so, and you're now looking at a far smaller investment in absolute terms, not to mention in proportion to the size of the business. Today, if your system is slow it's usually a lot cheaper, not to mention a great deal faster, to "throw some hardware at it" than to make a heroic effort at improving software speed. Of course, this advice applies only to a new project; an established business might make a different decision, choosing C or C++, possibly for reasons of compatibility with legacy software, possibly to accommodate legacy programmers, and possibly for improved speed.
While your choices in comparing software for performance and speed of development might be different for a new e-commerce organization than for an old-line business, the issue of software reliability would be similar in both cases. All software projects, even those using rapid application development techniques, require careful planning and documentation. Absent a well-conceived plan followed by thorough testing, the bug farm can bring down the business, with the server going south when you most need it and for reasons you can't easily diagnose. Without a plan, and painstaking documentation, the software will be difficult, perhaps impossible, to maintain and upgrade. Don't take software development lightly, no matter how much of a hurry you are in to get to the IPO.
There is no better illustration of the pace of change in computing than to compare the choices described above with ones people were making just 10 years ago. At that time, there was a fairly clear division in hardware—mainframes and minicomputers for the high end, and PCs and file servers for the low. Managers were just beginning to think about integrating the two. Relational databases were just gaining acceptance. Programmers were still working primarily in COBOL, assembler, and the like, while C was just becoming popular. The only people who could even describe object-oriented technology were very much on the fringes of commercial computing. And, of course, there's one other big difference. Ten years ago only a handful of businesses (e.g., airlines) thought about network functionality when they designed their systems. Today, it's often the first issue considered. We'll turn to networks in Part Three.