I recently had a chance to discuss the role of centralized architecture with a colleague.  When I say "centralized architecture", I'm talking about a group usually found in large companies that is responsible for technology standards across the organization.  In talking with developers over the past several years, I've seen the full spectrum of opinions on central architecture groups: At one end you have the developers who are appreciative of the architects hammering things out so that the organization has a common direction.  In the middle you have the folks that have heard such a group exists, but isn't exactly sure what they do.  At the other end are the developers who see the group actively impeding their progress.

Given the wide range of opinions and reactions to the architecture function, I started thinking about what I would want such a group to do.  I finally boiled it down to this:

The role of central architecture should be to balance the desires of the organization with the desires of the developers.

There are plenty of places where the desires of the organization and the developers are aligned.  The org wants some software, the developers want to write it.  But from there, things get a little tricky.  The org prefers to standardize on certain products in order to reduce cost and simplify maintenance.  Developers want to use whatever they want to use.  Developers focus on their system, or part of the system.  The org sees their system as part of a larger system and wants to make sure it can talk to everything else when need be.  The list goes on and on, but an architecture group can resolve these differences by providing the structure with which technology gets built.  Not only that, they can help developers work outside of the general structure when it makes sense to do so and provide tools that make staying inside the structure desirable.