Tom Graves / Tetradian

What do enterprise-architects do?

At first glance it’s not an easy question. We talk a lot, with many different people, about lots of different things; but we don’t seem to do much. We tend to use a jawbreaking jargon, about narratives of knowledge, terminology, taxonomy, and things with a 2.0 in the name; we mumble about models and methods and mash-ups, or mutter about meta that might not matter to anyone else at all. We might do a drawing or two, but we probably don’t design much – domain-architects do that instead. And we don’t drive the enterprise, or the organisation – that’s the CEO’s job, and definitely not ours. So what value do we add to the enterprise? What do we do?

A nice answer came up this morning: we deal with the is-ness of business.

What is anything? Does it exist? How does it exist? Why does it exist? Do we want it to exist? In what ways does it exist in relation to others? And what is this ‘it’ anyway?

That’s sounds a bit like philosophy, doesn’t it? But what’s that got to do with anything? Business is not exactly famed for its focus on philosophy: it’s much more concerned with getting the job out of the door – and with good reason, too.

Yet making sense of things certainly does matter in business. Communication is a key concern here: to make sense of what’s going on, or what we want to happen, we need to agree on what things are, how we describe them, and how we describe the arrangement of their relationships with each other. (Otherwise known as the ontology, terminology and taxonomy of those things.) If we don’t get clear on that, we end up with separation between silos, or ‘wicked-problems’ such as the infamous ”business/IT-divide’. Worse, we end up with strategies that don’t make sense, to everyone, or to anyone.

So whilst it might sound like philosophy – and about as far from the real work as it’s possible to get – in reality these seemingly absurd abstractions are right at the root of everything. Making sense of sense-making, and all that. Without it, nothing is going to work – or work well, anyway. Especially in any large organisation.

That’s why there’s a real job, called ‘enterprise architect’, just to deal with all of that that ‘is-ness’.

And that’s what we do: the is-ness of business.

Just seemed a nice way to put it, anyway.

A great conversation yesterday evening with a former colleague from Sydney, Robert Phipps. Rambling over a range of enterprise-architecture themes: about the distinctions between organisation and enterprise, about the role of values in the defining vision (or ‘venture’, as he put it – a useful term), about the flow of value around the shared-enterprise, and the usefulness of Business Model Canvas but its limitations for a not-for-profit government department – in other words, all the usual EA topics.

But there was one almost throwaway remark he made that caught my attention, that could be a very useful avenue to explore: the enterprise composed not of entities but vectors.

(He’s been brewing on this theme for quite a while, it seems, but unfortunately hasn’t written much about it as yet – will chase him to do so when he gets home from his holidays!)

What excites me here is that this could be a way to break enterprise-architecture discussions out of the wretched trap of talking about supposed states – ‘present-state’ versus the non-existent ‘future-state’, and so on. In effect this model uses the old physics metaphor of particle versus wave, but applies it to enterprise-architecture. The usual ‘components’ or ‘building-blocks’ are like particles, and hence it’s easy to fall back into the language of ‘states’. But if we see the same quantum-like entities in a guise of wave rather than particle, this suggests the notion that everything has a vector, a trajectory of change, with direction, velocity, even with its own mass or inertia – but not a ‘state’. A project or whatever doesn’t change the organisation from ‘current state’ to ‘future state’: instead, it provides a vector that points towards a particular direction at a particular speed. The vector does sort-of imply a ‘future state’ at an arbitrarily-chosen future point in time, but that kind of frozen-time snapshot belies the dynamics of what’s actually going on. And vectors intersect: hence whilst a single vector may point to a ‘future state’, the interaction of all the vectors will inherently take the overall system someplace else.

Architectural alignment also makes more sense in the terms of this metaphor, too: we’re not lining up a bunch of particles, but aligning the vectors. Or, another way to look at this would be in terms of Brownian motion: all the different vectors coincide and intersect and interact to drive larger, more visible ‘particles’ (business capabilities, perhaps? or even the organisation as a whole?).

