Understanding System Architecture: The Key to Effective System Design

A system architecture is a conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system.

Architecture describes the structure and organization of a system’s components, and the relationships of the components to each other and the environment—the system’s component interfaces, interactions, and the governing principles for a system’s design and evolution.

The architecture also specifies the externally visible properties of the components—its provided and required interfaces, its performance characteristics, and so forth. In this, it enables (provides for the ability to achieve) the stipulated (business) requirements to align with the design as it needs to be. The business requirements and the design should always be in sync for the system to function correctly for the underlying business operations and any potential legal requirements.

No matter how small a system may be (e.g., the backrest for your office chair) or how large the International Space Station (ISS), you don’t want to just guess how to make it by only hearing about it from a friend (informally at best). So, the business needs what it needs, and the architecture should reflect that in the design documentation right from the start! In other words, the system design will include the business requirements embedded in it, which will result in the architecture being documented just as formally such that the entire development team will understand clearly what to construct (even if it’s Agile, where you have sprints and backlog, but the reason for the backlog is related to the business parallel of the technical debt).

What is System Architecture?

Your system architecture is a structured set of ideas about what a system should look like: what it is; what it does; how it operates; and how it’s put together. Aligned with this is a set of principles or ideas about how the architecture will and should operate – a design philosophy (more about this later).

Architecture consists of:

• Purpose – what the system is for.
• Function – what it does, and what the system’s elements do; the operation of those elements.
• Interfaces – descriptions of how the elements relate to, interconnect with, or communicate with, each other – the form of interaction or interrelationship. For example, the architectural plan of a house will specify the number of rooms, what the rooms should be used for, and how they are laid out on a section. It could also specify which rooms should be next to each other, and where on the property that house should be located.
• Interrelatedness – how the elements interrelate. For example, the slowdown in the supply chain because of the COVID-19 pandemic (that took place in 2020) meant that some businesses that applied just-in-time stock control models, used by many low-margin operations, couldn’t get stock. In other words, if one part of the system is affected, the other parts could be.

The Role of Constraints in System Design

In system architecture, the term constraints are used to describe the set of limitations or the necessary requirements that we need to design for. They can be technical, including:

Hardware capabilities Software capabilities (do they need to interoperate with specific software or use specific software components?) Performance capabilities (must the system work within specific peaks, valleys, or averages?) Or non-technical (budgets, political considerations, laws or regulations, usability, etc.).

By setting out the list of constraints that a software product must (or mustn’t) adhere to, we give the product team a set of goals that the system absolutely must achieve. These constraints could be considered the absolute peak of our to-do list—this is the stuff that has to get done. This list does not help us prioritize the most meaningful work to do, but rather, helps us prioritize the work that can and cannot be done.

For example, if our system must run under a specific budget, well, we can simply decide which features to kill that may not create important user outcomes. Similarly, if your system must be operable by a specific group of users, designed in a specific programming language or operating system, or your system must be decentralized, you must focus on creating a product or system that works effectively under those set-in-stone constraints. Knowing the audience we have to engage or the system our software must operate on helps guide us toward the right process or the right product to conceive.

Identifying Driving Requirements

Driving requirements are the system requirements that primarily determine what the system must absolutely do. They constrain the functionality of the system more than any others.

Driving requirements are where the system “comes from;” the rest of the system follows from them. Appropriately, they drive the project, and in terms of the way the project is executed, they drive resources toward the design and development of the system’s architecture—and toward any problems that arise with the design.

In the architectures of systems, there are driving requirements—and the other kind.

To identify the driving requirements and to separate them out, perhaps it will be useful to establish some context first.

To find the true driving requirements (and indeed that is typically difficult to do), we must first ask ourselves (as developers): What type of system is it really, and therefore, as we go on to code it, what are the particular “features” of this thing that are the most important—and the most difficult—not in an attempt to build them (those requirements) first–so that the project won’t go on without them (without requirements like those, anyway) but in fact to drive the architecture of the system more than anything else possibly could?

