Tom Graves / Tetradian

This is a follow-on to the earlier post ‘Helping others make sense of my work’.

One of the various suggestions that came up from that – many thanks, folks! – was for better cross-reference between posts.

I’ve now added a ‘Related posts’ section to the end of each post. (It’s shown only when the page is displayed in ‘single-post’ format – it won’t appear in post-lists, such as on the blog home-page.)

It’s automatically generated (by YARPP, if you’re interested in such things), so it’ll occasionally give somewhat strange results, and I haven’t yet found a way to stop it returning links to the ‘A week in Tweets’ posts. But it’s something, anyway. Hope it’s useful.

And thanks again – I know I kinda flood people with ideas and information, but I do want to give you the best service I can.

Back on business-models again, this time with more of an emphasis on the implications for enterprise-architecture, rather than solely for business-architecture.

The initial challenge posed by my colleague was to describe my own business model, by which he meant “how do I make money?”. But there’s a bit more to it than that, which is what I’d like to explore here. It’ll also provide a means to link together some of what’s been covered in other recent posts.

So, to start with, here’s somewhat simplified version of ‘how I make money’, as laid out on Alex Osterwalder‘s BMTBox app implementation of his Business Model Canvas:

I’ve interpreted Value Proposition here as ‘offer’ – the products and services that I offer to the various Customer Segments. As can be seen, there are quite a few distinct offer-types, for quite a few distinct Customer Segments – and this is fairly typical for any independent consultant. (The ‘Online diagnostics’ offer is currently under (re)development, including a rewrite of my SEMPER diagnostic/intervention toolset, for more widespread availability, and a toolset for the Enterprise Canvas model – but the other offer-types I do already deliver in some form or other every day.)

I won’t spell it all out – the typeface in the diagrams is somewhat small, but it’s readable enough. The main point from this diagram is the same as we’ve so often hit with classic Zachman and the like: it’s just a bunch of boxes, each with a bunch of labels inside, and it’s not actually much use for anything. It’s a pretty picture, a nice taxonomy, but we can’t build a story of the business – a story of how it ‘makes money’ and so on – from this alone. The two-letter codes inside [..] and <..> do a give a few hints that some things might be connected in some way with other things, but that’s about it – and the codes are a bit of a kludge anyway, to be honest.

As most architects would agree, the ‘boxes’ alone are not enough. To make sense of the story, we need to see the connections between the items. This is a set of connections for the ‘Book’ offer (i.e. write and sell books), with connection-lines patched in on top of the BMTBox image of the Canvas via a simple graphics-program:

And the same kind of connection-set for the ‘Consult’ offer:

Two more points that we can see from this. One is the different layerings of ‘business model’: although this all fits under the general heading of ‘what I do and how I make money’, there are also six distinct ‘business models’ here – one for each offer-type – that have different impacts on all the other parts of the Canvas. They’re related, obviously – which is why they also link together under the same overall umbrella – yet they call on different activities, resources and partnerships, and so on. So a ‘business model’ can also be quite dynamic, with different components emphasised at different times and in different contexts: for this kind of business at least, there is no ‘the business-model’.

The other point is that we need to know a lot more about what’s in the ‘boxes’ and the ‘lines’, because that deeper information about the activities, the flows, and so on will have a lot of impact on decisions as to whether any specific part of this overall ‘business model’ is viable. The current version of the BMTBox app does allow us to record some basic numbers for Customer Segments, Revenue Streams and Cost Structure, and make some rudimentary financial-type calculations for each – but that’s nowhere near enough information to describe the full story of what would need to happen to make it work in real-world practice. ‘The numbers’ may indeed be enough for the core business-architecture – but that’s precisely why and where we see the limitations of business-architecture on its own, and why we need an enterprise-architecture that would link it to structural aspects of all the other domains. In other words, all the other ‘architectures’ within the business context.

The Business Model Canvas is very useful for what it does, within a business-architecture: no doubt about that at all. Yet on its own, it is not enough to describe a functioning business-model – how it would actually work in practice. Sometimes – perhaps quite often – it’s the detail that kills the viability of an otherwise good-looking business-model: and we can’t know that detail unless we are able to do a deep-dive into selected areas of the model’s implementation. That’s where Archimate, UML, BPMN and all those other modelling-techniques come into the picture; and also where Enterprise Canvas fits in, too, as a structured intermediate between the coarse-grained abstractions of the Business Model Canvas and the fine-grained detail of BPMN and the like. More on that in another post that’s coming soon, anyway.

The final point here, and perhaps the most important, is that in terms of enterprise-architecture, ‘how I make money’ is not a business-model in any meaningful sense of the term. It confuses means with ends: ‘making money’ is a ‘How’, not a Why’. (Even within a possession-economy, ‘making money’ is always an intermediate step towards something else, and in most cases trying to use it as a ‘Why’ makes no sense other than as a form of addiction – 12-Step Programme for Money-Obsessives Anonymous, anyone? ) To find the the ‘Why’ that we need for this, we have to move to a level ‘above’ the Business Model Canvas and business-architecture – which, again, is where enterprise-architecture comes into the picture.

If we look back at the immediately-previous post, ‘Do enterprise-architects design the enterprise?‘, the ‘Why’ that we need as the real driver for the business-model – and to which everything in the business-model must demonstrably align – is the ‘vision’ and concomitant values of the broader shared-enterprise. That vision – whatever it might be – is, in a very literal sense, the motive power behind the entire shared-enterprise. It’s also the common theme through which each player connects with all the others in that shared-enterprise. In my own case, as I described in the earlier post on this, what excites me – what I’m passionate about – is finding ways in which things can work together more effectively, in ways that work well for everyone. A business-related term for that shared-enterprise is ‘enterprise-architecture’ – hence that’s what I do, the label (or one of the labels) that I use for my work and my business. That’s the enterprise to which I personally am committed – and hence to which everything in my business would align.

As in the earlier post, it’s true that I need to ‘make money’ in order to work within that business space. But ‘making money’ is not the reason that I do the work – and in fact if ever I allow it to become ‘the reason why I work’, that’s the moment at which I would have allowed myself to disconnect from the shared-enterprise that underpins everything here, and hence also the moment at which my own business would start to fail. And that’s what we see so often around us: businesses that forget their ‘Why’, the deeper reason why they’re in business, will often shoot upward for a while as they grasp for the short-term gains of ‘grab the money and run’ – but it’s only a shining, delusory prelude to an inevitable, painful crash-and-burn.

Making sure that enterprises can fly, and continue to fly, is to me what enterprise-architecture is all about. That’s my ‘business-model’. What’s yours?

How do I make money, in my business? What’s my own business-model?

That was part of a follow-on to my previous post on ‘What do we mean by ‘business-architecture’?‘, in a great phone-conversation with a colleague last night, who challenged me to describe my own business-model and business-architecture.

To him, he said, a business-model is a kind of one-line summary about how a business makes money. (A commercial business, obviously: the business-model for a government department or non-profit is somewhat different, but it comes to much the same in the end, he said, because everyone is selling something… ) The Osterwalder-style concept of a ‘business-model’ is therefore not a business-model as such, he said, but more a model of how to action that business-model. The example he gave was of an airline: they make money by selling seats in aircraft flights, and earning more than they spend in doing so. The business-architecture then describes the detail of how they action that business-model.

Dunno that I would agree with that definition of ‘business-model’, but it is a definition, for sure, and clearly one that works for some business-architects. And a good challenge, too: how do I ‘make money’ in my own business?

The problem for me is that I just don’t see it that way. To me it’s all the wrong round: I’m more interested in the overall enterprise, and ‘making money’ is kind of peripheral to that – almost a distraction, in some ways, little more than a means to continue that engagement in the enterprise. Charles Handy put it well, in one of his books [approximate quote, from memory]:

Saying that we’re in business to ‘make money’ is like saying we play cricket to get a good batting average. It’s true we need a good batting-average to keep playing in first-class cricket, but the batting-average itself isn’t the purpose of the game.

To me, the enterprise comes first: in this case, the enterprise of enterprise-architecture, its relationships with all the subsidiary domain-architectures, and how best to get them all working together in real-world practice. That’s the real focus. So to be blunt, I don’t have good description of my own ‘business-model’, in my colleague’s sense. I write books and blog-posts, I work with people, I go to conferences, I think a lot about a lot of different things, try to make sense of how all those things work, how they could work together, and work better. That’s what I do. But the money side? It happens, I suppose – it’s not particularly important. In practice there’s always just enough to keep me going in doing all of that, and that’s really all that it needs to be. The simplest summary is that I’m always working, and occasionally someone pays me: that’s about it, really.

I know that to some people that’ll sound more than a bit odd, so perhaps I can best illustrate it by a poster I saw a few years ago, for an energy-company back in Australia:

One of those huge freeway billboards, showing a football stadium at night, brightly floodlit. Everyone’s intense on the game, going on just out-of shot.

Everyone, that is, except for one guy standing up, in the middle of the seating, dressed in yellow rain-slickers, facing the other way, staring up at the lights.

The caption: “We’re excited about electricity, even if you’re not”.

The point there being that, yes, most of the time, most people aren’t especially interested in electricity – they’re much more interested in the football, or some other equivalent. But – to paraphrase Chris Potts’ insightful aphorism again – when their experiences do touch on a need for electricity, it probably would be a good idea to talk with that company that says it’s “excited about electricity”. That’s the focus of that shared-enterprise: it may well be that the prospective client and the company share that enterprise for only a brief while, but they do share it in that moment – again, to paraphrase Chris, the company appears in the customer’s experiences because electricity is the current focus of their attention. And yes, no doubt there’ll be money-concerns appearing in there somewhere, somewhen: but electricity itself is what comes first here, in that shared-enterprise – and needs to come first, too.

In a sense, I’m much the same. I’m excited about enterprise-architecture, even if you’re not. Could well be kinda boring, to most people, most of the time: not as interesting as football, anyway – or ‘making money’, of course. Yet when your experiences do touch on enterprise-architecture, I’m probably a good person to come and talk with for a while. Simple as that, really.

So when would you want to come talk with someone who’s ‘excited about enterprise-architecture’? Well, I often describe myself as a ‘toolmaker’ – someone who creates custom-tools (if often of a more conceptual kind) for enterprise-architectures and the like. Most of my consultancy work tends not to be in developing an enterprise-architecture as such, but in helping internal teams develop their own enterprise-architectures – hence I work in practice-refresh, in helping a team lift themselves to the next level of architecture-maturity, and so on. Hence also describing all of that in books, in blog-posts, in conference-presentations – though if you want something custom-built for your own specific context, you’d more likely come to me direct. I deliberately don’t have much predefined product to ‘sell’, because so much of what I do needs to be custom-created for each specific context – though that again often makes it hard to say exactly what is that I do. And, yes, occasionally someone pays for doing this: and I’ll have to admit that that is good when that happens – if only because it tells me that they do value my work, in a monetary sense at least. Getting paid does help to keep me going in the game, of course: yet it isn’t why I’m in this game.

And that’s the simplest summary, really: the enterprise that I work in is enterprise-architecture; I’m always working; and occasionally someone pays me. It’s not complicated, not ‘clever’, it’s just what it is: nothing more than that. If you need to know my business-model, that’s it. Enough said?

So what’s your own business-model, then? Why do you do what you do?

Comments, perhaps?

Everyday Enterprise Architecture, the latest book in my Tetradian Enterprise Architecture series, is now available on Amazon:

• ‘Everyday Enterprise Architecture‘ on Amazon.com
• ‘Everyday Enterprise Architecture‘ on Amazon.co.uk

Note that Amazon have an unfortunate habit of listing print-on-demand books as ‘out of stock’: all that it means is that it takes at most one extra day for delivery.

The publisher-blurb is as follows:

All of architecture comes down to one simple idea: things work better when they work together, with clarity, with elegance, on purpose. Yet how do we express that ‘one idea’ in practice, within our organisations? With what results, and for what business-value? This book describes the down-to-earth detail of everyday enterprise architecture, to show what architects actually do to deliver value fast, across the entire enterprise.

Working step by step through a real ten-day architecture-project, this book explores the activities that underpin sensemaking, strategy, structures and solutions in the real-time turmoil of an enterprise-architect’s everyday work.

Topics covered include:

• • how to use enterprise-architecture to tackle executive-level business-problems
  • how to develop an agile architecture practice that can keep pace with the real-time pressures of the real business world
  • how to identify the business-reasons and business-value for each activity
  • how to thrive on the inherent uncertainties of the architecture process
  • how to use context-space maps to guide sensemaking and solution-design
  • how to apply architecture ideas and activities to describe what actually happens in a real enterprise-architecture project
  • how to enhance architectural skills, judgement and awareness, for continuous improvement across the enterprise and in the architecture itself

If you want your enterprise to flourish and prosper in the midst of relentless change, this is one book you’ll definitely need.

The book describes the actual thinking-processes and business-activities that typify real architecture-work at an enterprise-wide scope and scale. The structure of the book is a walk-through of a simultaneous pair of architecture projects, using an agile-style adaptation of the well-known TOGAF Architectural Development Method. Both of the projects need to be delivered in parallel, and fully completed within a ten-day period. One of the parallel projects focusses on ‘the architecture of architecture’; the other – adapted from real whole-of-enterprise architecture-consultancy assignments – tackles a serious business-strategy problem for a fictional bank.

The book also introduces a new sensemaking technique for enterprise-architectures, known as ‘context-space mapping’. The technique draws on systems-theory and complexity-theory to enable a much richer view of the architecture context, yet still deliver actionable results in tune with the timescales of the real business world.

The book-cover includes an illustration from the Dover Collection, indicating the kind of stress under which most enterprise-architects work! The aim is that the book should help to ease some of the overload, and make it easier to describe to others what it is that enterprise-architects actually do.

At present you can also download the full ebook version for free from the Tetradian Books website; note that this offer will only be available for a few more days, after which the the full ebook will be replaced by a  ’sample’ edition, containing contents and sample-chapters only.

Sounds a simple-enough question, no doubt, but seems to me that most nominal ‘enterprise architects’ have never even bothered to ask it. The usual answer would seem to be ‘the organization’, or worse, ‘the IT department’…

I’ve posted up on Slideshare a new slidedeck, “What is an enterprise?”, which aims to demonstrate a more realistic answer to the question. Nice and brief – only 10 slides.

Share and enjoy, perhaps?