Finding Your Next Steps
After getting TOGAF certified, what’s next on your architecture career journey? When speaking to a team of newly certified TOGAF® architects at a customer organization, most of the questions were centered around this, such as::
- How do I get started with my first EA project using TOGAF?
- How do I estimate EA projects?
- How do I create an EA Repository?
- How essential are modeling 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
The certification process provides one with a good conceptual knowledge of TOGAF and EA, but doesn’t really clarify these three big buckets or talk about how to put your new knowledge about each of them into practice.
Here are a few tips on the most important of the three big buckets to a new architect:
Three Things to Remember
First, 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!
Second, 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. Here are some things to consider:
- A discovery workshop can bring clarity in terms of the issues, goals, gaps and 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 the specific project is one of first things to do to communicate value to your stakeholders. 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.
Third, remember, you are running an architecture PROJECT. Treat it as a project, just like any good PM would do.
- Create EA project estimates based on how many business units are participating, roughly how many business processes you are addressing and their complexity. To get the hang of it, dig into process documentation, application code and workflows, and database tables. Interview stakeholders. Be ready for site visits such as call centers, data centers, corporate offices, warehouses, and so on.
- Develop an EA roadmap that clearly highlights milestones and deliverables in a way that anyone can understand.
- Business process modelling is best approached from the organization chart. For each business unit, model high level processes and then drill 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. Trying to work from business capability first rather than org structure is actually much harder for your customers and stakeholders to understand up front.
- Demand the right kind of people: Since EA is a horizontal function, it draws resources (architects) from the line of business or business units for the duration of the EA project.
- Use the right tools: Many EA tools have good TOGAF plug-ins that can guide you through the ADM phases. Use one if you can.
- Be flexible: 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.
Earn Respect with Consistency
Remember, every customer use case is unique, but the TOGAF approach is more or less the same. As long as you can show incremental value to your stakeholders by creating artifacts to convey direction or highlight process gaps or drive organizational reuse, you are definitely in the game.
0 Comments