Communication skills for an Architect

Communication Skill is a key skill for a Software Architect. An Architect need to communicate to different set of audiences starting from C-level Executives, Business Stakeholders, Subject Matter Experts to Software Developers.

They have to communicate the solutions in different ways to different audiences. Normally this takes time and comes by practice and experience. The Architect must also be capable of communicating their points with clarity so it is easy to understand for the rest.

There is no point in writing pages and pages of architecture documents instead how it can be communicated to the team is really the value added. "A picture is worth a thousand words". Therefore try and communicate your ideas in diagrams. These diagrams can be in Visio or even a white board drawing as long as it can convey the message.


Comments

Post a Comment

Popular posts from this blog

Architecture diagram using Visio Stencils

Image
In the previous post, I emphasised on how much a picture can communicate than words. In order to draw good Architecture diagrams using Visio, first we need the proper stencils. The following stencils would be handy for any Architecture diagrams using Visio. Office Stencils Microsoft Azure, Cloud and Enterprise Symbol / Icon Set Azure Reference Architectures Microsoft Integration Stencil Pack Exchange 2013 Stencil SOA Stencils (from Arcitura) ( Symbol Legend ) Cloud Computing Stencils (from Arcitura) ( Symbol Legend )
Read more

Why Decision Log is important for an Architect?

Image
As an Architect during the life cycle of Product Development, key decisions will be made for some valid reasons. Often if these reasons are not documented in a Decision Log then down the lane it will be hard for anyone to understand why certain decisions are made at that time. I personally get challenged asking these type of questions typically when people leave the project and new people take the role and they would like to understand why certain decisions have been made and rationale behind them.  Having a Decision Log and documenting the rationale will be really handy in these situations. As Simon Brown mentioned in his " Software Architecture for Developers " book keep them simple as it is mainly for technical audience.
Read more