Look like a Software Architect with distinction and elegance

Suppose you find yourself alone in a room, tired from standing, where you only have 2 chairs. You take one of them and sit down, experiencing an embarrassing fall to the floor due to the unforeseen “decomposition” of the chair. Without a pause, you assemble the scattered parts and manage to recompose the chair to its original shape… at least now it resembles a chair. Spurious thoughts aside, hopefully if someone enters the room and needs to sit down, you will surely offer just one of the chairs, the good one. You may not have noticed, but something interesting just happened: you have an element that is shaped like a chair but does not serve as a place to sit, as if that chair did not exist. But there it is, with its 4 legs, bottom and back you can touch, move. But no one can sit on it; thus it does not fulfill the purpose for which it was designed and built.

The reading between the lines is that everything has a ‘Be’ and a ‘seem’, and both aspects are derived from one purpose, a reason for existence. A second reading between the lines reveals that the ‘be’ is something that happens and the ‘seem’ makes the shapes.

That thing that seems like a chair (because it has 4 legs, bottom and back) is a chair because I can sit on it. And this is possible (that is to mean, it’s real) because it was designed intentionally to be like that. Talking in creole, we are going to call “architecture” the shape, structure and behavior that determines if things are what they seem. Said in another way, things are what they seem because they have an architecture that determines it.

Pocket notes for the test architect

Transferring the analogy of the chair to software development, we can improvise with some notes that’ll help your memory:

• The architecture determines how things are seen: the parts of everything don’t go wherever, neither do they have whatever shape, neither are they attached in any way.
• The architecture imposes restrictions: there are parts that need to be, and others don’t, there are things that have to happen, and others don’t.
• The architecture is executable: it manifests the moment it has to serve its purpose, when it is used.
• The architecture “lives” in the code: what we draw on paper are only representations of the decisions we make.
• If the code doesn’t work, or what it makes doesn’t work, then the software doesn’t exist.

Recommendations for staying healthy and making friends

If I didn’t confuse you too much with the architecture of things, let me collaborate in the enjoyment of your job as a software architect with some recommendations:

• Make sure to always associate every architectonic decision with some need of business. The best justification to defend your decisions is to soothe someone’s pain.
• Always fight, as soon as possible, the most relevant battles. They are the ones that will require confident architectonic decisions that will determine the final solution.
• The war wounds will clearly show what can be postponed to better concentrate on what is relevant.
• As soon as you feel comfortable with any architectonic decision, build something that can be executed to validate it.
• To evaluate what was done, evidence of its functionality is needed. Don’t forget to take measures. This will require you to think previously what you are going to measure and how you are going to do it.
• Always distrust ink architecture. On paper everything works, but it doesn’t resolve real problems (remember the chair!).
• Share your decisions with as many colleagues you can.