Tom Graves / Tetradian

In case you hadn’t noticed, I’ve been kinda pouring out the posts on enterprise-architecture and the like, over the past few weeks or so… (A few people have complained about the overload, and probably with good reason, too! Oh well. My apologies, anyway.)

What’s happening for me is that it seems all of the work I’ve done on enterprise-architecture theory and practice over the past several years is suddenly coalescing into something big. It feels like I have a handle, or hook, or something, onto a radically different approach to how we do architecture-work in an enterprise-context, and in particular how we document that work and use that documentation to drive and support more-viable enterprise change.

The practical problem is that it’s all crashing around in my head, coming at me from all sorts of different metaphorical directions – metamodels, toolsets, methodologies, metaphors, the lot – and I’m having real difficulty getting it all down into a usable form. I tend to work solo most of the time, but in this case, frankly, it’s become way too large to handle all on my own. I can’t hold all of it in my head at once: it’s too big, too complex, needs way too many different skillsets and experiences, some of what I’m trying to do is likely way too complicated at present, and it’s almost certain that some is just plain wrong.

Hence, to quote the famous phrase, “I guess I could do with some help here…”

Please?

To give an idea of the scale of what I’m trying to bring together at present, there are around 300 posts on enterprise-architecture here on this website (excluding the weekly ‘A week in Tweets’ posts), of which perhaps half – maybe more – describe some new idea or concrete item of research on EA and related themes. There are eight finished full-size books on enterprise-architecture so far in the set, and at least another two or three under development at present. There’s another website just on metamodels, and another weblog on ‘big-picture’ business-themes. There are fragments of notes and experiments scattered around on seven different computers here, not to mention ten years’ worth of paper-notebooks and sketch-pads, and discussion-notes and emails from colleagues and conferences and the like over most of that time-period, too. And all of it seems to be coming together all at once. Yikes…

The real focus, as has come up in the most recent posts, seems to be about techniques and toolsets, to take any starting-point – such as a business-model in Business Model Canvas – and expand outward to tackle all of the whole-enterprise issues, including themes such as quality, security, sustainability, continuity and so on. Here are links to some of those posts:

• From business-model to enterprise-architecture
• Upwards and sideways from business-model
• Why business-model to enterprise-architecture?
• Where marketing meets enterprise-architecture
• The Enterprise Canvas – a really simple summary

There’s stuff about metamodels to move beyond ‘classic’ IT-centrism:

• Meanderings on metamodels
• More metamodel stuff
• Unravelling the anatomy of Archimate

There’s stuff about Agile in relation to enterprise-architecture – in particular a metaphor of ‘backbone’ that I still haven’t seen discussed elsewhere:

• Agility needs a backbone
• Architecting the enterprise backbone
• Tackling uniqueness in enterprise-architecture

There’s also a real need to address the human side of enterprise-architecture, including architecture-as-story and the almost-unacknowledged issue of narrative-knowledge (as opposed to IT-based information) in enterprise-architecture:

• Two points of view on (enterprise)-architecture
• Modelling people in enterprise-architecture
• People, power and enterprise-architecture
• The relationship is the asset
• Where have all the good skills gone?
• Who are your anti-clients?
• The enterprise is the story

And perhaps the real core of what’s happening for me now, around toolsets to cover that whole scope:

• The toolset-ecosystem
• Next-generation toolsets for enterprise-architecture?
• Enabling enterprise-architecture conversations

So: that’s the range of topics that I’m struggling with at the moment. Because it’s so huge, different parts of it keep drifting in and out of cognisance at any given time, so it’s difficult to maintain a sense of the whole. And the problem is that it does need to be tackled as a whole if we’re to avoid the same kind of trap that earlier forms of EA fell into, first with IT-centrism and process-centrism, and now all too often with business-centrism. The only thing that will work is to create something – a methodology, a metamodel, and a toolset-ecosystem, all linked together – that will fully support the awareness that in enterprise-architecture, everywhere and nowhere is ‘the centre’, all at the same time.

To be honest, I need help in all aspects of getting this down into usable form. But where I most need help is around the overall toolset(s). I think that the ideas are just about ready now for a proof-of-concept: but I doubt that I still have the technical skill to do much if any of it on my own. (The last significant software project I developed on my own was a wiki-based ‘engine’ that was used for a number of system-prototypes such as the SEMPER diagnostic: but it was back in the days of PHP4,and way too crude for todays’ standards.) To cover the whole toolset-ecosystem we’ll need whatever-it-is to compatible in some way or other with all of this scope:

• large cross-enterprise repository-based formal EA system (like Troux Metis)
• team-driven repository-based formal modelling system (like BizzDesign)
• single-user formal modelling system (like Sparx or ArchiTool)
• free-form desktop, notebook and/or web-based modelling system (like Visio) but can do round-trip to formal modelling
• tablet-style with gestural interface (like a cross between Prezi and BMTBox app on iPad)
• handheld, mostly browsing, but also able to feed back updates/suggestions

and

• paper-based, whiteboard, driven from book or ebook, etc

So: if you’re interested in ‘pushing the envelope’ for EA, you’re keen to work on some kind of collaborative project, and have some expertise in system-prototyping, user-experience design, workflow, graphics or anything of that kind, please get in touch with me? Because, yeah, I could do with some real help here…

Thanks in advance, anyway.

What is ‘Why?’ And why, anyway?

“Oh no, not again“, do I hear you cry? Actually, it’s not as bad as that: it’s not going to be yet another of those long tedious technical posts – honest!

(It is a sort-of technical question, I’ll admit. And, in the event, quite long. But interesting to just about everyone, I hope.)

What do we mean by ‘Why’? It’s a question that’s been puzzling me for quite a while – not least because enterprise-architecture is in some ways all about the shared ‘why‘ of an enterprise, and how we express that ‘Why’ in practice.

That kind of ‘Why’ is energising, and engaging. “Start with Why“, says Simon Sinek – and in terms of how things really happen in enterprise, he’s right. If we start with why, things do indeed happen, and usually happen well.

But then I look at the ‘Why’ column in Zachman: ‘Why’ is business-rules, it says. Gosh. Wow. Exciting… (To be honest, my heart just sinks. Doesn’t yours?) Business-rules? – seriously, where’s the fun in that? Kind of the exact opposite of engaging, really. Something’s gone missing there, clearly…

That’s not quite fair, of course. Up at the top, Zachman describes ‘Why’ as a list of Goals. Not quite as unexciting as business-rules. (But close…) Yet there’s something kinda odd here… kinda like a sudden sideways jump… different things all mixed up together in the same space…?

And I hit up against the same problem when working on the Enterprise Canvas concept, a year or so ago. The same Start with Why: the ‘vision’ for the extended-enterprise is the core ‘Why’ from which everything else flows. That ‘Why’ is emotive, it means something: for the right kind of ‘Why’, people are willing, even eager, to get out of bed way too early on a cold dark dreary workday morning. It matters. It sits above everything else. And yet, to make sense of the content and activities of the service that we’d represent on an Enterprise Canvas module, there’s that same dull boring ‘Why’ again: decisions, principles, rules and regulations, all that kind of stuff. Where’s the fun gone? How come we’ve lost the why from the Why?

I’ve been bouncing up against an answer on this in several previous posts over the past while, such as one about principles in enterprise-architecture, and another on the relationship between architecture, design and implementation. But perhaps a better answer came up over the past couple of days, when trying to unravel the anatomy of Archimate and, in particular, struggling to make sense of the split between what in Archimate they call Intentional Concepts versus Extensional Concepts.

Intentional Concepts are, as the name suggests, about intent. Extensional Concepts are about what we do with that intent – about how we extend that intent out into real-world practice. In Archimate, Intentional Concepts are entities such as Value, Meaning and Reason. And the important point is that these are viewed as separate from ‘the action’. Yet down in the details of that ‘the action’, we again come across another kind of ‘reasons’ – all those business-rules and so on. (Archimate doesn’t model any of that as yet, but that’s another story.) So again we’ve got this kind of sideways jump: ‘Why’ is above everything, as Intent; yet it’s also just another part of that ‘everything’, as Extension, the ways things work together.

The obvious answer: we’re dealing with two different kinds of ‘Why’. Or two different sides of the same ‘Why’, perhaps.

One side of Why creates a question: literally, it starts a ’quest’. For most of us, that’s the exciting bit.

The other side of Why is the answer to the question, the end of the quest. That was the question, here’s the answer: The Decision. End of story. For most of us, that’s when the fun ends: a sense of relief, perhaps, that there’s no more need to quest, but also, well, no more need to quest… Final. That’s it. Full Stop. (or Period, if you speak the US version of English). An ending, that somehow ends up in a bunch of rules, with No Questions Allowed any more. A Why To End All Whys.

Kind of like the braces round a mathematical function: a=func(x,y) and all that. The opening-brace ( begins the question: what’s x? what’s y? what do we do with them? – exciting, new, gosh, wow! And then we hit the closing-brace ) that ends the question: its kind of ‘nothing more to say’, really. We have the answer, the decision. Nothing more to do. Oh. Oh well. (Except that in much of maths, and in computing too, we have parentheses within parentheses within parentheses: q=some(func(x,y), also(y,z, andalso(b,c))) – quests within quests! Fun within more fun – hooray! )

So we do have two different kinds of ‘Why’ – and they go into different places in our architecture.

One kind of ‘Why’ – the question, the ‘(‘ – goes above the Zachman space, goes above the Enterprise Canvas, goes into Archimate as intention. Think of it as a row above everything, or a backplane, or something like that: whichever way we view it, it pervades everything.

The other kind of ‘Why’ – the ‘)’, the decision – goes into the Zachman space as just another column, goes into Archimate as extension. Each decision is specific, explicit: it literally cuts off other choices in that context. We can connect it to things, show how it affects other things, but it doesn’t pervade everything in the way that the question does.

In that sense, it does make sense to put them in different places. (And also – very important – not to forget the intention. Zachman ignores it, or loses it somehow in its strange sideways jump; Archimate all but abandons it, when it squeezes all of its Intentional Concepts into the literal meaninglessness of Passive Structure; and Business Model Canvas doesn’t even bother, but seemingly assumes that the only ‘Why’ that matters is ‘How do we make money?’ The ‘questing Why’ is literally emotive, the source of all motivation: if we don’t explicitly include it in our enterprise models, we’ve just shut out any reason for anyone to be engaged in our whatever-it-is. Perhaps not a wise mistake…?)

In another sense, though, it’s still the same ‘Why’. Just different faces – or phases – of the same quest. That’s where so much of the confusion comes, because often where we place it is more about how we choose to look at it than anything else. Looking ‘downward’, we see a stream of decisions: “because so-and-so… therefore… therefore… therefore…”. Looking upward, we see a stream of reasons: “because… because… because…” – ultimately ending up in the the unquestionable ‘Because!’ of the enterprise-vision or whatever. (I tend to place only that ultimate ‘Because!’ and its immediate implied-values as that uppermost layer of the enterprise-model; everything else ends up at various levels of that Extensional side-column of ‘Why’.) The Knowledge Genes structure also describes this Janus-faced relationship well, though in a different way: move leftward towards the question of Why, rightwards towards the decisions of How. The same ‘Why’, and yet different; a different ‘Why’, and yet the same.

Two kinds of ‘Why’.

That are also the same ‘Why’.

Now why is that, I wonder…?

Was showing a colleague one of my favourite small books yesterday: Matthew Frederick’s 101 Things I Learned In Architecture School. Briefly flicking through the two-page spreads, one caught my eye. Seems so apposite to enterprise-architecture and the like that it’s worth reproducing here in its entirety:

Two points of view on architecture

ARCHITECTURE IS AN EXERCISE IN TRUTH. A proper building is responsible to universal knowledge and is wholly honest in the expression of its functions and materials.

ARCHITECTURE IS AN EXERCISE IN NARRATIVE. Architecture is a vehicle for the telling of stories, a canvas for relaying societal myths, a stage for the theater of everyday life.

‘Classic’ enterprise-architectures would lean toward the former point of view, I suppose. It’s certainly true that structure and function are key areas of focus, and the best do indeed express a real honesty and ‘responsibility to universal knowledge’.

Me, I’ll admit I lean more towards the latter point of view: my work does include exploration of structure – and a lot of it – but my real focus is on the enterprise as co-created story. That’s one of the reasons why I find the existing EA toolsets so frustrating: what I want is something that can capture the stories as well as the structure, and link them all together to extend and enhance the overall enterprise story.

It’s really important to keep these two points of view in balance in our architecture practice. And many other points of view too, of course.

No particular point being made here: just thought it was well worth sharing, is all.

Comments, anyone?

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?

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?

Oh not, not again… looks like the Open Group members are about to muddy the enterprise-architecture pool once more, this time around business-architecture… Please, please, we desperately do not need another taxonomy-disaster like the infamous ‘four architectures’ of the ADM: please can we get it right this time? Please can we keep it simple instead?

Yes, I know I’m probably over-reacting again, but this was the set of tweets from the current Open Group conference in Austin that triggered this off, including a reference to something new from Open Group apparently called the Business Architecture Method Framework:

• LarsHouge: Could it be a good idea to include an information architect in the work related to the Business Architecture Method Framework? #ogaus
• LarsHouge: The BA definition was good, but it seems like the Method Framework is less mature, ex. a clear link to the BMM stuff. #ogaus #entarch
• systemsflow: Interesting #bizarch Q&A comment: Biz arch is as much about connections between orgs as about the orgs themselves. #ogaus #stillparsing
• systemsflow: Another comment in the #bizarch track. Let’s avoid EA landgrabbing and competing with MBA-type biz strategy field. #ogaus
• systemsflow: Interesting #bizarch debate during Q&A.  Does #EA = #bizarch + #techarch?  Or does #bizarch include technology as well? #ogaus
• systemsflow: Q: What do biz leaders expect from #bizarch?   A: Nothing, because they don’t know what it is.  (Because we can’t tell them!) #ogaus
• visualmodeling: IBM’s Kevin Daley: A well-defined biz arch covers strategy, technology, & operations domains + governs their intersection. #ogaus

Kris Meukens and Pat Ferdinandi gave good answers to the ‘MBA’ question:

• krismeukens: RT @systemsflow avoid #entarch landgrabbing & competing w MBA-type #biz strategy #bizarch  #ogaus < circular rather than linear causality
• thoughtrans: UGH! Are you sure those are business architects? Or are they MBAs who … because they have an MBA are considered a business architect? (sorry…that’s my current rant on certifications)

But I’ll admit that some of this worries me a lot. For example, how can it not be obvious to everyone that connections between organisations must be a central theme in business-architecture, just as it is in enterprise-architectures? And whilst I haven’t seen ‘the Definition’, I would definitely agree with @systemsflow here: we should long since have gone past any question about “does #bizarch include technology as well?” The short answer, of course, is ‘No’: but the fact that people above are still talking about ‘technology and operations domains’ as if they’re included parts of business-architecture suggests very strongly that there’s still way too much confusion between the distinct roles of enterprise-architecture, business-architecture and all the other domain-architectures that we work with in business…

I’m sorry to have to reiterate this, but it needs to be understood everyone that whilst the TOGAF ADM does work well for IT-architectures, it has a number of fundamental flaws that mean that it should not be used ‘as-is’ beyond that scope. (I’ve described in several places how we can adapt it for use beyond an IT-specific scope: although quite a few people do use those extensions now, it’s still not yet part of the ‘official’ standard.) The most important flaws are the fixed ‘four-architectures’ of Phases B, C and D in the ADM – business, applications, data, IT-infrastructure – and the way in which it treats ‘business-architecture’ as a scrambled, undifferentiated, unintelligible mess of ‘anything not-IT that might affect IT’,with little if any connection to business as such. And the blunt fact is that Open Group is an IT-standards body: that’s its reason to exist, to “make standards work” in the realm of “boundaryless information-sharing” – but not necessarily anything else. It is very good at what it does, but it is not an architecture-body as such, especially not for outside of the relatively narrow domain of IT: and that fact is becoming all too evident these days. So I’m very, very wary of any ‘definition’ of business-architecture that might come from Open Group.

Instead, could we perhaps keep it much, much simpler? Please?

To do this, let’s go back to first principles,using the words themselves, and nothing more. (I’m using English here, but the same principle works just as well, if not better, in most other languages.)

Architecture: it’s about structure, creating structures that people use. Hence any definition we develop about architectures is going to be something about structure, and about people. (Technology enables architecture, but not is architecture: a rather important distinction…)

Enterprise: it’s not a business, it’s a commitment. It’s about emotion, feeling; about ‘the animal spirits of the entrepreneur’, and so on. In practice, at a collective level, it’s about how people come together to share their aims, and ways to achieve those shared aims. Hence enterprise-architecture is about the structures that people use to achieve their aims. Enterprise provides the ‘Why’ for what we do and how we do it.

Business is part of that: people do business with each other as a way to achieve their respective aims. Hence business-architecture is about the structures that people use to do business with each other, in support of their aims. Markets are obvious examples of structures that provide common space to do business; the law of contract is another kind of structure in that space; likewise exchange-mechanisms such as fiat-currency (money) and credit-cards, and social structures such as the ‘investor/beneficiary’ model that underpins so many commercial organisations. For an organisation, we could also say that its business-architecture is the architecture of ‘the business of the business’. And since it’s about how we achieve aims, clearly it comes under the overall umbrella of enterprise-architecture.

Security is about feeling safe. Hence, in an organisational sense, security architecture is about the structures that people use in order to feel safe whilst achieving their aims. For an organisation, clearly that too is part of its enterprise-architecture, but it’s kind of orthogonal to its business-architecture. In other words, architectures are not necessarily ‘layered’ – as in TOGAF – but intersect as a kind of multi-layered, multi-faceted Venn diagram.

Brands denote stories; likewise for other symbols of that kind. Within an enterprise-architecture and a business-architecture – but not necessarily in a layered way, as such – a brand-architecture is about the structure of how stories link people with their aims. The enterprise is a story: brands and the like form a key part of how we create that story. Brand-architectures are primarily enclosed within our business-architecture, but may well extend beyond: from the perspective of the shared-enterprise, for example, we are custodians of a brand, not the ‘possessors’ of it.

Processes are descriptions of what we do, in what sequence, and so on. They’re the ‘How’ of what we do. So process-architecture is about the structures of how people organise what they do to achieve their aims. Notice that this doesn’t inherently specify the ‘How’ of the ‘how’: it could be people, IT, machines, or any combinations of those. (‘Application-architecture’ is a specific subset of process-architecture where the ‘how’ is hosted on IT.) If we take Chris Potts’ aphorism that “people don’t appear in our processes – we appear in their experiences”, then it should be obvious that ‘process’ is both within and beyond our own organisation: always part of the enterprise-architecture, but not always solely enclosed our own business-architecture. In other words, another intersecting, interdependent set within this overall Venn-diagram of architectures.

We could say much the same for information-architecture: it’s about how people structure the information that they need to achieve their aims. Infrastructure-architecture is more about the ‘What’ of the enterprise: it’s about the structural ‘things’ that people use to achieve their aims. And so on, and so on, for all the myriad of other domain-architectures under the overall enterprise-architecture umbrella that links all of those disparate domains together.

There’s nothing complicated about this. There’s also almost nothing specific to IT about it; or money either, for that matter. It’s always about people, and about structures that help people to achieve aims. That’s it.

So let’s keep it simple? Please?

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.]

Yep, it’s red-rag time, folks…  Sometimes I really do despair of ‘enterprise’-architecture that completely fails to understand the difference between enterprise and organisation, or that mistakes the concerns of a single stakeholder group for the aims of the enterprise as a whole…

This came up yet again at the current Open Group conference in Austin. At least these days Open Group and TOGAF are making determined efforts to break out of the old IT-centric box, but unfortunately seem to be leaping straight into the next dead-end disaster-area, namely ‘business-centrism’. And that’s illustrated all too well in one of the tweets that floated up from the conference space:

• systemsflow: Business Architecture: can’t every business be boiled down to one use case name: Make Money? Drill down from there #ogaus

This came from an unnamed tweeter [update: his name's Ben Sommer - apologies, Ben ] at a company called Systems Flow Inc, whose Twitter summary – “We are a boutique IT consulting firm obsessed with perfecting the design and delivery of enterprise and solution architecture” – does kind of imply the all-too-usual misplaced IT-centrism. Not much about business-architecture, anyway. To which, well, yes, I fulminated once again:

• tetradian: RT @systemsflow: “can’t every business be boiled down to one use case: Make Money?” - no, it can’t: this is exactly what not to do for #entarch / #bizarch…

The response was a kind of brief acknowledgement that yes, it is possible that there might be a few rare business-models that are not solely focussed on money:

• systemsflow: forgot govmn’t: Win Mission

But to to me that still completely misses the point. In essence, it tries to assert that the enterprise-beneficiaries in effect are ‘the enterprise’ – ignoring every other player in the enterprise. (See the later part of this post and also here for an explanation of the enterprise-role of ‘beneficiary’.) To be blunt, this not only seems startling ignorant – in the literal sense of the word – but also represents an almost certain guarantee of failure of enterprise-architecture and business-architecture, delivering a model of the enterprise that in practice is so misleading and so incomplete as to be worse than useless. Hence, again, another explosion from me:

• tetradian: ‘make money’ / ‘win mission’ etc are subsidiary #entarch aims for specific stakeholders: understand whole-enterprise first! // we develop #entarch for an organisation, but about whole-enterprise – are not the same! http://slidesha.re/8wWNSq#ogaus

The reply didn’t look at that at all, but could perhaps be described as a variation on the theme of “it’s all the conference’s fault, honest”:

• systemsflow: theme for today is ‘benefit bottom line w/EA = succeed’

The reason I got cross about this – again – was that there was no questioning about what a ‘bottom-line’ might be: instead, it’s just assumed that it’s always and only about money. Which, to again be blunt, indicates some serious problems in the architecture – because in architecture-practice we must not and dare not allow any assumption to go unchallenged. And as architects we also need to ask some serious questions about way the various priorities are brought into balance within the enterprise – questions that clearly are not being asked if the only ‘bottom-line’ in focus is a monetary one. (I often wonder whether, as in so-called ‘economics’, the main reason why there’s so much focus on a monetary ‘bottom-line’ is because money is the easiest item to count? – in other words, the real problem is a particularly unimaginative form of laziness?) Anyway, another annoyed tweet from me:

• tetradian: systemsflow: “theme for today is ‘benefit bottom line w/EA = succeed’” – hmm. indicates limited model of how enterprise works…? #ogaus

To which there wasn’t a reply. (And fair enough: I admit I do perhaps go on at people a bit too much about this. Oh well. ) Joseph Gaus did join it at this point, though:

• JWGaus: @tetradian @systemsflow #entarch there are too many nuances of ‘make money’, the next level of detail is needed.  Too generic to be useful. // define vision and principles for how to ‘make money’ and define enterprise structure to that. // summarize higher than your vision and principles and you’ve lost your enterprise.
• tetradian: RT @JWGaus: define vision / principles for how to ‘make money’ , define enterprise structure to that. >wrong way round?http://bit.ly/9zU9J

In fact I’d got it wrong there in my fulminating. Joseph was in fact agreeing, but – as he said in another tweet – the 140-character limit on tweets meant that the meaning of what he was aiming say ended up compressed just that bit too much. The SystemsFlow tweeter did come back in again at this point, though:

• systemsflow: MT @jwgaus @tetradian #ogaus #entarch too many nuances of ‘make money’ to be useful // agree, the level at which all businesses are same
• tetradian: @systemsflow:  ’make money’..”agree, the level at which all businesses are same” – whole point is they’re not the same… #ogaus #entarch

To which no doubt quite a few folks would say “Yeah… so what?” Why does any of this matter, anyway? And anyway, if we talk about anything other than the (financial) bottom-line, that’ll get us fired, won’t it?

The blunt answer is it’s more that, as enterprise-architects, and even as business-architects, if we don’t talk about a lot more than that single ‘special’ bottom-line, we darn well ought to be fired, because we wouldn’t be doing our jobs properly. Again, this comes back to that difference between organisation and enterprise. It’s true that the organisation pays our wages or consultancy-fees, and we’ll usually develop an architecture for and on behalf of an organisation; but the architecture we develop needs to be about the enterprise – the extended-enterprise or ‘ecosystem’ in which the organisation operates, and which defines the larger-scope strategic context for the organisation.

If we equate ‘the enterprise’ with the organisation, we have no means to describe any of the context for the organisation; and we also shut out any awareness of the reasons why other people out there in the extended-enterprise would need or even want to engage with the organisation. And doing that would also shut out any awareness of the anti-client space, which usually represents some serious kurtosis-risks for the whole organisation.

Which means that we would be missing much if not most of the information we need in order to describe how we arrive at that beloved ‘bottom-line’.

Which would not be much of an architecture, to be honest.

Not one that would be much practical use, anyway.

Which is why I rant and rage about this so much – because the usual obsessive and exclusive focus on ‘the bottom-line’ actually destroys the potential value of enterprise-architecture, and in turn damages the entire enterprise-architecture profession itself. Oops…

[An aside: an even bigger 'Oops...' is the 'shareholder-only' model of US corporate law, which to just about every other country either looks like insanity, a structure for organised theft on a massive scale, or both. The notion that 'the shareholders' are the sole 'possessors' of the entire enterprise is, frankly, anachronistic and absurd - and that's putting it politely... For example, given that most of the so-called 'assets' of most corporations these days reside in people's heads, saying that the shareholders 'possess' those assets means that they also claim to 'possess' exclusive 'rights' to those people's lives - and there could be some very interesting challenges against that assertion in terms of the US Constitution, let alone anything else. Hmm... As a very minimum, enterprise-architects need to take a view of the enterprise such as that in German-style corporate law, which insists that the views of all stakeholders need to be taken into account in the organisation's structure and its more nuanced 'bottom-line'.]

Again, why does any of this matter, you might ask? – what’s the point? The reason why it’s not “yet another pointless ivory-tower quibbling-game” - and why it’s actually a foundational issue for enterprise-architecture and business-architecture alike – is well explained in a tweet from respected enterprise-architect Sally Bean:

• Cybersal: @tetradian @systemsflow The negative consequences of focusing on bottom line ahead of everything else http://bit.ly/oYCEiE#entarch #bizarch #ogaus

The link points to an insightful article in the British newspaper The Guardian, reporting on the current farrago around illegal phone-hacking – described as apparently ‘on an industrial scale’ – by the international Murdoch news-group. Why did they do it? Because the hacking supported their policy of tabloid sensationalism, which fed into their bottom-line. Why did they not think about any of the consequences of this, to others and, eventually, to themselves? Because they were focussed only on the financial bottom-line – so much so that they ignored all of the extended-enterprise context that could hit their bottom-line from so-called ‘left-field’. The only thing that mattered was the bottom-line, this financial year, this quarter, today, now. They built up a culture in which no-one could question the absolute and unrelenting primacy of that short-term bottom-line. In other words, they created a culture and architecture that, in the longer-term, was guaranteed to fail. Not clever…

As that Guardian article shows, Enron did exactly the same. Likewise the inanities of the banks that led directly to the ‘global financial crash’. Likewise the Ford Motor Company, with their infamous decisions around the design of the Ford Pinto. Likewise, for a somewhat different bottom-line, the NASA culture that led directly to the Challenger disaster. Likewise… likewise… likewise… the catalogue could go on, and on, and on.

To put it at its simplest, if we place the bottom-line as the first consideration – or, worse, the only consideration – then, at the very least, a lot of people are going to lose a lot of money, or more. It may well be that a lot of people lose their livelihoods, or even their lives. As enterprise-architects we have a professional responsibility to make sure that that doesn’t happen. And we would have neither right nor reason to call ourselves a profession unless we do take that responsibility seriously – for all of the organisation’s stakeholders. It’s as simple and as bald as that.

And that’s why the ‘bottom-line’ does not, cannot, in fact must not come first in enterprise-architecture.

That’s my view, anyway: your thoughts, perhaps?

Most of the Yabbies novel is made up of story-fragments that in principle could come together in any sequence: we make sense of them in whatever way we choose.

What follows is perhaps my favourite story-fragment, “Mishie’. (A gentle reminder that it’s fiction? ) A bit of context first, though. The fragment takes place perhaps thirty or forty years from now, some decades after one country has shifted from a ‘conventional’ possession-based economy to a responsibility-based (‘no-money’) economy. The latter is that ‘world’ that Mishie inhabits, has grown up in – and wants, very much, to see more of the world. A few terms: ‘vizzie’ is a ‘visitor’, someone from a different country; ‘GA’ and ‘garda’ are police, ‘tucker’ is a standard current Australianism for ‘food’; the language is basic English with a fair few adaptations over time, and a lot of local slang. The reference at the end to ‘that book we did in Year Nine’ is Ursula le Guin’s sci-fi masterpiece The Dispossessed. What happens in the story-fragment is a simple contrast of before, and after…

Over to you after the ‘Read more…’ link, anyway: have fun, I hope?

Read more…

All right, I admit it: my novel Yabbies doesn’t say much about real-life yabbies. In fact they only put in one cameo appearance in the whole book:

“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.”

The real yabby is a small Australian crayfish, a kind of miniature freshwater lobster. They’re common all over Australia, particularly in the south-east, and can frequently be found burrowing into the sides of a farm dam – hence their Latin name cherax destructor. They seem to come in all kinds of colours, from muddy brown to red to white to a really startling blue, such as this fairly large one at something close to actual size:

Yet what’s the connection to the book? Uh.. not much, to be honest. What’s now come out as the book first started out more than a dozen years ago as an idea about sustainability: namely, that we won’t be able to achieve any kind of sustainable economy unless we have a system of law that supports it – which we certainly don’t have at present. The working-title for the project was ‘Yet Another Book Idea’ – hence the acronym YABI. Which had a nice ring to it, and hence kind of stayed in the mind as ‘Yabbies’. Which is what the project has been called ever since. A bit unfair on real yabbies, and yabby-farmers and the like, perhaps, but there ’tis.

The idea of story-fragments that could assembled in any order came on quite early in project – in fact the first form in which it surfaced was as an interactive website in which people could make up their own story and add their own story-fragments to build a richer picture of the YABI ‘world’. (This was in the days before social-media, so it never really went anywhere: perhaps it might be worth-while having another go at recreating that website somewhen soon?) Later on, I tried doing it as a screenplay: it worked quite well as a story, but with so many characters in so many cameos it would almost certainly be too complicated an expensive to produce as a conventional film-type story. (But it might work well with current transmedia – another avenue to explore, perhaps.) All sorts of other frames I’ve tried out over the years: one version had technical notes attached to each story-fragment, another split it into separate story-streams for distinct audiences, and so on. But this version will do for now? – enough to get the story-ideas out there, anyway.

Its real aim, I guess, is to get some pretty challenging ideas out there in a more palatable form – hence packaging it as fiction. The ideas behind it, though, are not fiction at all: they’re real issues that somehow, collectively, we must all face, and definitely sooner rather than later. Make of it what you will, perhaps?

And the yabbies themselves? Yes, they’re strange little creatures, “all in their own world at the bottom of the dam”. Feeding on whatever falls down from the surface, making sense as best they can. Linking that across to my more usual ‘world’ of enterprise-architectures and the like, that’s kind of what we do every day, isn’t it? So I kind of like yabbies as a metaphor for ourselves…