A careful evaluation of the architecture of a developed or to be developed software system helps to understand if the team is on the right track to realize the customer’s vision and business solution, not only in the present moment but from a future perspective to future. long term as well.
There are mainly 5 reasons why customers should perform architecture assessments for their software systems. An evaluation of the architecture helps in…
Reinforce the vision and business objective (of the architecture).
Be aware of the current state (of the architecture).
· Identify unknown risks and address known issues.
· Definition of the long-term strategic roadmap.
Realization of ROI.
reinforcing the goal
One of the most important reasons for evaluating an architecture is to re-assure that the architecture’s goal(s) align with the client’s vision and business strategy. Many times, the architectures that are created are based on the latest trends and best practices available in the market and do not focus primarily on the non-functional requirements of the application. While it is definitely good practice to make use of the latest trends and practices, it is extremely important that we ensure that we do not deviate from the main objectives defined for the architecture.
The architecture is typically derived from the non-functional requirements and is designed to work cohesively with the functional requirements to achieve the overall business goal. The main goal of an architecture assessment is to ensure that we are on the right track to achieve the original goal of the architecture. For example: each architecture has its own compensation models, but each architecture should target a clear set of (non-functional) parameters that it should prioritize. It is important to prioritize among the parameters of the architecture, namely: performance, scalability, maintainability, reliability, extensibility. All parameters cannot have the same precedence, otherwise the architecture will be more of an overload than a solution. This is the common cause of failure in most architectures. The architect loses sight of the end product and long-term goals and comes up with something very elegant by implementing the latest principles that may be good but may not be applicable for that specific business instance and thus end up overloading the organization. architecture.
During an architecture assessment phase, the architect evaluates the prescribed architecture along with the NFR requirements and determines if the architecture has the right balance that will help support business requirements, growth, and customer vision.
Realize the current state
This is one of the most important reasons to have an architecture assessment. It is very important to realize the current state of the architecture versus the proposed state. Architecture assessments occur at different times in the life cycle of a project. 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 time constraints and project pressures. Therefore, in most cases, architecture assessments are done reactively to fix a particular set of issues that have arisen (during development/UAT/production) rather than preventing their occurrence in the first place. Some examples are: performance issues, maintenance issues, lack of scalability, etc.
On real-world projects, we perform architecture assessments to address project complexities that are well into development or during the UAT phase. Sometimes it is even done during the production phase at the request of the customer due to unsatisfactory application performance. Therefore, it is imperative to take stock of the current architecture implementation, understand the gap, if any, between the current architecture and the proposed architecture, and realize the current state and reason for it.
80% of the time the development architecture has more than 50% deviation from the proposed architecture. This is mainly due to a lack of well-defined requirements, a lack of understanding, or a lack of a long-term vision when finalizing the architecture during the proposal stage. Hence, it is important to understand this deviation and the reason for it, its root cause that justified it and assess whether we are on the right track or not. Deviations are often justified, and sometimes they are just due to timeline issues and due to “workaround” implementations. Whatever the case, it is imperative to assess the impact of the change against the overall vision desired by the customer. This part of the assessment serves as the basis for deriving the associated risks and action plan to ensure the architecture gets back on track.
Identify unknown risks and address known issues
Once we have assessed the current state of the architecture, we need to identify the likely risks associated with it and address any known issues along the way as well. This is probably one of the best known reasons why an architecture assessment is requested in 60% of cases. It is because the management suspects that there could be many hidden risks that developed during the implementation phase of the project or because the project has numerous bugs during the testing phase. Unfortunately, an architecture assessment is done at this stage to implement quick fixes and achieve a short-term result. Long-term hints at this stage are generally very expensive to implement, as they involve a substantial amount of reworking, and thus can be ignored as long as the application works “today”.
These suggestions are generally ignored until the application deteriorates so much that it becomes practically useless and the client would be forced to rewrite the application. Therefore, once the current state of the application is known, it is extremely important to effectively analyze this data and identify unknown risks, as well as prepare a short-term and long-term roadmap to address known issues. Sometimes clients and project teams are only interested in addressing known issues, but it is extremely important for the architect to establish the importance of a long-term solution over a short-term fix. It becomes even more important in cases where the current state of the architecture has deviated considerably from the proposed state. It becomes a necessity to get architecture back on track while also addressing known problem areas. Only after doing this can we ensure that we have not deviated from the client’s long-term business vision.
Definition of the long-term strategic roadmap
This phase would not be necessary in cases where the implemented architecture does not deviate from the proposed architecture, since when proposing the architecture it is the duty of the architect to create an architecture with a long-term vision and the business objective of the client. However, this phase is almost always necessary since the implemented architecture almost always deviates from the proposed architecture for the reasons mentioned above.
During this phase, the architect reassesses the original vision and analyzes the current architecture to determine its deviation from it. It is during this phase that the architect also addresses pain areas and problems and creates a detailed solution for them. He also prepares a roadmap containing corrective actions to ensure that in addition to addressing known issues and mitigating known/unknown risks, it also includes a detailed technical plan to realign the architecture to the original design and established standards.
Realization of return on investment
This is probably the most difficult thing to calculate as a result of an architecture assessment, but this is probably the most important result an architecture assessment should generate. Clients invest a lot of money in architectures, so it is absolutely necessary to verify that they get value for their money invested. Many times a lot of money is invested in implementing the latest architectures on the market. As good as those architectures may be, they may have been intended to address a different set of problems. Therefore, applying a general set of the latest architecture principles to address a wide range of problems is not giving the customer value for money.
At the end of the architecture evaluation, it is extremely important to realize the value for money or the tangible ROI that the customer has received from the prescribed architecture, especially if the architecture evaluation takes place after development or production. In cases where the evaluation is carried out prior to development, in those cases we would need to calculate the projected ROI that the client is expected to receive. Providing hard numbers to our clients is the only way to build client trust, as well as prevent us as architects from over-prescribing sophisticated architectures that may not be aligned with the client’s vision.
An architecture must be clean, focused, and fully aligned with the customer’s business requirements and must be able to grow proportionally with the business. A good architecture contains the perfect balance of technical components that have been designed after prioritizing non-functional customer requirements.
conclusion
The article outlines the top 5 reasons why customers and development teams should proactively conduct architecture assessments. In fact, the cost of an architecture assessment should be included in the budget for the total cost of the project. Ideally, it’s good to have it done before the start of the development phase. However, no matter at what stage it takes place, it still provides a lot of value by adding stability and reinforcing the client’s long-term business vision.