Thinking like an architect.

Following are some of my thoughts I have realized from several years of SDLC practice and listening to my mentors and inspired from the personal experience of many software architects.

1. Knowing all latest tools, technologies and trends are important. This helps your resume and also keeps you up to date and agile. However they might not be best solution for the problem. Never get intimated by using such unproved solution for your production. This will just create stress, fear, risk and doubt. Rather first try to understand existing older technology that have provided proven solution. This give you an opportunity to go deeper understanding.
2. Complexity is not a good thing. Sometime the problem itself is complex and that may lead the complex solution. However, this might be be true all the time, You can have simple solution to the complex problem if it is done right. Now the question is just what is right way? Make sure you select the right frameworks, choose just as much what you need. Sometime framework itself so complex and bolded, you will end up with complex solution. Other right things to do will be following right design pattern. These all should result the simple and clean solution.
3. Sometime, failure of a project is not because you choose one technology versus other, one language versus another or one framework vs other framework. Chances are it could be just people and more specifically, how they communicate or not communicate. So, in any software development, the success or failure depends also largely on communication and conversation. This makes smart people into an effective one. When you have a conservation, always…
   • Consider people problem as learning opportunity
   • Start the conversation with right attitude and manage your own emotions
   • Ask questions, listen more and never put people on the defensive
   These approaches not only make you effective but also teach you something every time. Also do not forget, being an architect means also leader. As a leader, you must gain respect of your co-workers to work in healthy and effective environment.Use diagrams or even whiteboard to communicate your ideas and to keep things simple starting from the beginnings of project. Keep your developers engaged by involving them in the architecture process. Have them in your side.
4. Never forget to ask your customer/client, why they think they need requested requirement? The other way to put this is to ask what is the problem? This is very important question to ask as an architect as it answers intended value, a business value of the requirements. For instance, a problem could be just solution needed to be very fast. And customer might give you the requirement as solution needed to be implemented in certain language or platform. If you know the problem you can suggest other viable solutions, which could be more effective, cheaper and better then original requirement. Knowing the intended value, also helps to prioritize the features.

…to be continued