Sunday, December 03, 2006
Architects who don't code...
How can someone who never writes a line of code be responsible for how that code will be written?...
Imagine meeting an applications architect who is responsible for designing your system but hasn't written a line of code in two years. But they've produced quite a lot of ISO9001 / CMM documentation and are quite proud of it. They are even better and spewing best practices at opportunistic times and even are great at giving wonderful Powerpoint presentations that make everyone feel good but lack substance.
Maybe enterprise architecture teams should get more involved at the implementation level as code is the system and not just a minor detail. Nothing more than code has the ability to either positively or negatively change the value of your IT portfolio. What would happen if you got architects involved at an implementation level. Most will scream and moan but it's for their own good. They don't need to be writing (necessarily) an equal share of production code but they need to get their feet wet from time to time and need to be aware of how changes in their design affect the project.
Minimally, architecture teams if they don't want to leap towards encouraging architects to code, that they could at least through their governance and review mechanisms, ensure that the architects ideas were vetted by folks who do write code. Sometimes, architects simply don't get concrete feedback on their ideas.
Having worked in several shops throughout my career, this conversation pops up pretty frequently. Maybe enterprise architecture teams should consider that while the question is valid that they should focus on something that is more pervasive. Consider a scenario where someone is performing a role that is considered to be more valuable doesn't get to experience the pain of someone performing a lesser role further into the SDLC. The more valuable is typically seen as being earlier in the development cycle (NOTE:This is encouraged by waterfall-oriented SDLCs), requiring greater experience, being more costly to resource and having some kind of authority. Likewise, the further one progresses into the SDLC, the less authority, experience, etc are supposedly required.
So, What to architects do? They create models representing the technology. What is the audience? Developers who are already knowledgeable in the technology. What does the audience really need to know? The operational details of how the product is to be used. The writers of software do not need to be told how to organize the software; they need to know what the software needs to do. Optimizing the organization of the software will not improve the success of the software; making sure the software meets the needs of the user is critical. Developers can do an adequate job of pratitioning software and don't really need to have someone tell them how to do it. Developers do need to know how the software is to be used, but unfortunately most developers never get this type of information until well after the software is deployed and the users complain about the "obvious" mistakes the developers made.
Whether the architect also contributes to the internal design or not, he must have development experience so that he knows what's possible, what's easy, what's hard and what's risky. This is at the essence of enterprise architecture...
| | View blog reactionsImagine meeting an applications architect who is responsible for designing your system but hasn't written a line of code in two years. But they've produced quite a lot of ISO9001 / CMM documentation and are quite proud of it. They are even better and spewing best practices at opportunistic times and even are great at giving wonderful Powerpoint presentations that make everyone feel good but lack substance.
Maybe enterprise architecture teams should get more involved at the implementation level as code is the system and not just a minor detail. Nothing more than code has the ability to either positively or negatively change the value of your IT portfolio. What would happen if you got architects involved at an implementation level. Most will scream and moan but it's for their own good. They don't need to be writing (necessarily) an equal share of production code but they need to get their feet wet from time to time and need to be aware of how changes in their design affect the project.
Minimally, architecture teams if they don't want to leap towards encouraging architects to code, that they could at least through their governance and review mechanisms, ensure that the architects ideas were vetted by folks who do write code. Sometimes, architects simply don't get concrete feedback on their ideas.
Having worked in several shops throughout my career, this conversation pops up pretty frequently. Maybe enterprise architecture teams should consider that while the question is valid that they should focus on something that is more pervasive. Consider a scenario where someone is performing a role that is considered to be more valuable doesn't get to experience the pain of someone performing a lesser role further into the SDLC. The more valuable is typically seen as being earlier in the development cycle (NOTE:This is encouraged by waterfall-oriented SDLCs), requiring greater experience, being more costly to resource and having some kind of authority. Likewise, the further one progresses into the SDLC, the less authority, experience, etc are supposedly required.
So, What to architects do? They create models representing the technology. What is the audience? Developers who are already knowledgeable in the technology. What does the audience really need to know? The operational details of how the product is to be used. The writers of software do not need to be told how to organize the software; they need to know what the software needs to do. Optimizing the organization of the software will not improve the success of the software; making sure the software meets the needs of the user is critical. Developers can do an adequate job of pratitioning software and don't really need to have someone tell them how to do it. Developers do need to know how the software is to be used, but unfortunately most developers never get this type of information until well after the software is deployed and the users complain about the "obvious" mistakes the developers made.
Whether the architect also contributes to the internal design or not, he must have development experience so that he knows what's possible, what's easy, what's hard and what's risky. This is at the essence of enterprise architecture...
