Every morning, some developer goes to work with software requirements for a new application in hand and starts writing code. Those who go off and start writing code without first developing a software architecture for their program are likely doomed to failure. Invest up front in your software architecture and you will be starting down the path to successful software development.
Developing an architecture for an industrial-strength software system prior to its construction is as essential as having a blueprint for 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 cannot 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 a software architecture. If you invest the time and effort up front to correctly define and communicate a software architecture, you will reap many benefits including:
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 a software architecture.
Start with a minimum yet sufficient software architecture to define the logical and physical structure of your system. Some sample activities performed are summarized in Table 1-2.
A software architecture is the top level blueprint for designing a software system. To develop a 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 the system will interface with. Knowledge of programming languages, operating systems, development tools, and programming frameworks is also necessary to develop a good software architecture. As software systems grow more and more complex, ever 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 .
|Gather user requirements|| |
Generate use-case examples
Document sample user activities
|Perform domain analysis|| |
Create class diagrams
Create state diagrams
Create collaboration diagrams
|Start design and production acceptance|| |
Define packages and components
Define deployment environment
There are no shortcuts to designing a good software architecture. It all starts with a small number, perhaps one to three, of software architects. 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 a 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 sometimes 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 architectures should always be designed from the top down. If you are going to implement a multi- tier software architecture across your IT organization, its nice to do this before you have lots of components written which can only communicate with other applications on the same host. Start by developing your organization& overall application architecture. Next, you should 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 up front before you develop any production code or invest in any purchased software packages. The notion of completing a software architecture up front does not 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 if what you're building is useful, tractable, and feasible , or not.