In this post I will present my views on various aspects of software architecture. These views are not limited to any specific technology.
What is Software Architecture?
A software architecture is typically a set of design decisions to address various non-functional requirements and attributes of a software system/application. It primarily focuses on aspects such as performance, reliability, scalability, testbility, maintainability and various other attributes, which can be key both structurally and behaviorally of a software system.
All architecture is design, but not all design is architecture
A new software product development requires a strong focus on some of these non-functional attributes based on the domain and the nature of the application. It establishes the context for design and coding. Example: A banking application may require special attention on security and availability of the application. Architectural decision have to be well thought to setup a strong base and long term view into consideration; its not only very difficult to change these decisions later on, but, will have significant ripple effects on the software.
Some of the things to keep in mind when architecting a software solution are:
- A, do not reinvent the wheel policy – Best architects copy solutions that are already proven in the software world. Architects are the one who adapts them to the current context, improve upon their weaknesses and design in such a way that it enables incremental improvements.
- Simplest architectures are the best – One always has to remember that there will be trade-offs. Example: For a highly scalable system you will trade off cost. Attempting to put an architecture in place which addresses all the non-functional attributes, you are asking for the trouble. By this approach you are not only creating complexity into the system but, making it extremely difficult for the design and implementation team.
- Demo’able architectural blueprint – A software architecture blueprint should ultimately be converted into executable code. It should not be a mere sketch on a paper or a soft-copy of the model, which the software designers find impossible to visualize and construct.
- Key responsibilities - Define and validate the system’s architecture, maintain the conceptual integrity of the system, assess and attack technical risks to the system, resolve the design and implementation teams conflicts, document the architecture.
- Keep tool set upto date – Modern day software requires architects to have updated tool sets in their bag to fulfill various challenges. They particularly have to be aware of how to effectively use them. There are several out of the box architectural tactics, patterns to help architect solve recurring problems.
I plan to cover some of these patterns and tactics in my next post.