TOGAF 9 can be a great starting point to increase the awareness within an organization and to more explicitly acknowledge the need for enterprise-wide investments in architecture. There are, however, also pitfalls to be aware of. Three important pitfalls to avoid stepping in are:
- Keep TOGAF in the ivory tower. When reading TOGAF and following it to the letter, it is certainly possible, maybe even tempting, to just execute every phase, deliver each artifact and create all repositories. This in itself does not have to be wrong, but please note that TOGAF also emphasizes, albeit in between the lines, that making selections, and tailoring the framework to the context at hand (which includes the business) is key. This prevents that TOGAF will just keeps a bunch of expensive architects busy for several months or years, without generating real business value.
- Exclude development processes from the scope of architecture. TOGAF’s architecture development method (ADM) reasons solely from the perspective of the architect. Actual software development takes place somewhere during or after the Implementation governance phase of the ADM, but no concrete guidance is offered on how architects should guarantee that the right software (solution building blocks in TOGAF) is developed. This is probably a gap in TOGAF that you should be aware of. Fortunately, there is plenty of good software architecture literature written that does focus around this intricate relationship with requirements engineering, design, and implementation.
- Make the tools, artifacts and languages leading. When reading TOGAF one often get the feeling that it is very technical-minded, focused on deliverable (which almost all have quite fancy names in the TOGAF world) and rather model-driven. Although architects need models, technology, instruments, languages, and deliverable, to effectively communicate with stakeholders, one should be aware that using them should never become a goal in itself. The Architecture Content Framework (ACF) in TOGAF 9, including the core meta model, and its extensions, is a helpful start to think of a common frame of reference to use in your organization, but please adapt your tone and language to your stakeholders and their interests and concerns. Many of TOGAF’s artifacts are borrowed from UML and this will definitely help in communicating about architecture to developers and other technical stakeholders.
Referred from: Rick Farenhorst blog