Tom Graves / Tetradian

Why is management the way that it is? Does it work well that way? And what part does the architecture of management play in determining how well it does or doesn’t work?

(This is probably another politically-risky post for me to play with, but never mind… )

In recent weeks I’ve repeatedly come across four seemingly-distinct themes:

• deeper exploration of the architectural idea that everything in the enterprise is or represents a service
• watching architecture colleagues in several different organisations struggle yet again with inane demands from management-hierarchies that simply don’t work
• deeper exploration of conceptual flaws in current economics, particularly around the concept of possession and ‘rights of possession’
• watching yet deeper cracks appear in the current worldwide economic system

For me there’s been a kind of nagging suspicion that there might be some strong interrelationships across all of that conceptual space. Which in turn leads me to several deeply-worrying questions – from an architectural perspective, if nothing else:

• If everything is a service, what services – if any – does management actually deliver to the enterprise?
• If everything is a service, why should management be assigned any priority over anything else?
• Why are management-services and management overall so consistently and notoriously inefficient and ineffective?
• What part does organisational-structure play in rendering management-services so seemingly-ineffective in practice?
• Why is it assumed that ‘promoting’ someone into management will necessarily improve overall service-delivery?
• Why is it so often assumed that the most effective way of organising management-services is a top-down hierarchy of supposed ‘control’ of all other services?
• Following the trails of prioritised service-relationships, why are financial-shareholders so often assigned priority over every service, when in many cases the only ‘service’ they offer seems, in essence, little different from a ‘protection-racket’ – enforced compliance to demands under threat of removal of ‘protection’?
• In the current socio-political context, what – if anything – can we do architecturally to make any of this work any better?

For that matter, what can we do to make it safe even to ask such questions…?

Hmm…

(Warning: this will no doubt be another long post…)

Read more…

What do I do, and how do I do it? What’s the nature of my work, and the methods that I use? And for that matter, why?

That’s perhaps the shortest summary to a request by Anthony Draffin, in a comment to my previous post ‘Not quite bus-pass day‘:

On a selfish note… It’s apparent that the common thread to dowsing, printing and enterprise architecture is your ability to look at a field holistically and apply logical thought to extract inconsistencies and errors, as well as looking at new ways of doing something more efficiently to meet the original aims. That’s a rare skill. Have you given thought to documenting how you go about doing this? While I imagine it’s the application of a number of taught skills, the way you put these together must be far from ubiquitous. Have you considered teaching this? Personally, as a 27 year old, I want to soak up as much of your approach and thought process as you’re willing to offer.

(Warning, this is going to be another (very) long one, mainly because there’ll be several case-studies.)

Read more…

The past few posts in this series have focussed on moving ‘downward’ from the business-model, towards implementation, such as might be modelled in Archimate notation. That’s an aspect of the business-architecture / enterprise-architecture interface that makes immediate and practical sense to most people.

Yet to complete and verify the business-model and its proposed implementation, we also need to look upward into the extended-enterprise, and sideways into other aspects of the business-architecture space – otherwise the business-model could well fail in ‘unexpected’ ways. This post explores how to do that exploration, using the Enterprise Canvas frame as a checklist and guide.

(This is an adaptation of material that’s explained in more detail in my books The Service-Oriented Enterprise and Mapping the Enterprise, but there should be enough here to use straight away without needing to refer to either of those books.)

This’ll be another long one, so continue after the ‘Read more…’ break.

Read more…

As the old phrase warns us, “vision without implementation is just hallucination”. That’s why all architects do some form of design, and ideally guide the implementation too. But do enterprise-architects design the enterprise? And if so, how do they do it? Or, for that matter, should they?

These are not trivial questions, as indicated well by these tweets from Chris Potts and Robert Phipps:

• chrisdpotts: @tetradian What comes first in an enterprise, and with that its architecture, is determined by the people whose enterprise it is. // You can choose whether you want be an architect of my enterprise, fair enough, but not what my enterprise is. #entarch
• Robert_Phipps: @chrisdpotts @tetradian this is almost a political resolution to the #entarch question.

The essence of a great sparring-partner is that they come up with great challenges, and these are some of the best. Chris is right: the notion that an enterprise-architect designs the enterprise itself seems at first to be a statement of incredible and unforgivable arrogance. And Robert is right, too: by its very nature, all enterprise-architecture work is intensely political – about as political as it gets, really…

And yet enterprise-architects do also do design – in the enterprise. Of the enterprise. About the enterprise.

But only design sort-of. Kinda. Ish. Y’know? That kinda thing? All a bit blurry, subtle… all about implications, edges, options, opportunities…

The real clue is in that comment of Robert’s above: it’s all political. Very. It’s all about people – so it’s not quite the kind of design-thinking that we would use in designing a machine to make toothpaste-tubes. We don’t design enterprises as such: as Chris indicates, they develop from people, as an expression of people and their choices and desires – and the notion that we should, would or even could ‘design’ people or people’s choices is an insult in the extreme. (Not that that’s an unusual insult, unfortunately…)

The enterprise is itself: “the animal spirits” of the entrepreneur and everyday people, as Chris puts it sometimes. That’s the whole point. Yet there is a specific sense in which we do sort-of design about the enterprise. The key resides in what we mean by ‘enterprise’ and ‘organisation’, and the crucial differences between them:

• an enterprise is bounded by vision, values and commitments: it is primarily about ‘Why‘
• an organisation is bounded by rules, roles and responsibilities: it is primarily about ‘How’ and ‘What’ and and ‘Who’ and ‘Where’ and ‘When’- in fact almost everything except ‘Why’

They are not the same: and if we ever make the mistake of thinking that they are the same, we’re in deep trouble. (It’s true that, by definition, the boundaries of an organisation do also coincide with the boundaries of an enterprise – but it’s a special-case, and one of which we should be very wary in enterprise-architectures.) Crucially, the nature of an organisation means that it has no ‘Why’ of its own: to make sense of its existence – to give it a reason to exist – it needs to attach itself to the ‘Why’ of an enterprise that is greater than itself. If it loses that connection, it tends to revert automatically to the dreaded metaphor of ‘organisation-as-machine’ – literally, a machine without a purpose, or at best with a non-purpose such as ‘making money’ that confuses means with ends – that has disastrous consequences for almost everyone involved. One of the key tasks of enterprise-architecture is to identify the enterprise to which the organisation is or needs to be attached, and to help guide the organisation’s responses to and relations with that enterprise. Enterprise-architects do not design the enterprise: they provide decision-support to guide the organisation in its relations with the enterprise. That’s a subtle yet very important distinction.

Enterprise-architects develop an architecture about an enterprise, for an organisation. Yet what do we mean by ‘an enterprise’, in this context? The simplest summary is that what we look for is an extended-enterprise or shared-enterprise – defined by some kind of shared and very human drive or intent – that denotes a conceptual and/or emotive space about three steps larger in scope than the organisation itself. The organisation sort-of ‘is’ an enterprise (that special-case, as above) that has a shared-enterprise with its partners – ‘customers’ and ‘suppliers’ – that exists within a broader shared-enterprise – the ‘market’ or its equivalents – that exists within a yet broader shared-enterprise of people who are emotionally or otherwise engaged in that overall aim or intent yet are not actively or directly engaged within that market.

An enterprise simply is: it cannot be ‘designed’ as such. (Nor is it anything that anyone could ‘possess’, or ‘control’ – a mistake still made by too many marketers, managers and MBAs…) Yet each enterprise is also bounded by vision, values and commitments – to which the organisation itself commits by choosing to align itself with that enterprise. The vision, the values, the commitments and even the alignment of the organisation to each of those often starts out as implicit: a key part of the role of the EA is to identify each of those implicit items, bring them into a more explicit space, and hence enable more-explicit and more-considered choices. That’s where the ‘design’ comes in: it’s not design of the enterprise, but about the enterprise, for the organisation in relation to (and relations with) that chosen enterprise.

Enterprises intersect: I’ve shown above a simple case of the organisation in relation to one enterprise, but in reality it’s more like a complex Venn-diagram, overlapping, overlaying, often arguing with each other, too. The organisation’s choice(s) of enterprise to which it chooses to align or belong – with the ‘choice’ often being either implicit and unknown, or mandated by fact of geography or social context – each bring consequences and other choices. For example, the extended-enterprise will hold the organisation accountable to the implied values and commitments of the enterprise, and will react strongly if the organisation fails to deliver on those commitments – which is where many organisations discover to their cost that there is indeed such a thing as ‘corporate social responsibility’, and that it’s not quite as simple as Milton Friedman‘s assertion that the sole social responsibility of business is to increase its profits…

I won’t go into detail on how we deal with those myriad of consequences: as usual, this post is too long already! But essentially that’s it: enterprise-architecture sort-of does and sort-of doesn’t ‘design’ the enterprise. It’s in that ‘sort-of’ where the real interest of the EA role lies.

Comments, anyone, as usual?

People seem to struggle so much with the word ‘enterprise’ in ‘enterprise-architecture’. So often they seem to think it’s about technology. Or money.

But if you want to understand ‘enterprise’, look for the story.

And if you want to see where and how people really commit themselves to an enterprise, look for the tattoos.

That’s commitment…

And actually, no, I’m not joking. (Not much, anyway.) There’s an excellent article on this in a recent Financial Times: ‘The culinary art: Nothing shows chefs’ commitment to the trade like their food tattoos’. It’s an article I would strongly recommend to any enterprise-architect: it describes what is to me one of the best illustrations (literally!) of what a shared-enterprise means, and how people connect with that enterprise:

“Although tattoos are non-conformist,” says [Russell] Norman , “they are also very conformist. It’s a way to show other like-minded individuals that they will understand you and your ideals. When chefs get tattoos of knives, food or kitchen equipment, it shows a sort of tribal allegiance.”

So what does this look like in practice? Well, here’s one example from the FT article:

The caption for that photo is worth including in its entirety:

Dario Sutera, 28, chef de partie, Locanda Locatelli, Marble Arch. I cook a lot of fish, and so I love that I have a fish tattoo that symbolises strength and power but is also what I live off. It’s a sign of respect, in a way. If I have a bad day, I look down and there it is (it’s quite big so it’s hard to miss) and it reminds me that perseverance is a strength, a great quality and very necessary for a chef.

Notice that it’s not like a brand – a corporate identity owned by the collective – or a generic symbol such as the chef’s uniform. It’s an intensely personal badge of commitment to that shared-enterprise – the way in which each person interprets how they connect themselves to and with that enterprise.

As the article puts it, we could perhaps argue that chefs are something of a special case:

While tattoos are more fashionable than ever, it’s fairly unusual for a profession as a whole to get tattoos illustrating what they do – there aren’t many bankers with pound signs inked along their arms, nor many plumbers decorated with wrenches.

But what about enterprise-architecture itself? Like the chefs, we’re often “a driven, passionate, artful, moody and overworked lot”, and likewise “crazy” too – or at least seen that way by many of the people with whom we work! So should we get our own tattoos too, perhaps?

Any suggestions for suitable designs, folks?

[Thanks to Florian for the initial Tweet-link.]

Happy to announce that I’ve at last gotten round to publishing my sort-of-novel Yabbies. Hooray!

(I perhaps ought to say ‘completed and published’, but as you’ll see, ‘completing’ isn’t quite the right word, since much of the content is made up of story-fragments that could be assembled in just about any order.)

At present you can download the full content in PDF format for free from the Tetradian Books website.

More details and background to follow, but for now, here’s the book-blurb:

“Yabbies. Funny little things, all in their own world at the bottom of the dam. A bit like us, ain’t they? Can’t see a thing for all the mud in the water; bits and pieces drift down, in any old order, all out of sequence, an’ we have to make sense of them as best we can.”

This unusual novel explores ideas about sustainability from a different angle: that we can’t achieve a sustainable world without a system of law that fully supports it. To make that happen, we would need truly revolutionary change in the way we see our world: a refocus of passion from possession to purpose. In some ways, as one of the characters here explains, we may not have much choice:

“The whole system is so fragile that there’s a real risk it could collapse at any time, in a really big way. Those problems are inherent in the system, so to speak, so that the whole thing is held together by little more than wishful thinking.”

But what would happen if only some countries made that change – and others didn’t? What would happen to trade, to international relations, to everyday living? How would they deal with each other’s business-visitors, or tourists? Yabbies explores these themes through story-fragments, each piece as if drifting down to us through the waters of time, different characters describing their own worlds and experiences each in their own unique voice. And perhaps a little magic, too.

Yabbies first appeared more than a decade ago as YABI – Yet Another Book Idea. Although it has taken many forms over the years, as an interactive website, screenplay, annotated text and more, this is its first time available as a conventional novel. This new edition includes a background section on the ideas and principles behind the story, and also a suggested timeline to link the fragments together.

Author Tom Graves is best known as a writer on a broad range of non-fiction topics – from the structure of organisations to the structure of magic, and much more besides. He applies the same perceptive eye and acerbic humour to this story, using fiction to explore some of the deep-questions and ‘undiscussable’ themes of the present day.

Share and enjoy, perhaps?

This is part of a series of posts that I’ll be doing about ‘The Really Big Picture‘ at a societal/economic level, in relation to enterprise-architecture.

This post sets out some of the scope and scale of the changes that are or are likely to be coming up on the horizon over the next few years and/or decades, and what we can start to do about it right now in our architecture-work within our existing organisations.

First, though, a brief aside about the practical purpose of this series of posts. In a comment to the previous post,  Cynthia Kurtz rightly hauled me over the coals for what might be described as ‘overly apocalyptic’ language in the earlier introductory posts, when I was talking about potential big-picture changes that could be “forced on us”, and the limitation of “Business As Usual”, and so on. Cynthia pointed out that we really can’t pretend to predict any of this: there are many other possible big-picture changes (including none at all – though that does seem very unlikely to me), and there are many, many different forms of ‘business as usual’. As she also commented:

One thing I’ve noticed in a lot of futurist writings is that “what will happen” means “what I want to happen.”

…to which I will have to plead somewhat guilty here, I suppose… – perhaps more than a leeetle bit of wishful thinking on my part, a bit too much ‘normative architecture’ and the like? Oh well. Yet Cynthia’s final ‘courteous challenge’ is the real point here:

How does your really-big-picture EA look in the light of this?

What I really want to do here, I suppose, is explore how to use futures-disciplines properly within enterprise-architecture and the like. In her comment, Cynthia correctly points out some of the common flaws in futures-work – for example, the tendency to use declaratives (“this will happen”) rather than the more correct language of possibility (“this may happen”). The practical problem, though, is that most existing EA tools and frameworks either fail to include any proper futures-techniques at all, or mangle them to the point of misleading unusability.  The TOGAF misuse of ‘scenarios‘ is one particularly egregious example of the latter: there, ‘scenarios’ are defined as little more than a slightly-broader-scope business use-case for IT, whereas the proper futures-usage is more as in the classic Shell scenarios, which cover a literally global scope.

Futures-literacy for enterprise-architecture would include a better understanding of where futures-techniques sit, and the ways in which they can be radically different from those we use for short- to medium-term architecture-development. One key point is that it’s not about planning, about (futile) attempts to ‘predict the future’: instead, it’s about developing the capability to adapt fast to any future – and, in our case, creating an architecture that can cope with potential revolutionary change in the context for our enterprise and organisation.

One illustration from the Five Element set may help here:

Planning and other tactical Preparation are mostly about thinking, about information; likewise the metrics and other information-sources on which we base our understanding of Performance. But to create some kind of handle on the future, we need to be willing to explore feelings and emotions – what we might call the taste or sensing or flavour of the respective future, what the challenges and opportunities might be. And that’s a significantly different skillset, a different kind of ‘thinking’ – much more about People and Purpose – compared to that which we use in the mostly-analytic work of planning and the like.

Hence what I’ll aim to do here is a set of what we might call ‘thought-experiments’ (or ‘feeling-experiments’?), to explore some of these different ‘ways of knowing’. I’ll present these as if they’re ‘factual’, with links and the like to other references – but as Cynthia warns, it’s probably best to think of them as ‘as-if’ scenarios, rather than any kind of certainty or ‘fact about the future’. And because architectures do need to do at least enough design to start off the sensemaking/solution cycle, I’ll present some suggested ideas for ways to address those challenges – though again, Cynthia’s dictum applies.

With all of these posts, I’ll split the material into two parts: ‘The Really Big Picture’, such as what I’m seeing coming up in the medium- to longer-term future, and various ways in which I believe those issues could be addressed; and ‘Putting it into practice’, about ideas and models and techniques to apply the same principles in current, real, everyday enterprise-architectures for commercial businesses or government or whatever.

I hope you’ll it’s a useful and important exercise, anyway: so let’s get started. A little bit of revolution, anyone?

The Really Big Picture

Most enterprise-architects still work primarily in IT, for which in most cases the ‘big picture’ is what TOGAF calls ‘business architecture’ – in other words, ‘anything not-IT that might affect our IT’. In most cases, this boundary of scope will relate only to what happens within this one organisation, though sometimes it might also include a few IT-oriented issues that extend beyond that scope: interface-protocols and standards for information-exchange, for example.

The Big Picture – the kind of ‘big picture’ that we use in a real business-oriented architecture, for example – is rather larger: at that scope, that equivalent of ‘anything not-IT that might affect IT’ becomes more like ‘anything not-business that might affect our business’. In other words, the extended-enterprise. And the scope that concerns us there is mainly in the present or the relatively-near future: in other words, concerns for which we can plan. Sort-of.

But only ‘sort-of’ – because the Really Big Picture is about changes we can’t plan for right now. Clausewitz’s old military dictum applies here: “no plan survives first contact with the enemy”. In a business-context, that translates roughly as “no business-plan survives first contact with the real world” (and it’s perhaps best not to view the real-world as ‘the enemy’ here? ). In the Really Big Picture, we’re always dealing with a real world that we can’t quite predict – or predict at all. And if we can’t predict it, that also means that we can’t control it – a fact which leaves many business-folk feeling very uncomfortable… But since it is reality, we have to find some way to become comfortable with that kind of ‘uncomfortable’ – and help our clients become more comfortable with it, too. That’s where futures-disciplines come into enterprise-architectures.

As enterprise-architects, we also need to be ready for those ‘unpredictable’ risks and opportunities, developing architectures that resilient enough to keep on track to the overall organisational- and enterprise-intent even under the most uncertain of circumstances. (We should already know about the predictable risks and opportunities, of course, and have planned for them in various components of our architecture, such as support for routine business-continuity and disaster-recovery – though amazingly some enterprise-architects and organisations don’t even bother to do that…) The unpredictable risks and opportunities sit some way out on the apparent edge of probability, further down the ‘Long Tail’ – typically referred to by terms such as ‘kurtosis risk‘ or ‘Black Swan event‘.

Futures practitioners refer to this aspect of work as ‘weak-signal detection’: picking up hints of real future possibilities. As Cynthia indicates in her comment, there are many very large-scale ‘known unknowns’ that could hit us, but let’s look at some real examples of ‘revolutions’ whose main effects could be some way down the track, but whose glimmerings are right here, right now.

Consider the environment, the ‘biosphere’ in which all humans live. We might argue about how much of it is actually man-made, and the potential scale of each type of impact, but the fact of major global change in environment is inescapable. Global warming is driving weather destabilisation on a global scale, by comparison with the historical record; major storms tend to be more destructive than – again – the historical record. Meso-climates are shifting their borders, particularly in marginal regions such as the ‘grain-belts’ of Australia or the US Mid-West. With many of the world’s largest cities being located on coastlines, any change in sea-level is likely to place those cities at risk – and as the Japanese earthquake indicated, sea-defences may not be much use if the land itself sinks downward relative to the previous sea-level.

So what, you might say? What’s that got to do with enterprise-architectures? Well, to take those examples:

• actuarial calculations for insurance are mainly based on the historical record – so what happens when the historical trends no longer apply?
• farming-practices are based on meso-climates – so what happens to the farming-industry when an arable region turns into a dustbowl, or a rainforest turns temperate?
• city sea-defences, sewage-outfalls and much else besides are all based on current levels and current risks – so what happens to the city, its population, its industry, its commerce, its ‘property-values’ and everything else, if the sea rises or the city itself sinks?
• conventional calculations often assume an even spread – but what happens if the future isn’t spread evenly?

That last example is much more important than it may seem. Japan was well prepared for earthquakes – even ones much more severe than anything in recent history. They were also prepared for tsunamis, with defences that went right round the coast. But they weren’t prepared for one of the strongest earthquakes on record that also triggered one of the largest tsunamis on record that also swamped the underdesigned defences of a nuclear power-station that had been run ‘on the cheap’ for way too long – with devastating consequences. Each of those items was an identifiable risk considered ‘too unlikely’ to make it worth the effort to address: but it was the interaction between all of those risks that pushed the overall risk much further inward along the ‘long tail’. One of the key tasks of architecture, we might note, is to identify the connections between things: this is a genuine concern for enterprise-architectures.

Consider the revolutions in technology. It’s hard enough trying to guess technological changes even five years ahead: but for this kind of work, we need to look ahead fifty, a hundred or more years. Kurzweil’s much-vaunted Singularity might come to pass, or it might not: what impact would either option have on the architecture of the enterprise? How do we deal with change on a vast scale? Or disappointment on a vast scale?

So what, you might say? What’s that got to do with enterprise-architecture? Well, to give just one example, people are living much longer than they did, thanks to advances in medical technology and the like. But all of the actuarial calculations for state-funded pension-schemes and the like were based on typical life-expectancies back when people started paying into those schemes, three and four and five decades ago – when life-expectancies were much closer to the nominal retirement-age. And there are also many fewer younger-age people coming into the ‘base-level’ of those schemes, to pay for those who’ve reached retirement age. The result? – an almost unmanageable shortfall in pension-funds, with no solution available that does not involve betraying someone, or everyone, on a huge scale. Oops.

And consider the very real social and economic revolutions beginning to take place even now. On one side there’s a major financial/economic mess: as UK Business Secretary Vince Cable described it, it’s hard to explain just how bad the current ‘economic crisis really is. “Ultimately it comes back to this defensiveness and an unwillingness to accept that Britain was operating a model that failed”, he said – a problem of paradigms that we’ll come up against often in any form of futures-work. Then, in part as an aspect of that financial mess, there’s a huge problem of rising prices for food and other fundamentals, coupled with an ‘unemployment’ problem, seemingly on a worldwide scale – with the socioeconomic tensions that powered the ‘Arab Spring’ now starting to appear in Spain, as reported by the BBC and by the Qatar-based news-service Al Jazeera. And behind it all, perhaps, there are other socioeconomic themes, all rising and falling and interweaving with each other, such as described in the BBC documentary All Watched Over By Machines Of Loving Grace.

Again, it’s not just the individual themes, but how they all interact. Looking further back in the past, for example, we could look at the huge social upheavals in 14th-century Europe, during and after the Black Death wiped out a third of the entire population. Or, also in Europe, the ‘mini Ice Age’ of the 17th-century, when it was cold enough to freeze the Thames for a ‘Frost Fair‘ several years in a row; or, by contrast, the warm-period of the mid 18th-century that apparently gave enough relief from subsistence to provide the impetus needed to get the nascent Industrial Revolution going.

Then consider too the military and political changes that have occurred throughout those periods: the rise and fall of colonialism, for example, and the complex structures of monopoly and privilege and (to be blunt) corruption that underpinned them. Consider what impacts those would each had had on the architectures and operations of the respective enterprises – not trivial at all.

So note that, given how many of these kinds of major changes have occurred throughout the world, and how often, it’s probable that it’s quite unlikely that you would not have to deal with a change on that scale somewhen during your working-lifetime as an enterprise-architect… Which means that it might perhaps be wise to be ready for that kind of change? – even though you will likely have little or no knowledge beforehand exactly what form that kind of change will take?

And that’s where the futures-disciplines come into the picture – even, or perhaps especially, for enterprise-architecture.

Putting it into practice

The simple suggestion here is to find out more about the futures disciplines and the overall ‘futures toolkit’. Obvious places to start would include the Wikipedia summary, or one of the formal futures bodies such as the Association of Professional Futurists.

Everyone has their collection of preferred tools, though mine would include the following:

• Shell’s guide to scenario-development
• Sohail Inayatullah’s Causal Layered Analysis (also Wikipedia summary) – one of the most powerful tools for exploration of ‘deep myth’ in a futures context
• a simple Futures toolkit from the [UK] Local Government Association
• another online Futures toolkit from the ‘Brighter Futures Together’ group in northern England
• the Carnegie Trust toolkit ‘Using scenarios and futures thinking‘ [PDF] – includes an extensive set of references and links

These are all tools that can be put to immediate practical use with architecture-stakeholders at various levels. Whichever way you use these tools, expect to find some real surprises about your own business-context – and about what the future may hold in store for you and your organisation.

Somewhere to start, anyway? – and post other links and queries here as appropriate, of course.

Watch This Space, though – there’ll be quite a few more posts to come in this series.

This is in part a follow-on to ‘The Really Big Picture for enterprise-architecture‘.

As a discipline, enterprise-architecture is still in the throes of a multi-year struggle against IT-centrism – in our context, the dangerous delusion that enterprise-scope IT-architecture somehow ‘is’ enterprise-architecture. There are signs now that that struggle is at last beginning to be won: a much better recognition in Open Group conferences, for example, that business-architecture is not merely “anything not-IT that might affect IT”.

But we need to be aware, and wary, of the next trap: business-centrism. Business-architecture is, and should be, the architecture of the business. But it is not the architecture of the enterprise: the two are fundamentally different. Or, more accurately, business-architecture is a detail-layer subset of enterprise-architecture – and exactly as with IT-architecture, it is essential not to mistake any subset for the whole.

Let’s take a classic business-architecture frame, Alex Osterwalder’s Business Model Canvas:

Business Model Canvas [(cc) Alex Osterwalder, Yves Pigneur et al.]

This provides an excellent way to describe a commercial organisation’s business-model: products and services, how the customer is contacted, revenue-streams, supply-chain concerns, costs and so on. We definitely need all that information in a business-architecture, and in considerable detail.

But what this doesn’t do is show how this expands downward into the fine-detail of implementation and operational-management – which is what we need in order to realise that business-model. For example, for the IT-related components of that business-model, that’s where the IT-architectures would come into play: information-architecture, data-architecture, applications-architecture, infrastructure-architecture and so on. We would also need to connect with BPM (business-process management), security-architectures, skills-mappings and a whole load more, especially on the ‘human’ side of business practice. So on its own, a business-centric architecture could be misleading: a big-picture that’s useful, and usefully descriptive, but not actually usable in real-world practice.

And that business-oriented ‘big-picture’ is not actually big enough: it ignores a whole swathe of information about the broader business-context, and hence is left to make arbitrary assumptions about that broader context – assumptions which may well turn out to be wrong. In essence, the Business Model Canvas – and almost every other business-architecture frame that I’ve seen – will summarise the core working of the organisation, its relationships with the ‘near-field’ aspects of the supply-chain, and some description of how it will relate to customer-prospects: but that’s usually as far as it will go. Which is dangerously incomplete in relation to the whole scope of the extended-enterprise:

Relationships with the ‘outside’ part of the extended-enterprise, beyond the core market, are primarily driven by values – not solely monetary concerns, which for the most part apply only at the market-transaction level. Failing to pay proper attention to those broader values can kill the viability of the business-model and even the business itself – even though those ‘transactions’ may not touch the actual business-model at all. We can perhaps see this best through what I call the ’market-cycle’:

Another cyclical view of the relationships between all these layers also illustrates the source – and danger – of the all-too-common ‘quick-profit’ short-cut version of the cycle, which is guaranteed to drive a business into the ground in the medium to longer term:

The greyed-out area described as ‘tactics + operations’ in that diagram is usually the maximum scope of a business-architecture. An enterprise-architecture must, by definition, cover the entire scope. A ‘business-centric’ version of enterprise-architecture would constrain us to the business-specific scope – which is why everything else would be left to arbitrary and often unconscious assumptions. Not a good idea – in fact actually worse than the IT-centric version of ‘enterprise’-architecture, because at least in the latter case the limitations are obvious to most people, whereas in the business-centric version the gaps are easier to miss.

One of the things that that unhelpful troll on LinkedIn mocked me for – and others have done much the same, in the past – was my attempt to explain that in an enterprise-architecture we must take into account the value-transactions and interactions: we can’t simply reduce it all to monetary terms. As should be obvious from the diagrams above, there are relationships between those value-transactions and the monetary-type transactions that come later in the market-cycle: but those relations are usually complex, non-linear and non-reversible, so we can’t start from a monetary view (as in so many conventional ‘value-proposition’ concepts) and return directly to a monetary view (as monetary ‘profit’). The transforms from there to the much-vaunted and apparently much-desired ‘shareholder-value’ are even more complex and non-linear: as Michael Porter once put it, the obsessive quest for ‘shareholder-value’ is “the Bermuda triangle of strategy“, in which so many companies sink without trace… Yet even Michael Porter misses the point in that article: he refers to ‘economic performance’, when what he means is ‘overall performance as measured in monetary terms’ – which is not the same thing. As business-architects we can sometimes get away with that kind of kludge: but as enterprise-architects, we can’t get away with it – especially at the Really Big Picture level.

So yes, heave a sigh of relief as we finally break free from IT-centrism in enterprise-architecture. But beware of the next trap – the trap of ‘business-centrism’ – and instead keep the focus and emphasis, at all times, on the extended-enterprise as a unified if always somewhat-chaotic whole.

The ‘Really Big Picture’ for enterprise-architecture is a sustainable world that works well for everyone.

Okay, that’s a bit of a bald statement. Let’s step back a bit.

To me, every enterprise-architecture is anchored in a vision of some kind – a descriptor for the aims of the overall enterprise. (One classic example of an enterprise-vision is the one used by the TED conferences: “ideas worth spreading”.) To achieve what I regard as the core aim of enterprise-architecture – that everything works better when they work together, on purpose – we use the vision as a stable reference-point to which everything in the enterprise can align. All fairly straightforward, both in principle and in practice.

Yet enterprises intersect and nest within each other: each enterprise that we might work on in EA also depends on the enterprises ‘above’ it in terms of scope. Those ‘higher-level’ enterprises provide part of the context for ‘our’ enterprise and its enterprise-architecture. So what is the highest-level enterprise-scope? And what is the implied vision for that enterprise – the Really Big Picture for our own enterprise-architecture? It seems to me that that tag-line above is about the closest we would find to a vision-descriptor for that highest-level enterprise: a sustainable world that works well for everyone.

(We could quibble about some aspects of that enterprise-descriptor: for example, it implies a human-oriented scope. But remember, we always develop an enterprise-architecture about an enterprise but for an organisation – and the ‘organisation’ in context at present is probably no broader in scope than ‘all humans, through all time’… )

That’s the enterprise-architecture at the Really Big Picture level: technically speaking, everything else is a kind of ‘solution-architecture’, building on constraints that are imposed upon us by Reality Department, and other relatively-arbitrary constraints that we ourselves impose on the solution-design.

At that Really Big Picture level, the kind of constraints imposed by Reality Department include the fact that we live on a single very small ball of a planet with limited resources and a fragile overall ecosystem, and there aren’t any spare planets that we could plunder or run away to within conceivable reach at the present time. At the same Really Big Picture level, the self-imposed constraints mainly arise from what in causal layered analysis would be described as the ‘deep-myth’ layer: largely-unconscious assumptions and assertions about ‘how the world really works’. We see these latter constraints as the underpinnings of economics and politics – which combine and merge, for example, in the notion of ‘rights of possession’.

In principle, the enterprise-architecture discipline is a decision-support function, not a decision-making one. Yet it always ends up being somewhat normative, not least because that there are consequences that increase enterprise-risk every time we implement something that points away from the enterprise-vision. (My colleague Kevin Smith would describe that misalignment as increasing the ‘Enterprise Debt‘ – and too much Enterprise Debt can kill the whole enterprise, or at the very least the organisation’s place within that enterprise.) So we need to advise our clients and stakeholders of those consequences, and research and explore alternatives that will still fit all of the unavoidable constraints, yet will also help to minimise – and preferably reduce – the overall long-term Enterprise Debt.

The hard part, for enterprise-architects, is that that process of research will often involve challenging some deep-seated myths and assumptions… which can make us very unpopular if we’re not very careful…

At the Really Big Picture level, what we have to face right now is that probably the core assumption of our entire mainstream economics – the concept of ‘right of possession’ – simply does not work. In an all too literal sense, we’re possessed by possession. (I’m not saying that possession is ‘wrong’, or ‘immoral’, or ‘evil’, or whatever: all I’m saying is that it doesn’t work – it doesn’t and cannot align with the survival-imperative of that Really Big Picture enterprise-vision – and therefore puts everyone at ever-increasing risk.) And if it’s clear that that doesn’t work, we face a literally fundamental re-architecting and redesign of just about everything that we currently think of as ‘normal’ in our economics, politics and pretty much everything else as well. Not an easy fact to face: to be blunt, it’s a very scary picture indeed. Yet to also be blunt, we don’t have much time in which to do it: the morass of indicators on key concerns such as resource-availabilities all tell us that we have perhaps only a few decades at most – if we’re lucky – in which to make that change. Which means that right now, whether we want to or not, we need to be taking that Really Big Picture into account in every aspect of our current everyday enterprise-architecture.

It’s urgent. Really urgent. Yet the scale is so huge, and the scale of change is so huge, that there’s no way we can do it all at once. Instead, like most other aspects of real-world architectures, it’s iterative, tens and hundreds and thousands and millions upon millions of small steps all slowly yet steadily converging on the same overall Really Big Picture vision, yet all happening in the small details of the everyday. In that sense, it’s just like any other form of enterprise-architecture: “challenging, confronting, and intensely political”. But we do need to do it; and we do need to get started now.

So over the next few days I’ll write a series of posts summarising where I think we are now in terms of that Really Big Picture, various thought-experiments that we could explore to build a better sense of the implications, and how we can apply those understandings in our everyday work in enterprise-architectures and the like. (I’ll prefix each of these posts with ‘RBP-EA’ – Really Big Picture enterprise-architecture.) In reality this is about a fundamental shift in paradigm or worldview – the ways we think, the ways we interact with others, the ways we act on the world – but in practice it’s not that big a change, because we apply it in small adjustments to how we think and what we do in our enterprise-architectures and the like. Even at the end of this, everyday life will go on, much as before – because that is the way that things work. But those small tweaks will all help to re-align to the overall human enterprise, and help to reduce the overall human Enterprise Debt. And in the meantime, it should also lead to everyday enterprise-architectures that are more efficient and effective – which means that our existing architecture-clients will be happy, too. Everyone wins.

That’s what we’re aiming for here, anyway.

—

Where did this start? In reality, I’ve been working on this for years – as you’ll see if you scroll back through the earlier posts in this weblog, for example. But this particular exercise was triggered off after trying to explain yet again on one of the LinkedIn enterprise-architecture lists that we need to think more broadly than monetary terms alone when developing even the business-oriented layers of an enterprise-architecture. For some reason, US folks in particular seem really to struggle with the idea that there can be any other form of value than money – perhaps because US corporate law all but enforces this sadly lethal form of mercantile myopia. This time, though, it was one of the more annoying British-based ‘enterprise-architecture’ trolls who laid into me about this, gleefully launching into mockery and petty personal put-downs as a shallow pseudo-substitute for any form of analysis or thought. (The pointless persistence of those pathetic trolls is one of the reasons I’ve all but abandoned LinkedIn these days. Oh well.) There’s never any point in trying to argue with a troll, of course: everyone on the net has learnt that lesson the hard way. But in any case the responses to those questions would take a lot more space than LinkedIn allows: hence bringing the discussion back to here, where we do also have some means to keep the trolls at bay.

There’s a lot of work to do, to make sense of the Really Big Picture level and its implications for enterprise-architectures. I certainly don’t claim to have ‘all the answers’: the best I can offer is some of the perhaps more useful questions, and some themes and thought-experiments around which new ideas and new options might start to coalesce. And as always, the devil will be in the details – and there’ll be a lot of detail here. But it should be a start, at the least. And constructive comments and suggestions would be very welcome, too.

More later, anyway: Watch This Space?