Writing code can be highly scientific. Design software can be highly artistic. Defining architecture that encompasses elegant designs, is easy to test, efficient to construct, and still manages to satisfy constantly changing business goals is some science, some art, but mostly magic.Let's face it, every code monkey likes the way they write their code. Conversely, they think the code someone else writes is mostly garbage. In the same way, all designers thinks their particular designs are elegant and demonstrate "best practices" while simultaneously denouncing other designs as grotesque or impractical. These two elements that are combined when defining the architecture of a solution are both highly inflammatory and subjective. So how does one allow individuals to contribute according to their skills and from their own perspectives without turning the architecture into a Frankenstein-like monstrosity?
The first technique is generally applied only at the design and code levels and is called Separation of Concerns. It is generally regarded to have originally been introduced by Dijkstra in a paper written in the '70s.
The general idea is that the various aspects of single effort should have their boundaries defined and respected in such a way that they can each receive focus individually. For example, separating how a screen displays information from the format in which the data is stored. Or agreeing on the bolt pattern for a tire so that tires can be manufactured by different suppliers and fit many cars. By creating a boundary between two areas of concern, they can each apply different ways to support the boundary independently.
While this principle is often touted and used a tool to flog the unsuspecting for the need for services, loose coupled interfaces, interface contracts, etc. it can just as easily be misapplied. Consider how there are many components in an automobile that require access to the electrical system. In software we often see these as secondary types of functionality such as providing access control, auditing activities, or styling a screen. When you have these type of cross-cutting concerns, they tend to flout the rules by which we create primary concerns. Which leads to the aforementioned architectural monstrosity.
In reality separation of concern is more than just for the elements, but it needs to be applied at all levels from how the work is structured, how the business processes interact, to how systems utilize shared resources. So working magic in your architecture will often involve applying this concept to more than just your designs, but will be present in your mindset and how you attack and decompose complex solutions into elements to be designed. Including the cross-cutting concerns as first-class concerns is definitely part of practicing this magic.
The second technique doesn't really have a formal name that I've been able to uncover. It essentially is realizing that there is going to be a difference between what is asked for, and what is needed. Generally, speaking we all think that providing good software is about giving users what they want. In reality, it's about giving them what they need in an efficient way and helping them feel like it's what they wanted.
Ask any user what they want and they immediately turn into children. We all know that every kid wants a pony. Girls want it to be white and gentle. Boys want it to be dark with a white streak and wild side that makes it run really fast. And there are a few crazy kids who go all out and decide they want a unicorn. They are users, they have no idea what goes into the lifecycle of acquiring, maintaining, riding, and eventually putting a bullet in the head of said pony. They just want all these things they associate with having a pony!
If you focus on giving them the pony, you are going to end up with really sad pony-owners. They'll have paid a premium for a beautiful pony that can't carry a rider and keeps growing until it's a huge horse that costs to much to keep. And who knows that they might have been totally happy with a cheap, durable, practical: donkey.
The magic isn't just in realizing that a donkey can meet the need. It's on selling the donkey to someone who thinks they want a pony by focusing on what they get instead of what they think they want. Sounds hard, doesn't it?
I told you it was mostly magic. And as an architect, it's what I practice every day.
