As the discipline of software engineering matures, few things remain constant. A few years ago, a large portion of the community thought that TDD was always the best methodology to use - after all, you move faster by being thorough and preventing bugs. Nowadays it's clear that unit tests do not ensure a successful project - when you're A/B testing new features or products and you're not even sure if your code will be around 3 months from now, it's better to churn out production code and test it in prod. You can clean up the mess later, if the business value makes it worth it.
But despite the pace of change in software engineering, in software architecture there exist a set of 'laws' which don't change over time and which apply to all architectural endeavors. I'd like to talk about 2 of them in this post as they are important ideas to keep in the back of your mind as your skills grow past coding, past design and into architecture.
Laws of Software Architecture
Law #1: Everything in software architecture is a trade off
There are no 'yes' or 'no' answers and no quippy one-sentence solutions in the world of software architecture. If you find an exception to the rule, you're probably missing a lot of aspects of the problem OR you're not working on architecture. When a problem is an architectural problem, the business requirements are only 1 aspect of the challenge at hand. Other aspects require effort to discover and can dramatically alter the way you would frame the problem.
For example, say you were building a batch processing system and that the only requirements given to you were that the system has a queue to accept new jobs even if other jobs are being processed, and that all jobs submitted to it were completed as quickly as possible. You might focus on the performance aspect and say 'we'll optimize the number of jobs running asynchronously to ensure we get the best throughput'. Seems simple - but there's so much more missing. What if the system goes down and can't even queue new jobs? Well that'd be bad, so let's add in reliability as a requirement. Also, if the system did go down, would the existing jobs in the queue be lost? Ok, now we'll have to ensure the system is recoverable too. But depending on how we design for recoverability, we may hurt performance - if the enqueue/dequeue operations need to go to disk, it'll increase latency...so now we've discovered the first trade-off and we're finally doing some architecting.
There are pros and cons to any architectural decision and they must be surfaced in order to make sound, well-thought-out decisions. If you don't have an explanation of the trade-offs and alternative options to an architectural decision, you're missing something.
Law #2: 'Why' is more important than 'How'
Don't get me wrong - architects are expected to have a breadth of knowledge in different technologies/domains so that understanding 'how' to do something is never a bottleneck. Architects can often look at the design of a system and quickly understand 'how' it works. But that skill is useless at best and dangerous at worst without the wisdom to ask 'why' as a first course of action. There are infinite ways to solve any architectural problem - but without clear and correct answers to 'why', your systems will overlook key architectural characteristics that are important for project success while focussing on others that have nothing to do with the problem domain.
It doesn't matter so much what you build - it matters that you can convince yourself (not to mention the stakeholders) that the reasons behind every decision is inline with the end goals of the project and reflective of the project priorities.
Comments
Post a Comment