- 1: Start Development with Software Requirements
- 2: Honor Your Users and Communicate with Them Often
- 3: Don't Allow Unwarranted Requirements Changes
- 4: Invest Up Front in Software Architecture
- 5: Don't Confuse Products with Standards
- 6: Recognize and Retain Your Top Talent
- 7: Understand Object-Oriented Technology
- 8: Design Web-Centric Applications and Reusable Components
- 9: Plan for Change
- 10: Implement and Always Adhere to a Production Acceptance Process
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
5: Don't Confuse Products with Standards
A common mistake made by IT organization 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 necessarily 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 many vendors typically support them, 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 shouldn't do so until you first settle 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 for an IT organization. Even the various third-party programs designed for NT (or any other operating system) don't 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 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 application architecture—it's a specific version of a vendor's database product. Again, application architectures should not be product-specific. A better architecture phrase would be something like this: "Relational databases that implement the SQL standard." 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.
System architecture doesn't address how the system is going to be tested. Many software projects have wonderfully elegant architectures (from a computer science perspective) 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. System architecture must take into account how a system is going to be fully exercised and tested. This is especially relevant when designing multiple-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 are few worse plights than to know that your whole system isn't operating successfully and have no way to isolate which component is causing the problem.
Software architecture doesn't consider production rollout of the application. In addition to 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. The Web-Centric Production Acceptance process discussed earlier specifically addresses the production rollout process for web-centric applications.