Sunday, April 20, 2008
Why Enterprise Architects need to support the role of technical lead...
Communication and alignment isn't just a problem between IT and the business as it also exist between those non-technical IT employees and those who actually write working software...
It is too much to ask for an architect to be conversant with the details of programming (e.g. give estimates on project design and programming costs). Likewise, one should not ask the "technical lead" about the implications of infrastructure decisions.
Many project managers ask the right questions only that they point them to the wrong demographic. The funny thing about being an architect is that we love our analogies that refer to the building trade yet we so frequently skew the meanings to fit the moment while not ackwoledging why we mostly suck.
If you could across a high-ranking architect with a blank look when discussing low-level issues, then he/she is not an architect. They are more than likely business analysts who went off course. He will probably wax lyrical on all things high-level and "important". He will produce lovely object hierarchies without a clue to implementation. He will use buzzwords such as best practices and champion heavyweight processes such as CMM while being good at playing golf. His background may also been employed in the past by a very large international insultancy.
The role of the technical lead is the solution to the miseducation of the architect demographic. I think the problem is that typically there are not enough "technical lead"s to address the communication gap between the architect and the programmers. A good "technical lead" should be able to understand the issues of concern to architects, and a good architect should be able to understand the concerns of development and maintenance programmers. A willingness to align and communicate should be the trait of both types of people...
| | View blog reactionsIt is too much to ask for an architect to be conversant with the details of programming (e.g. give estimates on project design and programming costs). Likewise, one should not ask the "technical lead" about the implications of infrastructure decisions.
Many project managers ask the right questions only that they point them to the wrong demographic. The funny thing about being an architect is that we love our analogies that refer to the building trade yet we so frequently skew the meanings to fit the moment while not ackwoledging why we mostly suck.
If you could across a high-ranking architect with a blank look when discussing low-level issues, then he/she is not an architect. They are more than likely business analysts who went off course. He will probably wax lyrical on all things high-level and "important". He will produce lovely object hierarchies without a clue to implementation. He will use buzzwords such as best practices and champion heavyweight processes such as CMM while being good at playing golf. His background may also been employed in the past by a very large international insultancy.
The role of the technical lead is the solution to the miseducation of the architect demographic. I think the problem is that typically there are not enough "technical lead"s to address the communication gap between the architect and the programmers. A good "technical lead" should be able to understand the issues of concern to architects, and a good architect should be able to understand the concerns of development and maintenance programmers. A willingness to align and communicate should be the trait of both types of people...