Just seems a nice idea, anyway. Comments or suggestions, anyone? (And if so, let Robert know via Twitter at @robert_phipps ?)

As can be seen from the comments to the previous post, the demands that we find another name for this framework-that-has-no-name have become increasingly strident.

Various urgent online and in-person conversations have ensued. The only directly-meaningful name we came up with was ‘solution-space mapping‘, but several people have disagreed with that, and in any case there is already a well-established usage of the acronym ‘SSM’ in this context, namely Checkland et al’s Soft Systems Methodology.

There’s a long-standing software tradition of assigning arbitrary names as working-titles for projects. Someone suggested ‘Eric’, which was a name they’d used when developing an IT system for an airline, and which reminded me of a nonsense-phrase I’ve often used, that “anything unknown is called Fred”.

But even an arbitrary proper-name seems too concrete for something that is necessarily abstract and, as a name, necessarily temporary. We couldn’t think of any meaningful acronym, so we played with sounds for a while, until someone came up with this:

tinc

It’s the sound of the penny dropping, as someone ‘gets it’; the small bright sound that the imaginary light-bulb makes at the ‘Aha!’ moment in solution-space. A quick, recursive echo of a sound. And it’s also a contraction of what this name really is: a temporary inconvenience.

Since it’s clear we’re not even allowed to use the name of the framework that this isn’t in order to describe what it isn’t, we would have to apply the same process to give us a temporary name for that. So we might note that in Welsh the plosive sound ‘toof!’ would be spelt as twf, which should give us a relatively-safe acronym for That Welsh Framework. (‘Twf‘ is also the name of the Welsh Language Board website, by the way – “Cymraeg o’r Crud, Two Languages from Day One”.)

So there we have it: tinc, for the framework, and twf, for the-framework-that-it-isn’t. A temporary inconvenience, but it’ll have to do for now.

Another cross-post from the discussions on LinkedIn. Over there, Pat Ferdinandi has been throwing me some really valuable challenges around this whole issue of assets in enterprise architecture – for example:

hmmm…service is not an asset? That made my mind crank a bit.
Is service tied to Intellectual property?
Is IP the asset delivered in different formats? (this would go against your assumption that employees are not assets).
Granted, I’m still thinking within the confines of an organization. But a service does have value (however it is measured).

In executive-speak, services are assets, just as people are assets – it’s a useful shorthand for something which is architecturally much more subtle and complex. As with ‘people are assets’, that colloquial shorthand contains some truly horrible boobytraps if we try to use it too literally.

Think ITIL: “people do not want products or services, they want the satisfaction of a particular need”. The ‘satisfaction of the particular need’ is the perceived value. To the customer, it’s not that the services are value but that they deliver ‘that which is valued’. The service gains value because it is the contact-point for that-which-is-valued – in other words, a relational and/or aspirational link (e.g. brand-as-implied-service-as-implied-value).

To the organisation, the service delivers value, both to the customer, and to the organisation. That value may (should?) be measured. In the colloquial sense, the service ‘has’ value, because it delivers measurable value. The value is derived from or through the service. But architecturally that’s not the same as saying that the value is inherent in the service itself.

Assets are used / referenced / changed / created / whatever in functions. It’s in the function that value is created (or destroyed), in the attachment of value to assets. A service is a conjunction of function and capability – the function can’t operate without the capability, and the capability has no function on its own.

The capability ‘has’ value in the same sense that a service ‘has’ value – in fact it’s where the service’s perceived value comes from. But the capability is embodied in an ‘actor’ or agent; and the agent itself is embodied / embedded in a physical asset (e.g. server, shop) and/or virtual asset (e.g. website) and/or via a relational-asset link to a real person. In a service, the service has perceived value, but the value itself is ultimately embodied in assets.

‘Services are assets’ is okay at board-level. (Even ‘people are assets’ is okay there if it gets the …s thinking about people as people rather than as interchangeable / disposable ‘resources’… ) But in our own thinking we need to be able to be more precise – especially if / when we’re facing down-to-the-roots redesigns, which ain’t at all unusual in the present circumstances. ::wrygrin::

