System Analysis & Design Hands-on Note
As the complexity of software architecture increases, good analysis and design become more and more critical. Since I became a software engineer so far, we are used to drawing something like an architecture diagram on a whiteboard and discuss with other colleagues.
But … have we really done the analysis and design well through this kind of process?
This may work during an interview that allows us to throw out a reasonable solution, but not always suitable for a real-world problem after onboarding. A software system needs to be considered about robustness and practicality, not just a proposal.
Most of the time we transplant and apply the pattern which we have learned before without planing the solution based on the current scenario.
Fortunately, almost all the popular modern tools are mature enough or having diverse plugins supported by a strong developer community to handle various issues.
However, these features could be helpless and inapplicable while facing an abstract topic of a big picture, or an extremely domain-specified bottleneck that no one else has ever encountered. I think this is the irreplaceable value of system analysis and design.
In this article, I will go through several perspectives that I care about and talk about why I will take them into consideration :)
Requirements
Understanding the requirements is always the first step, it can help me map out the corresponding objective through my domain knowledge. This makes every decision I have a clearer sense of direction, concatenate each part together, and play a key role in countless details.
Unlike software engineering, we should view the software outside-in while doing system analysis and design. Focus on the interface between the software and the outside world, the interactions with the supplier and user can explore more accurate results.
Sort out a series of specific requirements is not an easy task, just like describing how the economy works through a set of items. We may struggle with the wording, the level of details, and the boundaries of different requirements from time to time.
Functional Requirements & Non-Functional Requirements
I am used to listing the requirements from functional and non-functional perspectives, which stands for practicality and robustness, respectively. It makes me able to be more concentrated on each aspect individually.
While talking about the functional part, most of the discussion is around what this software can do, such as:
- Register a new account with the information form
- Pay with Apple Pay
- Show current location on the map
- Recommend posts that users will be interested in
These present the backbone of the business and need to be implemented correctly, but may change or increase as the software grows.
For the non-functional part, it's more about the software quality:
- Can afford up to 15000 requests per second
- Server response time should lower than 100ms
- Available with a Monthly Uptime Percentage of at least 99.95%
- End to end encryption
This is not the only way to deal with the boundaries of the requirements of different perspectives, but I think it works very well on software systems.
Tool as Solution
Tools often act as a solution for requirements these years, while I am researching some new technical tools, a vast amount of usage scenarios or experiences could be found on the official documentation or personal blogs.
This information really helps for a preliminary judgment on whether to continue to spend time on research and experiment, but it’s not adequate for analysis if I really attempt to use it in the software product.
Here I take Apache Kafka as an example, which is one of the most popular messages streaming platforms in the world recently.
After reading this, some readers may think …
Yeah, I really need Apache Kafka to streamming events in our software services.
Instead of adopting Apache Kafka in the production directly, I think starting from the original requirements should be a better choice.
- Queueing incoming tasks and deliver at-least-once to the backend server
- Allows multiple consumers consuming the same queue without affected by each other
- Can tolerate some nodes within the cluster failures
- Store all historical tasks for issue tracking
Use tools to achieve the requirements, not shape the requirements to fit the tools.
This can help me carefully examine whether technology or tool is what I need, and also avoid from blind obedience, instinct trap, and missed requirements.
Stakeholders
According to industry trends, it seems that we can no longer treat software as an independent unit. Some rental platforms or forums may operate stand-alone decades ago, but almost all software now and in the future needs to deal with many third-party roles.
A third-party library’s maintainers, the cooperative team in the same company, the public cloud provider, everything that’s not under our control should be taken as a stakeholder.
They are not static resources, their decisions, behaviors, and changes must be taken into consideration, instead of just focusing on the features they can currently provide.
Suppliers
The role of the supplier should be the most common stakeholders, tech companies often invest in computing resources, technical support, and paid services. But the tricky thing is we can’t assume they will never change as time goes by.
If they launch a new version of the software which more in line with the future needs of our team, are we able to follow up?
It can be very painful to get stuck in an outdated version, the team may need to invest extra time to workaround criticized issues or implement additional requirements.
However, the newer version may already have a better native practice.
It may be necessary for some third-party services to evaluate whether there is a need for upgrades in the future, track the release notes, and plan the upgrade process.
If the supplier changes the contract or billing policies, are we able to switch to another alternative solution?
It’s a more serious topic for a software system, but it also represents the importance of this kind of decision. Even the supplier does not change anything, we may also have these considerations for lower costs or corporate partnerships.
I usually prefer not to adopt a series of solutions from a single supplier entirely, this may cause the system to lose flexibility. If there is no significant gap in quality or technical support, maintaining a certain degree of diversity in the system is beneficial to withstand the changes of suppliers.
Trade-Offs
While doing system analysis and design, we may subconsciously focus only on what we can get or what problem can solve with the solution, but ignores the limitations and drawbacks.
Software engineering is not dreaming, everything needs to be traded off.
Consistency, partial fault tolerance, and accessibility are always mentioned when discussing distributed storage, it’s too expensive or difficult to achieve outstanding performance on multiple antagonistic aspects at the same time.
These force us to design the system base on the analysis of requirements, be aware of potential problems and judge how to trade-offs according to our objectives.
In addition to technical bottlenecks, there are also some engineering or operational issues that I think should be paid attention to.
Familiarity of the team with attractive technology
There are many highly discussed technologies on the market now, most of them have public success stories, and seems that the problem can indeed be solved. Those might be some great choices while facing similar dilemmas.
But the truth is, no matter how the solution fits the situation, the team needs to spend time on keeping it work with the current system, and even more costly if encountering a complex or rare error.
If no one has the ability to locate and solve the problem, it’s almost time to paid for technical support or looking for alternative solutions ;(
Fortunately, a lot of famous tools are open source, we can easily trace the issue through the documentation and source code while having enough related knowledge and experience.
I usually hope to introduce new technologies when there are two or more people in the team who are familiar with or are willing to study, in this way can we have effective discussion and code review.
Observability
After the software system goes online, how should we judge that it is in a normal state? Or, what kinds of benchmarks should we use to evaluate the status of the system?
Generally, most of the monitoring services help us take care of several resource usages such as CPU and RAM, but these OS-level metrics may not provide critical information, we need to know more about the system itself.
For example,
- The number of drivers and passengers of a ride-hailing service
- The voltage of each substation within a power grid
Expose the key metrics which match the requirements are very helpful for product maintenance, even indispensable. A clear dashboard can let the team react quickly to abnormalities, and have practical clues to track down the cause.
Closing
So far, several viewpoints on system analysis and design have been discussed, but this story is just the tip of the iceberg, having a global picture can empower us to promote software engineering more effectively.
