Why make enterprise-architecture more tangible?

Enterprise-architecture: yeah, so much of it is kinda abstract… – all that ‘meta-‘ and stuff. Which turns many people off, big-time.

Unfortunately, “all that ‘meta-‘ and stuff” is really important: it helps people explore the real complexities of their own enterprise, and provides possibly the only way to make sense of a large enterprise – especially one that’s undergoing near-continual dynamic change. So if the way we present it at present turns people off, that’s a big problem for enterprise-architecture. (And enterprise-architects too, of course.)

Yet how do we explain all these abstract concepts? At present there seem to be three main approaches, in rough order of ease of creation:

  • describe in words – either as text, or within in-person conversation
  • illustrate with images – as formal graphics, as diagrams generated by some toolset, or as freeform sketches and the like
  • experience via tangible objects – as physical models, as manipulable metaphors or mini-figures and model-theatres or whatever

The next question is: how well do these approaches work? How effective are they at getting the message across, in a way that changes people’s understanding, and people’s behaviours too?

Simple answer: test it for yourself, right here, right now.

For example, take one of the (often-missed) fundamentals of enterprise-architecture, that there are at least four distinct dimensions to all types of enterprise-assets, and hence to anything that acts on those assets. The one-word summary for each of those dimensions is: physical; virtual or conceptual; relational or human; and aspirational or purposive. Many approaches to enterprise-architecture focus only on one or two of these dimensions, and ignore the rest – and thereby create very real risks for architecture-failure. How do we explain this?

Try text-only first, with a summary of those asset-dimensions:

  • physical asset-dimension: physical objects, physical ‘things’
  • virtual asset-dimension: ideas, data, information
  • relational asset-dimension: relations/connections between people
  • aspirational asset-dimension: anchor-point for ‘belonging’, identity, motivation etc (e.g. as represented by brand)

And the practical implications for each dimension:

  • physical: is tangible, independent (it exists in its own right), occupies physical space, exchangeable (I can pass the thing itself to you), alienable (if I give it to you, I no longer have it)
  • virtual: is non-tangible, semi-independent (exists in its own right, but requires association with something physical to give it accessible form), semi-exchangeable (I can pass a clone or imperfect-copy of the thing to you), non-alienable (if I give it to you, I still have it)
  • relational: is semi-tangible (each end of the link is tangible), dependent (it exists between its nodes, and may be dropped from either end), non-exchangeable (if I have it, I cannot give it to you – though I can create conditions under which you could create your own equivalent copy), inherently non-alienable (there is nothing that can be given to others)
  • aspirational (‘meaning’): is semi-tangible at best (one end of the link may be tangible, but at least one node will be virtual), dependent (it exists between its nodes), non-exchangeable (as for relational-asset), inherently non-alienable (as for relational-asset)

Most real-world assets incorporate a mix of those dimensions. For example, a printed book is a physical object, hence we need to manage it as a such. But it also contains information, so we need to manage it as that, too. It probably also denotes a relationship between people – the vendor and purchaser, perhaps, or the lender and borrower – so we need to manage those aspects of the book-as-asset. And that copy of the book may well carry meaning for someone – a sense of connection with the author, perhaps, or with the ideas and aims described within the book itself – hence we’d also need to manage those aspects of the book-as-asset as well.

And so on, and so on…

But it’s likely that that text-only description is already getting hard to follow, yes? Most people eyes start to glaze over by about that stage, anyway…

So let’s add an image or two, to provide a better anchor for the text. Start with just a simple visual-summary, to illustrate that those asset-dimensions have an orthogonal relationship to each other:

Which then provides an anchor to illustrate, for example, how those dimensions would apply in a service-context:

Or, by changing the labels again, the roles that each dimension will typically play within the service-cycle:

What happens if we over-focus on one of the dimensions – information, perhaps? With a few minor tweaks, the same diagram shows us that whilst we can still see the other dimensions from that viewpoint, we can only see them in relation to our chosen dimension – and no longer in relationship with each other:

