A couple of weeks ago I was asked by one of the city’s near where I live to sit on an advisory board around the creation of their Digital Government strategy. For me the meeting was good since I felt that a cohort of us on the advisory board were really pushing the city into a place of discomfort (something you want an advisory board to do in certain ways). My sense is a big part of that conversation had to do with a subtle gap between the city staff and some of the participants around what a digital strategy should deal with.
Gord Ross (of Open Roads) – a friend and very smart guy – and I were debriefing afterwards about where and why the friction was arising.
We had been pushing the city hard on its need to iterate more and use data to drive decisions. This was echoed by some of the more internet oriented members of the board. But at one point I feel like I got healthy push back from one of the city staff. How, they asked, can I iterate when I’ve got 10-60 years timelines that I need to plan around? I simply cannot iterate when some of the investments I’m making are that longterm.
Gord raised Stewart Brands building layers as a metaphor which I think sums up the differing views nicely.
Brand presents his basic argument in an early chapter, “Shearing Layers,” which argues that any building is actually a hierarchy of pieces, each of which inherently changes at different rates. In his business-consulting manner, he calls these the “Six S’s” (borrowed in part from British architect and historian F. Duffy’s “Four S’s” of capital investment in buildings).
The Site is eternal; the Structure is good for 30 to 300 years (“but few buildings make it past 60, for other reasons”); the Skin now changes every 15 to 20 years due to both weathering and fashion; the Services (wiring, plumbing, kitchen appliances, heating and cooling) change every seven to 15 years, perhaps faster in more technological settings; Space Planning, the interior partitioning and pedestrian flow, changes every two or three years in offices and lasts perhaps 30 years in the most stable homes; and the innermost layers of Stuff (furnishings) change continually.
My sense is the city staff are trying to figure out what the structure, skin and services layers should be for a digital plan, whereas a lot of us in the internet/tech world live occasionally in the services layer but most in the the space planning and stuff layers where the time horizons are WAY shorter. It’s not that we have to think that way, it is just that we have become accustomed to thinking that way… doubly so since so much of what works on the internet isn’t really “planned” it is emergent. As a result, I found this metaphor useful for trying to understanding how we can end up talking past one another.
It also goes to the heart of what I was trying to convey to the staff: that I think there are a number of assumptions governments make about what has been a 10 or 50 year lifecycle versus what that lifecycle could be in the future.
In other words, a digital strategy could allow some things “phase change” from being say in the skin or service layer to being able to operate on the faster timeline, lower capital cost and increased flexibility of a space planning layer. This could have big implications on how the city works. If you are buying software or hardware on the expectation that you will only have to do it every 15 years your design parameters and expectations will be very different than if it is designed for 5 years. It also has big implications for the systems that you connect to or build around that software. If you accept that the software will constantly be changing, easy integration becomes a necessary feature. If you think you will have things for decades than, to a certain degree, stability and rigidity are a byproduct.
This is why, if the choice is between trying to better predict how to place a 30 year bet (e.g. architect something to be in the skin or services layer) or place a 5 year bet (architect it to be in the space planning or stuff layer) put as much of it in the latter as possible. If you
re-read my post on the US government’s Digital Government strategy, this is functionally what I think they are trying to do. By unbundling the data from the application they are trying to push the data up to the
services layer of the metaphor, while pushing the applications built upon it down to the
space planning and
stuff layer.
This is not to say that nothing should be long term, or that everything long term is bad. I hope not to convey this. Rather, that by being strategic about what we place where we can foster really effective platforms (services) that can last for decades (think data) while giving ourselves a lot more flexibility around what gets built around them (think applications, programs, etc…).
The Goal
On the competitive front I suspect that across Asia and Africa about 200 cities, and maybe a lot more, are going to get brand new infrastructure over the coming 100 years. Heck some of these cities are even being built from scratch. If you want your city to compete in that environment, you’d better be able to offer new and constantly improving services in order to keep up. If not, others may create efficiencies and discover improvements that given them structural advantages in the competition for talent and other resources.
But the other reason is that this kind of flexibility is, I think, critical to making (what Gord now has me referring to as the big “C” city) disappear. I like my government services best when they blend into my environment. If you live a privilidged Western World existence… how often do you think about electricity? Only when you flick the switch and it doesn’t work. That’s how I suspect most people want government to work. Seamless, reliable, designed into their lives, but not in the way of their lives. But more importantly, I want the “City” to be invisible so that it doesn’t get in the way of my ability to enjoy, contribute to, and be part of the (lower case) city – the city that we all belong to. The “city” as that messy, idea swapping, cosmopolitan, wealth and energy generating, problematic space that is the organism humans create where ever the gather in large numbers. I’d rather be writing the blog post on a WordPress installation that does a lot of things well but invisibly, rather than monkeying around with scripts, plugins or some crazy server language I don’t want to know. Likewise, the less time I spend on “the City,” and the more seamlessly it works, the more time I spend focused on “the city” doing the things that make life more interesting and hopefully better for myself and the world.
Sorry for the rambling post. But digesting a lot of thoughts. Hope there were some tasty pieces in that for you. Also, opaque blog post title eh? Okay bed time now.
Like this:
Like Loading...
Related
eaves.ca 
And you managed to write that all before going to bed… bravo.
I was quite proud to see the big-C/little-c city had gained
acceptance in the room – that was a big concept that I tried to
communicate to the big-C City staff during their website redesign
project; essentially trying to resolve some of the figure/ground tension
that I think plagues civic staff when trying to contemplate a more
citizen-centric notion of design. My World IA Day Keynote post covers more on that for those interested.
Stewart Brand and shearing layers have long had currency in information design circles, with folks like Peter Merholz and Peter Morville
having brought them into our collective consciousness back in 2001. As
you and I discussed last night – the boundaries and expectations about
the time scales and solidity of some of those layers has undergone a bit
of a transformation in the past few years. And seems to continue to do
so.
Of note, Brand gave a Long Now foundation talk in 2005 that’s worth
the watching/listening to, where he combines his concepts of pace
layering and how cities evolve, behave, and function: Cities and Time.
Getting back to the focus on layers (ours being on the space planning
& stuff vs. the City’s focus on structure, skin and services), I
think the language of the emerging field of Service Design is
particularly useful here.
We clearly need all layers to be working in coordination to deliver
successful services and service platforms (open-data, etc.), but we need
to understand how citizens perceive and experience these different
layers. Service Design takes a theatrical metaphor, using terms like
“front-stage” and “back-stage” to talk about the choreography of actors
and props and infrastructure to deliver successful service experiences.
In a multi-channel service environment (phone, web, mobile, fax, in-person, etc.), design artifacts like service blueprints that Brandon and Jamim at Adaptive Path
have helped refine over the past few years are helpful to make us think
about the demarcation and boundaries of Brand’s layers, as experienced
by both provider and consumer of said service. Their language is
informative and enlightening: line of interaction, line of visibility,
line of internal interaction, physical evidence, etc.
And I’ll admit, we spend a lot of time here at OpenRoad zooming in
and out between the layers – half of my staff are the builders of the
structure, skin, and services. We write a lot of code and get to talk to
those systems of record that store customer data, cost millions to
license, and move at a totally different time scale. Those systems are
monolithic – and there’s advantages and disadvantages to them being that
way, especially ERP systems that become the “single source of the
truth” about the customer or citizen. But that’s another post entirely.
Ending this epic comment with one of the many great things written
about the small-c city that we need to draw inspiration from in
understanding how to assist the big-C city in being better at its job,
using digital technologies:
“The city in its complete sense, then, is a geographic plexus, an economic organization, an institutional process, a theatre of social action, and an aesthetic symbol of collective unity. The city fosters art and is art; the city creates the theatre and it is the theatre. It is in the city, the city as theatre, that man’s more purposive activities are focused, and work out, through conflicting and cooperating personalities, events, groups, into more significant culminations.”
– Lewis Mumford, What is a City? 1938
And you managed to write that all before going to bed… bravo.
I was quite proud to see the big-C/little-c city had gained
acceptance in the room – that was a big concept that I tried to
communicate to the big-C City staff during their website redesign
project; essentially trying to resolve some of the figure/ground tension
that I think plagues civic staff when trying to contemplate a more
citizen-centric notion of design. My World IA Day Keynote post covers more on that for those interested.
Stewart Brand and shearing layers have long had currency in information design circles, with folks like Peter Merholz and Peter Morville
having brought them into our collective consciousness back in 2001. As
you and I discussed last night – the boundaries and expectations about
the time scales and solidity of some of those layers has undergone a bit
of a transformation in the past few years. And seems to continue to do
so.
Of note, Brand gave a Long Now foundation talk in 2005 that’s worth
the watching/listening to, where he combines his concepts of pace
layering and how cities evolve, behave, and function: Cities and Time.
Getting back to the focus on layers (ours being on the space planning
& stuff vs. the City’s focus on structure, skin and services), I
think the language of the emerging field of Service Design is
particularly useful here.
We clearly need all layers to be working in coordination to deliver
successful services and service platforms (open-data, etc.), but we need
to understand how citizens perceive and experience these different
layers. Service Design takes a theatrical metaphor, using terms like
“front-stage” and “back-stage” to talk about the choreography of actors
and props and infrastructure to deliver successful service experiences.
In a multi-channel service environment (phone, web, mobile, fax, in-person, etc.), design artifacts like service blueprints that Brandon and Jamim at Adaptive Path
have helped refine over the past few years are helpful to make us think
about the demarcation and boundaries of Brand’s layers, as experienced
by both provider and consumer of said service. Their language is
informative and enlightening: line of interaction, line of visibility,
line of internal interaction, physical evidence, etc.
And I’ll admit, we spend a lot of time here at OpenRoad zooming in
and out between the layers – half of my staff are the builders of the
structure, skin, and services. We write a lot of code and get to talk to
those systems of record that store customer data, cost millions to
license, and move at a totally different time scale. Those systems are
monolithic – and there’s advantages and disadvantages to them being that
way, especially ERP systems that become the “single source of the
truth” about the customer or citizen. But that’s another post entirely.
Ending this epic comment with one of the many great things written
about the small-c city that we need to draw inspiration from in
understanding how to assist the big-C city in being better at its job,
using digital technologies:
“The city in its complete sense, then, is a geographic plexus, an economic organization, an institutional process, a theatre of social action, and an aesthetic symbol of collective unity. The city fosters art and is art; the city creates the theatre and it is the theatre. It is in the city, the city as theatre, that man’s more purposive activities are focused, and work out, through conflicting and cooperating personalities, events, groups, into more significant culminations.”
– Lewis Mumford, What is a City? 1938
And you managed to write that all before going to bed… bravo.
I was quite proud to see the big-C/little-c city had gained
acceptance in the room – that was a big concept that I tried to
communicate to the big-C City staff during their website redesign
project; essentially trying to resolve some of the figure/ground tension
that I think plagues civic staff when trying to contemplate a more
citizen-centric notion of design. My World IA Day Keynote post covers more on that for those interested.
Stewart Brand and shearing layers have long had currency in information design circles, with folks like Peter Merholz and Peter Morville
having brought them into our collective consciousness back in 2001. As
you and I discussed last night – the boundaries and expectations about
the time scales and solidity of some of those layers has undergone a bit
of a transformation in the past few years. And seems to continue to do
so.
Of note, Brand gave a Long Now foundation talk in 2005 that’s worth
the watching/listening to, where he combines his concepts of pace
layering and how cities evolve, behave, and function: Cities and Time.
Getting back to the focus on layers (ours being on the space planning
& stuff vs. the City’s focus on structure, skin and services), I
think the language of the emerging field of Service Design is
particularly useful here.
We clearly need all layers to be working in coordination to deliver
successful services and service platforms (open-data, etc.), but we need
to understand how citizens perceive and experience these different
layers. Service Design takes a theatrical metaphor, using terms like
“front-stage” and “back-stage” to talk about the choreography of actors
and props and infrastructure to deliver successful service experiences.
In a multi-channel service environment (phone, web, mobile, fax, in-person, etc.), design artifacts like service blueprints that Brandon and Jamim at Adaptive Path
have helped refine over the past few years are helpful to make us think
about the demarcation and boundaries of Brand’s layers, as experienced
by both provider and consumer of said service. Their language is
informative and enlightening: line of interaction, line of visibility,
line of internal interaction, physical evidence, etc.
And I’ll admit, we spend a lot of time here at OpenRoad zooming in
and out between the layers – half of my staff are the builders of the
structure, skin, and services. We write a lot of code and get to talk to
those systems of record that store customer data, cost millions to
license, and move at a totally different time scale. Those systems are
monolithic – and there’s advantages and disadvantages to them being that
way, especially ERP systems that become the “single source of the
truth” about the customer or citizen. But that’s another post entirely.
Ending this epic comment with one of the many great things written
about the small-c city that we need to draw inspiration from in
understanding how to assist the big-C city in being better at its job,
using digital technologies:
“The city in its complete sense, then, is a geographic plexus, an economic organization, an institutional process, a theatre of social action, and an aesthetic symbol of collective unity. The city fosters art and is art; the city creates the theatre and it is the theatre. It is in the city, the city as theatre, that man’s more purposive activities are focused, and work out, through conflicting and cooperating personalities, events, groups, into more significant culminations.”
– Lewis Mumford, What is a City? 1938
And you managed to write that all before going to bed… bravo.
I was quite proud to see the big-C/little-c city had gained
acceptance in the room – that was a big concept that I tried to
communicate to the big-C City staff during their website redesign
project; essentially trying to resolve some of the figure/ground tension
that I think plagues civic staff when trying to contemplate a more
citizen-centric notion of design. My World IA Day Keynote post covers more on that for those interested.
Stewart Brand and shearing layers have long had currency in information design circles, with folks like Peter Merholz and Peter Morville
having brought them into our collective consciousness back in 2001. As
you and I discussed last night – the boundaries and expectations about
the time scales and solidity of some of those layers has undergone a bit
of a transformation in the past few years. And seems to continue to do
so.
Of note, Brand gave a Long Now foundation talk in 2005 that’s worth
the watching/listening to, where he combines his concepts of pace
layering and how cities evolve, behave, and function: Cities and Time.
Getting back to the focus on layers (ours being on the space planning
& stuff vs. the City’s focus on structure, skin and services), I
think the language of the emerging field of Service Design is
particularly useful here.
We clearly need all layers to be working in coordination to deliver
successful services and service platforms (open-data, etc.), but we need
to understand how citizens perceive and experience these different
layers. Service Design takes a theatrical metaphor, using terms like
“front-stage” and “back-stage” to talk about the choreography of actors
and props and infrastructure to deliver successful service experiences.
In a multi-channel service environment (phone, web, mobile, fax, in-person, etc.), design artifacts like service blueprints that Brandon and Jamim at Adaptive Path
have helped refine over the past few years are helpful to make us think
about the demarcation and boundaries of Brand’s layers, as experienced
by both provider and consumer of said service. Their language is
informative and enlightening: line of interaction, line of visibility,
line of internal interaction, physical evidence, etc.
And I’ll admit, we spend a lot of time here at OpenRoad zooming in
and out between the layers – half of my staff are the builders of the
structure, skin, and services. We write a lot of code and get to talk to
those systems of record that store customer data, cost millions to
license, and move at a totally different time scale. Those systems are
monolithic – and there’s advantages and disadvantages to them being that
way, especially ERP systems that become the “single source of the
truth” about the customer or citizen. But that’s another post entirely.
Ending this epic comment with one of the many great things written
about the small-c city that we need to draw inspiration from in
understanding how to assist the big-C city in being better at its job,
using digital technologies:
“The city in its complete sense, then, is a geographic plexus, an economic organization, an institutional process, a theatre of social action, and an aesthetic symbol of collective unity. The city fosters art and is art; the city creates the theatre and it is the theatre. It is in the city, the city as theatre, that man’s more purposive activities are focused, and work out, through conflicting and cooperating personalities, events, groups, into more significant culminations.”
– Lewis Mumford, What is a City? 1938
It is already a good start that you push some city staff thinking this way. I recently had a similar discussion with someone from an gov agency near where I leave. Although the layer analogy is interesting, IT proves to be more flexible than building/city (and for this reason, I tend to use system engineering principles even though it’s more classical).
For example, it is still possible to work on the low-level layers (let’s say structure) without touching the upper-layers. The agency staff I was discussing with explained me how they built a large software 15 years ago and they are still able to had some frequent evolutions even if this software now has lots of dependencies. One the important criteria is that they frequently do changes in many parts of the systems. It means they permanently have at least one internal staff that knows the important stuff about the software and they always try new things, incorporate new standard, new interfaces with other tools, etc. They do have some limitations (that’s what we were discussing) but I was amazed to see all the changes they did in the past.
At the other extrem, another software in the same agency (but managed by another team…) was completely subcontracted with no internal knowledge. They tend to group changes together every 3-4 years but the changes end up being so big that it takes 2 years to implement if not more.
So even if it is more difficult to work on the low-level layers compared to upper-level, it is still possible (more than in a building) and as consequence, IT services should try to iterate on all the elements as much as possible to 1. keep up to date in their needs 2. keep some living knowledge about their software. I do not think it is less expensive, but it provides smoother and more frequent updates on the software…
(A recent reading which uses the system engineering analogy to some extent: http://atechnologyjobisnoexcuse.com/2012/10/cult-of-the-product/ — a little to cloud-thingy oriented but still)