EA Soft Power Project Reviews (coach, don’t kill)

Enterprise Architecture made practical seems to be a topic that currently attracts a lot of attention. In a former post I tried to summarize some guidelines on how to approach Enterprise Architecture (see Practical Enterprise Architecture ). The key purpose of the post was to argue for a more agile approach that is better adapted to the stakeholders' needs and capabilities.

In this post I will describe some tactics concerning Enterprise Architecture and project reviews. Why bother reviewing projects from an Enterprise Architecture perspective? Below are a few possible reasons:

• A review may result in a more balanced basis for project decisions
• A review may clarify the alignment between business goals and supporting IT
• A review may identify synergies and explain different solution alternatives
• A review may engage competence that the project might have disregarded
• A review may discover risks that require mitigation
• A review may reveal aspects of the solution that are not obvious for the project members, e.g. re-use, integration and security

A review can be executed in different ways depending on the size and complexity of the project at hand. Generally, project reviews are performed in a very formal style, when the project is well under way, and the Enterprise Architect or EA team often takes the role of a (bad-guy) police. But is this always necessary?

An alternative approach might be to think about the review as a learning experience for the participants where the Enterprise Architect takes the role of a coach. The style of the review is preferably less formal. The Enterprise Architect identifies issues, leads a constructive dialogue and supports the project by suggesting different architectural improvements. These improvements are for the project to address and resolve.

This type of soft power project reviews should preferably start in the early project phases. This ensures that the project is doing the reasonable right things in the reasonably right way to minimize project risks as early as possible and to avoid the high costs of late project changes.

So, what kind of questions might the Enterprise Architect or EA team use as a foundation for a constructive dialogue with project representatives during an initial project phase? Below are some examples of statements that might elucidate many common project and architecture issues:

1. The suggested solution is documented and outlined in a comprehensible and concise way
2. The suggested solution is linked to significant and measurable business drivers, scenarios and services
3. The suggested solution clearly presents relationships to internal and external actors and stakeholders
4. The suggested solution illustrates key services and components as well as vital interfaces and interactions
5. The suggested solution answers to critical non-functional requirements and service levels
6. The suggested solution is compared to different solution alternatives and emerging IT trends
7. The suggested solution is related to its life cycle and to possible changes of the users and their usage
8. The suggested solution shows dependencies to existing IT plans and project portfolios
9. The suggested solution adheres to enterprise strategies for IT competence and sourcing
10. The suggested solution follows the established principles for Enterprise Architecture

The above statements may seem simple, but my experience is that most IT projects can not answer to all of them. A project does not need to have detailed responses to the statements during an initial phase. The point is to make sure the project members have started to think about them. Detailed explanations of how the project will solve them will then come naturally during forthcoming phases and reviews.