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,
- creating an architecture practice
- running an architecture project
- 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 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.