Software architecture phase
A student asked: “What is the difference between an architecture phase and a design phase? I am confused because the software lifecycle only mentions requirements, design, code, and test. What happen in the architecture phase? What does an architect do in this phase? Please explain.”
Answer: Basically, architecture phase is the highest level of abstraction of a software system and the design phase is the lower level that focuses on the details such as modules and components. Architecture is the allocation of system requirements (Hardware, Software, Interface etc.) to system components as well as the interaction between these components. Design usually deals with the functioning of each component in more details. For example, when you build a house you need an architect to design all the components of a house such as foundation, columns, roofs and walls but you do not need the architect to design the detailed kitchen or a bed rooms in the house. These details are often given to construction workers and the interior decorators.
When you build a large and complex software system, you need to divide the system into smaller components for easier implementation. Architecture phase is an essential step to make sure all these components are defined and the interaction between them is clearly identified. Sometime people consider architecture phase as the “high design” phase and design as the “detailed design” phase. The waterfall lifecycle considers both phases as “design” to keep it simple and easier for students to learn. Since most projects in school are small and simple where hardware and the interaction with software are known, students do not concern with hardware can start with the design phase of software. However in the industry, most software projects are large and complex and you need to know all components of the entire system (Both hardware and software) so you must learn software architecture well in order to build a quality system.
In the architecture phase, you must identify the context and scope of the project by set up boundary based on the customers’ requirements. You need to define both functional as well as non-functional views and all constraints. You need to identify all components such as the process view, logical view, physical view, interface view, infrastructure view, operational view, and security view for a complete software system.
Most software developers often pay attention to the functions of the system but not pay enough attention to the non-functional views (The quality attributes). Because most non-functional views are not well defined, projects often get into problem later because these are what customers’ expect but rarely mention in the requirements. This is where experienced developers are doing better than inexperienced ones as they learn through years of working by knowing what to ask customers. The customers may say: “The system must be fast”, it is a non-function requirements but that is too vague. Experienced developers know how to ask customers for more specific details to make sure that this request is measurable, and testable. (How fast do you want? What do you mean by fast? How many second? Etc.) They know that to achieve customers’ satisfaction they need to make sure that all of the important non-functional views are defined. These include the runtime characteristics such performance, scalability, availability and security etc. That is why the role of requirements engineers is so important in larger and complex system to clearly define these non-functional requirements.
Because most of the non-functional requirements are systemic issues, the architecture phase must identifies them as well as defines the interaction among them just like when building a house the architect must calculate the strength of the foundation and all the columns that keep the house in place. For example, larger house requires better foundation and more columns to withstand the weight of the house. For this reason the architecture phase is important in large software system. When all the functional and non-functional requirements are defined, the next step is to focus on how each component is implemented. In this phase, the software architect decides on what technologies are used, which components are built in house, which ones are brought from vendors, which one can be outsourced. They have to make decision based on factors such as cost, licensing, vendor relationships, compatibility, interoperability, support, and user environments etc. These decisions are vital to the success of the project because they are risks that must be deal with. Software architect must reducing risk where there is high degree of complexity or uncertainty by conducting trade-off analysis to manage risks and make sure the project can be done within costs and schedules. All decisions must be reviewed and evaluated by the architect, team leaders, project manager and customers.
The main problem with large and complex software system is that it is difficult for people to understand how these components work together. That is why software architect must use tool such as the Unified Modeling Language (UML) diagrams to convey the architecture to others. The architect review is where the project team, the support team (SQA and SCM, database specialists, security specialists etc.) as well as management and customers must participate to understand how the entire system will work. The software architect must make sure that the defined architecture is understood by everybody involved. Of course, development team must understand them since they will have to design and implement each component but support team must also know the architecture well. Configuration Management people must set a baseline to assure that all changes are under controlled. Quality Assurance must review all architecture components and make sure that they comply with standards and procedures. Security specialist must make sure that the architecture has taken necessary steps to ensure the integrity of the system etc.
If the architecture is approved, the next step is assign team members to start the design process for each component. Although the architect does not involved in the design and coding tasks, but he must actively helping team members to make sure that they are doing it correctly within the defined architecture. Basically the architecture phase is the most important in large software project. If it is done well, there will be les problems later but if it is not well defined, the chance that the project will fail may be very high. A poorly defined architecture will lead to bad design and bad design will lead to project failure and that is why so many software projects fail. They never fail because of coding but because of bad design and poorly defined architecture. That is why I think software engineering that covers all phases of software development is needed for all software students.
Sources
- Blogs of Prof. John Vu, Carnegie Mellon University
