TOGAF is not Enterprise Architecture

http://www.iasaglobal.org/iasa/NewsBot.asp?MODE=VIEW&ID=74

Let me start by saying TOGAF is a fine framework and if it is what your organization has selected that is great. This post is less about TOGAF and more about EA and making it work...

What is it about architects that makes us want to describe everything in a framework and then treat that framework AS everything? Oh common we all do it. EA's, SA's, IA's, all of us are guilty of trying to framework-atize whatever we are working on. It is probably one of our best features, and it is probably one of our worst.

Recently I was talking to a chief architect about architect education. One of the things that we discussed is that the organization has standardized on TOGAF and that nothing else would be allowed. I clarified that architecture education isn't about a framework it is about skills and capability development regardless of framework. Survey after survey both internal to their organization and within IASA shows that architects do not feel that they are prepared or have all of the skills necessary to do their jobs. Yet time and time again people think that TOGAF or UML or MSF or Struts or the Unified Process or whatever are architecture.

Lets put this clearly a SKILL is the ability to complete a job that is acquired over time. Sometimes a skill uses tools. Say for example you would like to be a good presenter. Some of the TOOLS you have to choose from are Keynote, PowerPoint and Open Office. Or like me you may often present without slides (I often find it is easier to capture an audience if they aren't constantly staring at a screen).

A framework is another tool (and not a very clear one at that since it is used equally for Zachman Views, TOGAF which is a methodology and portal components which is a technology framework). A framework is not the skill or the point of the activity in the first place. For example, the ADM from is basically a methodology like UP, MSF or SCRUM. It is a process for doing things. In this case it is a process for doing architectural things instead of developmental things but just a process none the less. There are other methodologies out ther for architects. FEAF, DODAF, MODAF, and others include methodology components. And your organization may choose to mix and match these or not use them all together. But what is the point, the goal and the skill?

The point is to use a common process to make architecture easier and better, the goal to save time and hence save money and the skill.... Applying Architecture Methodologies. Wow that was complicated. Learning TOGAF may help you with one company but what if you go to work for the DOD (Dept of Defense)? They use DODAF and well um you will be out of luck. Learn the skill not the tool and everything will stop 'looking like a nail'.

Oh by the way, methodologies like TOGAF aren't even comprehensive from a process perspective. Governance, Strategy Rationalization, ROI calculation, Technology Framework Selection, and the other 75 things listed in the architect skills taxonomy we've identified have NOTHING to do with it.

- See more at: http://www.iasaglobal.org/iasa/NewsBot.asp?MODE=VIEW&ID=74#sthash.hLhUlla6.dpuf