I studied TOGAF for the last four months. After training in April and May 2017, and a lot of study, I did the exam and was certified at level 2, with a score of 88,5%. During my studies I have made a summary of the basic concepts based on the study guide. And I have made some summaries per ADM phase: the objectives, the chapters, the deliverables, the steps in phase A, B, C, D, E and F and the steps in phases P, G, H and RM. I have retyped the table of contents, summarized chapter 23 the architecture principles and made overviews of all figures and all figures very small.
And I made my own overview, not following a TOGAF scheme, but sort of an onion scheme of the organization and the deliverables per layer.
TOGAF
TOGAF is a good piece of work. A lot of cross-references are made how the different concepts relate to each other. Sometimes the method is too elaborate in describing every detailed step, like the step “schedule meeting”. The business-part makes it sometimes difficult, because it is the thing that manages the architecture, whereas at the same time the architecture development wants to change it. All this together makes it a lot and difficult to come to grips with the standard.
TOGAF is 70% process. The content model part IV is where you really learn something about how to design an architecture. Summaries of the contentmodel and the artifacts are helas missing in this post.
TOGAF is very top-down, whereby there seems nothing left for the application-design to do. The flebility is in using the method itself, in defining the iterations any way you deem necessary.
Architecture versus application design
Where stops architecture development and begins application design? It seems like TOGAF does not make the distinction; the method can be applied to architecture and application design. While modelling an IT-problem the granularity of the requirements and of the solutions need to match.
What are architecture requirements and how are they related to business requirements? At first I thought architecture requirements were a subset of or were derived from business requirements. But it is the other way around: business requirements are a subset of architecture requirements, next to data-, application- and technology-requirements.
In what detail do you document the architecture requirements? Intuitively I expect an architecture to be more global, about how systems work together. TOGAF does not say anything about the detail needed; it seems like all requirements are architecture requirements and need to be documented. My interpretation would be: architecture requirements need to be documented to the level they influence the architecture, to the level the architect deems necessary.
Zachman is clearer in this aspect. The basic idea is that you reificate from the conceptual level to the concrete level; from the business-idea to working code. And in between there is a level where the architect is responsible.
