The TOGAF framework has its detractors, but they (and some of the larger number of advocates) often miss the point of TOGAF – it's not a step-by step architecture-by-numbers guide, it's more a grab bag of tools encapsulating best practices from the experiences of others. I tell people that they should expect to borrow from TOGAF instead of adopting it wholesale – after all, step 4 of the preliminary phase is to tailor the architecture framework. In the next four posts I’m going to talk about one of these tools that people often overlook, the TOGAF skills framework, and consider how it could be expanded by borrowing ideas from it to another skills framework in a different standard.
Summary: TOGAF provides a skills framework that can assist in preparing role definitions and planning training. However, there are several ways that it could be expanded, and in this post I examine what they are.
The TOGAF skills framework appears in chapter 52, the final chapter of TOGAF (this may be why so many people forget its existence). It defines roughly 75 skills, grouped into the headings of Generic Skills, Business Skills & Methods, Enterprise Architecture Skills, Program or Project Management Skills, IT General Knowledge Skills, Technical IT Skills, Legal Environment. These skills are then plotted against 9 specific roles:
- Architecture Board member
- Architecture Sponsor
Enterprise Architecture Manager
- Enterprise Architect - Technology
- Enterprise Architect - Data
- Enterprise Architect - Applications
- Enterprise Architect - Business
- Program/project manager
- IT Designer
For each skill/role intersection, the desired skill level in that skill for that role is rated on a scale of 1-4;
1- Background – not a required skill, though should be able to define and manage skill if required
2- Awareness – Understands the background, issues, and implications sufficiently to be able to understand how to proceed further and advise client accordingly
3- Knowledge – Detailed knowledge of subject area and capable of providing professional advice and guidance. Ability to integrate capability into architecture design.
4- Expert – Extensive and substantial practical experience and applied knowledge on the subject
(from TOGAF, chapter 52)
Now, this is all helpful. But there's some other information that I wish it could offer me.
First of all, while it is useful to have these roles defined, they are pretty tightly defined. For example, what profile should a security architect have? Secondly, there is no definition of what each skill actually means. It may or may not be useful to know that each of the Enterprise Architects and the Enterprise Architect should be an expert in ‘Enterprise Continuums’, but it is hard to judge whether they are or not without a better knowledge of what the skill actually involves. Essentially, the rating system is based on the approach of “I know it when I see it”. The final thing that I personally would like to see in this section is some guidance in how someone could move up the skill levels for a given skill. What is the development path that I should define for myself, or my team?
Now, every standard does face constraints in resource that can be expended – the authors of TOGAF have day jobs as well, so they needed to define their scope in terms of what could be delivered in a given timeframe. But it feels like the TOGAF skills framework is a part of the standard that could be expanded upon usefully.
In the next blog post I’m going to examine SCOR, and its approach to skills mapping.