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.
Über den Autor
Iqbal is a software architecture enthusiast, serving as a senior middleware architect at Red Hat.
Nach Thema durchsuchen
Automatisierung
Das Neueste zum Thema IT-Automatisierung für Technologien, Teams und Umgebungen
Künstliche Intelligenz
Erfahren Sie das Neueste von den Plattformen, die es Kunden ermöglichen, KI-Workloads beliebig auszuführen
Open Hybrid Cloud
Erfahren Sie, wie wir eine flexiblere Zukunft mit Hybrid Clouds schaffen.
Sicherheit
Erfahren Sie, wie wir Risiken in verschiedenen Umgebungen und Technologien reduzieren
Edge Computing
Erfahren Sie das Neueste von den Plattformen, die die Operations am Edge vereinfachen
Infrastruktur
Erfahren Sie das Neueste von der weltweit führenden Linux-Plattform für Unternehmen
Anwendungen
Entdecken Sie unsere Lösungen für komplexe Herausforderungen bei Anwendungen
Original Shows
Interessantes von den Experten, die die Technologien in Unternehmen mitgestalten
Produkte
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud-Services
- Alle Produkte anzeigen
Tools
- Training & Zertifizierung
- Eigenes Konto
- Kundensupport
- Für Entwickler
- Partner finden
- Red Hat Ecosystem Catalog
- Mehrwert von Red Hat berechnen
- Dokumentation
Testen, kaufen und verkaufen
Kommunizieren
Über Red Hat
Als weltweit größter Anbieter von Open-Source-Software-Lösungen für Unternehmen stellen wir Linux-, Cloud-, Container- und Kubernetes-Technologien bereit. Wir bieten robuste Lösungen, die es Unternehmen erleichtern, plattform- und umgebungsübergreifend zu arbeiten – vom Rechenzentrum bis zum Netzwerkrand.
Wählen Sie eine Sprache
Red Hat legal and privacy links
- Über Red Hat
- Jobs bei Red Hat
- Veranstaltungen
- Standorte
- Red Hat kontaktieren
- Red Hat Blog
- Diversität, Gleichberechtigung und Inklusion
- Cool Stuff Store
- Red Hat Summit