Software Development: Building Reliable Systems

#5 Thou shalt not confuse products with standards

A common mistake made by IT organizations is to confuse products with standards. Standards are open specifications such as TCP/IP or HTML. Standards can either be de facto or official. De facto standards, while not endorsed by any standards body, are widely accepted throughout an industry. Official standards are controlled by standards bodies such as the IEEE or ISO. Products can implement specific standards or they may be based on proprietary protocols or designs. Standards, because they are typically supported by many vendors , tend to outlive specific products. For instance, in the early 1990s, Banyan Vines was one of the top two network operating systems for PCs. Today, suffering from its own proprietary protocol, Banyan Vines has been relegated to a niche player in the network operating system market.

If your IT organization chooses to standardize on a product, say Cisco routers for network connectivity, you should not do so until you first standardize on a standard protocol for network connectivity, such as TCP/IP. Here are some common mistakes IT organizations make when defining their application, system, and software architectures.

• The application architecture is defined at too high a level. Some CIOs make the mistake of declaring Windows NT (or Unix, or Mainframes) their corporate application architecture. NT is an operating system, not an application architecture for an IT organization. Even the various third party programs designed for NT, or any other operating system, do not define all the characteristics of how to run a business. This is not to say that a corporation might not standardize on NT and use it wherever possible in its IT infrastructure, only that an application architecture requires a finer granularity of detail. In general, application architectures should not be so specific as to be tied to particular products.

• The application architecture is defined at too low a level. Oracle Version 8 is not an application architecture it is a specific version of a vendor's database product. Once again, application architectures should not be product specific. A better architecture phrase would be, "relational databases that implement the SQL standard." Once again, this may not preclude a company from deciding to purchase only SQL DBMS systems from Oracle, but specific product choices should be made only after the underlying standards decision has been made.

• A system architecture does not address how the system is going to be tested. Many software projects have wonderfully elegant (from a computer science perspective) architectures that result in projects that fail miserably because no attention was ever paid to how the system was going to be tested. One of the most commonly overlooked test factors is performance testing. A system architecture must take into account how a system is going to be fully exercised and tested . This is especially relevant when designing multi- tier applications. For instance, in a three-tiered system, the architecture may allow for individual testing of components in each of the three tiers, but may not allow for end-to-end system testing to verify the correct interoperation between all three tiers. An equally bad architecture allows for end-to-end testing without allowing for testing of components in each individual tier. There is no worse plight to know that your whole system isn't operating successfully and have no way to isolate what component is causing the problem.

• A software architecture does not consider production rollout of the application. Besides taking into account how an application will be tested, the process of rolling out an application into production needs to be considered in your software architecture. Many great systems have been designed that were never fielded because the infrastructure to support their widespread use was not available. Chapter 13 presents our Web-Centric Production Acceptance process, which specifically addresses the production rollout process for web-centric applications.