When I did my first ITIL certification (back in the days of ITIL v2), the instructor commented on how ITIL had initially struggled to gain traction in the United States, as organizations there would readily see the value of a standard for IT management, but then stumble when they asked how they could buy and install it. Which is not to say that they thought it was some piece of software, it's just that they wanted to take it and run with it, while keeping focus on their core business.
In the same way, I've encountered organizations that want to 'implement TOGAF', with slide decks talking about becoming 'TOGAF compliant'. One problem with this noble goal – what does it mean to be TOGAF compliant. I'm TOGAF certified, and I think the certification does a decent job of testing whether I know what's in the TOGAF spec. But if an organization doesn't use the governance mechanism given in chapter 50, does that make it TOGAF non-compliant?
The simple fact is that every framework and every industry standard is a compromise effort created by a number of different contributors. And this is necessary, to take advantage of the different experience that different contributors can offer. But it can also mean that standards can become a bit of a broad-spanning 'grab bag' of tools (TOGAF is probably the best example), sometimes with different sections of the standard contradicting each other over subtle points. I will never forgot the comment of my TOGAF instructor, who challenged on certain contradictions within TOGAF 9.0, offered the comment “yes, we know it's a problem, but it won't get resolved until certain people die”. I don't think he was describing a roadmap for addressing these problems...
The reality is that standards and frameworks are inherently designed by committee, which means that they are designed to be ‘best-fit’ to the widest number of organizations. Committees lead to compromise. Or to put it another way, I can quote Alec Issigonis, the designer of the Mini, who once said “A camel looks like a horse that was planned by a committee.”
The above may seem like I think the standards are not fit for purpose– far from it. The compromise nature of these standards is unavoidable given their provenance, which in turn is unavoidable given the need to take advantage of a wide range of perspectives.
So - what's my point in all this? It’s this: The nice thing about frameworks like BIAN, TOGAF or IT4IT is that unlike a technical standard such as a networking protocol, things don’t stop working if you deviate from the standard or only use part of it. Some standards, such as TOGAF, are actually best used as a grab bag of tools rather than an integrated standard that you adopt completely or not at all. Even others, such as ArchiMate have holes in them – for example, the famous lack of a capability object in version 2 (which is an excellent example of why standards get revised on a regular basis).
Many of the standards that exist have a LinkedIn forum for them, and gurus emerge from the community to suggest ways to adapt the standard to a given circumstance. So my conclusion is this – understand that standards such as IT4IT, TOGAF et al are necessarily compromises, and the intention is for you to adapt them to your needs – sure, you shouldn’t do something completely different to what the standard says and then say you’re following it, but if you just blindly follow a standard without thought, you’ll be riding a camel when you thought you were riding a horse.
If you want to try your hand and see how you can fit standards to you needs, check out our free to download TOGAF visio stencil pack below, or head to our resources to see the full range of free stencils we've got for you!