Tuesday, January 24, 2006
Further Rants About Tool Jockeys
My post yesterday on tool jockeys needs more exposition and yet another story on how they can make an architect's life miserable and what to do about it when it happens.
As I stated yesterday, tool jockeys are in love with software development suites, administration tools, metadata repositories, and other IT software that, by its very definition and presence in the enterprise, will 'make things better.' The tools involved usually do not discriminate between commercial or open-source, and all the better if it has a slick user interface reminicent of displays commonly seen on the Sci-Fi channel (hey, if it looks real slick, the suits will think it works and is doing something useful, right?).
What's usually the case beyond some misaligned hope that the tools will solve a wide variety of percieved or real problems in an IT organization is that experience in the tools will enhance one's resume. This is particularly true when tool jockeys in other organizations also have hiring decision input or authority - they're going to look for folks just like them, and the appearance of a big laundry list of tools in a job description is usually a dead giveaway that a TJ has hiring authority/input, or worse, that a Guild is present in the IT organization.
If not properly managed, TJs are a liability to architects in one area: dealing with the business. Too often, evangelism of this type can be fatal to projects or other IT initiatives if sold to the business as an ultimate solution and the business buys into it. As I stated yesterday, Guilds can be just as fatally effective in this regard, and I'll talk about them in more detail in a later post.
Here's a real world example of the damage a tool jockey can cause to architecture and projects:
A few years back I was counseling an organization on implementing a metadata management solution to address some serious problems this outfit had with data administration, data sourcing, and quality. While nothing had yet been presented to the business, the client had performed substantial research that resulted in a lengthy strawman proposal. I was given the document on day one of the gig and proceeded to digest it in my hotel room that evening.
It was, simply put, a disaster. After 5 pages explaining the overall issues, the remaining 50 pages waxed on and on about some vendor's metadata repository and toolset. Portions of it looked like it was copied verbatim from the vendor's marketing materials. The whole thing was skewed to tools so badly that most of it could not be salvaged for a business presentation.
The next morning I asked management who wrote the document. It turned out that their senior team lead developed most of it, and when I met him, he seemed very uninterested in the overall goals of the effort but much more engaged giving me a demo of the vendor's wares.
This proposed project had, all told, about a $2.5 million USD spend, so we weren't exactly talking spare change here, not to mention the organizational shifts that this effort would cause post-implementation. I informed the client management that from my perspective, what needed to be pitched to the business was the overall data admin/quality/management effort (and its benefits) and that while a metadata repository was certainly part of the solution, it was not the entire solution.
Unfortunately, the client decided to go with what they had into the management review, which turned out to be just as big a disaster as the document. This outfit's general management was very sharp and saw that they were getting pitched a proposal for a super-expensive product and not the solution to the issues. The proposal was declined by management and the effort to revive it floundered about for another month or so before being abandoned.
Architects and project managers need to pay close attention to situations like this or they court disaster even before the initiative gets off the ground. Anything that smells even slightly like a vendor pitch needs to be tossed, and if its stronger than that, the risks to the effort are too high to make bets like that.
Tool jockeys have their rightful place in any IT organization, particularly their deep expertise in day-to-day development and operational issues. However, architects need to think twice before incorporating this form of evangelism into designs or project proposals, particularly if such bias forms the majority of any major IT initiative.
As I stated yesterday, tool jockeys are in love with software development suites, administration tools, metadata repositories, and other IT software that, by its very definition and presence in the enterprise, will 'make things better.' The tools involved usually do not discriminate between commercial or open-source, and all the better if it has a slick user interface reminicent of displays commonly seen on the Sci-Fi channel (hey, if it looks real slick, the suits will think it works and is doing something useful, right?).
What's usually the case beyond some misaligned hope that the tools will solve a wide variety of percieved or real problems in an IT organization is that experience in the tools will enhance one's resume. This is particularly true when tool jockeys in other organizations also have hiring decision input or authority - they're going to look for folks just like them, and the appearance of a big laundry list of tools in a job description is usually a dead giveaway that a TJ has hiring authority/input, or worse, that a Guild is present in the IT organization.
If not properly managed, TJs are a liability to architects in one area: dealing with the business. Too often, evangelism of this type can be fatal to projects or other IT initiatives if sold to the business as an ultimate solution and the business buys into it. As I stated yesterday, Guilds can be just as fatally effective in this regard, and I'll talk about them in more detail in a later post.
Here's a real world example of the damage a tool jockey can cause to architecture and projects:
A few years back I was counseling an organization on implementing a metadata management solution to address some serious problems this outfit had with data administration, data sourcing, and quality. While nothing had yet been presented to the business, the client had performed substantial research that resulted in a lengthy strawman proposal. I was given the document on day one of the gig and proceeded to digest it in my hotel room that evening.
It was, simply put, a disaster. After 5 pages explaining the overall issues, the remaining 50 pages waxed on and on about some vendor's metadata repository and toolset. Portions of it looked like it was copied verbatim from the vendor's marketing materials. The whole thing was skewed to tools so badly that most of it could not be salvaged for a business presentation.
The next morning I asked management who wrote the document. It turned out that their senior team lead developed most of it, and when I met him, he seemed very uninterested in the overall goals of the effort but much more engaged giving me a demo of the vendor's wares.
This proposed project had, all told, about a $2.5 million USD spend, so we weren't exactly talking spare change here, not to mention the organizational shifts that this effort would cause post-implementation. I informed the client management that from my perspective, what needed to be pitched to the business was the overall data admin/quality/management effort (and its benefits) and that while a metadata repository was certainly part of the solution, it was not the entire solution.
Unfortunately, the client decided to go with what they had into the management review, which turned out to be just as big a disaster as the document. This outfit's general management was very sharp and saw that they were getting pitched a proposal for a super-expensive product and not the solution to the issues. The proposal was declined by management and the effort to revive it floundered about for another month or so before being abandoned.
Architects and project managers need to pay close attention to situations like this or they court disaster even before the initiative gets off the ground. Anything that smells even slightly like a vendor pitch needs to be tossed, and if its stronger than that, the risks to the effort are too high to make bets like that.
Tool jockeys have their rightful place in any IT organization, particularly their deep expertise in day-to-day development and operational issues. However, architects need to think twice before incorporating this form of evangelism into designs or project proposals, particularly if such bias forms the majority of any major IT initiative.
