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)
  • 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?

6 Comments on “Function, capability and affordance

  1. Tom
    Have a look at the concepts of ‘bricolage’ in project management, ‘degenerate solutions’ in complex adaptive systems, or ‘expatation’ in biology. They are all examples of affordances that can be used to recouple between actions and consequences.
    My “Manual for Planners of Viable Systems” (linked to the my website) gives a brief overview of such recoupling.

  2. Tom

    You have described in a different way what has emerged for me in thinking about capability and process perspectives (noting here that I am using abstracted processes, not detailed processes).

    I often approach an enterprise architecture from the starting point of considering the enterprise as a single process, such that we (the stakeholders and I) can establish some clarity around inputs and outputs and outcomes (will come back to outcomes on another occasion).

    The process thinking injects purpose – the test of what the purpose is and whether the process most effectively meets the purpose. This can then be applied to the subordinate processes that are required to deliver the output(s). It also brings in “governance” – how is the process performing? Is it doing the right things? Is it doing things right?

    I typically breakdown the process three or four levels, which gives enough granularity as well as context, and then explore a capability model in parallel to the process model.

    The thing about capability is that, as you say, it can be used for other purposes. So, as an enterprise, where I am interested in new opportunities, the easiest to pursue will be those where I can draw on existing capability to a large degree and just need a little “tweaking” here and there to take advantage of the opportunity. So, I believe this becomes an invaluable tool to those involved in developing business strategy, amongst others, as it enables them to explore new markets based on incremental change in delivery of new services (or products – still need to think about your proposition here!!).

    So, process thinking has afforded me an outside in view, capability affords me an inside out view.

    As an aside, I continue to find great value in these bi-directional approaches – inside-out, outside-in; top-down, bottom-up.

    • Thanks, Peter.

      “I often approach an enterprise architecture from the starting point of considering the enterprise as a single process”

      I’d suggest taking it one step further: if we view a process as an interweaving of services, and that a service can itself incorporate processes, then it makes even more sense to consider the enterprise (or, more usually, the organisation) as a single service. If we do this, we can then ask some very valuable additional questions: particularly around whom does this service actually, for what overall purpose, why, and with what value-definitions for ‘success’.

      “So, process thinking has afforded me an outside in view, capability affords me an inside out view.”

      I like this a lot – many thanks! The only thing I’d add to it is that service thinking then links those two views together: outside-in and inside-out, both at the same time.

  3. Hi Tom, via the terms ‘capability’ and ‘affordance’ I got to your article. Really like it! In my opinion one of the drawbacks of many EA approaches is that they start with stating whats needed and then go on to create a fitting architecture. Just like software developers have discovered that a lot of new knowledge arises during the ride, architects are now realizing that in a lot of environments upfront designs don’t fit anymore. Thinking in terms of affordances instead of ‘just capabilities’ can be really helpfull in changing the way most architects work. Thanks for an article that makes me happy!

Leave a Reply

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