On Pace and Panarchy

First blog for a while, been a bit busy of late in a new role at Headshift, part of the Dachis Group. As a result my head has been filled up to the brim on a regular basis as I take on board all the new processes and Headshift’s compendium of all wisdom the Headshift wiki built on Confluence. I’ve also been taking on board some conceptual thinking, the social business / E 2.0 argument keeps bubbling away, but more interesting are considerations on the practicalities of change – namely how do we evangelise 2,0 inside a company and practically roll out the social tools in ways that users adopt them and business advantage is gained?

One of the key concepts I’m rolling around my head is Pace, quickly followed by the dichotomy of Stablity vs Agility. For the backdrop to this, please see Dennis Howlett’s Pace layering: the glue between E2.0 and ERP? and the Headshift blog  Social layering can help bring IT and the business together , both of which feature a video by Lee Provoost of Headshift, someone I’ve been learning a lot from of late. And at this point I should double-plus emphasise that as ever this blog is a jotting pad of my ideas and is in no way the corporate view of my employers. It’s merely my understanding at present and some thoughts that are in the tumble drier of my mind.

Pace

And so to Pace, or more accurately Pace Layering or as the Wikipedians have it, Shearing Layers and attributes it to the architect Frank Duffy. Duffy used it to theorise about buildings building, almost literally on the geography of Site, through to the Structure and Skin, and ending eventually in Stuff, things like chairs and phones. The most important thing here is that there is a hierarchy of change here – the beams and supports of a house are changed infrequently if ever, the windows and doors at somewhat regular periods; and so to the paint and wallpaper, which in terms of the life of a building, change pretty often, while stuff like phones, change increasingly often.

Now here’s the important bit – we can use this model for other architectures, that of IT for example. Here we have layers of technology, all of which change at different speeds – the infrastructure, network and core applications changing a lot more slowly than say software, peripherals and websites.

Agility vs Stability

The Agility vs Stability dichotomy is, at least at first blush, relatively simple. There’s a pay-off between the two. This can be represented so:

Now if we return to the Pace model we can see that Stability refers to the foundation or lower levels of core technology: these tend to change very slowly and need to be extremely stable – often they’re business critical. On the other hand, technologies such as social business tools and applications change quickly – they need to be very agile and tend, at least at present, not to be so mission critical to a business. We can represent this layering as below and introduce 2 new terms I’ve learned from Lee Provoost- “Transaction” and “Interaction”.

Here Transaction refers to the core business processes of ERP, CMS and the hard core architecture, I’ve lazily dubbed this a foundation layer, Dennis calls it ERP. Interaction refers to the layer of the social tools. This is treated in more detail in the Headshift blog linked above.

What I’ve started to think about in more detail is how these layers change and how this element of time intersects with the more durable and by definition slower changing architecture and the more agile and modish social layer. I’ve correlated this as a four square interplay between stable and agile / slow and fast and come up with this:

It is no doubt debatable whether these delineations are correct. What I like here is the conceptualisation of fast changing yet stable systems or slow yet agile ones and of course fast agile ones. And missing? The most obvious is the motor of change, human agency and such. In some ways I think my train of thought has ended up stuck in the mire. I’ve a book on my desk, “Panarchy Understanding Transformations in Human and Natural Systems” perhaps that has some insights into how all this fits together and ways of moving forward.

One thought on “On Pace and Panarchy”

Leave a Reply

Your email address will not be published. Required fields are marked *