Frameworks, falseworks, and scaffolding

One of the topics we discussed at the Cynefin retreat in Whistler was the concept of scaffolding and its role complexity. I started thinking about this (and related concepts) in the context of ITSM and IT in general, and a conversation with Douglas Clark on Twitter helped me formalize some of that thinking as below.

In IT, we like to use the terminology from the engineering and construction industries, yet I’m not really sure how similar these are to what we do. Yes, many things are industrialized and repeatable, but the levels of complexity often move us towards experimentation, rather than relying on blueprints.

The way we build systems, especially when it comes to software, reminds me much more of artisanship than a standardized industrial process. At the same time, our relationship with our tools is different. We go beyond treating them lovingly and making sure they are in good working order. We worship them.

As a result, the frameworks, methods, techniques, etc. that we use often become a target of ‘implementations’ that miss the point. We become quasi-religious when it comes to our chosen way of getting work done — whether it’s because it’s the fashionable option today, or because we have invested too much in it to question the wisdom of continuing ‘as it has always been done”.

The industrial complex that develops around these ways of working is good in promoting them, but often becomes a victim of its own success, with the market demand of ‘silver bullets’ reducing the idea to the lowest common denominator, so something that can be sold ‘in a box’ with a straight face.

The thoughts below are meant to help with contextualizing some of the tools we use in IT — our philosophies, approaches, frameworks, products, projects, and services. The same logic could apply to other similar contexts as well.

Coherent approaches

For me, a framework (in the context of IT) is a coherent collection of ideas and principles. It’s something that can be adopted (as an approach to looking at things) if it helps to achieve the expected outcomes and makes sense overall, and should be adapted to be fit for purpose in a particular context.

While I don’t think frameworks should be used as cookie-cutters, I believe it’s important to keep the coherence of the framework when going through the continuous adaption cycle. The adapted version should remain true to the principles, while the specifics can (significantly) differ from the initial ideas.

A framework doesn’t define how the end result should look like — it’s not a blueprint. A framework is a tool. It can be enhanced by additional tools — suitable techniques and methods that align with the principles. It can have a set of practices that make use of these tools, but none of this should lead to the cult of the means. The utility of the framework and its practices is determined by their usefulness for achieving the objectives.

An organization is likely to leverage more than one framework at any time. The selection of frameworks doesn’t need to be uniform in their approach, but it needs to be coherent and take into account the context. On the level of an individual framework, the way it’s used needs to be coherent with its principles. Between frameworks, the coherence is with the organization’s objectives, although the used methods and techniques can differ significantly from framework to framework, and that’s OK.

Frameworks are supporting structures, and there are (at least) two types of supporting structures an organization can make use of when pursuing their objectives: falseworks and scaffolding.

Falsework

Temporary construction work on which a main work is wholly or partly built and supported until the main work is strong enough to support itself. (M-W)

This temporary support helps the organization design their own ways of working — both on the levels of ‘what’ and ‘how’ — to build the main work. In ITSM, the main work is the (IT) organization that is continuously improving their capabilities for co-creating customer value through services. In DevOps … it’s the same, except that we use the word ‘product’ instead of ‘service’ and still skip a few crucial elements of end-to-end value creation.

As a side-note: DevOps started as a philosophy of (and an approach to) end-to-end collaboration, but it hasn’t yet reached its objectives. While the approach is continually expanded (with Security now a fundamental and explicit part of it), steadily pushed towards becoming a framework, and sometimes (sadly) already sold as one, it’s not yet coherent. Right now, if something works, whatever the context, whatever the objectives, it’s DevOps. This is not meant as criticism — we are in the territory of novel and emergent practices — but it does make attempts at ‘implementing DevOps’ look bizarre. Same with ‘DevOps maturity models’.

I look at both ITIL (a framework in IT Service Management) and DevOps as examples of falsework. They are made to mimic the structure of the main work before and during the main work is put in place, but they aren’t meant to be or become the main work. For either of them to be successful in fulfilling their purpose, the architects and the builders need to understand what the main work is and what it looks like. Scrum (as part of the agile movement) is perhaps another example of falsework. Too often, we forget the purpose of falsework, though, and the cult of the means reigns.

Falsework should be bent and tweaked — while staying true to the principles — to support the main work, not vice versa. If the organization lacks a clear strategy, or there’s little alignment within the organization around its objectives, the falsework is often painted to look like the main work. Similar to the Potemkin village, but with gaping holes in the facade.

Scaffolding

A temporary or movable platform for workers […] to stand or sit on when working at a height above the floor or ground. (M-W)

Services (as in ITIL) or products (as in DevOps) are also not the main work. As abstraction layers for ease of management and ease of collaboration, I see them both as examples of scaffolding. They are used to support doing the work. There’s no one type of scaffolding that is always the best fit, but there are contexts and proven options. Sometimes, metal scaffolding is best — and sometimes, bamboo wins. Obsessing over favorites is pointless.

Projects are also an example of scaffolding. For some types of work, having a fixed end date is OK. Sometimes it’s required. Sometimes it makes sense to assemble a new temporary team for every project, and sometimes it makes sense to keep the same team for multiple subsequent projects. Sometimes the requirements can be defined beforehand, and sometimes the discovery is ongoing throughout the project. Whatever makes sense, within principles.

Another side-note: it’s important to remember, though, that project management (focusing on outputs) is likely to deliver limited success or instead lead to significant failures without program management (focusing on outcomes) and portfolio management (focusing on priorities) in place.

Processes, procedures, and techniques as described in any body of knowledge could also be looked at as scaffolding that supports the access to falsework. One way to make sense of them could be this: “Based on the principles of the part of the falsework in question, and given the context of the challenge, this is an example of how to address that challenge, based on what we know today”. This applies equally to incident management as it does to CI/CD.

Continuous improvement

The supporting structures are not supposed to stay in place after the main work has been completed, but in IT … is it ever?

As we continuously improve our organizations and our capabilities at co-creating customer value, we also need continuous support in the form of falsework and scaffolding, and continuous improvement of that support.

In today’s world of IT, the supporting structures have become permanent fixtures. We’re never done, and we’re likely to abandon what we have built before it’s finished, or change its purpose beyond recognition. This is messy and doesn’t look too presentable, but the result serves its function and we need to remember that we are not building landmarks anymore.

There’s a risk of the supporting structures’ maintenance work taking up most of our time, leaving very little to work on the building itself. To avoid that, we should think in terms of MVF (Minimum Viable Falsework) and MVS (Minimum Viable Scaffolding). A lightweight, perhaps even collapsible design for both types of structures helps us focus on the main work and can be ‘brought back’ when we spot an issue or need to improve a specific section.

It is very likely this design is based on principles, not on processes or practices.