Schooling of Software Architects

In my previous post I briefly described what I understand by software architecture. Software architecture is created by software architects.

When coders writes their first function, they start their schooling as architects. And the schooling continues all through their professional lives as coders. Here's why:

• As more code gets added, complexity increases, code will need to be refactored. If testing is getting complicated code will need to be refactored. Refactoring is architectural work. 
• Which functions are to be hidden and which ones to be made accessible (declared in a .h file) is an architectural issue. 
• Re-organizing functions so that the module (a .c file) has functions that cohere. That is architectural work. 
• Taking corrective action if the Law of Demeter is violated, is architectural work.

Caring about issues of complexity, coherence, coupling, privacy, interfaces, is the behavioral trait of an architect. Coders need to - and can - develop this trait from their earliest days. Coders who lack these traits, though they have decades of experience, are not architects. Putting "Architect" on a business card does not make an architect.

Software architects are not gurus preaching in an ashram. They operate in the heat and the dust of the bazaar. The more remote architects are from code, the more atrophied will be their architectural skills. Unlike building architects, software architects have to start as "brick layers" and "mistrys" (masons) and they must always continue to be competent "brick layers".

Creating architecture calls for judgement. Judgement develops with experience. Learning from one's own experience is a must. But learning from the experience of others - team members and the wider professional community - furthers it. Only a learning organization can be a school for architects. And real architects want to never graduate from school.