(See what I did here in the title? Of course you did. If not, take a look here)
One of the question I’m often asked is this:
“How to become an architect?”
Or, in some other forms:
“Is Some Name a real architect?”
“What makes a good architect?”
So I was thinking – what the hell! Let’s spill the beans…
There are actually five elements that when combined – create a great architect. And here they are:
- Vast Experience – Take a few seconds and count in your head – How many software projects were you involved in? Either as a deveoloper, team leader, development manager or CTO? Is it more than 30? Good.
Now, what kind of systems were they? Were all of them regular information system (Data-In / Data-Out)? Were you involved in some real-time applications? Mobile? Cloud? Web Front End? Windows Front End? Good.
And now – how many failures did you experience? Have you always succeeded? Not good… You’ve got to experience some failures, some projects that never took off to production. You must know the feeling, and how to cope with it.
If your answer to all the above questions are Yes – you’ve made your first step.
- Technical Knowledge – And now I’m stepping into a mine field. You see, there are architects who claim that a good architect should not have technical knowledge, but only an ability to understand and analyze complex entities. Now, these capabilities definitely won’t hurt, but they sure won’t be enough. My strong belief is that an architect must have a broad technical knowledge, covering development languages, data bases, front end libraries, public clouds, operation systems and more. To be clear – the knowledge should be broad, but not deep. No one expect the architect to analyze a crash dump, or to debug some obscure C code, but she definitely should be able to have an intelligent discussion about the best way to implement a Rate Limiter in a stateless environment based on C# and Redis.
- Business Mindset – Although Technical Knowledge is a must, it won’t make the difference between a great architect and an excellent developer. What will is the mindset. And the architect must embrace a Business mindset. So the first thing a great architect will do with a new customer is understanding the business. The real business. The thing that makes the CEO and all the other employees come to the office everyday. Hint: That is NOT the new application they want you to design. It could be money, it could be a sense of purpose, it could be a shared love of some hobby, it could be anything – and the architect should figure this out ASAP. And once figured, the architect should ask herself: “How will the architecture serve the business purpose?”
- Big Picture Vision – Great developers write great methods. And great classes. And great unit tests. Great architects write great architecture, one that define where and how those methods and classes will be coded.
A great architect looks at the requirement docs, and immediately builds a mental figure of the various components involved in the software, the way they communicate with each other, and how to make the whole thing stand an earth quake.
Of course, this mental figure will change countless times, but it sets the frame of reference which is the Big Picture of the software. Not having a Big Picture means drowning in the nitty-gritty details of the development process, and becoming another frustrated developer.
- Interpersonal Skills – An architect is usually in a unique position in the organization chart – he should bridge between the Project Manager / System Analyst and the development team. He needs to make sure his design will be backed by management, and he needs to approach the dev team in a non-intimidating way. All that means that the architect should be REALLY REALLY good with people. Like, really really REALLY good.
Have an ego? Throw it out of the window. You think you’re the smartest man in the room? Bad news – you’re not. You’ve got used to take all the credit to yourself? Stop. Now.
In two words – be nice.
(BTW – try these techniques with your significant other. you’ll be surprised :-))
If you have all these abilities – you, my friend, can be a truly great architect.
But wait!! What about all the buzzwords? What about Class Diagram? What about UML? Should I be familiar with SRS docs? Which modeling software is the best?
Well, that doesn’t really matter. These all are technicalities. Some customers will want them, and some won’t. For those who will – take a couple of hours and you’ll be proficient with all the relevant buzzwords. They have nothing to do will real architecture.
Oh, and before concluding this post – here are two elements that are absolutely, positively not necessary for becoming an architect:
- Academic Degree – That might come as a surprise, but in reality I’ve yet to see an academic course with a concrete and practical material regarding software architecture.
- Managerial Experience – An architect is usually not a people’s manager. I’ve never been a manager, and I forcefully refused any job offer which even remotely indicated managing responsibility.
Want to know more about being an architect? Drop me a note here in the comments section!