By Glenn Evans, Senior Consultant at Enterprise Architects
I remember as a young child coming from a ‘non-sports obsessed’ family, I didn’t know what a yorker was, didn’t know what ‘LBW’ meant, or why Dennis Lillee or Geoffrey Boycott were such legends. I was ill equipped to join in on those all-important schoolboy conversations – the Monday morning autopsy of the weekend’s sporting events. Similarly, 30 years later, enterprise architecture presented me with the same dilemma.
I remember as a junior IT engineer, I’d hear the technology choice made by the customer was for ‘business reasons’, not what was logical in my technical view of the world. I now see ‘Architecture’ was influencing the project decisions, it was the source of the ‘business reasons’.
In my early days as an Architect, it was like being back at primary school; I struggled with the conversation. There was a level of assumed knowledge with respect to the conversation and the process that was not readily accessible to me. So, I learnt the long and hard way.
Fast forward a decade or so… As a mandatory requirement of my new role with Enterprise Architects I recently attended our TOGAF® training. To be honest, I anticipated another dry, idealistic framework that, whilst relevant to the work that I do, would probably not be all that practical and would be difficult to apply to a real world situation. How wrong was I?
Don’t misunderstand! The TOGAF® manual is dry! Yes it is “another framework” and yes you do need to tailor it to the situation you are in, but this is one of its greatest strengths, this is what makes it so flexible and therefore relevant and applicable to real world situations. But it’s not the framework itself that has me excited. It’s what it enables.
To me TOGAF®:
- Is a common language, linking the discovery from each of the domains together and to the business requirements, across different levels of the business in an iterative process.
- Provides a toolset to articulate the complex, simply.
- Provides a backstop, giving traceable, auditable decision support for those difficult conversations.
- Allows the development of focused visual models of complex and disparate sets of data.
This was clearly demonstrated to me on a recent engagement. I was deep in thought, staring at a collection of printed Architecture Models displayed on a wall. One of the admin staff with no IT or business background asked me what “it all meant”. I spent a few minutes explaining that these were models of the business and the technology used in it. Not only did they immediately understand the overall concept of what they were looking at, they were actually able to start extracting real insights from the models.
In my mind, it doesn’t get any better than that. I wish I had known about TOGAF® a decade ago, I would have been a better architect – and a lot sooner.
Glenn Evans is a Senior Consultant for Enterprise Architects and is based in Melbourne, Australia.
This is an extract from Glenn’s recent blog post on the Enterprise Architects web site which you can view here.
Share the your sentiments.Togaf is a framework , a best practice and help connect the eternal business and IT divide by bringing in common taxonomy, effective tools and practical guidance when the rubber meets the road. It becomes full when you put your context into the framework and create your org specific artifacts and methods. On a related note here is a small article on why best practices are not obvious at first go from my blog and applies to any framework / standard including Togaf. At first Togaf seems like why do we need to do it this way but becomes clearer once the merits are understood well. http://eturnti.com/2013/06/08/best-practices/
We have a requirement of TOGAF Certification training for one individual in Sydney. Please provide the details (quote) to below mentioned my email id : Shantharaju.K@optus.com.au
Comments are closed.