Academic Architects

Dear Bob ... For a number of reasons my department formed an architecture group a couple of years ago. Since that time they've had very little practical impact - mostly they've published white papers and complained that nobody is following the architecture. I'm confident we need to manage architecture, but we don't seem to be able to make it anything more than an academic exercise. Any suggestions? - Architectur

Dear Bob ...

For a number of reasons my department formed an architecture group a couple of years ago. Since that time they've had very little practical impact - mostly they've published white papers and complained that nobody is following the architecture.

I'm confident we need to manage architecture, but we don't seem to be able to make it anything more than an academic exercise.

Any suggestions?

- Architecturally Challenged

Dear Challenged ...

If it makes you feel any better, you aren't alone. The two words I hear most often with respect to the architecture function are "academic" and "bureaucracy."

The good news is, you probably have a very good model to start from in making architecture an active participant in the success of your organization: Information Resource Management (IRM) - the place your data designers and database analysts live. How do these folks avoid being perceived as academics and bureaucrats? Simple: They get involved in real IT projects, up to their armpits or deeper. Few project managers would dream of implementing a major system without their participation.

The architecture function adds expertise to the two other layers of IT architecture: Applications and platforms. Make it non-optional that for any project that will have an impact on these layers, architects have to participate on those project teams as well. In the application layer they help structure the new application so it's sound and reuses existing code whenever possible. At the platform layer they make sure the project leverages existing platforms to the extent possible instead of bringing in new tools, operating systems, database management systems and so forth because it's the most expedient way to finish the project.

That's for new applications. For package implementations, architecture needs to be involved in the package selection process. Fit with the existing architecture and ease of integration in all three layers are the criteria architects bring to the process. These factors don't drive the decision, but they should receive strong consideration when making the final choice.

That's the core of the solution. Some organizations add another refinement: Every project team has to create an "architectural impact statement" during its design phase which architecture reviews, helping determine which projects need what kinds of participation from the architecture group. This can turn into a bureaucratic mess if you aren't careful. On the other hand, it can be a valuable way to ensure your scarce architecture resources are applied to the most urgent and important situations.

These are specific possibilities which might or might not fit your particular situation. Whether they do or not, the one thing you have to do is to get your architects out of abstract planning and into the real work of IT.

- Bob

--------