Software Development Commandment 8, 9 and 10

8: Design Web-Centric Applications and Reusable Components

As in the case of object-oriented programming, not all software architectures are web-centric. With the explosion of the public Internet, corporate intranets, and extranets, however, web-centric software is becoming more universal. This changes not only the way you design software, but also some of the very basic infrastructure requirements. Here are some of the infrastructure components needed for a typical web-centric application:

• Database server. A web-centric application typically accesses one or more corporate databases. Unlike a two-tiered client/server application, however, a web-centric application is less likely to access the database directly. More commonly, a web-centric application accesses some sort of middle-tier application server containing the business rules of the application. The middle-tier application then communicates with the database server on behalf of the web-centric client. Such a multi-tiered approach offers many advantages, including greater application scalability, security, and flexibility.
• Application servers. In a web-centric architecture, application servers implement the business logic of the application. In many cases, this is programmed using the Java language. From a Java program, the Java Database Connectivity (JDBC) API is most often used to connect back to the central database. Specialized application servers may offer services such as DBMS data caching or transactions. A single business function is often broken down into components that execute across many applications servers.
• Web servers. Web servers are used to store and distribute both Java applications and web pages containing text and graphics. Many advanced applications generate web pages dynamically to provide a customized look and feel.
• Caching proxy servers. These servers, while not explicitly part of the application, are typically located strategically across the network to cut down on network bandwidth and provide faster access times to web-based data and applications.
• Reverse proxy server. A reverse proxy server is typically used to provide remote users secure access over the Internet back to their corporate intranet.
• Web clients. Until recently, a web client meant either Netscape's Communicator or Navigator browser or Microsoft's Internet Explorer browser. Today, a web client could be one of these browsers, or any of the following:
  • HTML-rendering Java Bean component in your application
  • Applet viewer built into a Java Development Kit (JDK)
  • Java application
  • Collection of functions built directly into the operating system

One of the main advantages of web-centric design is that it starts taking IT out of the business of supporting heavyweight clients. In fact, most new operating systems ship with one or more bundled web browsers, so no additional client installation is required for a web-centric application. Even if you're deploying to older desktops without a bundled web browser, the popular browsers are available for free and easily installed. If a web-centric application is designed correctly, the end user client really doesn't matter, as long as an HTML-rendering component and Java Virtual Machine (JVM) are present.

If there is any disservice that the web has brought to software development, it's that inexperienced managers may believe that the web has trivialized web-centric software development. True, almost any word processor today can spit out HTML code, and dozens of development tools promise point-and-click generation of Java code, while the web makes software distribution a non-issue. All of this has allowed web-savvy organizations to develop new applications on "Internet time," several times faster than using traditional client/server environments. But it hasn't trivialized software development. From requirements definition through production acceptance, the same disciplines that apply to client/server development hold true for web-centric development.

While embracing web-centric design doesn't necessarily require using reusable components, it certainly is a good place to start. More development organizations every day are investing in the design and development of reusable components. Several of the popular component frameworks have fostered the popularity of reusable components. Let's consider some of the advantages of building reusable components:

• It can take longer and be more expensive to design and implement a given function as a reusable component than as a non-reusable one. The savings only come when the component is reused. Especially with web-centric design, however, developers increasingly reuse well-designed components. This reuse is facilitated by component standards such as Java Beans components integration. The cost tradeoff, therefore, is to compare the overhead of reusable design with the average number of times a component can be reused. A reusable component, on average, might cost from 10–25% more to develop. Few development managers today could justify a 25% cost and schedule overrun just to save the next project money. However, properly implemented, reusable components can begin saving project money today.
• If you invest in the design of reusable components and an accompanying framework, you will undoubtedly find components you can reuse from elsewhere in place of some of the code you would otherwise develop.
• It's likely that components developed for one project can be reused elsewhere in the organization on other projects.
• You can buy and sell components (either externally or by exchanging with other development groups inside your company).
• Well-built components are much easier to swap out and upgrade.

9: Plan for Change

The best developers and architects plan for change during all phases of the software lifecycle. During the course of an average one-year development cycle, not only will the design be subject to change, but so will the user requirements, the development tools, the third-party software libraries, the DBMS system, the operating system, the hardware, the network, the programmers, and many other aspects of the application that can't possibly be foreseen or otherwise planned for. Some aspects of change, such as a new release of the operating system, can certainly be planned for by discussing schedules with the vendor and making a decision whether a new release should be installed or not. Sometime during the application's life, however, the underlying operating system will probably have to be upgraded, so it's really just a matter of when changes such as these are made. In either case, you still have to plan for the changes.

