What goals should software architecture strive to meet? You would think that this subject would have been intensely debated in industry and academia and the issue resolved decades ago. Sadly, such is not the case. Not only can't we build good software that works in a timely and cost-effective way, we don't even have agreement or even discussion about the goals for software architecture!
Given the on-going nightmare of software building and the crisis in software that still going strong after more than 50 years, you would think that solving the issue would be top-of-mind. As far as I can tell, not only is it not top-of-mind, it’s not even bottom-of-mind. Arguably, it’s out-of-mind.
What is Software Architecture?
A software architecture comprises the tools, languages, libraries, frameworks and overall design approach to building a body of software. While the mainstream approach is that the best architecture depends on the functional requirements of the software, wouldn’t it be nice if there were a set of architectural goals that were largely independent of the requirements for the software? Certainly such an independence would be desirable, because it would shorten and de-risk the path to success. Read on and judge for yourself whether there is a set of goals that the vast majority of software efforts could reasonably share.
The Goals
Here’s a crack at common-sense goals that all software architectures should strive to achieve and/or enable. The earlier items on the list should be very familiar. The later items may not be goals of every software effort; the greater in scope the software effort, the more their importance is likely to increase.
- Fast to build
- This is nearly universal. Given a choice, who wants to spend more time and money getting a software job done?
- This is nearly universal. Given a choice, who wants to spend more time and money getting a software job done?
- View and test as you build
- Do you want to be surprised at the end by functionality that isn't right or deep flaws that would have been easy to fix during the process?
- Do you want to be surprised at the end by functionality that isn't right or deep flaws that would have been easy to fix during the process?
- Easy to change course while building
- No set of initial requirements is perfect. Things change, and you learn as you see early results. There should be near-zero cost of making changes as you go.
- Minimal effort for fully automated regression testing
- What you've built should work. When you add and change, you shouldn't break what you've already built. There should be near-zero cost for comprehensive, on-going regression testing.
- Seconds to deploy and re-deploy
- Whether your software is in progress or "done," deploying a new version should be near-immediate.
- Gradual, controlled roll-out
- When you "release" your software, who exactly sees the new version? It is usually important to control who sees new versions when.
- Minimal translation required from requirements to implementation
- The shortest path with the least translation from what is wanted to the details of building it yields speed, accuracy and mis-translations.
- The shortest path with the least translation from what is wanted to the details of building it yields speed, accuracy and mis-translations.
- Likelihood of slowness, crashes or downtime near zero
- 'Nuff said.
- Easily deployed to all functions in an organization
- Everything that is common among functions and departments is shared
- Only differences between functions and departments needs to be built
- Minimal effort to support varying interfaces and roles
- Incorporate different languages, interfaces, modes of interaction and user roles into every aspect of the system’s operation in a central way
- Easily increase sophisticated work handling
- Seamless incorporation of history, evolving personalization, segmentation and contextualization in all functions and each stage of every workflow
- Easily incorporate sophisticated analytics
- Seamless ability to integrate on and off-line Analytics, ML, and AI into workflows
- Changes the same as building
- Since software spends most of its life being changed, all of the above for changes
Let’s have a show of hands. Anyone who thinks these are bad or irrelevant goals for software, please raise your hand. Anyone?
I'm well aware that the later goals may not be among the early deliverables of a given project. However, it's important to acknowledge such goals and their rising importance over time so that the methods to achieve earlier goals don't increase the difficulty of meeting the later ones.
Typical Responses to the Goals
I have asked scores of top software people and managers about one or more of these goals. I detail the range of typical responses to a couple of them in my book on Software Quality.
After the blank stare, the response I've most often gotten is a strong statement about the software architecture and/or project management methods they support. These include:
- We strictly adhere to Object-oriented principles and use language X that minimizes programmer errors
- We practice TDD (test-driven development)
- We practice X, Y or Z variant of Agile with squads for speed
- We have a micro-services architecture with enterprise queuing and strictly enforced contracts between services
- Our quality team is building a comprehensive set of regression tests and a rich sandbox environment.
- We practice continuous release and deployment. We practice dev ops.
- We have a data science team that is testing advanced methods for our application
I never get any discussion of the goals or their inter-relationships. Just a leap to the answer. I also rarely get "this is what I used to think/do, but experience has led me to that." I don't hear concerns or limitations of the strongly asserted approaches. After all, the people I ask are experts!
What's wrong with these responses?
In each case, the expert asserts that his/her selection of architectural element is the best way to meet the relevant goals. The results rarely stand out from the crowd for the typical answers listed above.
The key thing that's wrong is the complete lack of principles and demonstration that the approaches actually come closer to meeting the goals than anything else.
The Appropriate Response to the Goals
First and foremost, how about concentrating on the goals themselves! Are they the right goals? Do any of them work against the others?
That's a major first step. No one is likely to get excited, though. Most people think goals like the ones listed above don't merit discussion. They're just common sense, after all.
Things start to get contentious when you ask for ways to measure progress towards each goal. If you're going to the North Pole or climbing Mt. Everest, shouldn't you know where it is, how far away you are, and whether your efforts are bringing you closer?
Are the goals equally important? Is their relative importance constant, or does the importance change?
Wouldn't it be wonderful if someone, somewhere took on the job of evaluating existing practices and ... wait for it ... measured the extent they achieved the goals. Yes, you might not know what "perfect" is, but surely relative achievement can be measured.
For example, people are endlessly inventing new software languages and making strong claims about their virtues. Suppose similar claims were made about new bats in baseball. Do you think it might be possible that the batter's skill makes more of a difference than the bat? Wouldn't it be important to know? Apparently, this is one of the many highly important -- indeed, essential -- questions in software that never gets asked, let alone answered.
Along the same lines, wouldn't it be wonderful if someone took on the job of examining outliers? Projects that worked out not just in the typical dismal way, but failed spectacularly? On the other end of the spectrum, wouldn't amazing fast jobs be interesting? This would be done on start-from-scratch projects, but equally important on making changes to existing software.
A whole slew of PhD's should be given out for pioneering work on identifying and refining the exact methods that make progress towards the goals. It's likely that minor changes to the methods used to meet the earlier goals well would make a huge difference in meeting later goals such as seamlessly incorporating the results of analytics.
Strong Candidates for Optimal Architecture
After decades of programming and then more of examining software in the field, I have a list of candidates for optimal architecture. My list isn't secret -- it's in books and all over this blog. Here's a couple places to start:
Conclusion
I've seen software fashions change over the years, with things getting hot, fading away, and sometimes coming back with a new name. The fashions get hot, and all tech leaders who want to be seen as modern embrace them. No real analysis. No examination of the principles involved. Just claims. At the same time, degrees are handed out by universities in Computer Science by Professors who are largely unscientific. In some ways they'd be better off in Art History -- except they rarely have taste and don't like studying history either.
I look forward to the day when someone writes what I hope will be an amusing history of the evolution of Computer Pseudo-Science.
Comments