Summary: Having looked at two different skills frameworks in two different standards, it’s time to stop and consider the relative strengths and weaknesses of both TOGAF & SCOR. The differences imply a different objective for each framework…but since the two approaches do not contradict each other, the door is open to combining the strengths of each.
To some extent, the differences between the skills framework in TOGAF and the skills framework in SCOR are a result of the two frameworks having differing opinions about what the purpose of a skills framework is (or rather, what they want to achieve with their particular skills frameworks).
The TOGAF skills framework seems to be almost completely aimed at specifying the roles of involved parties, in particular the roles for an enterprise transformation effort as envisioned by the TOGAF Architecture Development Method. This is seen in the way that it focused on defining desired skill levels for a set of predefined roles. So the TOGAF skills framework seems to target the enablement of an organization to staff its roles within an Enterprise Architecture function sufficiently for their Enterprise Architecture initiative to succeed.
It’s possible that this brevity is deliberate. At more than 700 pages, the TOGAF 9.1 specification is already an impressively large document. Indeed, many people who’ve studied TOGAF have been surprised when I inform them that the final chapter of TOGAF contains a discussion of necessary skills. So it may be that the omission of a more detailed skills framework was simply a matter of choosing scope.
Now, in contrast to the TOGAF skills framework, the SCOR skills framework seems to be more aimed at the development of skills. This is seen in the way that it looks to define, for each skill, what aptitudes a person needs to have to obtain a certain level of skill, what experiences that they must have to obtain a certain level of skill, and training that they must have to obtain a certain level of skill. In this way it becomes possible to define a plan for continuing education as well as a role profile.
However, what is perhaps surprising as an omission from SCOR is the complete absence of roles – in other words, what roles should have what skills. The supply chain area seems mature and well-defined enough to enable the definition of specific roles … it’s possible that the absence of roles may be because the SCOR processes don’t go to the level of role-based flows. Given the rigor that the other parts of SCOR offer, we can speculate that the authors decided to omit roles until they could be integrated fully into every part of the framework – whether by RACI or in actual BPMN flows.
So the two frameworks both have aspects that the other lacks – and as stated, the choice of scope may have been a deliberate factor for both of the standards. In the final part of this series, we’ll consider how the two approaches could complement each other and speculate on possible ways that the TOGAF skills framework could be improved.