- 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
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.