We know that we need to review the code we write the test strategy and test cases we make because it's better to have four eyes than two. Did we ever think of reviewing the architecture ? For many the answer would be a pause and going to think more and then reply mmm, not really. We all think architecture is something that needs to be worked on in the beginning of a brand new product or software or a service. Yes that's true, but that should not be the only time we need to look at those architecture diagrams and try to understand the meaning of the drawings or think how possible those diagrams can be converted to code. The reality is we need to review our architecture as well in regular intervals for several reasons. For cloud native software architecture review should be more frequent as cloud software development is more agile and changes are even more than traditional softwares. Today we will see why we need to review our architectures.
Contents
When to review architecture?
There are several occasions when an architecture review is needed. I am mentioning a few of the prominent ones here.
Evaluation for correctness
When architects come up with an architecture, it's not the end of discussion. The architecture also has to be reviewed. As an architect you need to keep room for assessment and review of your architecture by others. Before we start the architecture we have a requirement to fulfil. The requirements are functional and quality requirements. Accordingly we set our goal. Once the first draft of the architecture is ready we need to examine it for its functional correctness. When the architecture will be developed will it achieve the desired functionality ? Will it achieve the quality requirements ? We need to be sure what is being drawn is what we want to implement. There can be discrepancies or deviations from our goal. This can happen due to many reason. For example due to ambiguity or misunderstanding in the requirement or due to limitations in the technology, infrastructure and manpower. We also need to verify whether every stakeholder of the project understands the architecture.
Evaluation after Proof of Concept(PoC)
When architects develop the architecture of a new concept, generally they have some assumptions and to validate the assumption they conduct proof of concept(PoC). The PoC is a small, fast and ugly development to verify whether the assumptions are correct. Once a PoC is done the outcome of the PoC needs to be evaluated. The architecture needs to be reviewed when there are some differences between the assumption and the outcome.
After major release(s)
When you have an existing product and one or more major releases have been completed, there are some major changes or improvements. This might cause the current architecture to be different from the current state of the product. A major release and a series of minor releases can cause a significant change in behaviour of the software product which does not match the original architecture. Over time addition or modification of features and functionality can be significant and the architecture no longer represents the exact leaving software. This is a good time when you will want to review your architecture and make necessary adjustments in the architecture to keep it up-to-date.
Before start of development
This is obvious when you check back whether any development work is differing from the desired state of the architecture. It might also happen that you have a current state of architecture and the development starts assuming that the state of the architecture has not changed. As requirements and goals and boundary conditions always change, the architecture is also evolving. The development team might not notice the change and might start developing the old state of the architecture. It's a good idea to evaluate the architecture before major development tasks begin.
Change due to customer need or ask
When we are building software for a customer, they can always come up and change their mind. Customers can ask to add or remove features after the requirements are finalized. This kind of request can come after the architecture blueprint has been finalized and development has started. We need to accommodate customers' needs and change the architecture accordingly.
Change due to shift in business goal
When we start building a product we have some business goals from which architecture requirements are derived. Preparing an architecture blueprint takes some time when a software needs to be built from scratch. During this time the business goal can shift from its original point due to various reasons like a new market study can reveal that the target customer group has to be changed. This change in business goal can change the requirement. A rework and review of the architecture is needed at this point.
After a major issue is reported
When a major issue is reported by the customer or any stakeholders, the issue might be an effect of some architecture decisions taken in the past or assumptions taken while developing architecture, or some loopholes that have not been identified. This can force architects to change their previous decisions. It's better to touch base with the latest architecture of the product. Often solving the issue needs to be addressed in the architecture of the product.
Replacement of old technology
Technology is evolving fast. What was not possible a few years back is possible now. When we have an existing software product with existing architecture. Chances are that during the architecture decision making process limitations of then existing technologies are identified and an architecture decision is made according to that. After a few years development in technology may make it obvious to change the decision to improve the situation or provide a functionality which was not possible or not cost effective.
Replacement of old service
In cloud products it's very common to use off the shelf services to develop the product. The services used may no longer cope with the traffic or volume of data. A better service might be available from another vendor. It's even possible that the whole infrastructure on which the product runs is shifted to a new infrastructure.
Customer evaluation
During the customer evaluation phase of your product customers can resize what they need is not included. This can happen because the user requirement was not properly understood by consultants or architects or the customer was not aware of what he needs in detail. Or customers recognize the need for some features that they did not think of. Customers might find some loopholes in your product during acceptance testing too. All of these can trigger a change in the architecture.
Security validation
Your security expert can find discrepancies or weaknesses during security validation of the architecture or the product itself. You as an architect might need to address those security issues in the architecture of the product.
Who evaluates architecture?
Once the architect responsible for developing the architecture is ready with his architecture he/she needs to approach various stakeholders and review the architecture with them. This is needed to validate the correctness and also verify whether expectations of each stakeholders has been addressed properly. The peer architects, the Senior/chief architects can review the architecture for correctness. The Quality team can review architecture to check whether all quality attributes are present in the architecture with the right amount of weightage. The Security team can evaluate the architecture to identify any security loopholes. At the end Customers also need to review the architecture to get a feeling that what is being built is what they want.
Today, in this blog post we have seen why it's important to review architecture even more for cloud native architectures, when we need to review them and with whom we need to review them.