Yes, TOGAF is an EA (Enterprise Architecture) framework – but what is that suppose to mean?
Imagine that you have to oversee the IT integration of 2 companies which has merged and they have different ERP, CRM, billing system and the customer facing process are different. The merged entity needs to rationalize the product offering and needs to project a uniform and integrated face to the customer. Obviously, this is going to be a big challenge – technological, people, process and change-management. How would you go about this complex transition? You can do a ground up thinking and make a plan or you can take the help on an EA framework like TOGAF and tailor it to your specific needs.
However, the important point that needs to be kept in mind is that TOGAF is NOT a methodology for managing software development. It will help you to identify what software to build – what need the software should satisfy – if you are planning to outsource the work, what should go into an RFP – even how to monitor the development and implementation.
ADM = Architecture Development Method
If you look around a little you will realize that the core element of TOGAF is ADM. Important point to remember is the “A” in ADM is 
ARCHITECTURE and not application.
[BTW: TOGAF = The Open Group Architecture Framework and the current version is 9]
You will also come across this diagram either in the Wikipedia page on TOGAF or on the Introduction to ADMpage on the TOGAF site. I won’t blame you if you find the content in these pages to be too confusing. However, the annotated diagram on the left should be able to give you an overview.
Though the diagram has 10 circles, ADM is essentially a 4 step process.
- Tailor TOGAF to suit your need: this is a onetime activity to be done before you start adopting TOGAF for your organization
- Define scope of work and prepare plan for rollout: this activity is made of six distinct steps – we will get into the details in a later post
- Oversee development and implementation: how the actual development and implementation is done is not within the scope of TOGAF
- Manage post-implementation change: Any major change will trigger off another cycle of ADM
You may have multiple ADM cycles simultaneously running for different projects running within your organization. These projects need not be in sync.
Requirement Management = Central knowledge repository
The circle at the centre represents a knowledge repository. TOGAF was specific recommendations on how to organize the repository. We will see more about this in a later post.
I will also not get into the detail of what Enterprise Continuum is. If you had tried skimming through the TOGAF material, you surely would have encountered this term. It is a way of classifying item in the knowledge repository. On one dimension is to separate architecture and solution. On this other dimension is about moving from more generic to more specific (foundation, common system, industry, organization specific). Again, this requires more detailed discussion and we will do it in a later post.
Architecture as defined in TOGAF
The architecture is used in TOGAF in ways you would not normally use. You need some time to get used to it. The TOGAF study guide explicitly states that…
…”architecture” has two meanings depending upon the context:
- A formal description of a system, or a detailed plan of the system at a component level to guide its implementation
- The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time
At this stage I will not analyze this definition but draw your attention to 2 phrases – “detailed plan … to guide its implementation” and “evolution over time”. Do you find this different or confusing? You better get used to it.
If you come across the term Architecture Work, it means the work that needs to be done to move frombaseline (current) architecture to target (desired) architecture. In simple term it means scope of work.
Source : http://setandbma.wordpress.com/2011/01/25/what-is-togaf-without-jargon/