This is the 17th article on the System Design and Software Architecture series. In this article, we are discussing the System Boundaries in software engineering.
Previous articles
- Introduction to System Design and Architecture
- Values of system software
- Programming Paradigm
- What is Software Architecture
What is System Boundaries?
The system boundary is a concept line that divides the system you want to study from ‘everything else. The system environment is not part of the system, but it is useful to think that they are made up of things that affect or can affect the system. There are some examples of a specific area called a domain to see system limitations and how they can change.
The smaller the system, the sharper its boundary. Larger systems can have different limitations when interfacing with multiple systems. The boundary depends on the point at which it is seen in comparison to other systems that interface with it.
An example of the complexity and difficulty of defining system boundaries is the ATM (ATM). Consider the following candidates for the system limit:
- The physical machine itself
- Customer and machine
- The machine of customer accounts and the local database of the bank
- Machine & Bank National Network and Central Database of Transactions and Account Balance
- Machine and staff who issue regular software checks
What could the “correct” limit for analyzing an ATM-centric system? Different analysts may choose different limits, and these limits may vary when discussing with clients who want to build the system and with end-users of the system. An important skill has developed by system analysts and software engineers is to determine the limitations to consider.
The software we develop as software engineers are only part of the larger information systems of an organization or group. This module focuses on software development and engineering, but in order to design such software effectively and we just need to able to understand the information system as a whole and connect the software to it.
Architecture mainly depends on boundaries
In summary, the architecture of a system defines the shape of the system. More specifically, the architecture of a system defines how the system is divided into components, how those components have arranged, what kind of boundaries exists between different components, and how components communicate across those boundaries. Basically, this is all about how we use boundaries to separate parts of the system that we should not know too much about each other.
The purpose of this type of separation is to facilitate system development, deployment, and maintenance. The maintenance part, in particular, is very important because this is usually the riskiest and expensive part. Often, the first version of a system product is just the beginning, and most tasks take place after that. Additional requirements will need to add, changing the existing functionality. Etc. Adequate boundaries will provide the flexibility required for this type of maintenance.
Different types of System Boundaries
- Horizontal and vertical separation
When looking at different types of boundaries, we can start by comparing the boundaries by creating a horizontal or vertical separation.
Horizontal cutting creates boundaries between different technical areas of the system. This can create a layer for the API, business logic, and a layer for communication with the database. Horizontal boundaries help to organize the system source code. However, if the boundaries between different parts of the system are also the boundaries between different groups, horizontal cutting is often not the best option. Adding or modifying features often requires changes in multiple layers of technical inventory. If these different layers are managed by different groups, and even something as simple as adding one field requires coordination between several groups, which increases the complexity of the development process.
Vertical cutting, on the other hand, creates boundaries between different functional areas of the system. For example, the customer management function has the ability to separate from the function to order. One particular example of vertical slice cutting is the micro-services access, where each of the various small groups maintains one or more micro-services. Also that even a functional area is included in the database across several layers of the technical layer. This means that changes can occur within a single functional domain within a single group, and coordination with other groups is required only if changes are also needed to communicate with other active domains.
As mentioned earlier, boundaries are beneficial to the group scale, allowing internal coordination to develop the system by several small groups with more efficient internal communication than a single group at the top. It is an interesting idea about grouping is the Conway law. This “law” states that an organization that designs a system must create a system with a structure that fits the organization’s communication structure. It makes sense to design it this way: if changes in one part of the system can occur within a single group, these changes are easier to design and implement. The idea behind Conway’s law also means that if there is a mismatch between the team structure within your organization and the architecture of the application you are working on, application building can be a struggle. You can use the corner rule to your advantage by configuring your application (and thus your groups) so that system changes are limited to only one part of the application. In practice, vertical slicing usually seems to the best way to do it
Combining different kinds of System Boundaries
There is no need to select only one border. Different borders at different levels of your architecture are useful.
For example, you may have a microservice kit that you obtained using vertical tablets. However, each of those micro-services may have a layered architecture using horizontal slices to separate the various technical parts, which may can through components that have the ability to deploy across the original level boundaries or separately.
Boundaries come at a cost
While there are significant benefits to your system limitations, these benefits are not free. Boundaries can have some performance impact, but the most costly impact is their impact on development efforts. By providing flexibility and independence, limitations support productivity, which must need to developed and maintained, and their disconnection mechanisms can increase the complexity of the system as a whole, as is often the case in software development, instead of blindly introducing limitations and abstractions everywhere. Also, it is necessary to trade between the benefits and costs of each limit.
If you have five teams working on a system, they will benefit from having five clearly separate sections with fixed interfaces that connect them together. If only a small team is working on the system, the same architecture can detrimental to productivity. The experience and knowledge of different team members also contribute to this.
When in doubt, keep it simple. Unless there is a clear need for a limit, adding a limit is an opportunity sometimes in heavy engineering. There are already plenty of scary stories about systems with many abstract layers, some of which are hard to figure out where the logic sits at the base of the code or where any new feature should need to be implemented. This is not an indication of good architecture.
Conclusion
Thanks for reading the article System boundary as an essential component in System design and architecture.
My articles on medium
