Friday, February 10, 2006
Requiem for a Legacy Architect
In many ways, this is a sad story to tell, but I'm sharing it with the blogosphere because clones of this man exist in a lot of IT organizations and need to be successfully dealt with...and that's not to mean downsized, right-sized, or whatever businesses are calling 'fired' these days.
Our man is in his mid-50s and has been in the IT business his entire career. He ascended through the programming ranks to lead teams and design major systems for his employer. His development experience was in structured programming languages such as FORTRAN and C on big old DEC hardware like VAX-11's (which, back in the day, were pretty awesome machines even though P4 PCs pack much more punch at 1/1000th the size...:)).
However, over the years as he gained more responsibility as a non-management-level architect, he grew resistant to newer technologies and ways of accomplishing development and testing. For him, it was as if time needed to stand still and the systems he knew well and had a hand in developing would stand the test of time and be in production forever.
More troubling is how he spent his working days, which largely consisted of going to meetings that in large part either consisted of the same topics over-and-over each week (what I call 'Groundhog Day' meetings) or full of technical minutae and trivialities. While the Groundhog-style meetings are largely indicative of his organization's culture, the latter set he needn't have attended at all, so his focus could be a bit more dealing with the lines of business and doing more architectural-related work (which his organization badly needed, and still does).
He also developed a nickname amongst the development staff: 'Dr. No,' after the villian in the James Bond movie. He liked to say 'no' a lot to new ideas and technologies. Web-based applications? No. Web services? No. Replace extremely aged, 30-year-old systems that, while they still work, are fragile and will permanently break any moment? No. Since he is an architect in the organization, management solicits and respects his opinions enough where he has enormous sway in decision-making on projects like this.
Lately, however, the organization hired a CTO who, after shaking his head at the state of affairs within the production architecture, is moving to upgrade and consolidate a large number of systems, servers, and networks. All of which freaked our man out to the point where he spends an inordinate amount of time with all of us blasting these decisions and proclaiming that the initiatives 'will never work' in addition to wasting large sums of money.
The reasons for his behavior became clear to me a couple of weeks ago when he returned from a week of training. I asked him what he went off-site for...
Me: How was the class?
Him: I went to a C# programming class. It didn't go very well.
Me: Why not?
Him: I never understood object-oriented programming, so I didn't get what was being presented in the course.
Then it hit me: the man is a control freak, and if he doesn't understand (or want to understand) something, it's bad because he feels that he loses any control he has if he can't or won't take the time to understand newer technology and issues.
Since 'structured programming' had more or less bit the dust some years ago and object-orientation is pretty much standard when using the terms 'programming' or 'programming languages,' you can tell how out-of-date (and out of touch) this man really is.
If architects and CTOs are going to succeed in their careers long-term, they must operate in what I call constant learning mode, which includes business as well as technologies. Another attribute successful architects and CTOs have is the ability to successfully refactor themselves career-wise when technology and business changes mandate them. The rest eventually get left in the dust, and unfortunately for our boy, he's recently been getting tuned-out by higher-ups and others are coming to the fore to drive technology development in the organization.
If you've got people like this in your organization, you're operating with a 100-pound weight strapped to your back. Even the time it takes to rebuff (or in extreme cases, usurp) people like this is much better spent getting some real work done. While time must always be allotted to playing organizational politics, the ROI on constantly dealing with guys like this is too low, but the price usually must be paid in any event until the situation comes to a head and a resolution is reached.
While it's sad to see this man flounder (or worse, go on another tirade) when topics like SOA and open-source come up, there is hope for guys like him if management and you play your cards right - and no, that doesn't necessarily mean giving him a pink slip. If these people have any worth left to the organization, have them oversee legacy operations and maintenance or even better, if they have excellent knowledge of your business, start dealing exclusively with the business as some sort of IT liason, with the decision-making they were formerly responsible for safely in the hands of you as enterprise architect, your systems & data architects, and your CTO if you have one.
And as the years pass by, don't let this happen to you.
Our man is in his mid-50s and has been in the IT business his entire career. He ascended through the programming ranks to lead teams and design major systems for his employer. His development experience was in structured programming languages such as FORTRAN and C on big old DEC hardware like VAX-11's (which, back in the day, were pretty awesome machines even though P4 PCs pack much more punch at 1/1000th the size...:)).
However, over the years as he gained more responsibility as a non-management-level architect, he grew resistant to newer technologies and ways of accomplishing development and testing. For him, it was as if time needed to stand still and the systems he knew well and had a hand in developing would stand the test of time and be in production forever.
More troubling is how he spent his working days, which largely consisted of going to meetings that in large part either consisted of the same topics over-and-over each week (what I call 'Groundhog Day' meetings) or full of technical minutae and trivialities. While the Groundhog-style meetings are largely indicative of his organization's culture, the latter set he needn't have attended at all, so his focus could be a bit more dealing with the lines of business and doing more architectural-related work (which his organization badly needed, and still does).
He also developed a nickname amongst the development staff: 'Dr. No,' after the villian in the James Bond movie. He liked to say 'no' a lot to new ideas and technologies. Web-based applications? No. Web services? No. Replace extremely aged, 30-year-old systems that, while they still work, are fragile and will permanently break any moment? No. Since he is an architect in the organization, management solicits and respects his opinions enough where he has enormous sway in decision-making on projects like this.
Lately, however, the organization hired a CTO who, after shaking his head at the state of affairs within the production architecture, is moving to upgrade and consolidate a large number of systems, servers, and networks. All of which freaked our man out to the point where he spends an inordinate amount of time with all of us blasting these decisions and proclaiming that the initiatives 'will never work' in addition to wasting large sums of money.
The reasons for his behavior became clear to me a couple of weeks ago when he returned from a week of training. I asked him what he went off-site for...
Me: How was the class?
Him: I went to a C# programming class. It didn't go very well.
Me: Why not?
Him: I never understood object-oriented programming, so I didn't get what was being presented in the course.
Then it hit me: the man is a control freak, and if he doesn't understand (or want to understand) something, it's bad because he feels that he loses any control he has if he can't or won't take the time to understand newer technology and issues.
Since 'structured programming' had more or less bit the dust some years ago and object-orientation is pretty much standard when using the terms 'programming' or 'programming languages,' you can tell how out-of-date (and out of touch) this man really is.
If architects and CTOs are going to succeed in their careers long-term, they must operate in what I call constant learning mode, which includes business as well as technologies. Another attribute successful architects and CTOs have is the ability to successfully refactor themselves career-wise when technology and business changes mandate them. The rest eventually get left in the dust, and unfortunately for our boy, he's recently been getting tuned-out by higher-ups and others are coming to the fore to drive technology development in the organization.
If you've got people like this in your organization, you're operating with a 100-pound weight strapped to your back. Even the time it takes to rebuff (or in extreme cases, usurp) people like this is much better spent getting some real work done. While time must always be allotted to playing organizational politics, the ROI on constantly dealing with guys like this is too low, but the price usually must be paid in any event until the situation comes to a head and a resolution is reached.
While it's sad to see this man flounder (or worse, go on another tirade) when topics like SOA and open-source come up, there is hope for guys like him if management and you play your cards right - and no, that doesn't necessarily mean giving him a pink slip. If these people have any worth left to the organization, have them oversee legacy operations and maintenance or even better, if they have excellent knowledge of your business, start dealing exclusively with the business as some sort of IT liason, with the decision-making they were formerly responsible for safely in the hands of you as enterprise architect, your systems & data architects, and your CTO if you have one.
And as the years pass by, don't let this happen to you.
