Architect Police vs Architect Leads

A classic problem I encounter in various IT organizations is the massive divide between Architecture and Project Delivery. Most organizations today have recognized that architecture is important to the organization and as a result have established some form of Enterprise Architecture Governance (Architecture Review Boards, Advisory, etc). This is a good first step, as having a central body that can provide holistic and strategic oversight and advice can help consolidate the maze of systems and designs that has been inherited from past bad behaviours and move organizations towards a rationalized portfolio.

However, in an effort to provide "independence" these governing bodies often suffer from the classic ivory tower syndrome and have evolved themselves into a "policing" role. As a result, project delivery teams looking to deliver cheaper, faster and better for their clients find themselves at odds with Architecture which they look at as a speed bump to their work.

This "architecture policing" anti-pattern tends to produce the following results:

• directing scarce and valuable experienced resources into producing conceptual and logical architectures that provide little value to delivery teams
• emphasizing "policing" over "advising" and "leading" resulting in architects that are out of touch with the client requirements, project context and implementation decisions
• mandating high ceremony checkpoints with heavy documentation and review that slows down project delivery while adding little value to the team and clients
  

Instead of playing the role of police, architects can provide much more value to an organization by decentralizing themselves back into project delivery roles and taking ownership of delivering solutions to clients. During my attendance at the IBM Impact Conference 2010, there was a great success story with a Leading Canadian Bank that delivered an enterprise wide service bus architecture and framework with working code led and owned by their architects. The organization established Framework Architects that were responsible for designing and evolving their ESB framework and assigned responsibility to channel and business facing Solution Architects to extend the framework for their specific client needs.

I am hoping to see more organizations continue to follow the approach of embedding architects in delivery and leading the development of core frameworks and assets for reuse / extension by the organization. Architects leading by "doing" is always a good thing.