A meticulous architecture assessment of a software system that is developed or yet to be developed helps in understanding if the team is on the right track to realizing the customer's vision and business solution, not only at the present moment but from a futuristic long term perspective as well.
There are primarily 5 reasons why customers should carry out Architecture Assessments for their software systems. An architecture assessment helps in…
· Reinforcing the business vision and objective(of the architecture).
· Realizing the current state(of the architecture).
· Identifying unknown risks and addressing known problems.
· Defining the long term strategic roadmap.
· Realizing the ROI.
Reinforcing the objective
One of the most crucial reasons for an architecture assessment is to re-ensure that the objective or the goals of the architecture matches with the customer's vision and business strategy. Many a time's architectures that are created are based upon latest trends and best practices available in the market and don't focus primarily on the non-functional requirements of the application. While it is definitely a good practice to make use of the latest trends and practices it is extremely important we ensure we don't astray from the main objectives defined for the architecture.
Architecture is generally derived from the non-functional requirements and is designed to work in cohesion with functional requirements in order to achieve the overall business objective. The main goal of an architecture assessment is to ensure that we are on the right track to achieving the original objective of the architecture. For example: Every architecture has its own trade-off models, but every architecture should target a clear set of (non-functional)parameters that it should prioritize. It is important to prioritize between the architecture parameters viz: Performance, scalability, maintainability, reliability, extensibility. All parameters cannot have the same precedence else the architecture will be more of an overhead rather than a solution. This is the common cause of failures in most architecture's. The architect loses sight of the end product and long term goals and comes up with something very fancy by implementing the latest principles which may be good but may not be applicable for that specific business instance and hence ends up overburdening the architecture.
During an architecture assessment phase the architect assess the prescribed architecture along with the NFR requirements and determines if the architecture has the right balance that will help sustain the business requirements, growth and vision of the customer.
Realizing the current state
This is one of the most important reasons for having an architecture assessment. It is very important to realize the current state of the architecture vis-a-vie the proposed state. Architecture assessments happen at different times of a project lifecycle. Ideally it should happen just before the start of design or before the start of development. However that may not be the case with most software projects due to timeline crunches and project pressures. Hence in most cases architecture assessments are done reactively to take care of a particular set of problems that has risen (during development/UAT/production) rather than preventing its occurrence in the first place itself. Examples are: Performance problems, maintainability problems, lack of scalability etc.
In real world projects we have architecture assessments done to address project complexities that are well into the development or during UAT phase. Sometimes it's even done during the production phase on request of the customer due to a dis-satisfactory performance of the application. Hence it is imperative to take stock of the current architecture implementation, to understand the gap if any between the current architecture and the proposed architecture and to realize the current state and reason for the same.
80% of times the development architecture has more than 50% of deviation when compared with the proposed architecture. This is mostly due to the lack of well defined requirements, gap in understanding or lack in long term vision whilst finalizing the architecture during the proposal stage. Hence it is important to understand this deviation and the reason for the same, its root cause that warranted it and assess if we are on the right track or not. Many a times the deviations are warranted and at times it's just due to timeline crunches and due to implementations of “work-arounds”. Whatever maybe the case it is imperative to assess the impact of the change with respect to the overall vision desired by the customer. This part of the assessment serves as the bases to derive the associated risks and plan of action for the same to ensure the architecture is put back on the right track.
Identifying unknown risks and addressing known problems
Once we have assessed the current state of the architecture we then need to identify the probable risks associated with it and address the known problems along the way as well. This is probably one of the most well-known reasons as to why an architecture assessment is requested in 60% of the cases. It is because the management suspect that there could be a lot hidden risks that have developed during the implementation phase of the project or because the project has numerous bugs during the testing phase. Unfortunately an architecture assessment at this stage is done to put in quick fixes to achieve a short term outcome. The long term suggestions at this stage are generally very costly to implement since it involves a substantial amount of re-work and hence may be ignored as long as the application is working “Today”.
These suggestions are generally ignored until the application deteriorates so much that it becomes practically useless and the customer would be forced to rewrite the application. Hence once the current state of the application is known it is extremely important to analyze this data effectively and identify the unknown risks as well as prepare a short term and long term roadmap to address the known problems. Sometimes customers and project teams are only interested in addressing the known problems but it is extremely important for the architect to state the importance of a long term solution over a short term fix. It becomes even more important in cases when existing state of the architecture has deviated considerably from the proposed state. It becomes a necessity to get the architecture back on track while simultaneously addressing the known problem areas as well. Only after we do this we can ensure that we have not deviated from the long term business vision of the customer.
Defining the long term strategic roadmap
This phase would not be required in cases where the implemented architecture doesn't deviate from proposed architecture, since while proposing the architecture it is the duty of the architect to create an architecture with a long term vision and customer's business objective. This phase however is almost always required since the implemented architecture almost always deviates from the proposed architecture for reasons mentioned above.
During this phase the architect reassess the original vision and analyses the current architecture to ascertain its deviation from the same. It is during this phase that the architect also addresses the pain areas and problems and creates a detail solution for the same. He also prepares a roadmap which contains corrective actions to ensure that along with addressing the known problems and mitigating the known/unknown risks he also puts in a detail technical plan to realign the architecture as per the original design and established standards.
Realizing the ROI
This is probably the most difficult thing to calculate as outcome of an architecture assessment but this is probably the most important outcome that an architecture assessment should generate. Customers invest in a lot of money in architectures hence it becomes absolutely necessary to verify they are getting value for their money invested. Many a times a lot of money gets invested in implementing the latest architectures in the market. As good as those architectures may be they may well have been intended to address a different set of problems. Hence applying a general set of latest architecture principles to target a wide range of problems is not really giving the customer value for money.
At the end of the architecture assessment it is extremely important to derive the value for money or tangible ROI the customer has received from the architecture prescribed, especially if the architecture assessment is being carried out post development or post production. In instances where the assessment is carried out before development then in those cases we would need to calculate the projected ROI the customer would be expected to receive. Giving tangible numbers to our customers is the only way to generate confidence in customers as well as it keep us architects in check from over prescribing fancy architectures which may not be aligning with customer's vision.
An architecture should be crisp, focused and completely aligned with the customer business requirement and should be able to grow proportionally with the business. A good architecture contains the perfect balance of technical components that have been designed after prioritizing the non-functional requirements of the customer.
Conclusion
The article outlines the 5 most important reasons why customers and development teams should pro-actively carry out architecture assessments. In fact the cost of an architecture assessment should be budgeted for in the overall project cost. Ideally it's good to have it done prior to the start of the development phase. However no matter in what stage it is carried out, it still provides a lot of value by adding stability and reinforcing long term business vision of the customer.