What happens if we over-emphasise two of the dimensions – information and technology, perhaps, as happens all the time in IT-centric ‘enterprise’-architecture? Another few tweaks to the diagram shows us that in effect we force the other two dimensions into opposition with our chosen pair of dimensions, and weaken all of the other links between them – which is exactly what happens in the infamous ‘IT/business divide’:

And three dimensions out of the four? That’s what we so often see when classic ‘enterprise’-architecture tries to become ‘business-centric’ – in other words, include the aspirational or ‘purpose’ dimension – whilst still clinging on to its old IT-centric frameworks. The result is that the remaining dimension – people, the relational-dimension – gets blocked from view, almost entirely:

And so on, and so on, again – lots of other ideas and relationships that we could describe via further small tweaks to the same basic diagram.

Which is good – and we notice that the eyes don’t glaze over anything like as quickly this way, yes?

But let’s take it a step further, to make it not just text, not just visual images, but a tangible experience too.

To do this, we need a physical representation of those same dimensions. The simplest way to do this is with a small cardboard tetrahedron. Copy the graphic of the template below, scale it up to A4 or US-Letter, and print it out on a thin sheet of card:

Cut it out round the outline; cut slots for the tabs to go into (as per the very thin rectangles on the non-arrow tabs on the graphic); add descriptive text or graphics on the surfaces; and then fold and assemble the whole thing so that it looks somewhat like this:

Here, each asset-dimension is represented by one of the vertices or points on the tetrahedron.

Notice the shift in perception and perspective when we literally hold this conceptual-model in the hand. For example, it becomes obvious, self-evident, that we need all four dimensions in balance to make this work: it won’t work with just one, or two, or three.

And we maintain a sense of the whole by rotating the tetrahedron, such that different points and faces come into the foreground of the view, and move away again into the background:

When we hold the tetrahedron with one point facing upward, we don’t just see that one dimension somewhat separated from the others, we can literally feel, from the way the other points dig into our palm, that that chosen priority-dimension is still underpinned by all of the others. Even if we can’t see them, they’re always still there.

Hold the tetrahedron with two of the points between finger and thumb – for example, Technology (physical) and Knowledge (virtual). Hold the remaining two points – People (relational) and Business (aspirational), in this case – between finger and thumb of the other hand. You’ll immediately feel the tension between those two pairings: any movement on one immediately puts pressure on the other pairing, forcing it to move. A literally tangible metaphor, here, of the too-common tension between IT and ‘the Business’…

Now turn the tetrahedron around such that there’s only one face visible – for example, Knowledge (virtual), People (relational) and Technology (physical), as in the central instance of the three in that photograph just above. To remind us of the ‘missing’ dimension – Business (aspirational), for this example – its label is printed in the centre of the respective face of the tetrahedron. If this were just a diagram, that extra label would be all the information we’d have, to warn us about that hidden dimension; but when it’s a physical, tangible tetrahedron, we can feel that ‘missing’ point literally pushing pointedly into the palm of the hand. And if the point is sharp enough, it’s a message we don’t forget!

The moral of this story: making our models and metaphors into literally tangible form helps elicit information and insights that would not be available any other way.

It’s only when people can see, and feel, an architecture, from every direction, and with every sense, that architecture itself starts to make sense, starts to become real, in a literally realisable form.

Building-architects have known this for a very long time: that’s why there’s always been a thriving industry of model-making attached to the architecture trade. Yet in enterprise-architecture and related disciplines, we’ve been dominated by unwise IT-centrism for so long that we’ve been at risk of losing touch – literally – with the physical world. Not A Good Idea…

Time now to redress the balance, perhaps? – and bring the physical, tangible, human world back into enterprise-architecture.

Posted in Business, Complexity / Structure, Enterprise architecture, Knowledge Tagged with: , , , , , , , , , , , ,
4 comments on “Why make enterprise-architecture more tangible?
  1. Time now to redress the balance, perhaps? Let’s work together.

  2. At long last, a series of illustrations that clearly explain with graphics a very complex topic… Thank you. I have included and properly cited the diagrams and definitions in a lesson for my students in CIS421 Collaborative Enterprise Architecture, a course I am now teaching at National University.

Leave a Reply

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

*