Lessons Learned
The following lessons learned come from an architect who in 2008 finished a two year project for the U.S. Department of Defense. The architect worked as a contractor in a team of 4-8 consultants.
- Architecture must be used – it must be the guiding path of the project.
- Architecture design and development must be a formal program and not a study.
- Architecture must be results oriented.
- There must be an advocate on the stakeholders’ side to promote the development of architecture, otherwise the endeavor will fail.
- The project goals must be understood so that progress can be measured.
- The purpose of the architectural endeavor must be bounded (scoped).
- Collaboration is essential with the stakeholders who own the problem.
- Architecture must have multiple views – specifically a briefing for the people who will not read the whole document. An architectural view for executives is a must.
- A continuously updated risk matrix must exist to keep a prioritized track of issues.
- An architect must possess mission / domain knowledge. Domain knowledge helps an architect understand a wider array of choices.
- A combination of tools must be used to manage the development process, but tools cannot drive the process.
- Architect’s skills can be learned by the stakeholders – after all an architect follows some process and it’s learnable.
- Powerful configuration management tools must be in place – especially if the stakeholders and architects are geographically dispersed. Ramifications of using a wrong version of architecture can lead to catastrophic results and raise legal issues.
- Architecture artifacts must safeguarded, because architecture is an organizational asset and provides competitive advantage.
- Architecture must be viewed as an investment strategy. Like an airplane the lead time between design and the final product may be years.
