Reading through this post on The Key Difference Between Developer and Architect Roles I was reminded of a few other key attributes that successful architects possess that developers and (certainly not ex-consulting firm wanks) tend to not have.
Once upon a time I was an architect working on an large packaged application installation along with two ex-consulting types. These guys had zero technical background and were basically good for creating and following task lists with no understanding of what the tasks were (or could be). Any conversation with them ended with them drolly replying ‘well that’s nice but it’s not in scope’. Problem is that if they had a modicum of technical/architectural skill, they would have recognized that every suggestion was in scope and had the recommendations been acted on would have saved the project enormous amounts of time and money.
For example, their task list said that they should rubber stamp the scripts they had for data transformation and movement. Well, in the ten years since the original scripts had been written, the company had acquired an ETL tool that would have made creating, modifying and maintaining the data movement portions much easier and quicker. But, no, that was ‘out of scope’. The ‘task list architects’ spent something like 700x the estimate for the ETL effort to essentially build a hairball-esque shell script-based hack that failed miserably. The team spent huge amounts of time and effort trying to maintain the scripts. On top of that, they had huge data consistency issues because the scripts barely worked in one scenario let alone have the flexibility to accommodate new requirements.
That was just one of their many ‘successes’ on the project. They basically did the same with the reporting for the system. Rather than use the ‘out of scope’ modern BI tools, they ‘re-used’ the 10 year old scripting hacks. Another huge dose of fail. And again with environment (mis)management. Somehow through their utter ineptness they ‘required’ something like 39 copies of the production environment to complete their testing. Thirty nine. The mind boggles.
But this is what you get when people who can barely write a requirements document (but have ‘experience’ from big consulting) adopt the title of ‘architect’. Real architecture requires enough vision and understanding to know when to make both strategic and tactical decisions that enable a project to deliver a quality result. Real architects understand what changes can be made and why, without greatly (if at all) effecting scope. Task list ‘architects’ can’t see beyond their own tick lists.
Technorati Tags:
architecture, enterprisearchitecture, software, technology