Art Villanueva – G2 Ops System Engineering Solution Director
Keywords – architecture, technology, software, hardware, systems, enterprise, engineer, solution, systems architecture
Estimated Reading Time: 4 minutes
What does System Architecture mean in the world of technology and non-shelter engineering?
The word architecture invokes reflections of structure. And often, it elicits feelings of awe and grandeur. After all, when we talk about architecture, we often refer to buildings – the beauty of St. Peter’s Basilica, the massiveness and simplicity of the pyramids of Giza, and the alluring gaudiness of the Sagrada Familia. But when we talk about systems architecture, we’re most likely not referring to brick and mortar. Systems architecture is the embodiment of a system solution that takes into consideration functional needs (what does it do?), non-functional needs (how would you describe it?), and most specifically, its required quality attributes.
What is Architecture?
Architecture is design (though not necessarily the other way around), whether it be of software, hardware, systems, or enterprises. Architecture defines the highest-level solution to a problem. System architecture is the collective structure and behavior of a system and its relationship with its environment. What an architecture is not, is a model. A model is simply a representation of an architecture akin to what a blueprint is to the architecture of an office building.
But if systems architecture embodies the systems solution, it must also focus on such things as usability, reliability, security, affordability, and so on (sometimes called “ilities”). Because of this, when systems engineers refer to architecturally-significant requirements, it is these quality attribute requirements that matter the most. Because while problems often have many solutions, an architect realizes that there are only a handful of ways to satisfy the most important quality attribute requirements. So, what does this mean in the practical sense?
Architecture for the Real World
Take for example a need in which the goal is to get from point A to point B multiple times a week. Let’s assume the distance between the two points is anywhere between one and 300 miles of flat land. Functionally, many solutions exist, from a bicycle, a helicopter, a hot air balloon, a bus, and even a pair of shoes – you name it! A good architect, however, considers the non-functional requirements of this transportation device as the driving force in the design of a solution.
Does the customer require efficiency as the primary driving requirement? Is it affordability? Reliability? Coolness factor? If money is no object (wouldn’t that be nice) – i.e. affordability is absolutely not an issue – and other circumstances (such as laws) allow it, perhaps a quadcopter-like machine will suffice. If the customer has $100 to spend and getting to the destination quickly is not an issue, perhaps a bicycle-like solution for this transportation device will do.
Though this example is certainly contrived, it illustrates obvious architectural selections. In reality, these architectural decisions are not so clear-cut, and the architect is forced to weigh multiple quality attribute requirements against each other. Some or all may be equally important, and often diametrically opposed (e.g., how much more important is usability over security, or affordability over reliability?). Compromises are often necessary, and drive architectural solutions to be chosen among, say, an n-tier, a SOA, or a peer-to-peer solution.
System Architect/Engineer collaboration
Ultimately, because of many factors, the architecture of a system is defined not just by the architect, but equally as much by the implementing engineer. The relationship between an architect and an engineer is a push-and-pull, where the architect describes the vision of the solution, and the engineer provides its implementation. If the engineer cannot implement a particular architecture, the architect may be forced to reconsider other solutions or determine that, with consultation with the client, certain tradeoffs are now acceptable.
Final Words
It’s important to pay attention to non-functional requirements over functional ones. Architects, designers, engineers, and anyone that designs systems needs to know that functional requirements are not sufficient in defining a system, much less a complex one.
As for the transportation example, if I were the customer, and I need availability of fuel as well as reliability and sustainability of the device itself. I think a solution that’s an electric car will be just fine.
***
Learn more about MBSE, Cybersecurity, and Cloud Engineering at www.G2-ops.com
