Software architecture is software design , but not all software design is software architecture. Architecture implies a high level overview of things. It set the boundaries and key guidelines of the development effort without going into a detailed specification of each implemented use case on the technological or business level.
Every developed system has an architecture. Most software architectures are incidental, matters of accident and small decisions made by different people at different times without accord or shared vision.
Software architecture is both easy and hard. It is easy because it doesn't get into every detail of the system being built, that is for the detailed design effort it is hard because it requires an encompassing vision of each key element of a system and the capability to set it in clear, concise and understandable writing.
As the product changes the architecture will change. Decisions are being made by each key stroke, by each library reference and each guideline not met - no matter how small or temporary.
The software architecture document must be therefore written in a short and concise way with pictures describing each key section of it in order to facilitate rapid understanding and ease of maintenance.
There are muliple way of doing software architecture. A good , and free book published by Microsofts Patterns and Practices covers all aspects of it, the Microsoft Application Architecture Guide, 2nd Edition. I would recommend it to everyone.
A dummy high-level model for a HRM system
When I approach and design a high level architecture document I generally cover the following sections:
- Project overview
- Project goals
- High level architecture diagram
- Technology platform
- Technology platform - process and techniques used for specific problems
- Key processes covered by the product
- Other
Project overview. A short overview of the project, usually a project sales pitch describing what is the project, who is the client and what the project is really about. I do not go into great details since there are other documents which are generally built to elaborate on the topic further.
Project goals. Or the project high level requirements are the handful of key things the project must be able to accomplish. This is the basis on which the architecture is being designed on. The architecture must be able to fully satisfy these , generally around five, requirements in order to be successful.
High level architecture diagram. The highlevel architecture diagram is the corner stone of the document. This is actually the picture or the sets of pictures most architectural discussions are done between engineers and which will set the broad strokes of the project. The key goal of the high level diagram is to set the relationships and communication channels between each compoment of a system. It can be done by using a block diagram with squares and arrows indicating componets (applications, modules, databases and etc. ) or it can be done by using UML's component diagrams.
Technology platform. A list of technologies used for the product organized in logical sections describing the goals and reasons for the usage of the technology. It is important to correlate the chosen technologies interdependencies, e.g. all the technologies must work well together and if not the risks must be identified, documented and review by all the architectural key stakeholders of the project.
Technology platform - process and techniques used for specific problems. Description of key usages of each technology. Most modern technologies used for the development of modern systems and products can be used in several ways, buy applying several techniques at ones disposal. For example one can rely heavily on the ObjectDataSource object in ASP.NET for all grid operations or could choose to manually bind data or just to build a normal HTML table with data into it. This important for a data heavy application where data will be often presented in a tabular fashion and this will be the main way a user will interact with the system.
Key processes covered by the product. This correlates directly with the high level requirements set for the product, e.g. the project goals and other critical issues which can applied to the entire product and are critical for its proper functioning. Here we could specify how the system reporting solution will work, how the system will interact with other key systems ( for example with an old dos accounting application critical to the client who can only write to the file system plain text files), how the authentication and authorization system will work , how will the caching solution work etc. Apart from the high level diagram this is the most critical part of the architecture and more so for the client. Often to support a specific process implementation an architectural spike will be developed to prove and disprove a point to the key architectural stakeholders.
Other. Architecture is for the most part a technical discipline done for the product development team. It is purposefully ten thousand feet up from the detailed specification of the product in other to cover, restrict and keep up with the full product life cycle. Each product is a separate beast with its issues and pitfalls, risks and challenges and there a myriad characteristic who could be added to the software architecture for a specific project.
