- Why is software architecture good (i.e., why do\nyou need software architects?) <\/li>
- How can you quantitatively assess an application\nor service? <\/li>
- What makes a good software architect?<\/li><\/ul>\n\n\n\n
These are difficult questions, particularly when you compare\nsoftware architecture with other fields. For example, it\u2019s relatively easy to\nquantify the value of a Six Sigma process-improvement organization: you measure\ntime, resources required, and costs of a process before optimization, and then\nafter, and you have a solid measurement of value \u2013 one that is simply not\npossible with software architecture. <\/p>\n\n\n\n
Why? <\/p>\n\n\n\n
Well, on a net-new project, architecture is applied at the\nvery beginning, so it\u2019s difficult to know if the lack of it would have made any\ndifference. Arguably, on a rewrite of a project, one could compare against some\nset of criteria how much better the new version works vis-\u00e0-vis the old one \u2013\nbut there are usually so many other factors in such a project that it\u2019s\nessentially impossible to separate out the contribution architecture makes. For\nexample, faster hardware or just plain better coding might be the reason the\nnew app runs faster, not the fact that the new design is factored more\neffectively.<\/p>\n\n\n\n
The Army Barracks<\/h2>\n\n\n\n
Perhaps an analogy can help us tease out how to think about\nthese questions. Software architecture is often compared (poorly) against\nphysical, building architecture \u2013 but let\u2019s try to make the analysis a bit more\nconstructive (pun intended). <\/p>\n\n\n\n
![\"\"](\"http:\/\/www.barrybriggs.com\/blog\/wp-content\/uploads\/2022\/03\/ArmyBarracks.jpg\")
<\/figure><\/div>\n\n\n\nConsider something as mundane as an army\nbarracks. How would we measure the quality of its architecture? <\/p>\n\n\n\n
I suppose there are lots of ways, but here are mine.<\/p>\n\n\n\n
First and foremost, does it do the job for which it was\nintended? <\/strong>That is, does it provide enough room to house the required number\nof soldiers, does it provide appropriate storage, bathrooms, and showers for\nthem? Is it well insulated and heated? In other words, does it meet the\nimmediate \u201cbusiness need?\u201d If not \u2013 well, you certainly couldn\u2019t assess its\narchitecture as good in any way.<\/p>\n\n\n\n
Then we could ask many other questions, such as:<\/p>\n\n\n\n
- Compliance with laws and standards, <\/strong>that is, building codes, Army regulations, local standards, and so on. Like business need, this one\u2019s binary: if not compliant, no need to perform any additional evaluation.
<\/li>- How resilient is it<\/strong>? Can it withstand a power failure, a Force 5 hurricane or (since this is a military installation) a direct hit by an artillery shell?
<\/li>- How much load can it take<\/strong>? If there\u2019s a general mobilization and much more space is needed, how many extra beds can it hold? 2x? 5x? 10x, in a pinch?
<\/li>- New workloads. <\/strong>The Army mandates that barracks become coed. Can the facilities be quickly adapted \u2013 if at all \u2013 to support separate sleeping areas, bathrooms, etc.?
<\/li>- How easy is it to add new features<\/strong>? For example, does it require a teardown to add air conditioning or can existing heating ducts be reused in the summer? How hard is it to install wi-fi hubs?
<\/li>- What about new components<\/strong>? Say the Army mandates that every barracks has to have a ping-pong table, which entails a building addition. Can such a thing be done quickly with minimal disruption?
<\/li>- Business continuity<\/strong>. Say the barracks does fall down in a storm. Are there sufficient facilities on the base \u2013 or on other bases \u2013 that the soldiers can rehoused?
<\/li>- Aesthetics<\/strong>. OK, maybe this isn\u2019t a good one for a barracks, but for other types of buildings \u2013 think I.M. Pei or Frank Lloyd Wright \u2013 aesthetics drive our view of good architecture. <\/li><\/ul>\n\n\n\n
You get the idea, and, hopefully, the analogy. In this case\nthe value of good design \u2013 of architecture \u2013 is readily apparent. <\/p>\n\n\n\n
Assessing Software Architecture <\/h2>\n\n\n\n
![\"\"](\"http:\/\/www.barrybriggs.com\/blog\/wp-content\/uploads\/2022\/03\/OnesAndZeros.png\")
<\/figure><\/div>\n\n\n\nWhen we think about software architecture,\nwe can apply similar criteria. <\/p>\n\n\n\n
Business Need<\/h3>\n\n\n\n
If the software doesn\u2019t satisfy business requirements, then \u2013 as we said above \u2013 it by definition cannot be \u201cwell-architected.\u201d Determining how well<\/em> software meets the need, however, can be an interesting and challenging discussion. For years, software development began with requirements documents, which could stretch to tens, hundreds, even thousands of pages; and managers would simply tick off the features that were implemented. (And as often as not by the time all the documented requirements were met, the business environment had changed, and the app was behind.) <\/p>\n\n\n\n
With agile development, users are much more involved in\ndevelopment from the start, tweaking and mid-course-correcting the product\nduring the development process. If there is a requirements document, it\nrepresents the starting point rather than a final statement \u2013 and this is good,\nbecause as the product takes shape, opportunities always present themselves,\nboth to users and developers.<\/p>\n\n\n\n
Still, how do we assess how well the product meets the need?\nOf course, one way is to ask users if they have the features they need; if not,\nsomething\u2019s obviously missing. <\/p>\n\n\n\n
But that\u2019s not all.<\/p>\n\n\n\n
Every line of code, every non-code artifact (e.g., images)\nshould be traceable <\/strong>back to the business requirement. If there is a\nfeature, somebody should be using it. Monitoring tools can help track which\nfeatures are exercised and which are not. (The Zachman Framework<\/a>\nwas an early approach to documenting traceability.) <\/p>\n\n\n\n
This applies to infrastructure as well. As infrastructure is\nincreasingly documented through Infrastructure-as-Code (IaC) these Terraform or\nARM or CloudFormation configurations should justify their choices: why \u2013 from a\nbusiness perspective \u2013 this or that instance type is required because of\nexpected load, SSD storage is needed because of anticipated IOPS.<\/p>\n\n\n\n
Standards and Compliance<\/h3>\n\n\n\n
Like satisfying the business need, complying with relevant\nstandards is binary: the software does or it doesn\u2019t, and if it doesn\u2019t, you\u2019re\ndone.<\/p>\n\n\n\n
Now by standards we don\u2019t mean \u201cbest practices\u201d \u2013 we\u2019ll talk\nabout those in a moment. Rather, ensuring that personal data is anonymized in\norder to comply with GDPR, or that two-factor authentication against a central\ncorporate provider (such as Active Directory) is used, or that only certain\nindividuals have administrative privileges: where such standards are in place,\nthey are mandatory, not complying places the organization at considerable risk,\nand thus the system cannot be assessed as well-architected. <\/p>\n\n\n\n
However, best practices can be more flexible. For example, a\ncloud governance team may mandate the use of a particular cloud provider, a\ncertain set of landing zones, a particular relational database, and so on. In\nrare cases exceptions may be granted. Here the goal of such guidelines is intended\nto speed development and ease operations, by removing the need for every\ndevelopment team to waste time selecting the appropriate provider or service\nand for operations teams to learn them all. <\/p>\n\n\n\n
Granting such exceptions must be intentional, <\/em>that\nis, careful analysis should uncover the core need for the exception; it should\nbe documented and possibly, the best practice should be updated. <\/p>\n\n\n\n
Defining Your Software Architecture Strategy<\/h2>\n\n\n\n
As is true with best practices, the definition and importance\nof other aspects of software architecture will necessarily vary from\norganization to organization. When developing architecture assessments,\norganizations should consider what their goals <\/em>regarding software\narchitecture are. For example, what are the relative priorities of:<\/p>\n\n\n\n
- Application performance<\/li>
- Application scalability<\/li>
- Developer productivity<\/li>
- Business continuity, including RTO\/RPO<\/li>
- Application visibility (observability) and\nself-healing<\/li>
- Software extensibility<\/li>
- Ease of upgrade<\/li>
- Usability (e.g., is it mundane\/functional or\nbeautiful?) <\/li><\/ul>\n\n\n\n
For example, for non-multi-national organizations\ngeoredundancy or multi-regional replicas may not be necessary. Others may\ndecide that the expense of active-active BC\/DR solutions is too high.<\/p>\n\n\n\n
Moreover, different applications will attach different\nlevels of importance to these criteria. For example, an intranet application that\nshows cafeteria menus need hardly be georedundant or be built with\nmicroservices \u2013 it wouldn\u2019t hurt, but perhaps resources could be devoted elsewhere!\n<\/p>\n\n\n\n
Strategy to Principles to Assessment <\/h2>\n\n\n\n
Having defined the organization\u2019s strategic goals from\nsoftware architecture \u2013 i.e., what is good software architecture and why it\u2019s\nnecessary \u2013 actionable principles can be developed. By \u201cactionable\u201d we mean\nthat developers can look at them and understand what must implemented, and\nperhaps even how. <\/p>\n\n\n\n
For example, if a key strategic goal is that applications should\nbe extensible, then a principle \u2013 that a developer can use \u2013 is that apps\nshould have a REST API, documented with OpenAPI or the like. <\/p>\n\n\n\n
A good starting point can be popular industry principles,\nsuch as the The Twelve-Factor App<\/a> originally\nintended to guide the development of SaaS applications but in fact is very\nbroadly applicable (shown below, via Wikipedia<\/a>).\n<\/p>\n\n\n\n
- How resilient is it<\/strong>? Can it withstand a power failure, a Force 5 hurricane or (since this is a military installation) a direct hit by an artillery shell?
- Compliance with laws and standards, <\/strong>that is, building codes, Army regulations, local standards, and so on. Like business need, this one\u2019s binary: if not compliant, no need to perform any additional evaluation.