Frameworks tend to overstretch their reach
Some years ago, IT industry analyst Charles Betz stated that, over time, frameworks tend to expand their scope and overstretch their reach. This leads to potential confusion about the framework's core - and most valuable - guidance. This article proposes a more explicit distinction between a framework’s core guidance and guidance that supports interaction with adjacent disciplines.
Frameworks
When a domain of work involves more than one professional specialization, each field of specialization often has its own concepts, beliefs, terminology and practices – a ‘framework’. The degree to which each framework reflects the existence of other fields (with their own frameworks), varies from framework to framework.
Core guidance versus interaction guidance
There seems to be a tendency for frameworks, over time, to expand their scope and describe adjacent domains. On the one hand, this expansion is useful. It provides the practitioner with a better understanding of the bigger picture and how to interact with adjacent disciplines. On the other hand, it can distract from the framework’s core guidance and confuse the practitioner as to the scope of their field.
An example from the IT service management field: ITIL describes business analysis because IT service management practitioners sometimes interact with business analysts, but nobody in their right mind uses ITIL to learn how to practice business analysis.
Recommended by LinkedIn
Another example: the incident management practice has recently been reconstructed by part of the DevOps community. At its core, DevOps excels in shipping software from Dev to Ops, irrespective of the functionality. Incident management is by no means too far from its core but, thinking more about the evolution of DevOps in the longer term, it would be a shame to lose focus and credibility by expanding too much.
Scope
The scope of a field of specialization can be defined by the stages of the lifecycle (e.g. analysis, design, code, build, test, deployment, operations), the parts of the system (service vs product vs platform), the way of working (e.g. agile vs waterfall), or by other means. An additional approach is to state what IT service management or DevOps – or any other field – is not.
Once the scope has been defined, including any legitimately grey areas, the framework can make a more explicit distinction between its core guidance and guidance for interaction with adjacent fields.
Full stack cloud engineer. React, Angular, Vue, Node, Python on AWS. I dabble in React Native often.
3yIt’s been years since I talked to you Mark but your content is on point as ever.
Very true. And in addition: Every framework carries some kind of abstraction, and because of the abstraction it never works unmodified.
Interesting, Mark. Parallels with the Peter Principle. From a source smarter than me, but I forget whom - Frameworks are all flawed but some are useful. Also, they should be springboards, not straight jackets.
Head of Product Strategy and Innovation @ emite | DCMM CoAuthor | CBRM | IT Quality Expert
3yGreat article, I fully agree and this happens to all successfully adopted ideas. The problem is also the context in which the frameworks originate, for example not all IT functions are the same but it's become accepted to all follow the same guidance regardless. Using a framework outside of this context has unintended consequences. It is also true that knowledge has a shelf life, there comes a point where the core principals and assumption are no longer relevant. A practitioner should have an ever expanding kit bag, as soon as something becomes a 'best practice' it's the role of the practitioner to challenge the status quo and expand the industry to new levels, new paradigms, otherwise it stagnates.