Some lessons learned as a Software Architect

I started out in the role of a Software Architect roughly one year ago. Here I found that my previous image of architecture work does differ quite a bit from what was actually expected of me.

Correction #1: Shifting around blocks is a task that comes only very late

I originally thought that the task of an architect is to devise the architecture of a software system, i.e. shifting around different blocks of functionality. While this is not entirely wrong, it comprises only a small part of what should actually be done. The task of a software architect is to make sure that an intended software product does fulfill its task and can be developed.

Correction #2: Titles are (actually) meaningless

Yes, I hold a PhD. Does not matter a bit here. People love to assign themselves fancy titles. Do not pay attention to these self-assigned titles. However, pay close attention to what they say and do. If it overlaps, great. If there's an obvious discrepancy, try to stay away.

Correction #3: Talk non-nerdy to me

Software Architects must be great communicators, yes. Be aware who you talk to! While you were chosen (amongst the other great qualities you surely possess) because are technically very proficient, most times, you will communicate with people on the far end of the proficiency spectrum. Talk to them with very easy words and maybe slightly inaccurate descriptions, as long as it helps to make them understand. Technical details are for developers.

Correction #4: Software is only a large part of your architecture

As a software architect, you design the architecture of a piece of software. The decisions you take while designing are however heavily influenced by the ecosystem where the software will be used in. This ecosystem can be entirely non-soft, for example the hardware parts of a car's sensor and actor infrastructure, or even something entirely unpredictable, like the human that is attempting to drive the car.