By Tony Scott

In the minds of CIOs that I have met with, Architecture is a critical function within their IT organization.  I don’t believe there is any debate of the intrinsic value of an architecture team.  They set the technical and process framework that a technology organization will work in.  This ranges from the security standards, to server and network infrastructure standards, and application frameworks that the company will leverage, and business process integration standards.

In an environment where information is readily available all the time, it is critical that the architecture function of a technology department establishes a workable structure for technologist to follow to provide that information to customers and employees.  As an example, the birth of social networking has established new channels for companies to reach out to its customers.  First the first time, as a collective, customers are interacting with each other and companies in real time.  If they have not already done so, companies need to look at how to reach out to their customer base in this new medium.  Architecture teams play a major role in providing the plan to tap into this customer channel.

While it is relatively easy to establish these standards, the trick is to put that framework into the correct context for operational and project use.   With the need to set an overall direction for IT and the need for practical application of that vision, the question that comes up is how you manage an architecture team.   The implementation of an architecture function is as varied as the organizations they serve.  I’ve found though that there are two distinct services that architecture functions need to provide: strategic vision and tactical application of that vision. 

Strategic

The strategic function drives those decisions about leveraging which technology to support the business need and the technology direction that should be used.  This includes the validation of existing and new infrastructure and application requirements.  For argument sake, let’s call these folks “Enterprise Architects”.  The Enterprise Architect needs to develop strong relationships with the business lines that the technology department serves, as well as solution vendors in the development of standards.  They also drive the integration of those standards into the PMO by way of process integration and assuring that there is accountability within the project gates as well as operational functions.

Tactical

The tactical side then provides the context.  Within each project or operational issue that comes up, there is always the challenge of determining how to apply those architecture standards to any given situation.  This is where the tactics of applying the standards set come into place.  Quite frankly, having the various technical team police these themselves is not very effective.  In these cases, you will often find decisions that were made that are not in the best interest of the bigger vision for the company, costing both time and money.  Depending on the scope of the project or operational issue being addressed, the expense can be quite large and from an accountability perspective, unforgiving.   

Again, for argument sake, let’s call these folks that make tactical decisions” Solutions Architects”.  Their role is to put the architectural standards into practical application.  They need to be working with the various technical teams to advocate and enforce the use of the standards set for technology. 

Organization

Organizationally, Enterprise Architects need to be an independent function.  The application of Solution Architects is handled in a variety of ways from being imbedded in each of the technical teams with dotted line responsibility to Enterprise Architecture, or provided as a pool of resources assigned to each technical team, but reporting directly into the architecture organization. 

The actual implementation will work in either scenario, but the key here is to develop a structure whereby the architecture standards can be enforced and audited.