Thursday, April 12, 2007
Architects who don't code
You probably have ran across architects that don't code. Hopefully you aren't one of them...
Us enterprisey folks continue to abuse words. We have been successful in distorting the following words: innovation, enterprise, agile, diversity, leadership and now even the word architecture. Words mean things. Maybe part of aligning IT with the business is us figuring out the distinction in our own roles.
If you were to ask any technical person in another shop to provide you with the definition of what an architect does, you would probably become even more confused. While the folks in HR have landed on the notion that it is something you get promoted to once you no longer want to write software, we know that a better definition must exist.
Several weeks ago, I was in Home Depot when I ran across a technical lead that works for another enterprise down the street and concluded that one of the things that enterprises should seriously noodle is a better career path for those who want to stay 100% technical and not align with the business. I wonder if enterprise architecture teams have acknowledged in terms of talent management that there aren't enough technical folks to address the communication gap between architects and programmers.
Yes, communication gaps don't just exist between IT and the business, they also exist within IT itself. A good technical person 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 folks. A willingness to communicate and align should be the trait of both types of folks and in many ways is more important than IT aligning with the business.
This technical person asked me for my opinion (mistake number one) on how to better work with architects. While lots of ideas came to mind, I told him that he needed a way to express a preference of working with architects who were also technical on future projects to his boss. The second thing I mentioned was that he should ask his boss to ask the architect's boss to figure out ways that architects could become more conversant with the details of programming and that those that didn't have this as a background may want to spend time not coding but in reading well-written code that others have created. I also suggested some books and open source projects where I thought the code was particularly good.
In the same way, an art major doesn't show up for class on the first day attempting to paint a Picasso, us IT folks shouldn't expect to show up at a computer science course expecting to write code on the first day. We need to learn to read code before we write code. Maybe reading code together might help bring alignment?
| | View blog reactionsUs enterprisey folks continue to abuse words. We have been successful in distorting the following words: innovation, enterprise, agile, diversity, leadership and now even the word architecture. Words mean things. Maybe part of aligning IT with the business is us figuring out the distinction in our own roles.
If you were to ask any technical person in another shop to provide you with the definition of what an architect does, you would probably become even more confused. While the folks in HR have landed on the notion that it is something you get promoted to once you no longer want to write software, we know that a better definition must exist.
Several weeks ago, I was in Home Depot when I ran across a technical lead that works for another enterprise down the street and concluded that one of the things that enterprises should seriously noodle is a better career path for those who want to stay 100% technical and not align with the business. I wonder if enterprise architecture teams have acknowledged in terms of talent management that there aren't enough technical folks to address the communication gap between architects and programmers.
Yes, communication gaps don't just exist between IT and the business, they also exist within IT itself. A good technical person 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 folks. A willingness to communicate and align should be the trait of both types of folks and in many ways is more important than IT aligning with the business.
This technical person asked me for my opinion (mistake number one) on how to better work with architects. While lots of ideas came to mind, I told him that he needed a way to express a preference of working with architects who were also technical on future projects to his boss. The second thing I mentioned was that he should ask his boss to ask the architect's boss to figure out ways that architects could become more conversant with the details of programming and that those that didn't have this as a background may want to spend time not coding but in reading well-written code that others have created. I also suggested some books and open source projects where I thought the code was particularly good.
In the same way, an art major doesn't show up for class on the first day attempting to paint a Picasso, us IT folks shouldn't expect to show up at a computer science course expecting to write code on the first day. We need to learn to read code before we write code. Maybe reading code together might help bring alignment?
