Monday, February 20, 2006
Enterprise Architecture and resume driven design
Scott Mark, an architect for a Fortune 200 enterprise recently blogged: Resume Points to Consider if you want a job at a large enterprise. I have always wondered how prevalent is resume-driven design amongst enterprise architects in choosing a technology based on what will pad out your resume?
In thinking about it, it is more prevalent than IT executives would expect. Architects who will only consider software products that are on quadrants at the expense of valuable working software that can be cheaply obtained from the open source community may be guilty of this practice. In cultures where outsourcing is prevalent, this may become practiced even more making the sole architect who dissents stand out like a sore thumb.
Likewise, outsourcing firms have the same problem in that many of their staff are "freshers" who understand the importance of building their resumes. IT executives in America fall into the trap by allowing them to have a say in the architecture as they are of the belief that buy-in increases the chance for success.
I would love to know if there is a such thing as an empowered enterprise architect in Fortune 100 enterprises that can go against the rallying forces of resume-driven design and change direction with minimal effort. Imagine if someone could simply say: "The reason I want to choose product X is because I want to learn it..." it would at least make some sense to me. I wouldn't even get in the way if it were stated in this manner as they are being truthful and coming up with a useful goal. I guess governance as typically practiced fails in this regard because it requires folks to be less than honest...
In thinking more about governance, this behavior in some situations should be encouraged. Language and technology choices affect management's ability to keep the people they have and attract new people. More importantly, it helps counter the disease known as Rationalization.
A strong governance process should acknowledge that languages, processes and products are chosen for social reasons and otherwise may not be justified for technical or even business requirement reasons. If you are looking to hire top talent and tell a candidate that you wrote your system in Smalltalk or even COBOL, they may think, "If I take this job, it's a dead-end career move for me." If an enterprise archtiect is justifying technology choices based on the idea that the enterprise going to have to hire a replacement or make the need to outsource diminish, that's fine. You've not made the choice technically. You've made it socially, and that's OK. This is good governance and should be stated as such as long as it is publicly acknowledged...
| | View blog reactionsIn thinking about it, it is more prevalent than IT executives would expect. Architects who will only consider software products that are on quadrants at the expense of valuable working software that can be cheaply obtained from the open source community may be guilty of this practice. In cultures where outsourcing is prevalent, this may become practiced even more making the sole architect who dissents stand out like a sore thumb.
Likewise, outsourcing firms have the same problem in that many of their staff are "freshers" who understand the importance of building their resumes. IT executives in America fall into the trap by allowing them to have a say in the architecture as they are of the belief that buy-in increases the chance for success.
I would love to know if there is a such thing as an empowered enterprise architect in Fortune 100 enterprises that can go against the rallying forces of resume-driven design and change direction with minimal effort. Imagine if someone could simply say: "The reason I want to choose product X is because I want to learn it..." it would at least make some sense to me. I wouldn't even get in the way if it were stated in this manner as they are being truthful and coming up with a useful goal. I guess governance as typically practiced fails in this regard because it requires folks to be less than honest...
In thinking more about governance, this behavior in some situations should be encouraged. Language and technology choices affect management's ability to keep the people they have and attract new people. More importantly, it helps counter the disease known as Rationalization.
A strong governance process should acknowledge that languages, processes and products are chosen for social reasons and otherwise may not be justified for technical or even business requirement reasons. If you are looking to hire top talent and tell a candidate that you wrote your system in Smalltalk or even COBOL, they may think, "If I take this job, it's a dead-end career move for me." If an enterprise archtiect is justifying technology choices based on the idea that the enterprise going to have to hire a replacement or make the need to outsource diminish, that's fine. You've not made the choice technically. You've made it socially, and that's OK. This is good governance and should be stated as such as long as it is publicly acknowledged...
