Very often, good software architecture signifies high quality of the software. No single architecture style fits perfectly for all projects. What makes the architecture good for a software project depends on many aspects. The following are three aspects that I learned from watching the videos of ‘advancing developers to architects’.
Firstly, good architecture is feasible. It indicates economic feasibility, technical feasibility, operational feasibility and political feasibility. There is no need to design a perfect architecture at the expense of 5 times more of the planned budget and scheduled time. So prior to dive deep into an architecture design, think about how much time, money, and human efforts it will cost to implement that architecture design, and do the cost/benefit analysis. Technical feasibility represents concerns of whether the designed software can be actually implemented. Technical feasibility should be assessed in terms of two aspects: technology issues, e.g. the performance and scalability of a technology; and market issues, e.g. third-party / vendor support for related products / services . Operational feasibility highlights how feasible to maintain the software after it is built. Political feasibility concerns whether such software is allowed to be built internally within the organization or externally.
Secondly, good architecture meets the most critical architectural requirements in the project. For instances, trading software must exhibit high performance and high reliability while insurance software must present high usability of managing its data, so their software architecture must exhibit those qualities to be a fairly good one. Deciding what the most critical architectural requirements are mainly depends on the tradeoffs between project constraints and business goals.
Thirdly, good architecture accommodates changes in the future. Changes constantly happen in business, where changes might come from acquisitions, mergers and increased competition, etc. Changes constantly happen in technology as well, such as new platforms, new frameworks, and new languages. In this aspect, it asks architects to design for change, which facilitates software evolution. Design for change could be achieved by layering, open implementation and aspect-oriented programming, etc. More generally, it could be achieved by reducing dependencies, leveraging standards, creating product-agnostic architectures and creating domain-specific architectures.
1. Ambysoft. Justifying a software development project. http://www.ambysoft.com/essays/projectJustification.html