Thoughts on ecologies of infrastructure

Some thoughts on our local systems and how we can work towards building better and stronger communities inside enterprise wide systems

Definitions of terms:

Tool: a tool is not just a thing with pre-given attributes frozen in time — a thing becomes a tool when it is put into practice, when connected to a particular activity by a person

Infrastructure: a fundamentally relational concept; infrastructure cannot exist without organized practice defining it. Infrastructure is commonly thought of as roadways, water pipes, or electric lines, but it’s really any tool that has become necessary to complete a normal day’s work. Once a tool moves past being a tool and becomes infrastructure, it includes the following attributes:

· It is embedded: it’s sunk into other structures, practices, or technologies;

· It is transparent: it does not have to be reinvented each time a task changes, it simply invisibly supports tasks, and the user molds the infrastructure to enable new tasks;

· It has scope: it has reach beyond a single event or one-site practice;

· It is learned as part of membership: strangers to the infrastructure are expected to learn it in order to participate in the group that they have joined;

· It links with conventions of practice: it both shapes and is shaped by the community that uses it;

· It is an embodiment of standards: infrastructure takes on transparency by plugging into other tools in a standardized way;

· It is built on a base: it does not grow de novo, it inherits its strengths (and limitations) from what has come before;

· It becomes visible upon breakdown: its usefulness and its embeddedness often don’t get recognized until the system fails.

Structuration: the idea that technological standards give rise to adaptations by users, which in turn require calibration and re-standardization. Over time, the system shifts due to users’ shifting. We experience this as our own digital asset management system evolves; the system guides users but users tweak the system to fit their own needs. We should expect to experience this evolution with our new CMS as well in order for the tool to become an infrastructure.

Thesis:

Lowest common denominator systems (ie very open, very simple) don’t solve users’ demand for customization; rigid standards or exceptionally inflexible systems don’t either. One person’s standard might be another’s chaos. There is no absolute center from which control and standards flow; no absolute periphery either. This acceptance of the natural chaos of system-building and rebuilding should be the place where we stand.

Discussion:

When we decided to start using our new digital asset management system as a tool, it was immediately apparent that it really needed to become an infrastructure in order to succeed. It already fulfilled a few of the characteristics of infrastructure; it was built on a base, embodied standards, had scope. What it didn’t have was embeddedness or transparency. The push for training, and a constant “championing” of the system to users, led quickly to embeddedness; it has sunk itself into many practices in our own group and to pockets of businesses outside our group. Transparency is still evolving. Our digital asset management system is not yet infrastructure, but I believe it can be, and will be, in a matter of time.

The new CMS is following a similar journey — it is built on a base, it has scope. We are working on setting standards that make sense for all user groups. But will it become infrastructure? How will the users’ experience drive adoption or rejection as an enterprise-wide platform? We must be ready to tackle user issues and help users feel as if the new platform is enabling them, rather than restricting them. This is a fine line to walk, but the benefits of moving from tool to infrastructure are vast.

An infrastructure occurs when the tension between global and local is resolved. When local practices are optimized by a large-scale technology built on the foundations of standardization, the problems of small teams working with other small teams, across distances, fade away and become reduced. The thing that forestalls an occurrence of infrastructure is that local and global rhythms of change are often mismatched or have no champion to help resolve them in a meaningful way. Many tools fail to become infrastructure because of this. If there was no utility department, a plumber would never be able to ensure that water is running to someone’s home — they would just hope that it worked, but without someone managing the infrastructure, the individual users couldn’t make sure it was working in a way that helped them get the service. This is like how a CMS works across teams: someone may make a website, but without a CMS that is built on standards and has good practices behind it, you can only ever *hope* that you’re doing the right things that align with the others in your company.

Structuration, the process of moving from tool to infrastructure, guides the relationship between users and system over time, usually in an organic way, but how do they affect one another in actual terms at the beginning of a project? How can we guide the structuration process so that tools can become infrastructure faster and with less stress to the organization?

If a project to create infrastructure is seen as purely technical, or as just “high-quality” interface design, we miss many potential hazards (and potential successes) by ignoring the socio-technical nature of such a project. When interacting with a new version of an old system, or with a new system that purports to be replacing a less technological experience, people will follow well-known behaviors first, and then may start exploring new behaviors that may innovate or disrupt the way that the system was “meant” to work. This is the structuration of a system, an iterative process that adapts both the user to the system, and the system to the user, simultaneously. To me, if the user doesn’t feel that they can sufficiently adapt the system to their purposes, they may abandon it. This breaks the structuration process because the system no longer has users to act upon it, and it turns stagnant. Once it is stagnant, users are even less likely to want to interact with it.

Enterprise systems usually only fail if the users cannot adapt, or if the barrier to entry is too high from an emotional or psychological standpoint. Users ask: do I wait on email responses? Can I troubleshoot anything on my own? What happens if I fail, is there someone to help me succeed? These are the questions that, depending on the answers, lead to success or failure of a system as a whole.

If we wish to have an enterprise wide CMS, one that people might abandon other CMS platforms to adopt, we must try to remain flexible and offer solutions that make sense on both the macro and micro scales. I’m not entirely sure that our new CMS is capable of maintaining enough flexibility for all our sites to eventually come under it, but we can at least use the CMS to start unifying our approach, our branding, and our practice, so that if we do move to another CMS in a few years, we already have a shared set of values to move together as one and make the leap from tool to infrastructure faster than before.