From #developer to #architect – Step 1

So, you’ve decided to be an architect? What makes you think to get into this stream – love of technology, passion to build solutions, you hate your architect and you can do well more than him/her, etc. Anyway, since now you have decided (or reading for some sake) let me, at least put some basic information, what you should know when you are aspired to be an arch. I’ll try to keep this as simple as it should be, consider this article as a baby step or first step.

Rule # 1: Inputs and deliverable – Very first you may have observed that architects often start their answer with “it depends”! Yes, that’s correct and it is! When you are developer, you know there’ll be only single approach to a problem – meaning to open a File Dialog to save file from your application, you’ll use single line syntax using your favourite programming language – FileDialog.Open(); An architect has to consider various factors and inputs before coming up with answer, hence “it depends!”. Deliverables are what, as an architect, you will deliver. Unlike coder, where you deliver code (module, database, set of classes, etc.), the deliverables are often documents and artifacts. Depending on audience, documents and artifacts delivery will vary.

Rule # 2: Fundamentals – Strengthen your fundamentals. By now, you’ve invested your time and efforts in development. Round the clock, burned your weekends, gained calories, compromised your health (and hair). Being an engineer, you should be aware how things work! By things, I mean – anything what you are familiar with – language, database, programming, etc. This will help you to justify what to use, when.

Rule # 3: Keep learning – by that I mean, be learner. Don’t refrain or limit yourself to specific technology or concepts. This will help to widen your thoughts and help you to choose when to use, what! 

Rule # 4: Good listener – Developers are impatient. They generally get into coding without much thinking solution’s cons. I would suggest to be good listener and then react. Start practicing drawings on paper. This will help in visualising what is being said.

Rule # 5: Terminology – often architect speak business language which is familiar to business. Yes, you should start thinking from business view like how your earlier work has helped to the business and try to visualize it in a bigger picture.

Rule # 6: Visualize – Start visualizing the end product/software/business solution well before it has been realized. Be analytical, how particular business requirement will solve through software.

Rule # 7: Communication – Most importantly, be communicative. Unlike in development zone, this soft skill will help you to grow from all dimensions. As an architect you will be dealing with different stakeholders – project manager, business, analysts, developers, operations, etc. hence, you should be communicative and that too, precisely and to the point.

Rule # 8: Some managerial skills – Get the work done from your peers, understand the strength and weakness of your team and based on that react and estimate the time required to develop your architecture. Be a good planner, good estimator.

Rule # 9: Patterns and practice – know the patterns that are solution to common problems. This will help not only in reducing the efforts but also improves quality architect delivery

Rule # 10: Books – these are man’s best friend. Keep reading, understand the concepts, patterns, solutions, common practices, guide, common terminologies. This not only will help you to grow, but also widen your boundary of thinking.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at

Up ↑

%d bloggers like this: