Software/Application High Level Design

Question

What are the standards or recommendations for developing a high-level design of an existing software/application? Are there any reference guidelines that one can follow to build a high-level design? So that all the stakeholders understand the design in the same manner.

Answer 1

As I understand, the question is about developing and representing the high level design of an existing application. Assuming that the stakeholders are from varied backgrounds and not only technical folks, there can be multiple ways to represent the design. I would start with something like below:

Use Case Diagram - Any system will generally have actors and the various scenarios where the actor interacts with the system. The use case diagram helps lay out different scenarios of a system - for example - for a shopping application - user browsing the products, user searching for a product, user viewing the details of a product, user making a purchase, etc. This way we can capture what all capabilities the system provides and how do different actors interact with the system. To keep it at high level, the important scenarios can be included and the non-important ones can be excluded.

Flow Chart - Although a very traditional kind of diagram, Flow Chart is still very effective to convey a lot of information. The flow of data or process can be represented by the flow chart. A system can have many sequential and/or parallel activities going on. Many systems have a start (trigger) point while some systems are cyclic (having a loop). Also the system can have alternate paths depending on the conditions. These decision points and alternate paths can be very well represented by flow charts.

ER Diagrams - Any system generally has some entities and the entities are associated with other entities in some fashion. For example, a customer entity is associated with the order entity and has one to many relationship. While the flow charts and use case diagrams focus on the flow of data/process and the interactions, the ER diagrams focus on the relationships between entities. It provides a great way to understand the high level entities involved in the system and how are they related. Usually these relationships are long lasting, they do not change as frequently as the the data flow or processes change.

Deployment Diagram - Another diagram that provides a different type of information is the deployment diagram of a system. However this is more technical and may not be required at a high level but I think it provides a great value. Basically in a deployment diagram we specify how the system is deployed. For example, in an online shopping application, the diagram can show a rectangular box representing a browser and then show the load balancers which would be contacted first when the requests first hit the servers, and then show the application servers that handle the request, include the caching servers, show the databases, queuing mechanisms such as Kafka and so on. By modelling the deployment, someone can get a high level overview of what computer systems are involved to make the whole system function.

Hope this answer makes sense and provides some pointers for your question.

Answer 2

You can start by domain. Domain is the common language between stakeholders (business) and development. Well explained and understand domain is the first part of the high level architecture.