On one fine autumn morning during my university education, our software analysis and design lecturer drew two different hierarchical representations for the same group of classes on the whiteboard. He turned back to us and asked a very simple question: "Which depiction is the right one?"
Unfortunately, he picked me to answer his question. As a young, unsure student put on the spot, I nervously chose the solution on the right side of the whiteboard. Our lecturer stared at me from behind his spectacles with a deadpan expression, then turned his attention to a student sitting next to me and asked, "Is he right?" My classmate, probably just as nervous and uncertain as I was, chose to disagree with me. He pointed toward the whiteboard and said, "I think the one on the left side is the right solution."
Our lecturer smiled and replied, "You both were right." He went on to explain at length that there are no right or wrong solutions in software architecture; there are only degrees of excellence that determine whether it may achieve or fail. An architecture that achieves a high level of excellence is prodigious, remarkable, impressive. Years have passed since, but it amuses me how that argument still holds true.
Defining software architecture
This argument that no solution is inherently right or wrong also applies to something as simple as the definition of software architecture. No other discipline fascinates me more than software architecture because it is a magnificent combination of art and science. It is also widely established that architecture is a hard term to define. Not because of any complexity associated with it, rather due to the depth it must dive and the layers it must unfold to ensure that it covers all bases.
Having said that, software architecture is a discipline that comes with an additional level of complexity. It has a logical representation that you can draw on paper. It can be discussed and explained, but its outcome doesn't physically exist. It cannot be praised for its magnificence. You can only measure it for its degree of excellence. Perhaps that is one of the factors that inflicts a general discontent with almost every definition created for this discipline, no matter how elaborate.
This could be why many experts consider Ralph Johnson's extremely short and open-ended statement about software architecture to be the most comprehensive definition:
"Architecture is about the important stuff. Whatever that is."
Fundamental characteristics of prodigious architecture
There was a time when a solution's structure would mostly be tightly coupled, shakey, unadaptable, and lacking vision or direction. Thanks to the evolution of software design patterns (layered, event-driven, microkernel, microservices, and space-based), architects can now weigh the advantages and disadvantages of particular designs before choosing the most suitable fit. These constraints include things such as infrastructure support, developers' skillset, budgeting, deadlines, and estimated effort.
Architects must always justify their architecture decisions, particularly when choosing a structure derived from a design pattern because it is tough and expensive to alter it in later stages. The architecture, however, is not just the structure. It must comply with more important characteristics (including resilience, reliability, and predictive ability) to attain a certain degree of excellence.
[ Working at the edge? Learn more about validated patterns. ]
Resilience is probably the most important mark of excellence for a structure. From the smallest individual component within the structure to the entire structure as a unit, the structure must be resilient enough to endure a small-scale failure and a large-scale disaster.
In addition to being able to sustain failure, all key components of the structure should be atomic—comprised of individual units—to enable their existence and function. Additionally, the capacity to adapt to changing dynamics over time elevates the pedigree of any structure. A structure should also be able to grow seamlessly and absorb any potential shock(s) from added exertion, stress, or structural deterioration without collapsing on itself.
Reliability is another aspect that contributes to a structure's excellence. It is easy to confuse reliability with resilience, but there is a lot more to reliability than just ensuring that a disaster cannot take the structure down or make it unavailable.
A structure can be considered reliable only if the interior is accessible only to legitimate requesters. It also means that authenticated and authorized users are not able to misuse or exploit the parts made available to them. Having this added layer of reliability ensures that the structure can help prevent meaningful amounts of effort from being wasted.
You can draw the structure on paper, but its ability to execute in the real world involves numerous processes such as development, verification, repair, upgrade, and maintenance, as well the capacity of your technological choices and human resources. Even a perfectly working system experiences normal wear and tear. Therefore, it must be able to undergo maintenance without entering a stop-the-world event in a fail-safe manner. It also must be intelligent enough to realize when its health is deteriorating and then raise alerts to preempt a potential failure instead of merely reacting to a failure's occurrence.
The structure should also have the capability to offer meaningful insight for future capacity planning. The majority of the effort required for these operations takes place early, in the beginning of the lifecycle. Therefore, it's a good idea to make them more immune to human error through automated deployment, testing, builds, and so forth. A structure that ignores these facts falls short of excellence.
Conclusion
Software architecture is way more than simply drawing arrows and other shapes depicting key components, complex use cases, and their respective interactions. Prodigious architecture goes beyond simply drawing some lines on paper. It peels back multiple layers and dives into depths to seek the right context and characteristics to achieve excellence.
About the author
Iqbal is a software architecture enthusiast, serving as a senior middleware architect at Red Hat.
More like this
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit