There can be many descriptions of what software architecture is. In our mind, software architecture is a simplified full system and carries the main theme of the whole system. As we know, software system is self-similar; that is, it looks similar at different scales. From the full system, to subsystems, to modules, and to objects, they all follow the similar design principles and patterns. For example, applying the "open closed" principle, we separate interfaces from implementations at all levels of the system. The main theme is the sum of all the common principles, patterns and solutions that can be and shall be applied to all the levels of the software system. The goal of software architecture is to define such main theme so that by following the same theme software developers can work togeter towards a unified, common style final product. Besides, software architecture provides particular solutions for system infrastructure, and answers the following questions:
-
What does the overall system look like?
-
How many subsystems does it have?
-
How do subsystems communicate with each other?
-
What are the interfaces to external users and systems?
-
What is the concurrent processing model?
-
How to collect and process runtime data?
-
How to report and handle exceptions and errors?
-
How to achieve high availability?
-
How well does the system respond to changing requirements?
-
What are the mandatory design patterns and coding practices?
-
What are the testing strategies?
-
How to assess the performance?
-
How many man-hours are needed to build the whole system?
Usually architecture definition is delivered in the form of documents, literatures or software industry conventions such as UML. However, experience told us that how to effectively communicate the architecture to the users still remains as a serious challenge. On one end, customers want something simple yet countable so that they can understand and assess what they pay for. On the other end, developers want details and living examples so that they can understand completely and accurately the styles and principles set by the architect. Many architecture teams do not realize that architectures are only as good as they are communicated, and many projects fail because the architectures, even though very sound and impressive on paper, do not get all the way to the customers and developers.
At WISETEL, we face the same challenge. Throughout the years we have formed our unique and effective way to present the architecture - build a baseline system. Only through the tangible code, customers and developers can be convinced that the principles and designs are countable. For the subset of requirements to be covered, the baseline system must be fully functional and tested so that users can gain certain insights on how to assess the system performance and estimate the development efforts. The design and code of the baseline system are meant to be perfect models containing all the best practice and design patterns so that developers can follow easily and precisely. However, the baseline system will not and shall not cover all the requirements. There is an orthogonal relationship between the requirements and the baseline system. You need a complete baseline system to support even a small subset of requirements; however the baseline system will touch all the building blocks and infrastructure and set up an overall structure to mitigate the uncertainties and risks. To support more requirements, more design and implementation will be added but no fundamental change should be made to the baseline system. Therefore the baseline system, as a living example of the architecture, is more driven by the software vision, which is an abstraction of requirements, rather than by the requirements themselves.
