Framework versus body-of-knowledge

What’s the difference between a framework and a body-of-knowledge?

A colleague asked me to write some notes on this, and it seems worthwhile doing so in more generally-available form – in other words, a blog-post. 🙂

To me this is much like the difference between an organisation versus an enterprise: framework and body-of-knowledge are closely related, and in some special-cases can even coincide, but they’re not actually the same.

An organisation is a discrete conceptual entity with distinct boundaries and constraints, bounded by rules, roles and responsibilities. In much the same same way, a framework is a discrete and consistent collection of methods and model-types that describes an explicit approach to a particular problem or task, or set of related problems and/or tasks. Each framework is usually separate and distinct, though in some cases may incorporate other frameworks within itself. A framework is usually either static, or tightly versioned.

An enterprise is a discrete emotive entity with somewhat-blurry boundaries indicated by vision, values, shared-aims and mutual-commitments. In much the same way, a body-of-knowledge [BoK] is a discrete yet somewhat-open collection of experiences and intents in relation to an overall area of interest or practice (hence ‘community-of-interest’ versus ‘community-of-practice’). Bodies-of-knowledge may often overlap, and always exist within the context of and as sort-of-subsets within the overall pool of human knowledge (‘background knowledge’). To maintain its ongoing relevance in relation to real-world change, a BoK must be dynamically extensible, often indefinitely, but will need also governance (and explicit methods for that governance) in order to manage and maintain the quality, usability and validity of that body-of-knowledge.

A BoK will often accrete around a framework, but they aren’t the same. In particular, a BoK will need to be able to critique a framework, or contextualise or explore the applicability, limitations and opportunities around the use of a framework; a framework will not be able to do so to itself (though it may well attempt to do so for other frameworks).

A framework will often aim to systematise some aspect of a BoK – in other words, provide a consistent structure (methodology, taxonomy etc) for that part of BoK, and/or tasks or needs within that BoK.

Examples

The Zachman Framework is not really a full framework in this sense, because it does not (at present) include any methods: as Zachman himself says these days, it’s more an ontology than a full framework. Nevertheless, it qualifies as a framework, even in that limited sense, because it provides systematic structure around which a body-of-knowledge can (and does) accrete.

Much the same applies to DoDAF([US] Department of Defense Architecture Framework): in essence, it specifies a set of deliverables, and the relationships between those deliverables, but does not describe the methods via which those deliverables should be created. Again, though, it qualifies as a framework because it provides structure around which a body-of-knowledge has been able to develop.

Frameworx – a framework used extensively in the telecoms industry – is a more complete framework: for example, it incorporates and updates a suite of older taxonomies (eTOM [enhanced Telecom Operations Map]), reference-frameworks (SID [Structured Information/Data) and methods (part of NGOSS [New-Generation Operations Systems & Software]). It provides a structure around which an extensive body-of-knowledge has developed, but is not itself a formal BoK.

PEAF (Pragmatic Enterprise Architecture Framework) is another more-complete framework: it has a full set of methods, reference-models and defined-deliverables that, in its current version focus on the one specific task of getting started in enterprise-architecture. In that sense, it’s a framework that would (or should) be used in conjunction with other frameworks that focus on other aspects of the overall longer-term tasks of enterprise-architecture. Again, it provides a structure around which a body-of-knowledge can accrete, but is not itself a formal BoK.

TOGAF(The Open Group Architecture Framework) is a mixture of framework and BoK: it incorporates structured taxonomies and metamodels, a systematic method (ADM [Architecture Development Method]) and various commentaries on how these and other components (such as definition-structures for principles) should be used in real-world practice. However, it is not extensible, and hence is not fully usable as a BoK in its own right.

Much the same applies to ITIL (IT Infrastructure Library): it is a collection of models, metamodels, reference-frameworks and methods, with additional commentaries on recognised best-practice in IT service-management (and service-management in general). As with TOGAF, though, it’s not extensible in its own right, and hence needs to be associated with a broader body of practice-knowledge.

PMBoK (Project Management Body of Knowledge) is perhaps the best-known formal BoK, though in a sense does not fully qualify as a body-of-knowledge, because it exists primarily as a static published document – much like a framework. The actual body-of-knowledge for project-management is that which has accreted around PMBoK and related artifacts, rather than the document itself. (The PMBoK book is correctly referred to as a Guide to PMBoK, rather than ‘as’ the PMBoK itself.)

The body-of-knowledge for enterprise-architecture is the sum total of all knowledge about EA, its applicability, use, critique, interrelations with other disciplines, and much else besides. It has accreted around and between all the various EA-frameworks and practices: there are several BoKs around individual frameworks (such as around TOGAF, for example), but in practice it needs to cover a scope that is much broader than any one framework or sub-discipline such as IT-architecture – and at present there is almost no governance or consistency either for frameworks or, even more, the body-of-knowledge, across the broader EA space.

In short, we probably have too many would-be EA-frameworks already; what we urgently need is a proper BoK for enterprise-architecture!