Learning from Architecture Assessment

Learning from Architecture Assessment

In the recent past, I got a short assignment to analyze/assess the application architecture of an existing application, where they were planning to increase the users by 3 folds. The client wanted me to understand the current capability of the application and assess it can scale to the expected user load.

As I was doing this first time, I was not sure how to proceed. I consulted some of the senior members and got some tips as well, perhaps most of the things were different when I reached the client place.

So, I thought of summarizing my experience and give away some useful information if some architect gets such request in future.


This assessment is a Black box assessment which essentially means,  you need to look at high level architecture NOT the code.

Expectations from this assessment :

  •  Scale of the app to the required Users
  •  Identify Performance bottlenecks / Risks
  •  Suggest mitigation plans for identified issues
  •  Rate the risks and prioritize
  •  Suggest a road map with estimations to reach the target state.

Q: Any Standard approach available ?

A: Yes & No.

Yes, because there are some standard approaches available based on the previous experience. For eg: ATAM (Architecture Tradeoff Analysis Method) by SEI (Software Engineering Institute)

No, because the approach might change as per the application and available documentation and resources.

My Custom Approach: 

  • Do interviews with Technical and Business teams.
  • Understand the high level pain points of users
  • Map these pain points to Architecture
  • Collect metrics (memory, CPU usage, requests/sec, etc.)
  • Identify the risks and suggest mitigation plans.

I divided the architecture in 3 different types based on the application high level understanding. Then most importantly understand the business and types of users and their activities on the application. Identify the peak loads, most used functionalities, background jobs & their scheduled times, Master data loads, Any remote data push/pulls via different protocols and any other type of load coming to our application servers. If the application is used across different geo locations/time zones find out the over lap of users and their activities during peak loads (particularly).

Logical Architecture:  This is mostly the high level components involved in the application at each layer and how they communicate to each other and cross cutting concerns like logging, security handled. How the data is transmitted between application and database.

Integration Architecture: If the current application has any communication channels open both inbound or outbound with any external system. Usually all Enterprise applications have integrations with their ERP/CRM/SSO/DW/MDM systems. Apart from these depending on application there might be some systems outside the Enterprise also integrated. As cloud is becoming popular, these days many companies decide to store their content/documents in Box/Drive etc. and many other possibilities are there depending on the business of the application.

Deployment Architecture: If the application is deployed in traditional system, this is a key diagram you need to analyze and figure out the load balancing strategies. What is the hardware configuration of each server, their health reports during the performance testing, will become critical to decide the suggestions of this architecture.

Key Challenges involved: 

Availability of update architecture documentation:  this is very rarely available for most of the applications. In course of development the architecture will be changed, no architect will update the documents prepared at the design stage. So, I faced very similar challenge. They did NOT choose to document most of the stuff due to lack of time 😦

When you reach this state, all you are left with is to interview key players ( Architects, Lead developers, Business Analysts, Project Managers, Domain Experts etc;)

Availability of Resources for these interviews: as I already mentioned , they are key players. They are always busy doing some stuff. If you are not having a push from top, they might choose to ignore you. You somehow has to get time from these guyz to extract the information you need and in time.

Language issues: You might choose to ignore if you are lucky enough to work with all English speaking teams. For me it was  a challenge as half the team speak one language and the other half speaks another language. I am the only person who speak English 🙂

Conclusion:  First understand the business and collect metrics on required parameters. Do interview required people and gather information. Once you have all required information, analyze properly and figure out the key risks in the architectures and suggest best mitigation plans.

Hope this is helpful and happy assessments 🙂

Other Useful references :

Enterprise Architecture Assessment Framework

Assessing technical architecture