[EN] A (quite open) letter to an Aspiring Architect
Dear Architect,
I decided to publish this letter because I think I might be helpful for some people seeking guidance on how to make a transition from a developer to an architect.
The main reason I write to You is this ‘technology’ requirement. It is said that one cannot create a good design without knowing all the technologies her design is about to use. Or all available technologies at all. It is a common misconception that designing is a process of choosing the right technology for the case.
I say: even if it would be (and in my humble opinion, it is not), it is not essential to know all the technologies inside and out. I would be worthy to know advantages and limitations of them. For example if I had to make a choice about object-relational mapping library would I have to know the technical details about how NHibernate handles state management (in contrast to EDM)? Of course I wouldn’t. The knowledge that NHibernate supports POCO while EDM does not is enough. It is the essential part an architect should know. The details are what developers care about. What is in the domain of architects interests are the facts that help him make a choice. Only that. All the other facts are not helpful and can event distract one from making a good design.
Another opinion which is especially common among developers it that learning new technologies will help one to create better designs. I think it is wrong, too. There is no point in learning how something works in its internals besides that you will be able to code against that ‘thing’. The is no advantage for the architect in learning how Unity works. Or learning how Castle works. Unity and Castle are implementation details. Architects are not even expected to make choice to use one container and not to use another.
There is, however, an advantage in learning how both (or three or four of them) containers work. This knowledge let me make some general statements about how is Inversion of Control implemented and how to use it properly. Knowing differences between implementation allowed me to make a statement (in the architecture document) that all dependencies should be injected via constructor. Yes, this in an architectural decision, because it have a direct influence on ability to switch DI infrastructure.
I strongly believe, however, that if one is smart (and You are smart if You are an aspiring architect) You can come to a similar conclusion by simply looking at specifications. By reviewing some sample code or reading documentations, blog posts and that kind of things. With simple analytical thinking one can achieve the same effect as with reviewing all the codebases of potentially useable libraries but faster.
I must confess that I am a ‘technology guy’. I love to drill down into internal structure of libraries I use. But on the other hand I deeply understand that when I am doing this I am in totally different role than the role of Architect. When I write a Unity extension, I am an infrastructure developer for example. I love to be an infrastructure developer. I also love to be an architect. But those are two different roles.
So, dear aspiring architect, one can be a good architect, even the best one, without deep knowledge of technology. As You said once, good architect should be aware of it. And awareness is something completely different than knowledge.
So, should I abandon my technical hobby completely and focus on the architecture? Perhaps. Will I? I don’t think so. When I have an architectural assignment my main role is of course an Architect. But I can also be a technological mentor, a trainer, an infrastructure developer. All those things thanks to my ‘hobby’. So basically, I have more work to do and it distracts me a little from what is the most valuable. Should I be angry with my colleague who does only the architecture? Of course, no! Should I earn more money? Preferably:-)