My week of TOGAF training.

By | Jun 30, 2017

I spent the last week on a TOGAF 9.1 course in the hope that it will assist me with furthering my career by moving out of the developer role and moving myself further down the road to become a security / infrastructure architect – roles that I already partially fulfill.


After 19 years of coding I feel its time that I to start to think about moving into the planning and management space within the next 2-3 years and let the youngsters take over more and more of the coding battles. I hope to possibly grow a role like this within the organisation where I work by using my existing expertise in the infrastructure, distributed computing and security domains.


The course offered by RealIRM here in cape town was very good, the presenter Michael Payne is very knowledgeable and is awesome presenter. The course is extremely theoretical and I can see that I am going to have to spent sever hours and days digesting and re-analyzing that which was discussed. The current projections is that it will take 1-2 months of intense studying to get certification.

What did I learn?

Architecture is all about planning!

enough said.

Architecture should start at the executive level of the company.

You need input from you executives. If the company you work for does not buy into architecture as a planning requirement at business level then what ever you do at the IT level will struggle to bare fruit as the IT department may be developing a solution that business did not intend on or outside the requirement parameters of business..

Architecture is a business process \ operation with technology implementation as a goal – It is not only a IT function.

Its all about the business. There needs to be a business person involved with the architecture planning of a project to control the direction of the IT architects.

All Architects must understand the business.

The architects in IT level must understand why business is doing this project – why is the money being spent to do this project, the architect should also understand the business model and vision of the company so that he can plan according to the needs and report back to the key stake holders with various documents to assist them. As IT architects we sometimes get lost into the technology available while losing track of the stake holders and the reason for the project in the first place. Good enough vs gold plating.

Enterprise Architecture is part of business strategy.

Architecting is part of strategy while drawing on domain knowledge from people in different areas of the business that might be architects themselves. The enterprise and business architect should sit at the strategy level of the company.

Real architecture is about strategy and planning in detail to get to a plan that is near 100% accurate to minimize risk and lay out a plan that can be followed step by step to shorten the implementation phase.

Architecture is about the stake holders and the artificats produced during planning so that they can make informed decisions.

The task of the architect is not to do IT (hardware, software, develops) design but to also be able to produce artificats to business, to allow for transparency into the project, allowing different stake holders (people higher up in the organisation structure) to understand the coming cost, risk, technology, operation changes, and resources needed to make a informed decision to go ahead of change direction.

By doing architecture the progress of the project can also be more easily be tracked – by product of the planning.

Architects are project planners with domain experience within their position of the company.

I also learned that you can’t just have a single architect. There are too many aspects to consider. From what I could see you need a minimum of 4 types of architects working together on a single  project, each considering his area with the business vision and objective at mind. The 4/5 types of architects are an enterprise \ business architect, a IT / Security architect, Application architect, a Technology architect and if needed a solution architect. I will cover the responsibilities and the areas of these architects in a later post.

The planning at the IT \ Application architect level is the most intense with the most amount of detail.

This is also where things will go wrong most of the time.

The architects hand over the work to dev ops.

The architects are not always directly involved with the implementation but keeps an eye on the progress. This depends on the size of the organization.


And that is what i learned at a very high level this week.

0 0 votes
Article Rating
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments