Tom Graves

There’s been a fairly lengthy argument on the LinkedIn business-architecture list about the role and meaning of ‘value’ in business-architecture. As usual, most of the US contingent leapt off onto the red-herring of ’shareholder-value’, which to me is almost completely irrelevant to the actual design and structure of a business-architecture – it’s an outcome, not an input as such.

After much back-and-forth – and a constant struggle to detach the discussion from the US obsession with ’shareholder-value’ – I finally managed to get at least some of the contributors to understand that values are some of the key inputs to an architecture. At this point, one of contributors tossed in what I can only describe as a lame attempt at a justification for architectural incompetence:

In my work I usually don’t create the many-layered value model that you do. I go right to the heart and relate tactical decisions to tangible value.

I’d have to say that I was shocked but not surprised. Three instant comments:

• it’s talking about price, not value;
• it’s going to the head (analysis), not to the heart (value); and
• it’s describing business-strategy and/or business-tactics, not business-architecture.

What’s still needed is a solid focus on the actual topic, namely value in business-architecture - in other words, the values-architecture that underpins the business-architecture itself.

To illustrate this, consider that statement “I usually don’t create the many-layered value model that you do”. A simple question: would you trust a purported architect who said “I’m going to use metal and glass in your building”, without any explanation or analysis as to why those materials would be used? Or what calculations underpin the choice of properties for the metal, or solar and other characteristics of the glass? Would you be concerned that there’s no ‘many-layered model’ behind the design, for example no apparent awareness of the need for resilience against earthquake or severe-storm, because though those are relatively rare in the short-term, they are highly likely in the medium to longer term? Would you trust an architect who regarded a many-layered, multi-faceted model of the building as irrelevant to the architecture-development and subsequent design and implementation? Would you trust an ‘architect’ whose only concern was price? I would hope that the answer would be ‘No’…

Which is why, like any real architect, I do insist on models that demonstrably assess all of the key factors in play in an architecture design.

So: some suggestions towards a Values Architecture 101:

#1. Values are subjective, not objective; they are feelings, not things.

#2. Values are the literal drivers for a business-architecture: they are the winds that blow across it, the rivers that flow through it, the forces that shake the ground beneath it. Values are the actual links in any value-chain or value-web. As with a physical building, the business-architecture cannot ignore those forces – it must be designed around them.

#3. Values are primarily qualitative, not quantitative. Where it is necessary to describe values in quantitative terms, it is usually best to use simple 1-5 scales or the like; anything else is likely to introduce ’spurious precision’, which is both misleading and dangerous.

#4. Any attempt to ‘objectivise’ values – such as by ‘valuation’ into a price – will always be based on hidden assumptions. Because of those hidden-assumptions, transforms to price etc are non-reversible, making it impracticable or impossible to derive the underlying value-factors by reverse-engineering from the valuation itself. Hence in architecture it is always best to model the values as values, in order to surface those hidden-assumptions.

#5. An enterprise (or extended-enterprise, reaching far beyond the ‘enterprise’ of the business itself) coalesces around a core value (the ‘vision’) and a cluster of related values and derived principles. These values represent the choices – conscious and unconscious – of the stakeholders in the enterprise, and are context-dependent. These enterprise-choices describe and define the ecosystem within which the business will operate. Amongst many other possible stakeholder-roles, a business will typically place itself in a ’supplier’ role within that enterprise.

#6. The core of the business’s relationship with other stakeholders is its set of ‘value-propositions’ – which, by definition, incorporate key concepts of value to and with the respective stakeholders. The business-model, operating-model, organisation-model etc are artefacts that are derived architecturally from the value-propositions and their underlying values.

#7. A business has a value-relationship with every stakeholder in the enterprise, whether or not this is made explicit via a value-proposition. It is extremely dangerous – especially in the longer-term – to ignore the implied relationships with enterprise-stakeholders not explicitly referenced in value-propositions.

#8. Pseudo-values such as ’shareholder-value’ may be derived from the architecture, but usually play no direct part in the architecture.

Enough to start with, I hope?

Oops – running late again. The week’s usual collections and categories, with a few extra discussions on specific topics – which is why it’s a fair bit longer than usual. Click on the ‘Read more…’ link, anyway.

Read more…

Courtesy of a pointer by Mike Aikins (@AussiMike), came across a brilliant yet scary pair of videos about just how far ‘augmented reality’ might intrude into our lives in the relatively near future. The two videos were created by architecture-student Keiichi Matsuda:

The latter half of the 20th century saw the built environment merged with media space, and architecture taking on new roles related to branding, image and consumerism. Augmented reality may recontextualise the functions of consumerism and architecture, and change in the way in which we operate within it.

A film produced for my final year Masters in Architecture, part of a larger project about the social and architectural consequences of new media and augmented reality.

First, here’s the original version of the video: a very ordinary first-person view of someone in the kitchen of a small, cramped flat (presumably in Britain, judging by the power-sockets), engaged in the mundane task of making a cup of tea. (The reasons for the strange hand-gestures will become apparent in the second video.)

domestic robocop: original footage from Keiichi Matsuda on Vimeo.

And here’s the same footage with an overdose of ‘augmented reality’ applied…

Augmented (hyper)Reality: Domestic Robocop from Keiichi Matsuda on Vimeo.

I love the detail and precision here: the clock and kettle-timer ticking away, the banal music, the equally-banal recipe and voice-over instructions. And the subtly ironic sense of humour, too: one of the messages (at 01:00) asks plaintively “Anyone up for a RL [real-life] meeting this weekend?”; the departure from the kitchen is signalled (at 01:30) by a red-flashing warning on the ‘Liquid waste’ bar on the personal-status indicator.

I can see that augmented-reality does have its value, but this is definitely not a future I’d like to live in!

Architecture is non-functional.

I’ll bet that statement raised the blood-pressure a few notches for some folks, yes? Defensive? Irritated? Sarcastic? “Waddayamean, non-functional, hey?”

Good point, because ‘non-functional’ is not the same as ‘has no function’ – although it’s often misread that way…

The problem all stems from an arbitrary and amazingly unhelpful categorisation of project-requirements as either ‘functional’ or ‘non-functional’. In this case, ‘functional’ means ‘what the project/object/thing/whatever does‘, whilst ‘non-functional’ is a generalised grab-bag for any requirements about anything else at all. But because ‘functional’ implies ‘useful’, or ‘working’, whilst ‘non-functional’ kind of implies ‘not-useful’ or ‘not-working’, this categorisation means that so-called ‘non-functional’ requirements are often assigned a much lower priority, or even ignored altogether. Which is not wise, because ‘functional’ requirements only cover the ‘what’ and ‘how’ of a project – and usually only a subset of ‘what’ and ‘how’ at that. Everything else is probably classed as ‘non-functional’: when, where, who, how much, how well, how often, and so on – and ignoring those needs is not wise at all. (The one question that’s often missing from any list of requirements – ‘functional’ or ‘non-functional’ – is why: sometimes it seems that people automatically forget how to ask pertinent questions once ‘The Requirements’ have been defined…) Which is a worry – to say the least.

But there is another way to view the notion of ‘non-functional’ – an alternative term that much better describes the real meaning or purpose of those requirements, and the architecture role with it. I was reminded of this as I skimmed through the presentations at the the current Open Group Enterprise Architecture Practitioners conference in Seattle, and came across the following table in a presentation on ‘Business-Driven IT Strategy‘ by Sam Ishak of First Canadian Title:

The ‘role’ row caught my eye because the same ‘driver/navigator’ metaphor had been used by several people in yesterday’s discussion on strategy. But then I noticed the ‘responsibility’ row – and a light-bulb lit up in my head: “Govern the quality of the solution”. The project-manager deals with the ‘functional requirements’ for the project itself; the architect deals with all the other ‘non-functional requirements’, ensuring that the end-result is not merely efficient in a functional sense, but effective overall. The PM ensures that the end-result works, within the available time and budget; but the architect ensures that it is useful – which is not a trivial matter at all.

So a more general term for ‘non-functional’ is qualitative – ensuring that whatever-it-is not only works, but also does what we want, how, where, when, with whom and, especially, why we want it to do so. There’s not much point in any focus on function alone without also including those qualitative concerns.

Architecture is about quality. Architecture is ‘non-functional’ – and that is what is should be, because its purpose is to “govern the quality of the solution”.

So yes, architecture is indeed ‘non-functional’. But perhaps we ought to be more openly proud of that fact?

This one’s kinda tangled, not least because it starts off from a follow-up that I never saw, to my previous post ‘Enterprise Architecture and Strategy‘.

(It’s also long, as usual… – click on the ‘Read more…’ link for the rest.)

Read more…

A few days back, one of my fellow Twitterers (I forget who – my apologies) pointed me to a brief video, ‘Context is King‘, by futurist David Houle. His theme in the video and elsewhere is that we are in an “evolution shift” from ‘the Information Age’ to what he calls ‘the Shift Age’. In the video he suggests that:

In the Information Age, the phrase was “Content is King”. While that may still be true, in the Shift Age, “Context is King”

Yet whilst that also “may still be true”, it doesn’t go anything like far enough. At the very least, we need to add ‘connections’ to that list, and probably ‘purpose’ as well – and, perhaps most important, the integration that links all of those dimensions together.

(Oh dear, yet another one that’s getting a bit long, and probably a bit too abstract too. Mainly enterprise-architecture and the like, so click on the ‘Read more…’ link if that’s of interest to you.)

Read more…

Another weblog item that’s been triggered by a question on Twitter, though in this case it came via a personal ‘direct message’ from Australian enterprise-architect Mike Aikins (@AussiMike):

Surely there are groups focused on the art and discipline of strategic planning and execution? How can we coalesce #entarch and these groups

Often there will be several “groups focused on the art and discipline of strategic planning and execution” – or there should be, at any rate. It’s true that enterprise architecture – and especially IT-architecture – will often be landed with a strategic role, though I would suggest that that’s more by default than by actual understanding of what EA is or does.

(Once again this has turned out to be a long explanation, so read on after the ‘Read more…’ link.)

Read more…

Every enterprise has a story, of course – many of them, in fact. Yet there’s also a deeper story that defines the enterprise itself, what the enterprise is. It’s not just that the enterprise has a story: the enterprise is a story.

What’s special about the enterprise-story is that every participant in the enterprise chooses to engage with that story. In a sometimes very literal sense, they each see themselves within the story. So how could and should that story be told, by whom, in what forms, via what means or media? And since it’s a story that’s also shared by every participant in the enterprise, there are some real questions about ownership here: if the enterprise is a story, who really owns the enterprise?

Just what that means in practice for the enterprise, and the risks and opportunities that it implies, seems a theme that’s worth exploring – not just for enterprise-architects, but for almost everyone else as well. So whatever your interest, although this is going to be another long post, you may find it more relevant than some of my other recent articles. Click on the ‘Read more…’ link to keep going, anyway.

Read more…

The current week’s-worth of assorted Tweets and links, in the usual categories, and with the usual ‘Read more…’ link to open ‘em up.

Read more…

The headline article in The Independent caught my attention this morning: ‘Head of bomb detector company arrested in fraud investigation‘. “This is an act of terrible betrayal”, wrote the Independent’s defence  journalist Kim Sengupta in a parallel piece – clearly an accurate comment given that the detectors in question failed to detect literally tons of explosives that were used to kill and maim hundreds in Iraq in a single suicide-bomb event, and all too many others like it.

As I read the article, my heart sank still further – though perhaps not for the reasons you might expect. Yes, the ‘bomb-detector’ has proved to be unreliable: there are huge problems on that score, without doubt. But to me the ‘betrayal’ turns out to be much more complex than it seems on the surface – because despite the ‘military-hardware’ packaging of the device in question, and its impressive-looking dials and cables and the rest, the underlying technology of the ‘bomb detector’ is a plain old ordinary everyday dowsing-rod.

Dowsing has been a serious interest of mine for several decades: over the years I’ve written what are now some of the best-known books on dowsing, in fact. Hence – unlike many of the critics – I do have some solid understanding of what’s going on in this case. And because of that longstanding background in the field, I’ll freely admit that I have few fundamental doubts about the use of dowsing in this context, not least because there’s plenty of long-documented, long-proven military practice in dowsing for land-mines and the like (contact the British Society of Dowsers for case-studies in Aden, for example, or the American Society of Dowsers for US use in Vietnam).  Like most people, I would much prefer a predictable and reliable machine to do the job, if there’s one available and it actually does work – which many don’t. But when lives are on the line and you don’t have anything else, a dowsing-rod in experienced hands can work wonders: so at least that part of this sad, messy story is no fraud. Yet that point about ‘experienced hands’ is extremely important: in unskilled hands a dowsing-rod can easily be worse than useless – as those on the receiving-end of those undetected explosives would have discovered to their cost…

(This is getting very long: better put a ‘Read more… link in here.)

Read more…