Tom Graves / Tetradian

An important email for me this morning, from management consultant Ray McKenzie, that’s triggered off a significant re-think on the role and label for one of the nine main cells in the Enterprise Canvas model:

While you labelled the bottom row of ‘Enterprise Canvas’ as Value, somehow as I read through the material I kept thinking ‘Governance’, not sure if this was your intent or just my imagination.

And yes, he’s right: of course it’s ‘Value-Governance’ – of course! Why on earth didn’t I see that before? I knew that ‘Management’ wasn’t right when I wrote it, but I couldn’t find the right alternative. Yet there it is, staring me right in the face: of course it’s ‘value-governance’! – in fact, given its role, at the intersection of ‘our value’ and ‘the past’, it really couldn’t be anything else. Using the term ‘value-management’ for that single cell gives it completely the wrong flavour – in fact that’s the main function of the ‘value-direction’ cell in the somewhat-external ‘guidance’ group, so it’s already covered elsewhere. Management is something that happens throughout the service, not just in one place – but it is fair enough to say that overall governance-activities for a service tend to be concentrated in one subdomain of that service, enacted via its own domain-specific roles.

Value-governance makes sense here in both directions on the Canvas’ grid. On the vertical ‘our value’ axis, ‘value-proposition’ deals mainly with what we will do (future); ‘value-creation’ is concerned with what we are doing (present); whilst ‘value-governance’ looks at what we will do, but perhaps even more at what we have done (past), to ensure that they match up correctly. And in the horizontal value-web axis, ‘value-governance’ sits on the backchannel – completions and the past – to hold the balance between what comes in as ‘value-return’ from the customer-side of transactions, and what goes out as ‘value-outlay’ on the supplier-side.

Hence duly-amended versions of the key diagrams – first, the ’service-cross’ version of the ‘brick’:

…and the ‘robot-chicken’:

Not many people use the shorthand two-letter codes for cells and flows, but these should change from VM to VG (for the cell-label), and XM to XG (for the flow-label). The XG flow now focusses primarily on matters relating to governance between the layers (rather than getting mixed up with overall management and direction, which should probably be associated more with the XD guidance-flow).

In all, this cleans up an inconsistency that had been bugging me for ages in the structure of the Canvas, but I hadn’t been able to see what was wrong or why. Hence, once again, many thanks to Ray McKenzie for this.

Another week, another twittering of Tweets and other connective coincidences of the … oh, whatever you want to call it. Usual categories, usual possibly-useful items, usual ‘Read more…’ link:

Read more…

One of the most essential tasks in enterprise-architecture is that of enabling conversations on architectural issues, with any groups of stakeholders, anywhere across the enterprise.

Our toolsets play an important role in those conversations. The right tool used in the right way can really help the conversation, help create new shared understandings across the silos and the specifics of each distinct discipline.

But the wrong tool – or even the right tool used in the wrong way – may instead act as a real barrier against awareness and understanding. Getting the balance right is critical to creating the clarity we need – yet the requirements, and the balance, are different for every type of architecture-conversation.

We’ve long had a good range of frameworks and toolsets for IT-oriented architectures. Some were aimed more at systems-development; others more at taxonomy and ontology and metamodel-development; others again at modelling dependencies across IT systems and ‘business/IT-alignment’; and yet others at requirements-traceability, governance and project-management. Yet they all had one thing in common: their whole focus was about precision, about certainty – because that’s what system design and development really needs.

But as enterprise-architecture at last begins to break out of the IT-centric box that it’s been trapped in for the past couple of decades, we start to hit up against some real limitations of those toolsets:

• most of the underlying metamodels and model-types are still very IT-centric
• user-interfaces are usually complicated, abstract, often intolerant of error, and in some cases even downright ‘user-hostile’
• most of the tools – especially at the high-end – are too expensive for general use
• diagramming is usually abstract (‘boxes and lines’) rather than ‘real-world’ (trucks, people, machines, servers, cables etc)
• support for versioning and for tentative ‘what-if’ experiments ranges from poor to non-existent
• none of the user-interfaces are well-suited for use in real-time exploratory conversations

There’s also still no common exchange-language to transfer architecture-information between the tools that we already have – and even when we get one, we’ll need it to go wider than that, anyway. A lot wider.

When we look at how we actually work with executives or process-designers or security-architects or the like, the tools we most often use at present are a whiteboard or a sketchbook – nothing else has the flexibility that we need. None of the existing tools allow us to play ‘what-if?’ as well as we can on a whiteboard; and the precise formal rigour of model-validation is far more of a hindrance than a help in this kind of work, where half the time we don’t even know what kinds of architectural-entities are involved – the whole point is that that’s what we’re aiming to find out!

But we still need some kind of toolset-help here: images on whiteboards and sketchbooks aren’t easy to share – I’ve often seen people simply photograph the results and pass the image-files around as ‘the model’ – whilst office tools such as Visio and Powerpoint give a spurious illusion that the results have been captured with enough rigour to be re-usable (which they’re not), and are usually too slow and cumbersome for an across-the-table discussion anyway.

So here’s our challenge: develop a toolset for the ‘conversations’ end of the enterprise-architecture spectrum – one that will work on laptops and netbooks, on the new tablet and touchpad systems, and preferably right down to smartphones as well.

It needs to be able to cover any aspect of enterprise-architecture – from business-models to skills to security to process to disaster-recovery to operations to knowledge-management to applications to service-management to IT-infrastructure to building-infrastructure and anything in between.

It needs to be able to adapt itself to the needs and worldviews and language of each of those groups of stakeholders – and provide some means of translation between each group, too.

It needs to be fast, easy to use, engaging, enjoyable, preferably tactile too – yet have a fully-structured methodology and metamodel behind it.

It needs to allow freeform development of models and diagrams – yet still be capable of linking to the formal rigour of the ‘top end’ systems.

Coming the other way, it needs to help us explain the structures and reference-models that we already have in our ‘top-end’ systems – and explain the reasoning behind those models, too – whilst still keeping people actively engaged in the conversation.

And more and more, architects are beginning to recognise that spurious certainty is a real risk for the enterprise – so this also toolset needs to help our stakeholders become more comfortable with uncertainty and change.

Working with a loose consortium of colleagues – including Adrian Campbell, Kevin Smith, Milan Guenther, Nigel Green and others – we’ve done a fair bit of work on this already:

• preliminary metamodels and file-structures
• probable user-interface workflows on tablet (mouse/stylus) and touchpad (finger) interfaces
• probable user-experience interactions in multi-stakeholder conversations
• some suggested methodologies
• some key features, such as AudioNote-style synchronised voice-recording and Prezi-style zooming ‘infinite’ workspace
• support for a broad user-extensible range of model-types – potentially-unlimited, including user-defined types
• support for indefinite nesting/layering of models and model-types
• support for freeform-drawing, notes, embedding of user-selected icons and images
• support for reports that enable us to describe some or all of the enterprise as a story

There’s a lot more to do to get this even to an alpha-release state in any format or platform; and whilst all of us, in the group so far, have ‘done our time’ in software-development and the like, none of us is sufficiently available (or, in my case at least, really up to the speed or quality needed) for professional-level app-development on current systems. So we’re going to need help to make this happen.

I for one would prefer to see this as an Open Source or at least freeware/shareware type of development, so as to get this out into as general a usage as possible. (As I see it, this kind of toolset should have many other applications outside of enterprise-architecture, such as in strategy-development, tactical planning etc.) But if some commercial developer wants to take it on, that would be fine too, as long as we can keep the final end-user cost down to app-levels (perhaps $10-30 at most) rather than the three-, four-, five- or even six-digit sums we sometimes see for other toolsets.

So: over to you. Any offers of help or advice? Any other comments or suggestions?

I fear I’ve overdone it this week – almost twice as many as usual. Still, that’s what I collected as the week’s Tweets and links, so here y’is, y’all. Usual categories, after the usual ‘Read more…’ link.

Read more…

Architects are designers too. Application-architecture designs link across an array of applications, process-architects design ways to link processes together, business-architects design business-models and their linkage into the everyday practices of the organisation. That much should be obvious, I would presume.

Yet in practice – and certainly as the scope widens – more and more of our actual day-to-day work consists of creating and enabling new conversations: architectural conversations between business and IT and anyone and everyone else in the overall enterprise. The ‘one idea’ of all architecture is that things work better when they work together, with efficiency, with clarity, on purpose: and to make that happen, we need to get people to talk with each other. Simple as that, really.

One practical problem we face is that the architecture tools that we have available to us at present are not that well-suited to that purpose. For some conversations, yes – but those tend to be the most technical of the conversations. For the ordinary-yet-important conversations with everyday stakeholders, we’re not well-served at all. And as we move more and more out of the purely technical domains and towards a true ‘architecture of the enterprise’, the more that gap is going to get in our way.

One tool to rule them all?

What we really need is something that’s probably impossible in practice: a single tool that will cover the whole spectrum from the loose, freehand sketching and storyboarding of architectural issues and requirements, all the way through to the tight rigour and discipline that we need in specifications for real-world design and implementation.

We also need that imaginary ‘one tool’ to cover another whole spectrum of usages, from centralised repositories and very large ’scorecard/analysis’ displays through to multi-screen desktops to single-screen laptops to tablets and touchpads right down to handhelds and smartphones.

The big, expensive enterprise-architecture toolsets such as System Architect or ARIS or Troux Metis tend to sit over in one corner of the matrix between those two spectra: they embody the formal rigour of software-, system- or process-design and simulation, and they need big repositories, big servers and big displays to deliver their best performance. These are also definitely not tools that should (or even can) be used by general users – a fact I know from painful first-hand experience of the months we had to spend tidying up the mess that our business-managers made of our repository after we’d foolishly allowed them to play with it for a single week…

Then there’s the mid-range: toolsets such as Avolution or BizzDesign Architect or Sparx Enterprise Architect, or Alfabet or Essential. All of these are well suited to laptops and other larger single-screen systems, and each tend to emphasise particular themes: metamodelling with Avolution or Essential, for example, or Archimate business/IT-alignment with BizzDesign or Sparx, or IT-infrastucture configuration with Alfabet. They all have some kind of internal repository, which in turn supports some kind of diagramming; but it’s not always easy to share – especially across a whole multi-organisation enterprise. And these are still tools for specialists – not something that we can use with everyday business-folk, as I discovered the hard way when I presented a set of BPMN diagrams at an executive-meeting…

Down in the far corner, though, there’s almost nothing: no usable toolsets for idea-thrashing with ops-staff, developers, executives and all the other myriad non-specialists. Office tools such as Powerpoint and Visio are just-about-okay for documentation after the event – though they provide little to no support for architecture-rigour at all – but they’re far too slow and cumbersome for real-time discussion. So it’s no surprise that for most architects I know, their most important tools are a whiteboard and a sketchpad – and not only do those provide no linkage to formal architecture-rigour, but it’s usual not even possible to record and share the results. Which means that we have almost nothing with which we can engage people in the architecture itself – in the discipline of the architecture.

But what would such a toolset look like? What aspects of architecture-discussions could it cover?

Enabling interactive conversations on architectures

One project that I’ve been involved in (as a member of its alpha-test team) is Alex Osterwalder’s iPad app for his Business Model Canvas framework – perhaps take a look at the videos on Alex’s post. That’s also a key reason why I developed the Enterprise Canvas concept, to extend the same basic idea to the whole-of-enterprise scope. And there’s also a swathe of iPad or smartphone apps that cover themes such as sketching or mindmapping or outlining or project-management, that do at least enable us to record in a form which can be stored and re-used later.

The real aim, though, is to get to some kind of toolset that is freeform enough to be used in live discussions, yet beneath the surface embeds at least some of the rigour needed for architecture-development. There are some great hints towards this in an article in HBR by Michael Schrage, ‘How Your Smartphone Will Transform Your Elevator Pitch‘, which are worth noting in some detail here:

… His [business-idea] was undeniably clever, but aspects of his business model weren’t clear to me. He had his elevator pitch answers down pat, but I wanted to learn more. Unprompted by me, Osman whipped out his smartphone and handed it over. I was watching a decent video clip illustrating his product’s features and functionality. I could tap to hear testimonials. I could tap to play with a simulation of the software. In a matter of moments, the device had transformed Osman from an entrepreneur I was having a conversation with to a guide and narrator of an interactive experience. My focus and attention alternated between what he said and what appeared onscreen. Sometimes he’d take, touch, and hand back the device; other times, I’d point to something onscreen and ask another question.

The object — and our interaction with it — became an intimate part of our conversation. We couldn’t have discussed either [his product] or his answers to my questions the same way without it. An idle part of me wondered how cool it would be if our conversation (and my questions) could be recorded and time-stamped along with what was appearing onscreen. Osman refused to allow his smartphone to decay into a sales tool or product pitch — although those elements were baked into the material — and instead used the device as a medium to both reinforce his conversation points and invite new questions and comments from me.

I can say without hesitation that this felt technically and interpersonally different from “laptop-on-the-table” presentations I’d experienced 1,000 times. We were standing up, drinking coffee, chatting, and taking turns holding, viewing, and manipulating this device. The kinesthetics, eye contact, questions, and interruptions revolved as much around the device as us. We would have been worse off without it.

And, further on in the article:

Elevator pitches are important. The ability to boil down the essence of your innovation into a tasty forty-second sound-bite remains essential. Only now, the pervasiveness, ubiquity, and visuality of mobile devices quantitatively and qualitatively changes the ecology of interpersonal interaction. It’s no longer about what you say and how you say it; it’s increasingly about what you hand over.

What do you hand over that transforms the conversation? What do you hand over that visually and interactively adds value to your spoken words? What do you hand over that complements and supplements your pitch? What do you hand over that invites and inspires the curiosity you want? What do you hand over that makes you more persuasive?

… “Hand-it-over” innovation pitches can be seamlessly slipped wherever your prospects desire. Indeed, an excellent measure of “hand-it-over” effectiveness is whether the person who you “hand-it-over” to actually asks you to send what they’ve been seeing and interacting with.

So let’s summarise some of the key themes there:

• it’s not a presentation, it’s an interaction – a two-way or multiway conversation
• the interaction is kinesthetic – it involves touch (ie. handling and interacting with the device) as well as listening and seeing
• if practicable, the interaction itself should be recorded, as an annotation on the original presentation
• if practicable, it should be possible that the whole interaction can be shared

Beyond the whiteboard

That’s what we need for that part of our enterprise-architecture work – a toolset that enables us to engage directly with our stakeholders. And it needs to go both ways, too: to take a model or diagram from the formal ‘big-system’ part of the toolset-spectrum and share it and discuss it; and also enable and capture discussions about requirements, about trade-offs, about different understandings and paradigms and worldviews and expectations and assumptions across all the myriad of different perspectives in the enterprise. Both ways. About anything – about any aspect of the architecture.

Which also means that we must have some kind of language to enable us to move information up and down through that spectrum, across different devices, different systems, different toolsets. (It seems very unlikely that one vendor will ever cover the whole range that we need – but the information itself must be able to move around in any form that we need, yet always anchored back to the formal rigour required by each architecture-domain.) So that’s another hurdle to cross, because no such language exists at present.

So, given all of this, how could we improve on the venerable whiteboard and sketchpad? How could or would we record that kind of interaction? And how can we support a form of diagramming that is as interactive and illustrative as a whiteboard-session, yet still enables the underlying rigour? The specialist EA toolsets may be too cumbersome for this kind of interactive use, but surely we can create something with more rigour than Powerpoint or Visio?

That’s our challenge here. Comments/suggestions, anyone?

In part this is a follow-on from the previous post on the fundamental flaws underlying all forms of currency, but it also has many implications for businesses, enterprise-architectures, societal models, corporate social responsibility and much else besides.

And don’t worry, I’ll aim to keep this one short(ish) [later: turns out it's another long one - sorry...] – though I’ll probably return to the theme quite a bit in subsequent posts.

The key point in the previous post was that no ‘alternative-currency’ would solve the socioeconomic problems that we currently face: the all-too-evident failures and failings of the money-economy are merely at the symptom level, and attempting to replace conventional state-issued currency with some other kind of home-grown alternative would be merely one more variant on the theme of ’shifting deckchairs on the Titanic‘.

Yet clearly we do need something that will enable us to operate the kind of global-scale exchanges that our current economic models allow – because without that, it’s obvious that the city-based cultures especially could quickly collapse into anarchy of the worst possible kind.

It might perhaps be a surprise that what I’m suggesting here as an alternative actually is anarchy – but anarchy only in a strict technical sense, and of a radically different form.

Let me explain.

In the previous post I hope I made it clear that there is no way in which a possession-based economy can be made sustainable. Therein lies the real economic problem: possession is a classic example of the antipattern that “for every complex problem there’s a least one clear, easily-understood wrong answer”.

Underpinning that ‘wrong answer’ is another even deeper ‘wrong answer’: the notion of rights. Possession is defined as a right – the right to personal property, and so on. (In British law it’s more subtle again, in that it’s actually defined as a right to exclude others from access to resources that they may need: as the 18th-century jurist William Blackstone put it, “that “sole and despotic dominion which one man claims and exercises over the external things of the world, in total exclusion of the right of any other individual in the universe”.) But there’s a catch – a very important catch. To paraphrase Margaret Mead:

Rights are a social fiction; responsibilities are a social fact.

More to the point, it’s probable that responsibilities are the ’social fact’ – that the structure of a society is actually an emergent property that arises from the intermeshing of mutual responsibilities. A society – and hence that society’s economics – arise from those mutual responsibilities. A society’s economics represent its recognised means and controls via which its available resources are shared, exchanged and used – and those ‘means and controls’ are, in effect, defined and circumscribed by mutual responsibilities.

You might ask “So where do rights come into this?” But that’s the whole point: they don’t. Rights don’t even exist in any real sense: they’re just a convenient social fiction, useful for some circumstances – as we’ll see in a moment – but dangerously misleading in others. And economics and purported ‘rights of possession’ are a good example of where the rights-discourse is indeed dangerously misleading – as all of us are discovering right now…

Read more…

Any competent observer of economics would acknowledge that the money-based model on which most current economics is based is in deep trouble right now: somewhere between seriously-dysfunctional and completely broken. Many of the purported key-metrics such as GDP and GNP don’t really tell us anything useful at all about the actual functioning of the economy: all they describe, really, is the potential tax-base, in monetary terms – and the distortions that this introduces into the economic picture are the direct cause of many economic problems. Banking and, especially, finance have moved so far from their functional roots that they’re now little more than engines for embezzlement on an almost unimaginable scale. And the preferred ’solution’ to the fact that many, many things cannot be meaningfully described in monetary terms is simply to declare that such things do not exist or, if they do, they cannot conceivably matter within the overall economy.

(I won’t give links for any of those assertions above: we’d be here all day. They’re all well-known and long-proven problems, as a few hours’ worth of careful web-searches will demonstrate all too clearly. Just take it as read for the moment that that’s so, because the details as such aren’t that relevant right here.)

Given that there’s a perceived problem with the ‘money-economy’, what can we do about it? Well, the usual ’solution’ – and I use that term advisedly – is to rush out and devise some form of alternative-currency. I’ve seen dozens of these so far, and apparently there are actually thousands of these projects, across a whole spectrum from simple barter to community-based currencies to time-based currencies. But they all have one thing in common: they won’t work.

Not just ‘won’t work’: they actually can’t work. They can’t solve the problems that we face.

No form of currency will satisfy all of the requirements for managing an economy, without requiring distortions to the economy itself that will render that economy non-viable or non-sustainable, especially over the longer term.

And there’s no way round that fact.

My apologies if that fact offends anyone, but it is indeed a fact. And refusing to face that fact is not going to help anyone. Sorry.

Read more…

One of those happily-bizarre conversations about enterprise-architecture that happens on Twitter from time to time.

It started with a Tweet from Jörgen Dalhberg (@greblhad), to which I duly threw in a lighthearted reply:

• greblhad: If your #entarch can not be illustrated in 3D using LEGO then you have a problem.
• tetradian: RT @greblhad: If your #entarch can not be illustrated in 3D using LEGO then you have a problem <does that include LEGO ‘people-figures’?

I’d presumed that Jörgen was being reasonably serious about it – as in fact he was, as will become clear later. But I was also fairly serious about it too, because a couple of years back the CTO at one of my clients had done a beautiful physical ‘demonstrator’ for her overall infrastructure/applications-architecture, built as a three-layer wooden jigsaw-puzzle, which she’d presented to the organisation’s executive. By making all the trade-offs and dependencies visible – and literally tangible – in this way, she’d finally given them a means to understand what was going in their systems, and what they needed to do to help her bring it into a more sustainable state.

So I’d seen how such models really do work in practice – and was a lot more inclined to take Jörgen at his word. But for various reasons, others perhaps weren’t, as the following Twitter-conversation shows:

• oscarberg: RT @greblhad: If your #entarch can not be illustrated in 3D using LEGO then you have a problem > Static view only. How show interactions?
• oscarberg: @tetradian @greblhad 3D LEGO is better suited to describe a physical architecture than for #entarch
• richardveryard: @oscarberg @tetradian @greblhad LEGO (even with people figures) shows momentary instantiation of an architecture, wrong level of abstraction
• tetradian: @richardveryard @oscarberg @greblhad yeah, true, but playing with those little LEGO-people is *fun*!
• oscarberg: @tetradian @richardveryard @greblhad  I play a lot with LEGO with my kids, but it doesn’t make it suited for describing #entarch
• greblhad: @tetradian @richardveryard @oscarberg you should all check out http://www.seriousplay.com/ that’s part of what has inspired me #entarch
• greblhad: @richardveryard @oscarberg @tetradian LEGO … wrong level of abstraction < all illustrations are momentary, still useful though
• oscarberg: @greblhad @richardveryard @tetradian  would agree 3D Lego can be used to describe certain aspects of an #entarch, but not complete
• greblhad: @oscarberg @richardveryard @tetradian  Oscar what aspects of an #entarch are you referring to as not possible to model with Lego?
• oscarberg: @greblhad @richardveryard @tetradian perhaps “not possible” is not what i mean, but rather “not usable” // a model is a communication tool. We need different ways to communicate different things
• greblhad: I am so sure any #entarch in production today could be expressed perfectly well in a Lego model, I’d probably bet a 100.000 GBP on it.
• jenshoffmann: @oscarberg @tetradian @greblhad we have succesfuly used LEGO #entarch modells in early stages to dev. a shared view of the stakeholders // you wouldn’t document/manage an #entarch with Lego, but as a tool for critical discussions.
• oscarberg: @greblhad @hypergogue original discussion was about describing entire #entarch with Lego. Lego as a comm tool is another question
• greblhad: @oscarberg @hypergogue original discussion was about describing  #entarch with Lego. < which is a one way of communicating intention
• oscarberg: @greblhad @hypergogue yes, but using one tool to communicate every aspect of an #entarch is unlikely to be effective
• greblhad: @oscarberg  @hypergogue yes, but using one tool to communicate every aspect of an #entarch is unlikely to be effective < I agree

There the conversation seemed to languish for a while, so whilst writing this I tossed in a request for more information:

• tetradian: .@greblhad would love to see some LEGO models of #entarch – even just for communication purposes – a blog-post w photo examples, please?

What I hadn’t realised, until following up the Serious Play link, is that this really is a serious part of the Lego domain, with serious registered-trademarks and all. Via a network of licensed facilitators they’ve in fact been running Serious Play workshops for the past five years or so – I remember now that I’d once heard of it somewhen, but had long since forgotten about it. But they’ve now (as of June 2010) opened it up as a kind of ‘open source’ toolset: take a look at the LEGO® Serious Play® Open Source page, for a download document describing the principles, and then perhaps take a wander round the website itself. Will admit I’m surprised, and impressed: ’serious play’ indeed.

No further information as yet from Jörgen or any of the others in that conversation - will post an update here if any comes past. Watch This Space?

Been having a fairly intense (but good ) discussion on the LinkedIn Enterprise Architecture group, about standard economics and its impact on enterprise architecture. This is one of the many side-threads popping up off Kevin Smith’s now long-running discussion on “EA is not the glue between IT and ‘The Business’, EA is the glue between strategy and execution”. I don’t know whether this set of posts from various participants will make much sense to anyone else, but it seems worthwhile to post it where others can see it if they wish.

(Note that I’ve done a small amount of editing of the original posts by trimming and snipping ['...'] and, in one case, concatenating posts from the same person. I believe I’ve kept the sense intact in each case, but if not, please let me know straight away? Thanks.)

For me, in this case, the start-point was a post by Harold ‘Hal’ Stull:

When in doubt I always think Econ 101. An organization manages three resources (capital, labor, and material) to produce a product. If a customer pays more for the product more than the value of the resources consumed, the company shows a profit for its risk and will continue operating. As an architect of any kind, I have to discover the “Who, what, when, how, where, and why” of the client’s operation and add something that may possibly increase the perceived value of the product to his customer or reduce the resources needed to produce it.

I also try to stay away from absolutes: Truth, Best, Optimum, Consistent, etc. I can do a whole lot with organizational and interface symantics. I would never say “ontology” in front of a client, but being able to work with higher abstractions helps me choose and squeeze value from tool kits. (But I see there is another thread for that topic).

As you’d probably guess, given some of the other posts on this weblog (such as ‘Economics: the worst term-hijack ever?’), I kind of jumped at Hal’s comment about ”When in doubt I always think Econ 101.”:

Hmm. That assumes that ‘Econ 101′ makes sense and works in the real world, which it doesn’t. That’s the problem.

You say: “An organization manages three resources (capital, labor, and material) to produce a product.”

The answer would be “Sort-of…”. More accurately, Econ 101 treats all of those items (including non-financial capital, such as conceptual and/or social capital) as ‘possessable objects’ that are the ‘property’ or ‘possession’ of an individual or of an organisation-as-corporate-person. Unfortunately this would take a long post to explain, but in essence the ‘possession’-based concept of economics is a parasitic overlay on the actual economy, which operates on mutual-responsibility rather than possession. The quickest summary is that Econ 101 is inherently dysfunctional and inherently unsustainable: so if we’re to build an enterprise-architecture that will work for an organisation, we need to focus on the responsibility-based economy behind the possession-based delusions of Econ 101, and not allow ourselves to be distracted by those delusions.

To give one very quick example, most conventional ‘business-models’ that I’ve seen assume a very simple Econ 101 market-sequence of:

attention (via advertising) > transaction (via sales) > profit

For enterprise-architecture, we need to deal with a much broader range (e.g. including non-active stakeholders [e.g. government, community, non-clients] and also anti-clients and others who are active participants but who are not involved in sales-transactions), and a much more complex market-sequence, such as:

reputation > trust > respect > attention > conversation > relationship > transaction [ > profit] > reputation > …

We also need to understand that ‘the enterprise’ is not the same as ‘the organisation’: an organisation is bounded by rules, roles and responsibilities (e.g. legal responsibilities), whereas an enterprise is bounded by vision, values and commitments (see my presentation ‘What is an enterprise?‘)

True, an organisation is a type of enterprise, but for most enterprise-architecture the relevant enterprise is typically at least three steps larger in scope than that of the organisation in scope. (We develop an architecture about an enterprise for an organisation.)

Using the assumptions of Econ 101 will guarantee that we will deliver an ‘enterprise’-architecture that will fail in the longer term. To build an architecture that works, we must think wider than that.

Read more…

Another week’s worth of Tweets and links – rather more than usual, this time. Same categories as usual, though, following the usual ‘More info…’ link:

Read more…