EA Corner

TOGAF Certified? Congrats! Now, what next?

by Sharad B Nalawade, Senior Architect


Last November I was speaking to a team of TOGAF® certified architects at my customer organization. Most of the questions were cantered around things such as

  • how do I get started with my first ever EA project using TOGAF®
  • how do I estimate EA projects
  • how do I create EA Repository
  • how essential are modelling skills

As the questions kept coming in, it was clear that we weren't yet differentiating between the three big buckets of work outlined in TOGAF®, that is,

  1. creating an architecture practice
  2. running an architecture project
  3. governing the enterprise's architecture

While the certification process provides one with a good conceptual knowledge of TOGAF® and EA, it doesn't really clarify the three big buckets or talk about how to put your new knowledge about each of the big buckets into practice.

Here are a few tips for you to get started, based on my many years of experience helping customers like you.I will focus today on the most important of the three big buckets to a new architect, running an architecture project.


  • Learn when to start and when to end the EA project. You are covering phases A through F of the TOGAF® ADM. You are not overlapping with the actual design and development of the software!

  • The time you spend and the quality of work you do in the 'A' phase of the ADM will decide the overall success of the project.

  • A Discovery workshop can bring clarity in terms of the issues, goals, gaps and the scope. Bring your business and IT teams together on the same page and watch them argue and differ on challenges, gaps and issues.

  • Developing an EA value proposition for this specific project is one of first things to do to communicate value to your stake holders. It will also help keep you focused on always delivering business outcomes.

  • Develop and demo a few sample EA artifacts using an EA tool. Try these out with friendly stakeholders to see how they resonate. Be sure to reuse templates from others in the organization that have worked before.

  • Remember, you are running an architecture PROJECT. Treat it as a project, just like any good PM would do.

  • Many tools have good TOGAF® plug-ins that can guide you through the TOGAF® ADM phases. Use one if you can.

  • Create EA project estimation based on how many Business units are participating, roughly how many business processes you are addressing and their complexity. To get a hang of it, dig into process documentation, application code and workflows, database tables, interview stakeholders. Be ready for site visits such as call centre, data centre, corporate office, warehouse, etc.

  • Business process modelling is best approached from the Org. chart and then for each BU, modelling high level processes and then drilling down to the next levels. Develop your own hierarchy of business services -> business processes -> business sub-processes -> application functions, etc. Then you can rationalize back up into business capabilities. But trying to work from business capability first rather than org structure is actually much harder for your customers and stakeholders to understand up front.

  • Develop an EA roadmap that clearly highlights milestones and deliverables in a way that anyone can understand.

  • There is no need to strictly adhere to a TOGAF® way of doing things. As long as you follow the general philosophy and the ADM flow, that should be enough.

  • Since EA is a horizontal function, it draws resources (architects) from the LOB or BUs for the duration of the EA project. So, demand the right kind of people.

Remember, every customer use case is unique but the approach is more or less the same. As long as you can show incremental value to your stakeholders by way of creating artifacts to convey direction or highlighting process gaps or driving organizational reuse, you are definitely in the game.