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.
Transferring the analogy of the chair to software development, we can improvise with some notes that’ll help your memory:
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: