commandment 4 and 5 software engineering

4: Invest Up Front in Software Architecture

Every morning, some developer goes to work with software requirements for a new application in hand and starts writing code. For those who do so without first developing software architecture, their programs are likely doomed to failure. Invest up front in your software architecture, and you'll be starting down the path to successful software development.

Developing architecture for an industrial-strength software system prior to its construction is as essential as having a blueprint for construction of a large building. The architecture becomes the blueprint or model for the design of your software system. We build models of complex systems because we can't comprehend any such system in its entirety. As the complexity of systems increases, so does the importance of good modeling techniques. There are many additional factors to a project's success, but starting with a software architecture backed by rigorous models is one essential factor.

In the face of increasingly complex systems, visualization and modeling become essential tools in defining software architecture. If you invest the time and effort up front to correctly define and communicate software architecture, you'll reap many benefits including these:

• Accelerated development, by improved communication among various team members
• Improved quality, by mapping business processes to software architecture
• Increased visibility and predictability, by making critical design decisions explicit

Here are some tips on how and why to always start your software development project with software architecture.

Start with a minimum yet sufficient software architecture to define the logical and physical structure of your system. Table 2 summarizes some sample activities to be performed.

Software architecture is the top-level blueprint for designing a software system. Developing good software architecture requires knowledge of the system's end users, the business domain, and the production environment, including hardware and the other software programs with which the system will interface. Knowledge of programming languages and operating systems is crucial to developing good software architecture. As software systems grow more complex, more knowledge is required of the software architect. Object-oriented and component-based technologies may simplify individual programs, but the complexity typically remains at the architectural level, as more objects or components and their interaction must be understood.

Table 2 Software Architecture Activities

Activity	Architecture Level	Examples
Gather user requirements	Logical architecture	Generate use-case examples Document sample user activities Create class, state, sequence, and collaboration diagrams
Start design and production acceptance	Physical architecture	Define packages and components Define deployment environment

There are no shortcuts to designing good software architecture. It all starts with a small number of software architects, perhaps one to three. If you have more than three architects working on a single program's software architecture, they probably are not working at the right level of detail. When software architecture delves too deeply into detailed design, it becomes impossible to see the whole architecture at a top level and properly design from it.

Most software applications are much more complex than the makers of GUI development tools would like you to believe. Every application should be built around a software architecture that defines the overall structure, main components, internal and external interfaces, and logic of the application. Applications that work together in a common subsystem should adhere to an architecture that defines the data flow and event triggers between applications. Finally, applications that run across your entire organization need to follow some set of minimal guidelines to assure interoperability and consistency between applications and maximize opportunities for reuse of components.

Software architecture should always be designed from the top down. If you're going to implement a multiple-tier software architecture across your IT organization, it's nice to do this before you have lots of components written that can only communicate with other applications on the same host. Start by developing your organization's overall application architecture. Next, define the system architecture for the major systems that will be deployed in your organization. Finally, each application in every system needs to have its own internal software architecture. All of these architectures should be developed before you develop any production code or invest in any purchased software packages. The notion of completing software architecture up front doesn't contradict the spiral model of software development that utilizes prototyping and iterative refinement of software. Rather, prototyping should be acknowledged as an essential step in defining many parts of your architecture.

Trying to design a global set of every reusable component you think you might ever need is a losing proposition. You only know which components will be useful with lots of real experience delivering systems. If you don't prototype, you don't know whether what you're building is feasible, useful, and tractable.

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.