Points to Understand Architecture of an Application/System

Question

We are working on a knowledge transition of multiple applications (around 700). To make the process easy, I am preparing a list of key points we need to consdier for understanding the architecture of each application like below.

Why the list is important is once the transition is over, we are trying to integrate/rewrite/refactor these applications.

1. Technology Stack ( a. Programming languages b. Tools used c. Third party components)
2. Database ( a. Data model b. Data flow c. Clustering)
3. Interfaces with other applications
4. Dependencies
5. NFR

Anyone has any exclusive check list for this or enrich the above list?

Answer 1

If you built a house and you want to describe it to someone, would you talk about what kind of flooring material you used? About what kind of hammer and tools you used? About the plumbing?
You might, but none of this has to do with architecture.

Architecture is about what kind of rooms there are, where they are and how they are connected.

So the first thing you should talk about when describing your application is what it does. What its modules are and what those individual modules do. Then you should talk about how those modules relate to and interact with each other. That's its architecture.

The next thing is to talk about how the application and its modules work.

And the last thing is to talk about what tools you used to make that.

Your list so far only mentions tools and implementation details. I'm afraid none of those has to do with the architecture of the system.

Answer 2

In addition to Roman Reiner's answer, your checklist doesn't mention the requirements for each application.

You will need some combination of documents/diagrams/tests to say what the old applications are supposed to do before you start writing new applications to replace them.