The longer the expected project lifetime, the more important it is to plan for change. The Cassini mission to Saturn, operated by JPL, was launched in October of 1997. With any luck, the spacecraft will enter orbit around Saturn in 2004. The JPL engineers running the Cassini ground station definitely must plan for changes in hardware and software prior to the spacecraft's encounter with Saturn in 2004. Any company that designs an extended-lifetime product with an embedded hardware and software component must pay careful attention to planning for change. Back down on earth, for instance, every high-end Xerox printer contains an embedded workstation controller. Typically these workstations are commercial off-the-shelf products with an average lifespan of 18 months. Xerox high-end printers are designed for 5–10 or more years of continuous operation. Xerox must plan for change in the embedded workstation components for each of its printer lines.

There are many ways to plan for change. For starters, allow extra budget and schedule in your project for unforeseen changes. At the start of the project, work to clearly identify all risk items that could lead to a possible change somewhere in the future. During the design, look for ways to mitigate the risk of a change further downstream. At the coding level, look for ways to quickly and easily set up code to be adapted to new situations and events within your business. For instance, use tabular definitions whenever possible versus hard-coding these parameters into your code.

10: Implement and Always Adhere to a Production Acceptance Process

Our last commandment centers around the use of the Web-Centric Production Acceptance (WCPA) process mentioned in earlier commandments. The WCPA process is really a superset of the Client/Server Production Acceptance (CSPA) process presented in  Building the New Enterprise: People, Processes, and Technologies (Prentice Hall PTR, 1998, ISBN 0-13-079671-9). Most of the WCPA process is useful even if you're not yet designing web-centric applications. Production acceptance takes an application from the early stages of development and into a production status. However, planning for WCPA really begins at the first stages of the software development process. This is where we first start getting users involved and keeping them involved throughout the development process through the use of customer project teams. At the same time, the development team needs to start getting IT operations involved. It's never too early to start getting both users and operations involved.

One of the reasons we developed the WCPA process is to serve as a communications vehicle. All too often, development organizations are isolated from the business groups that will use their applications and the operations group that will run and maintain them. Proper use of the WCPA process helps promote and instill good communication practices. Just as iterative development is a key software development process, so is iterative and ongoing communications with operations and with users.

This commandment is important because, without a closely followed WCPA process, your business may lose valuable revenue—or even customers—because your web-centric application doesn't function as expected. Perhaps one of the earliest examples of a WCPA process can be traced to Netscape's web server when they first opened for business in mid-1994. When designing their web site, Netscape engineers studied the web server load of their competitor at the time, the Mosaic web site at the National Center for Supercomputer Applications (NCSA). At the time, the NCSA site was receiving approximately 1.5 million hits a day. Netscape engineers thus sized their web site to initially handle 5 million hits a day during its first week of operation. Luckily, Netscape had planned their web site architecture to be scalable, and were able to add additional hardware capacity to handle the load.

The success of the WCPA process is also related to the robustness of your software system's architecture. An even greater percentage growth than Netscape's occurred at AT&T Worldnet. AT&T had expected to sign up 40,000 customers for their Worldnet Internet service during its first month of operation and had designed the site accordingly. During its first month of operation, however, Worldnet registered 400,000 new subscribers, 10 times the expected amount. Luckily for AT&T, they had architected the system for growth and put in place the equivalent of a WCPA process. As a result, all new subscribers were able to start receiving service, with few complaints of busy signals on dial-in attempts (in contrast to some other well-known Internet services).

A great example of what happens when you don't follow a complete WCPA process occurred at a major U.S. bank. The bank was planning an upgrade to its Internet home-banking service. Prior to the upgrade, the bank used a load-balancing scheme to distribute users to a number of front-end web servers, all of which connected to the bank's mainframe back-end systems. As part of the upgrade process, the bank was planning to let all users change their login ID and password, thus allowing more individual flexibility than the previous bank-generated login ID scheme. The first time a customer logged in after the upgrade, he would be required to select a new login ID and password or confirm keeping the old login ID. This process was delegated to a separate new web server to avoid interfering with any of the software on the existing load-sharing servers. The bank had some production acceptance processes in place, of course, and tested the entire web-centric system. On the first day of production, users started to complain of extremely long access times. Unfortunately, the bank had not taken into account the potential bottleneck of funneling all users through the single server while they were queried for potential login ID changes.

While no process can guarantee that a new production system will function 100% correctly, web-centric applications require new kinds of planning like that covered in the WCPA. Not only are user loads on the Internet much more unpredictable, web-centric applications typically involve the interaction of a much larger number of software and hardware systems.