Whatever becomes embodied in those requirements will, no doubt, be coded into the system first (in that next long marathon). Here, then, the particular type of system that we have on our backs is what will reveal what those difficult and most important features are.

The particulars of the architecture will dictate the system type because it will be these few—and few, several? Only one or two? Who knows—requirements that will drive the whole design of it.

So we must ask: What…is it? In order to find the driving requirements?

Now let’s see…. If we could define a process for turning this into a repeatable task for the project manager?

1. Identify those features that are most important to performance.
2. Categorize them based on whether they are equally, or more or less, or much less, important.
3. Distinguish between what is typically critical to manage, in terms of the system’s requirements. The driving requirements will be the first up for this because the system cannot do without them.
4. Distinguish between subsequent, less critical categories of requirements.
5. We must use our own judgment for those that simply may not be able to be included.

(a) … now we will know the difference between driving and trivial.

6. Now focus on the projects: those that will have in them the tough, mean ones that will drive the project’s costs. Validate those driving requirements through the use of prototypes.

Segmentation of the System

Segmenting a system is necessary to successfully address driving requirements in the various segments of a large system. Segmenting makes the system better organized, simpler, and, thus, a tremendously more effective way to implement.

For example, for one set of requirements, it might be possible to undertake a Functional Decomposition, whereby the top-level function of the entire system is first identified and established. After that, that top-level function should be broken down further into a series of sub-functions, which together perform the top-level function. It should then be possible to continue decomposing (detailed design) the sub-functions (which have been established to be independent of each other), hoping to treat each sub-function eventually as a low-level “black box.” One great advantage of this scheme would be that the sub-functions (segments of the system to which driving requirements have been assigned) would then be ignored for the most part, allowing the many participants in the development effort to be devoted, on a continuing basis, to the discussion only of the driving requirements themselves.

That’s about as pure as you can get it! And you might also be able to accomplish basically the same thing with an Agile approach. In that case, you would produce, one at a time, a succession of segments of the total system (running through all the design phases each time). As the segments accumulate, you should be able to fit the entire set of them together to trim thus far.

From Architecture to Design

Architecture is the high-level organizing structure for design; it is the backbone upon which all detailed design components are hung.

Architecture involves identifying high-level organizational structures and components, how they work together, and their relationships. It provides a place to deal with and understand design issues/problems at the macro level so that you’re not solving those same (macro) issues when you reach the detailed design phase later on.

Like all design, and as a form of requirements-based design, before you can escape this phase, you must perform requirements analysis. This involves identifying the design problem and, among other things, consulting with project stakeholders and users, brainstorming solutions (then gaining feedback on those prototypes), and parsing functional from non-functional requirements. Not until this phase is over—and is the architecture considered compliant with the system/product/function requirements—is the work product of the architectural design reviewed and approved.

One or more design reviews will occur during this phase and each phase after Project Planning (and before Validation) to make sure that before design leaves this phase, it not only achieves compliance but maintains goodness along the way. “Goodness” in design refers to robustness and adaptability. Here, the system, product, or function is reviewed in its current state (“as built”) for all design outputs and activities to date.

System architecture means the conceptual structure and logical organization of classes, packages, subsystems, layers, and components of a software process.

It is the set of components, their properties, the interplay between them, and the guidelines to derive and evolve the architecture over time. A good architecture must be functional for the needs the system is balanced to address, but also satisfy a good helping of the “-ilities,” like scalability, the ability to work through redundant instances, speed, and cybersecurity.

Those designing software systems are right to put an emphasis on architecture. A good architecture:

• Helps drive the system requirements.
• Helps identify risks.
• Simplifies development and testing. Designers first work on any project after the Project Requirements Report, ProRR, is completed, is to take on the logical view of the software. Under the workload of the architecture is to build the very first concept and choose a direct-to-architecture (DA) customer. Under this DA customer, there is a user. Under this user, there is a Design (D) to be done. The value of completing this to the design team is a longer and longer list that is feeding the work continually through a smaller number of architects. These architects work to examine best practices and drive these concepts.