“Is service tied to Intellectual property?” – it’s one possible linkage, yes, but service could be linked to any type or combination of types of assets.

“Is IP the asset delivered in different formats?” – IP is a type of asset, and can be delivered in different formats or composites, yes.

“(this would go against your assumption that employees are not assets)” – not at all. All I’m saying there is that people themselves are not assets, but the relational link to/with that person is an asset – and needs protecting and preserving just like any other organisational asset. ‘Our people are our assets’ is a useful colloquial shorthand for ‘The relational links we have with the people who have employee-relationships with us are the assets which permit us access to that person’s capability / competence”. But it’s critically important to recognise that the ownable asset is the relationship, not the person: if we try treating people (or IP, for that matter) in the same way that we ‘possess’ physical things, they’re gone. Hence the need for the deep-level precision about this stuff at an architectural level.

(This is a thread I’ve started over on the enterprise-architecture lists on LinkedIn, but thought I’d also place it here.)

The start-point was a throwaway comment by a guy on one of the lists that was probably meant to be dismissive and sarcastic – given his overall behaviour at the time – but is worth thinking about a lot more deeply:

“Assets do not imply ownership, assets imply value.”

For me, this triggered off a whole stream of questions about what we mean by ‘asset’ in the first place, and likewise what we mean by ‘ownership’ and ‘value’. More on that in the enterprise-architecture books, of course, but this is what I put up on LinkedIn as a ‘conversation-starter’:

(Some of this may sound a bit abstract at first, but if you look a little deeper, it has direct, concrete, practical application in architecture, sometimes with far-reaching consequences on architecture and design.)

The classic economics definition of assets is in terms of capital, land and labour. A useful overview, but too coarse-grained on which to build an enterprise-architecture.

The asset-categories I use are:

• physical: transferable, alienable (if I give it to you, I no longer have it) – a tangible ‘thing’
• virtual: transferable, non-alienable (if I give it to you, I still have it) – data, information etc
• relational: only partially transferable – a mutual link that exists between two entities
• aspirational: ‘one-way’ relationship from a person (mostly) to a virtual or imagined ‘other’ – belonging, meaning, brand etc

(A crucially important example of the need for precision here: people are not assets, it is the relationship with each person that is the asset. Thinking that people are assets can easily destroy an enterprise, and often has.)

Many (most?) real-world assets are composites of these categories:

• paper form: physical and virtual
• CRM record: virtual as indicator of relational
• money: virtual and aspirational (in essence, money is a belief of worth)
• trust: relational and aspirational

These days, most shareholder-value is derived from virtual (IP), relational (‘goodwill’, client-base) and aspirational (reputation) assets – the physical assets are often a tiny proportion of the perceived value.

Each asset-category requires fundamentally different handling: e.g. physical assets require physical storage, other assets (mostly) don’t. Real problems occur when business-models are based on ‘unnatural’ bundling in asset-categories: e.g. music-industry used to bundle its virtual asset (music) into physical form (disc, cassette) which it can control as a physical asset, but cannot control when unbundled into virtual form only (digital download). In architecture, we need to understand the implications of each asset-category, and of bundling and re-bundling of the underlying asset-categories in the assets we manage.

Assets are what are used or changed etc in business-functions. They imply value in that changes within business-functions may add (or remove) perceived value for the asset.

Assets do imply ownership, in that the entity only becomes an asset when it is owned. But note two fundamentally different models of ownership:

• possession – the legal ‘right’ of exclusion
• responsibility – e.g. process-owner, project-owner etc

Although most business-models are based on possession, it’s arguable that it doesn’t work (in fact is the core reason for the current economic crisis), and that the only models that work are responsibility-based. This would take more space to describe than available here, but for architecture purposes:

• what responsibilities are implied by each asset?
• how are those responsibilities transferred?
• how is value determined in relation to the asset and to those responsibilities?

I still have a long way to go to get my head fully around this, so I’m asking for others’ opinions, experiences, suggestions and views. Over to you, if you would? Thanks.