High-Level Design Application
How to make a High-Level Design in Software Development
Background
In the software development process, in this case, significant scope project development. That has many teams involved, and sometimes there is some missing link between the member for understanding the feature. The absent link cause by there is no base understanding for each team. That is why documentation is needed to standardize the development process. A High-Level Design can be a way to get all team understanding of how the overall solution that will be implemented.
High-Level design can provide a framework or guidance for across the team the get a better understanding of the feature. This documentation can drive the detailed design to follow the overall solution. To create a High-Level Design there are many approaches to start with. The simple way to do it is to create a diagram to represent the solution. The document will not contain a full explanation, like what framework to be used. But more like a general flow on how the process would be and what technical solution that we needed to complete the requirement.
The Solution
Gather Requirement
The first thing to do is to get the full requirement from the business team. Regardless they already make the User Story (List of requirement in a story form by user perspective), we also need to get a better understanding of the requirement. To get a solid base of understanding requires a discussion of the requirement with the Product Owner, which in that session, we can run through the requirement one by one.
We usually will look at the story, and the UI design (if already there) briefly take a look at:
- Business rules
- Front End
- Data flow
- API standpoint
- Database
- External system integration
In the session, we can roughly discuss all the points and our perspectives from the technical team to the business team. Then there might be a change in their requirement and design based on how the session going because we don’t want any funny requirement that in the end cannot be implemented in our application.
Get High-Level Flow
After getting clear about the requirement and high-level flow, it is time to create a high-level design. First, We make a (System) diagram to design our solution. In our project, because we use Microservices architecture, we will define the use case as a service. We will create a relationship between service to create a general understanding of the service that will be used.
Second, we will create a diagram between the screen flow. In this diagram, we can get an overview of the general flow. We also put all the possible API (Application Programming interface), data flow, and external system integration. To create this diagram, we need to align the requirement and the design screen. Don’t forget to include all the decisions and logic between each flow. For High-Level Design, we only create a positive flow, or usually, we call this happy flow. Because first, we want to know the goal of the process.
System Diagram
In creating the System Diagram, we’ll have to see deeper from the technical standpoint. These days, we use separate Micro Services for each feature. It will be based on how the technical team doing the work. So for this case you have to understand already when we will need to create a new Microservice and when it is not. This understanding will be variant on how the organization work and you as the one to develop the solution. There will be a lengthy discussion across the team before and after creating the solution. But the main point here is to get the answer first on how we will complete the requirement.
- Can we use existing Micro Services to handle the requirement?
- How many new Micro Services that we need?
- Is there any external system that needs to be integrated?
Based on this question we need to come up with the answer by the system diagram. We can draw it like this, in this case, is a mobile application, by connecting it to the require Micro Services and what external system that we need.
High-Level Design
After creating the System Diagram, we can continue work on the High-Level Design. In this diagram, it will be much better if the UI/UX already finish their design. So we can recreate their flow with plus the technical solution that we come up with. To doing so, start with the positive flow, where is the entry point, draw the process until when the flow is ended. Add the decision and logic for each screen. After that add the solution, what API that we need to call, what Microservice that we use, what data we need to pass for each screen. We will use this naming convention for the API. But it will be based on how the technical team will write it.
The next step is to add the external system that we needed for each API. If you already know the system name you can put there specifically, either way, you can put the function first like “Payment Gateway” etc.
Later after you finish the positive flow, we can design the negative flow. Practically we need to see all the possible handling for the flow. Like when the API call is failed, business error, external system down, or cannot be reached. All that can be added here in the High-Level Solution, or we can keep it later for the Detailed Design. At least, we can identify first how the handling would be looked like.
Conclusion
By doing this organization now will have base documentation on how the feature will be. We can present our solution upfront to explain how the feature work and what we need to implement. The technical team can get a bigger picture of the feature and start thinking of the implementation. From a business team standpoint, they can get a functional diagram that explains how the requirement will be built. When we can get all team to understand the big picture we can collect the feedback faster on how complex the feature will be and of course how long it will take. This documentation and process will remove the missing links and can get all the team on board with the same goal; collaboration from each team require to produce a quality and faster implementation.
Although creating a High-Level Design is not a one-time process, you need to iterate the process over and over again through many cases and scenarios. Because you want this as a foundation of the feature or application, you want to build. Get experience by discussing with many functions of the team. Even you can use High-Level Design to communicate with management on how the solution will be. In the end, all member from the business team or technical team can go back to this to see the solution, how the feature work, what do we need, and what the goals of the feature or application.
