|
I am currently working as a team lead with 9 years of experience, working with a team on 6 people taking care of several web-based traditional MVC, and .Net Core applications.
I am interested in moving to the architect role sometime next year and I need some suggestions from the people who've done it before me.
How to go about it? Any resources to suggest?
Cheers,
Gaurav.
modified 22-Jun-23 7:59am.
|
|
|
|
|
If you are in a .NET shop you might be interested in "Software Architecture with C# 10 and .NET 6" by Packt publishing, it covers developing software solutions using microservices, DevOps, EF Core, and design patterns for Azure.
You might also be interested in Archi, a free and open source modelling tool for creating ArchiMate models and sketches. The ArchiMate language is an open and independent Enterprise Architecture standard.
modified 22-Jun-23 9:41am.
|
|
|
|
|
There are no "small" companies with "architects". If you want the title, you have to join a big company. As a "team lead", one often wears many hats, including "architect"; though no one will admit it. And you can't "architect" unless you understand the business model of the company you're architecting; so, it depends on more than just technical expertise; you need (some) business knowledge of that company. (The "big" picture). And, you get to make (sell) presentations.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I transitioned from a developer to an architect while working in a large retail bank.
Being a software architect (rather than just a technical lead) is about getting to know your business users, those people who pay for and use you software. Spend as much time as you can meeting and talking to people who are not techies. Get to know how your business works, who makes the decisions and who controls the budgets. Start hanging out with them, find excuses to go and ask questions and get involved in business meetings.
Eventually those people will start coming to you as their first port of call when considering new projects. Once this happens you will be well on your way to becoming an architect.
Your job as a software architect is to translate the business vision into a blueprint that the tech leads can then implement.
An architect is not a super-skilled technical lead. As a software architect you will eventually stop doing any hands-on development at all. You act as a bridge between the business and the development team. Does this sound attractive to you? Most developers can't do this, they can't let go of the code.
There are plenty of architecture courses to go on and plenty of books to read, but it is the personal relationships that you develop outside your coding environment that will make all the difference.
Good luck!
|
|
|
|
|
Thank you, this is valuable!
|
|
|
|
|
Further to this, it is not all about making the right decision in the moment, but documenting it so that tech and non-tech people understand the implications and organising the documentation so that in a couple of years time you can find the answer to "Why the heck did we decide to do it this way?", or "What are the implications of making change X?". How do you feel about organising documentation?
As mentioned above, your decisions have to take into account the overall business needs, which means sometimes taking the (technically) sub-optimal choice, and being the one who has to justify this to the dev team. How do you feel about making technical compromises?
Adam
|
|
|
|
|
adambl wrote: How do you feel about organising documentation?
I'm a proponent as I've been on the receiving end of managing some badly documented projects.
adambl wrote: How do you feel about making technical compromises?
I have seen that happen and I don't mind it, I understand that there must be a good balance between readability, maintainability and performance of the code. Designing also takes into account the skills available at the time of implementation and choosing what fits.
|
|
|
|
|
I'm a fan of detailed documentation as well, however, keep in mind that if using an Agile development approach, then there is minimal focus on documentation. In fact, one of the core values is valuing "working software over comprehensive documentation". This has always been a mind struggle for me. However, I remind myself that the Agile Manifesto doesn't forbid documentation, and many projects may include that requirement, however, it just states that it is much more important to spend time on software that works as intended rather than using that time to create comprehensive documentation. Ultimately, I just try to strike a good balance, because my users must be able to know how to install and use the software that my company produces. I wear many hats as an IT Manager, one of which is Project Manager, but could easily see myself happy as a Software Architect. Best of luck to you.
  ![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
As a general point you should be aware of the distinction between "Software Architecture" and "being a Software Architect".
Many books on Software Architecture are technical works that detail how to design an application/system. They are about software design rather than "being an architect". They are firmly in the technical sphere.
Transitioning from Technical Lead to the role of Software Architect is about adding soft-skills to all those good technical design skills you know. For example, learning how to present your design to a room of business colleagues without them all glazing over and falling asleep will be critical to your success. If you can't do that then it doesn't matter how good your technical design skills are. This is what really distinguishes an architect from a technical lead who is good at software design. As an architect your role is now business-facing, it isn't just technical any more.
|
|
|
|
|
I've read the other comments and I think there is a lot of great advice, especially getting to know the business. The funny thing is that my title is "Senior System Architect", yet most of that doesn't apply to me. What the people I have worked for see is that they can describe what they want and I can lay out a robust, Maintainable, complete system to do it. ... My niche is a bit odd though. I just do weird stuff no one else wants to try. My management likes me focused.
|
|
|
|
|
Gaurav,
Some good suggestions in the replies.
With a small team and your brief description without knowing your client/user base, to me it's important to consider whether the S in SA is Solution or Software. Somewhat depends on what other positions are in your company. Is there a project manager, a "sales engineer", or "customer success" person and if so, where do they fit in the chain. One thing about this industry, especially with smaller companies, is that there may be some very blurred lines in titles and responsibilities.
As an SA, regardless of what the S means, you may be the principal interface person with your clients or one of just a few. You need to understand your customer's business case and processes. On a basic level, you're the translator of those business needs into a software solution. That could involve DB development, workflows, UIDs amongst other things. It may even include business processes discussions with the users. It requires a broad understanding of what can be done, how long it would take, and at what cost. Good communications skills are important as you are the go-between that translates from non-technical to technical.
Just some major considerations to think about. Specific answers are situational and would require a really long answer. From my POV, life's easier when the client has a vision. Those clients with a blank canvas put you more into the role of an ad man pitching a campaign. While I'm thinking about language, databases, frameworks, existing systems, etc., those are in the back of my mind though existing conditions are a biggie. My first main concern is the "can it be done" within the external parameters.
I do think looking at something like Archimate modeling is a good idea. Even if you don't end up using it, the model opens up your thought process to the larger scope of an architect.
|
|
|
|
|
Have you identified your why? Why do you want to become an architect why not Project/Program Manager or CEO etc? If yes then please share those reasons with us and I will respond to those reasons but in general is My suggestion don't aspire for 'Architect Role' in India. If you really want that role then move out of India. Because you will rarely get the opportunity to work as Architect here, I have that title since 2011 in 4 different companies where I have worked as architect only a few times and that too because my counterparts/seniors didn't had the expertise in the technology.
Following are my reasons for what I said above :
1) There is no clearly defined responsibilities for architect role and the title is just given based on your experience. if you have more than 10-12 years of experience and company needs a all-in-one developer/lead they will give you architect title. But if you see the responsibilities of the role it will mainly be of Developer or Lead.
2) 80% of Indian companies are service based companies working mainly on maintenance applications where architect is either not needed or already present at their client end.
3) Rest 10% companies are outsourcing unit of internal software development divisions of international product companies which operates similar to service based companies and has Architects at their company headquarters. And final 10% are startups where mostly the owner/CTO or Lead Developer is the architect
So if you really want to become an architect then find a way to move out of India and then do a proper architect certification as suggested in this article (https://medium.com/@nvashanin/certificates-in-software-architecture-6b18e0102fe7[^])
Or talk to your HR and follow the growth path defined in your company.
Best of Luck.
|
|
|
|
|
Very true Ravi. Our bank (in the UK) used Indian companies a lot. The architect was nearly always a UK bank employee, even if the rest of the development team was in India.
|
|
|
|
|
|
|
One major reason why I stick to Logitech mice (and keyboard) is that I never could count the number of times I have pushed the (wireless) mouse over the edge of my table and onto the stone floor. I just pick it up and continue working. Never ever a problem. They are as robust as granite stone. As reliable as a hammer. They do the job.
The only reason why I have had more than one (starting with Logitech's first wireless model) is that the charging solutions have improved over the years. My current one charges from any USB port.
I never was into gaming, so I never had a gamepad. Yet, if they are anyway near the quality and robustness of the mice, I can easily understand why they are used. I have seen other articles pointing out this piece of equipment, where it stated explicitly that it was selected due to its robustness and reliability.
|
|
|
|
|
This is the same outfit that refused to use a viewport window rated for the depths needed to tour the titanic. It wasn't even within the ballpark.
Those people are almost certainly dead and I'd be surprised if we ever recover the bodies.
Either way, I wouldn't expect much in terms of the choices of equipment they made if the above is any judge. 
Check out my IoT graphics library here:
https://honeythecodewitch/gfx
|
|
|
|
|
honey the codewitch wrote: https://honeythecodewitch/gfx
I think you meant honeythecodewitch.com. 
/ravi
|
|
|
|
|
yeah, i typod and then tried to edit it, but the sig editor requires magic to make it actually work, and I'm fresh out of dead chickens.
Check out my IoT graphics library here:
https://honeythecodewitch/gfx
|
|
|
|
|
Is THAT what you were raising those chickens for?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
My kids raise chickens. What me to ship you a few?
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
I actually am raising 4. We named them after The Golden Girls, so they are immune to being slaughtered.
Who could murder Blanche?
Check out my IoT graphics library here:
https://honeythecodewitch/gfx
|
|
|
|
|
I agree. I like Logitech products.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I'm glad to hear your experience with LogiTech has been positive.
I have had problems with their higher-end headphones being very easy to break, their mice failing after six months, etc.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
