Function, capability and affordance

What can our business-capabilities do? As our business-needs and business-context change, what options do we have to re-purpose and re-use those capabilities?

These questions came up for me from a brief yet excellent LinkedIn thread on affordances. To me that thread seems to make more sense – or at least is more usable – if we link it to that previous work on the relationships between services, functions and capabilities.

Back in that post, I said that if we take the view that ‘everything is a service’, then:

• a function provides an interface and protocols for a service (‘black-box’ perspective)
• a capability provides a means to execute the ‘promise’ of the service (‘white-box’ perspective)

Within the service, we can use different capabilities to implement the same function – though perhaps with somewhat different service-levels:

And we also can re-use the same capabilities to deliver different functions. It all depends on how we choose to combine functions and capabilities (and assets and all the other service-content elements) into our required services.

But what exactly are ‘capabilities’? In the service-content model, we’d describe these as combinations of several closely-related themes, of which the key items in that model include the assets to be acted on, the agent that will execute that action, and the skill-level (decision-characteristics) that would guide the execution. It’s actually recursive, because we also need to take account of the functions and capabilities and services and suchlike that would be used within those same capabilities, but we can summarise it visually as follows:

The usual way to describe a capability is in terms of what it should deliver, or how it’s expected or designed to be used. Which, in effect, is very little different from describing the capability itself as a set of predefined services.

The idea of affordances turns all of that on its head, and focusses not on what the item is expected to do, but on what it can do – which can sometimes be radically different.

For example, we might expect that a hammer should be used to hammer a nail into place, but it can be used to force a screw into place, too, or to reshape a metal surface, or to jolt two components apart when they’re stuck together. A pencil should be used to write something, or draw something, but it can be used as a drumstick, or a toy boat, or a placeholder amidst a pile of papers, whilst its sharp point can be used to punch a hole in a sheet of paper or in the cling-film over your ready-to-microwave meal.

We invent affordances by using something in ways that we create. Given a new object, or new capability, a child will first try to eat it, then (usually) try to make a noise with it. An adult’s first response might be to use it to build something, or to mend something, or to use it as a weapon, or try to have sex with it. (We can tell a lot about people by the affordances they choose… 😐 )

These are all additional capabilities that the item can ‘afford‘, beyond those that it was designed to deliver. It may not do them as well – as efficient, reliable, elegant or whatever – as an item that’s designed to do the job: but the fact that it can do them may well be significant – as illustrated by the classic scene in the real-life story of Apollo 13, where engineers on the ground had to devise a viable air-filter only from parts that were available on the crippled spacecraft.

There’s a really simple key here: if an item can be used in some specific way, someone will use it in that way, at some point in some context. In effect, it’s a variant of Murphy’s Law, and one that has huge implications for security and safety and suchlike: most system-designers will have gone through the agonising experience that “each time we make the system fool-proof, along comes a better fool!” – one form of fool being the hackers who hunt endlessly for new ways to be a nuisance to others, just because they can.

Yet, as with the often-unacknowledged upside of Murphy’s Law, these same affordances can also present us with huge opportunities too – if we notice those opportunities as opportunities. The classic example is Twitter: its #hashtags and @address-mentions first arose as unexpected and un-designed-for affordances that became key conventions in the Twitter user-interface and user-experience. Yet the same is true of every platform, and just about every type of asset: innovation – and often the most valuable use – arises from bringing things together in ways that we don’t at first expect.

In short: affordances are the real capabilities of our capabilities. So it’s useful to know how to explore them – and, even more, how to use them.

Implications for enterprise-architecture practice

To make sense of this, assume a service-oriented approach to enterprise-architecture, based on the assertion that ‘everything is or represents a service’.

Use the service-content checklist (the matrix-diagram above) to explore the context. Probably the key here is to dump the expectations of the ‘Why’ or ‘Decision/reason’ column – or at least, play down their importance – and see what happens as we play around with everything else:

— Given an asset, what can we do with it? How do we want it to be used? How do we not want it to be used? In each case, why? Why not?

— Given a function (an interface or protocol), what happens when we change the underlying assets or capabilities or other service-content or context? What else could that interface afford? What actions do we want to encourage, or dissuade? (For example, we redesigned a bank’s internal cash-management system to encourage people to use the regular schedule-based cash-requests and dissuade them from using the [costly and over-used] ad-hoc cash-order functions by moving the schedule to front-and-centre of the interface and burying the ad-hoc order interface three levels furthe3r down.)

— Given a location, what options does this place afford, or not afford? In what ways is this different from other places – physical virtual, social or whatever? (for example, Iceland presents the affordances of cold climate, large amounts of geothermal and/or hydro-electric energy, yet also on or close to major international data-routes: a very useful combination for energy-hungry data-centres!)

— Given an event, what assets and capabilities are at present assumed for this? What other assets, capabilities or functions could be used to respond to this event? (Think of the Apollo 13 example.) How and with-what do we not want to respond to this event? Why? Or why not?

— Explore capabilities in terms of affordances, weaving across those three strands of capability:

• action: what types of assets can this capability act upon? (What changes when we change the assets to be acted upon with the same capability?)
• agent: through what agents can this capability be enacted? (What changes when we change the agent?)
• skill-level: what competencies and skill-levels can this capability require? (What changes as we change the competencies and/or skill-levels?)

Probably the key word here is play: new affordances are usually found through ‘playing about’ with something, especially in unexpected ways. Hence, via recursion, there’s also another real architectural issue we need to address here: the architecture of ‘play’ in the enterprise context – because if we don’t plan for it, someone else certainly will do it, whether we like it or not!

Just another interesting architectural-challenge to explore, perhaps?