8.09.2010

DNA of Software Architect ...

Software Architects must have excellent communications and base technical software skills.
Communications skills are the skills that I work on the most because they are the most critical for an architect. Don’t get me wrong: technical skills are an absolute necessity, but without top communications skills, it’s going to be difficult to get your vision into the heads of others. Many of the disciplines, attitudes, and ideas that I discuss in my IT operations article also apply to solutions architecture. The highest responsibility of an architect is communicating the solution to the business leaders, technical leaders, and any other interested parties in a language that they understand. Architects need to have a mastery of three languages: business language for communicating with the business people, industry language for communicating in the vernacular of the business, and technical language for communicating to the technical leadership and the developers. I personally have a dual degree having majored in business (marketing) and minored in engineering. I actually started out in engineering and then started taking business classes in my junior year. At a job fair job fair I kept hearing that I should take some business classes because I would be out working with business people and would need to understand their world. Thinking back, my team won an engineering competition not because of the technical merit of the solution, but because we had given the business case for the solution to a panel of judges who happened to be all business people. We spoke in a language that they could understand. We need to speak in a language that an audience can understand. It is often the case that the audience will not tell you when they do not understand you, and a confused mind will always say no. So be sure to understand your audience, and then be sure to speak their language. I have worked in many different industry sectors, all with their own specific domain languages. As a result I picked up a habit early on in my career that has allowed me to quickly learn each domain. In most business lobbies, trade magazines for that industry are displayed. I would read these magazines as I would wait to meet with the client. I would also take the free subscription cards for the journals and send them in to get my own copies of the periodicals. Granted this was before the Internet, which has made industry specific research much easier. The point is that you need to become familiar with the domain in which you will be developing a solution. And whilewe are on the topic, I believe that there is a tremendous benefit to having experience in multiple industries and domains.


This allows you to be like a bumble bee and cross-pollinate the best ideas across industries. I have also found that the DNA of most architects has a hunger for knowledge in a broad range of subject areas. Architects are interested in knowing about things and understanding how things work. Architects can then synthesize this knowledge into creating solutions. 

It is assumed that architects know the technical language. Yet this is not always the case as not all architects come from the technical ranks. And even if an architect comes from the technical ranks, their vocabulary and experience may still be narrow enough to hinder communications to all parties. I believe that an architect needs to understand several development methodologies and development environments, and also understand infrastructure, security, databases, business integration, and operations and support. Blindness in any of these areas can cause problems, however such limitations can be overcome with a team of architects and or a good network of peers. 

Source : ITABOK - http://www.iasahome.org/web/home/skillset

No comments: