A good software product rarely has a bad or not so good architecture and a good architecture does not guarantee the product to be good. What do we mean when we say a software product is a good product ? This blog post explains what it takes to build a good software architecture.
Contents
What makes a piece of software good ?
To begin with, we can think of some software that we think is good , excellent, or best in breed. I leave that up to you, but as an example, you could nominate Google Maps, Microsoft Teams etc. The very next question you might already have guessed. Why do you think so? Then you start listing down its capabilities. Below I have listed a few of them that will come to your mind. Don't look at them. Prepare your pick, think what those architectural decisions could be.
It's not hard to guess even if you don't know the inner details on how the software works. The next questions will be why and how they are able to provide these capabilities. And if you think a bit more you will realize, they have taken few good architecture decisions that made the software usable, performant and loveable. If you look at all of the reasons that you like the software you will see the architecture has to address all of them from the very initial phase. The architecture has to incorporate these in itself to advocate these capabilities.
List of capabilities
Standard
A good product follows standards, so that it's as per according to industry and according to the latest available technology. Without maintaining a standard it's extremely difficult to extend or integrate across pieces of the same software as well as other software. So we need to incorporate a standard in the design itself so that it can be enforced while developing the software.
Extendable
A good product is easy to extend and can add new features easily. As an architect you need to keep that provision in the architecture itself.
Consistent
A good product keeps consistency between the old and new versions. If the architecture is not easy to adapt changes then you can't keep consistency in you product,
Documentation
A good software always has good documentation for its users. If your architecture is not simple and elegant the software itself will be complex. And the documentation also will be complex.
Integration
A good software can easily integrate with various other software's or can incorporate or embed other software's. The architecture should allow easy integration with other products. It can be done by taking a decentralized and modularized approach in the architecture. The Interfaces of each module should be well defined and generic enough to be able to integrate with others.
Adapt changes
A software experiences lots of change with time, new requirements come, new features get added, old not used features are removed. New technologies provide opportunities for new capabilities. Good software always keeps itself relevant by continuous adaptation and upgradation. The architecture should be open so that it can easily adapt the changes to itself.
Ease of use and Configurable
A good software is usable, it's easy to use and it works out of the box. You do not have to train your users extensibility and changes can be made to the software by easy configuration. Ease of configurability and handling complexity has to do with the architecture of the software itself. From the beginning of the conception the architecture needed to take care of these.
Customizable
In a good piece of software can sell part or collection of its features, the product should be customized according to the need of the customer. We can't achieve customizability if the architecture is not modular and layered.
Performant
An enterprise software should have good performance, it should be fast enough. It should show the same performance when lots of users can use it at the same time. The architecture needs to have quality gates of each module and for the product as a whole. The quality measurement units and KPIs need to be established by the architect(s) and they need to provide how to measure and evaluate the product against those KPIs.
Scalable and resilient
A Cloud native product needs to scale that means each module or micro services that comprise the product needs to scale in the cloud as well and it needs to happen on demand. The architecture needs to be modularized so that different microservices can work together. The architecture should have the answer to how the microservices will scale on demand. If one or few micro services or modules does not work the whole product should not stop working unless those modules are central to the product. How should the product behave or inform users when such incidents happen? The architecture should be done keeping this in mind.
Balancing trade-offs
A good product has high quality(e.g. Performance, scalability), few of the quality attributes are contradictory in nature. The architecture should address the quality attributes according to their priority. When we develop a new cloud product we need to make sure the product is not a monolith but consists of reusable microservice. We also need to know the trade-offs between a monolith software vs a cloud based product. The architecture of a product will differ based on these decisions.
Outage management
A good product manages the outages and provides clear communication to the users. For example when a part of a cloud product is not working because few modules are down, there should be a clear and fast communication to the users. When a product is dependent on Cloud Infrastructure and reusable services its obvious that there will be hick ups. If the failure detection and notification propagation is not well thought of during the architecture modelling then it will be very difficult to adapt the product afterwards.
Cost effective
A product should be cost effective for the customers. What infrastructure and reusable services we are going to use to build the product should be well thought off from their capability, availability and cost perspective. All of these will have an impact on the price of the product. These points need to be well thought off during developing the deployment architecture of the product.
Reliable and Secure
A product is rated as good when it's reliable, it works almost all the time, always the same input provides the same output and the software is secured against various attacks. The security and reliability is a technical topic but needs to be implemented in the architecture itself, so the the product is developed as per the set standards and guidelines.
Robust
A product is good when its robust means when it can handle failures gracefully and can recover quickly. The failure detection and handling strategy and automatic or semi automatic recovery should be addressed in the architecture itself.
Agile
A product development should support Agile development, so the product idea can be brought to the market as quickly as possible. Even if the whole feature set is not developed the product should be launched with core features. The architecture of the product should support quick development and delivery. The architecture should be modular and the work packages have to be assigned to small teams that work in agile mode.
The list could go on. Few Other points to mention is that a product and its architecture should be customer driven, architects should have empathy for customers to solve their problem. A product should be Lightweight and powerful so that it can work and can be installed for a small and novice group of users as well as a large and knowledgeable group of users. The architecture should be done with eyes to the future so that any new concept and technologies can be incorporated easily.