A software architect has an impotent role in software development- he explores the business needs, chooses the right technologies, designs and aids in implementation. Amongst other things an architect serves as a quality gate in the organization, preventing bad technology decisions and mitigating technological risks. But what happens when a quality gate is raised to high and risk mitigation is more impotent than the needs for change? Then the architect becomes a roadblock to any change and innovation, the architect then becomes a person you need to “pass” rather than “consult with”.
The problem domain
“We must pass the architects review” said the client to me with a frightened voice. “You do not know them, they are a real pain in the …” “I need you to manage and make our in-house architects happy, they can stop any project!” – I hear this often and it makes me think if these architects have forgotten why they are there for – to facilitate the empowerment of business through technology.
Why are these architects blocking any new project?
An architect needs to drive the satisfaction and enablement of business, but he also need to ensure that new solution conform to security and technology standards which he has put in place to ensure the quality of the overall enterprise/solution-set.
Business drivers (such as cost and timeframes) sometime conflict with the company’s overall technology strategy and if an architect sticks to the “perfect process, perfect framework, perfect technology” he could kill most projects proposed by business.
How to be a roadblock
- Enforce cumbersome technology approval processes that take a very long time.
- Mandate unneeded documentation.
- Criticise every decision without giving any alternatives
- Drive SOA and integration where there are not needed
- Mandate N-tier (N>3) architecture even for the simplest of sites
- Focus on technology and forget about business needs
How to be a productive architect
- Streamline technology choices
- Promote a pragmatic approach
- Facilitate business integration, when needed, through SOA
- Understand the business and it’s needs
The architect needs to be the “go to guy”, guru or, at worst case, the Mega-geek – not the roadblock.
