Tom Graves

Several people asked me to cross-post to other ‘economics’ sites the previous post on ‘Whuffie’ and currencies‘. I wasn’t comfortable doing so without editing-out the comments about the ‘Ready? Fire! Aim…’ syndrome, which were specific to the conversations to which that post referred: hence the re-work in this post here. I’ve also taken the opportunity to extend some parts, to link it more strongly to my ‘day-job’ of enterprise-architecture.

So: what can we learn if we tackle economics as enterprise-architecture? In other words, as if it was just another exercise in whole-of-enterprise architecture, the same as we would do for any large organisation (such as described in my book ‘Doing Enterprise-Architecture‘)? After all, ‘the economy’ is just another enterprise – it happens to be at a very large scale, but the exact same principles should apply.

(This’ll be another long one, hence I’ll place a ‘Read more…’ link here.)

Read more…

Spent much of the past couple of days getting overly-involved in two great threads on Venessa Miemis‘ ‘Emergent by Design‘ blog:

• Social Capital is not the same as Whuffie
• What could the future of money look like?

The first thread started with a very necessary attempt to distinguish between social-capital and reputation-based ‘currencies’ such as Cory Doctorow’s imaginary ‘Whuffie‘ (as described in his sci-fi novel “Down and Out in the Magic Kingdom” – the ‘magic kingdom’ being Disneyland, of course ). The key distinction that Venessa drew – and I think she’s right – is that social-capital is collective, a ‘network effect’ of the social context, whereas reputation is an attribute within the frame of that social-network, typically attached or attributed to the individual: in other words, they’re not the same, and should definitely not be treated as being the same.

This lead to the second thread, about ‘the future of money’, because much of the discussion in the ‘Whuffie’ thread was about the supposed need for some kind of ‘alternative currency’. (Clearly some people in the thread had hoped that ‘Whuffie’ would be it, but despite the efforts of well-meant initiatives such as The Whuffie Bank, it became evident quite quickly that it wouldn’t and couldn’t work in a ‘currency-like’ way.) There was – and at present, still is – a lot of discussion about various ‘currency-like’ proposals, such as TimeBanks, ITEX cashless payment, ‘Quids’ alternate-currency, and so on.

But what I found immensely frustrating was that almost none of them were thinking in true economic terms – and I wasn’t very popular for pointing out this unfortunate fact. Instead of enquiring what an economy is, what it needs to do, what purpose it serves, and so on – what would seem to be essential first-principles concerns about the context – they’d all assumed automatically, without question, that some kind of currency was ‘the answer’, and hence rushed off to create it. In other words, exactly the same mistake as far too many IT-folks: “here’s the solution – how can we force your problem to fit it?”

Ready? Fire!!! … aim…?

oops…

Yeah… really frustrating…

No-one with any sense would doubt that there are serious problems with the present ‘money-economy’ – not so much ’serious problems’ as ‘close to catastrophic failure’, in fact. Everyone in that conversation recognised this – which is why they were pushing so hard for alternatives. But the catch was that none of the alternatives actually resolved the core reasons why a money-economy won’t work; most of the proposed ’solutions’ not only replicated those problems, but actually made some of them worse. What was so frustrating was that in each case it took no more than a couple of minutes’ analysis not only to show that it wouldn’t work, but why it wouldn’t work. Yet no-one, it seemed, wanted to hear this: instead, off they want, charging off down their respective blind-alleys in the blind certainty that they’d found ‘the solution’.

What’s wrong with money, then? Short answer is: a lot. To give just a few examples:

• It only deals with point-to-point transactions, not network-effects – especially at a societal level.
• It’s designed to work with ‘alienable’ physical objects, but now no longer has any actual anchor in the real world – instead, we have literally trillions of supposed ‘money’ in imaginary ‘derivatives’ sloshing around the globe.
• It’s very easy to ‘game’ via artificially-constructed price/value mismatches.
• The implied ‘gravitation’ structure of money-based capital means that it tends to create ‘winner-takes-all’ accumulations – exacerbating social imbalances, often in the extreme, requiring separate action to try to redress the balance.
• Attempts to link ‘intellectual property’ into the money-system have resulted in a system which purports to match finite ‘alienable’ entities (physical ‘things’) with potentially-infinite ‘non-alienable’ entities (information) – which by definition cannot balance.
• Many organisations – particularly banks – are legally ‘entitled’ to invent money from nowhere, in effect assigning themselves an ever-increasing share of the society’s resources.
• A currency, by definition, relies on trust in the institutions that manage that currency, which in this case is the banks – yet much of that trust has been lost, and at present remains at an all-time low (hence the strong societal interest in options for ‘alternative currencies’).
• There are no built-in mechanisms to manage assignment of resources to those ‘outside’ of the monetary exchange-system (particularly children, parents, elderly, disabled and their carers, but also artists, scientists, thinkers, futurists, ‘creatives’ of any kind) – these stakeholders can only be served by ‘external’ mechanisms such as taxation (which are clunky and kludge-ridden at best), or by forcing them to do work within the money-economy (which means that their actual needed work can no longer be done).
• There is a very strong tendency towards short-termism.
• There is a very strong tendency to try to force everything into a crude, ludicrously-simplistic ‘double-entry life-keeping’.
• There is a very strong tendency to assume that ‘value’ exists only in monetary terms, as ‘valuations’ of ‘resources’ – hence, for example, a forest supposedly has no value until it is cut down, a mountain has no value until mined for its minerals, and so on.
• There is a very strong tendency to assume that anything which cannot be counted and ‘valued’ in monetary terms either does not matter or does not exist.

The societal impacts of these problems are rapidly approaching catastrophic levels. Yet none of the proposed ‘alternative currencies’ tackle more than a minute fraction of that list: most offer at best a localised kludge that might address a couple of issues whilst creating several more.

Let’s be blunt about this: the present system does not work. It actually never has – and that’s not surprising, because it was only ever intended to deal with point-to-point ‘trade’-transactions between fairly large groups (tribes, communities etc), hence it’s bit unfair to expect it to be able to run the entirety of an economy. But to create something that does work, we do need to go right back up to the level of the entire economy, and work our way back down from there. Which, yes, might – might – include some kind of ‘currency’ to tackle specific types of transactions: but not as the core of the economy itself.

This is actually no different from any other whole-of-enterprise architecture. (The only distinction is that it’s an ‘enterprise’ at the scale of an entire society, but that’s all.) So we would use the same overall approach:

• Who (and/or what) are the stakeholders in this enterprise?
• What are the core values? What is ‘value’ in this context? What is valued, and by whom? In other words, what determines ‘appropriate’ in this enterprise?
• What are the assets, functions, locations, events, capabilities and decisions within this enterprise? – in other words, the resources of the enterprise that need to be managed, distributed, shared and used in the most appropriate manner.
• What are the value-propositions that this enterprise needs to offer to and with its stakeholders?
• What mechanisms and responsibilities would be needed to create, deliver and monitor those value-propositions?
• What governance would be needed to ensure that all activities within the enterprise are optimised to be ‘on purpose’?
• …and so on.

To me, every attempt at a currency will inherently fail because it cannot take network-effects into account: by its nature, a currency is a mechanism for governance of point-to-point transactions, without any direct means to link to whole-of-system impacts. So I honestly believe that all of these attempts at ‘alternative currencies’ are a waste of time: we should be far better served by putting the same effort into understanding how an economy actually works.

And the key to that, to my mind, comes down to perhaps the scariest fact of all: there are no rights. ‘Rights’ are a social fiction; but the mutual, interlocking responsibilities that underpin those purported ‘rights’ are a social reality. If we want those purported ‘rights’, where we need to start is with creating a better understanding the ways in which those real responsibilities need to interlock: a focus on ‘rights’, like a focus on ‘currency’, is at best an unhelpful distraction from this requirement.

Where this gets gets scarier still is that our entire present economic model is based on a concept of ‘right of possession’ – hence a ‘right to personal property’. But there are no rights: only responsibilities are real. And in a network, there is no ‘personal’: only the network is real. Right at the fundamentals of economics, ‘personal property’ is just another fiction – and a very dangerous fiction at that. Yet personal responsibilities for societal resources – the appropriate management, maintenance and use of those resources – are real. And as with ‘rights’, those interlocking responsibilities result in something that looks almost exactly the same as ‘personal property’ – but we now know how we get there, via those responsibilities.

If we turn it this way round, we end up with something that looks very similar to what we have at present: but it resolves all of the structural flaws of a ‘money-type’ economy, and we also know exactly how we get there.

Once we know that that’s what we need to aim for, then we can start talking about ‘intermediate currencies’ and the rest, as part of a transitional ‘roadmap’ towards that more workable model. But those ‘alternative currencies’ are only an intermediate step, and we don’t start from there.

That’s what would change these sad attempts at ‘Ready? Fire! Aim…’ into a more viable ‘Ready? Aim? Fire!’ – and rekindle the fire in our social economy.

Another week, another month, and it’s back to the usual collection of Tweets and links. Usual layout, after the usual ‘Read more…’ link.

Read more…

(This series of posts explores a concept of ‘context-space’ which in part draws on a categorisation immortalised in a certain well-known diagram. It must be emphasised that this is not about ’That Welsh Framework‘ (aka twf) which that diagram illustrates: for details on twf, please contact this company. I apologise for these absurd aliases, but regrettably their necessity has been forced upon us by others.)

We seem to be iterating steadily towards a full description of what I’ve termed context-space mapping (as a more permanent name than the temporary label ‘tinc‘). For example, there’s been some very useful discussion on the previous post, especially by enterprise-architects Paul Jansen and Sally Bean. Paul Jansen followed this up with another Tweet:

@tetradian May the ‘chaotic approach’ be the key to #tinc? http://bit.ly/amJa1o

In fact this leads to what is probably the fundamental difference between twf and context-space mapping (aka tinc): the role of the Chaotic domain. This particularly applies in terms of the respective views of repeatability within the context.

In the hope of preventing yet more repercussions, I won’t say anything about twf’s approach at this point, other than to express my opinion that, in the terms of context-space mapping, its focus is primarily on the Complex domain, which in turn leads to an emphasis on contexts that are ‘partly-repeatable’ in highly complex ‘unordered’ ways.

Context-space mapping, however, needs to cover all repeatability-types. As twf’s proponent indicates, the Simple domain of presumed-repeatability is covered by Taylorism et al.; the Complicated domain of analysed-repeatability by hard-Systems Thinking and the like; and the Complex by twf and so on. But there’s so far been little or nothing to cover the Chaotic domain of ‘barely-repeatable’ events and processes. So in practice it’s likely that that’s where whole-of-scope techniques such as context-space mapping will have the most impact.

The central theme in the Chaotic domain of practice is low- to zero-repeatability: some part(s) of the practice cannot be repeated, either because the conditions have changed – including the awareness and experience of the person doing the work. Conventional ’scientific-analysis’ approaches (Complicated-domain) rely on repeatability, so they’re actually not all that much use in the Chaotic components of any real-world task – in fact will often be misleading because they provide an illusion of predictability. In a way, the same is true of many Complex-domain techniques: they give us a much more reliable picture of an overall uncertain context, but we can’t reliably apply that in reverse to tell us what to do for a specific ‘market-of-one’, such as a specific medical diagnosis.

Ability to engage appropriately in the Chaotic-domain in this sense is almost a definition of skill. It’s also a key component of almost all knowledge-work – which is why this concern is coming much more to the fore, as knowledge-work becomes an increasingly important part of the overall economy.

At the business-process level, one of the key figures is Sigurd Rinde, whose concept of ‘barely-repeatable processes’ is the focus for his Thingamy business-process-execution software. The whole point of Thingamy is that the processes themselves are made up as they go along, by the people doing the work, expressing and applying their expertise. Underneath this, however, is a consistent Simple structure that records every decision, every artefact, every transfer of responsibility – which makes it possible to create any required reports from the process, including conventional statistical analysis. The result is nicely summarised on Sig’s other website, 30megs.com – so-called from his tag-line “Here’s 30 Megs. Now go run Germany”, which in principle is entirely feasible with this kind of decision-support/decision-tracking software. Sig is not alone in this, of course – for example, Stafford Beer developed something similar that in effect ran the entire economy of Chile for a while, way back in the early 1970s – but Thingamy is probably the best example of a software package available today that is designed for true Chaotic-domain processes.

Context-space mapping is part of what needs to happen before we settle on any technique or tool such as Thingamy. It’s about mapping the options available to us, and the decisions that we make within ’solution-space’, as part of an overall process of sensemaking in order to arrive at appropriate actions for the context. One of the key points in this is an awareness that we are part of the context, part of the ’solution’: in the classic Chaotic-domain sense, there is a boundary, and there is no boundary, always in the same moment.

We always start from ‘reality’ – that which in twf is termed the ‘disorder’ domain. (Everything does in fact take place within that domain: any purported subdivisions – such as Simple, Chaotic and suchlike – are sensemaking-abstractions that we place onto that domain, but are not actually ‘real’ as such.) From there, we would move into some kind of recursive OODA loop (Observe/Orient/Decide/Act), where sensemaking itself forms one or more of the earliest iterations. In those terms, context-space mapping would typically proceed as follows:

• Observe: What is ‘the context’ here?
• Orient: How do I make sense of what I’m seeing?
  1. What parts of the context appear to be unique (Chaotic), unordered or ‘wicked-problem’ (Complex), complicated but repeatable (Complicated) or universal (Simple)? Using that categorisation, map out the ‘problem-space’.
  2. Given that categorisation, what cross-maps would be useful for sensemaking?
     Note: There are an infinite number of cross-maps that could be used: some examples shown in this series include:
     • here: repeatability and action-tactics; domains and tetradian asset-dimensions; time versus focus; Jungian domains
     • here: twf tactics and types of practice; timescale versus ‘bindedness’; development of embodied ‘best-practice’
     • here: repeatability and ‘truth’; marketing versus sales; the ‘plan / do / check / act’ cycle
     • here: ISO-9000 quality-model; skill-levels; automated versus manual processes; asset-types; data, information, knowledge, wisdom
     • here: cause/effect relationships; decision-mode, timescale and level of abstraction
     • here: nature of boundaries between domains
     • here: phases of matter
  3. Using the categorisations from the cross-maps, what available tools and techniques are ’situated’ in what regions of the maps’ ’solution-space’? What can we learn from this?
• Decide: Given what I have learned from sensemaking, what should be my ‘action-plan’?
  1. Select from the available tools/techniques.
  2. Decide on a plan as to how, why, when, where, by whom, with what, and in what order each of the selected tools or techniques should be used.
• Act:  What am I doing as I am doing, and what do I see as I am doing?
  1. Enact the desired action.
  2. Apply the same overall OODA-loop to the action taken – recursively, where appropriate – for review, further sensemaking, decision and action.
• Repeat as appropriate.

(Some people might suggest that this kind of OODA-loop fits more within a twf-style Complex-domain mode than Chaotic-domain. True, there are important similarities, such as the shared focus on ‘unorder’ versus the Complicated/Simple notion of ‘order’. But the key distinction is that this acts on a single, individual, specific context rather than a Complex-domain collective – and is often also much closer to real-time than most Complex-domain decision-making.)

The above is a start towards how we would use context-space mapping, anyway. I’ll leave it there for now: any constructive comments, ideas and suggestions would be most welcome, as usual – over to you?

Previous posts in this series:

• Complexity, chaos and enterprise-architecture
• More on chaos and Cynefin
• Alternatives to the ‘Cynefin’ term, please?
• Solution-space: beyond Cynefin?
• On meta-methodology
• Using ‘Cynefin-like’ cross-maps
• More ‘Cynefin-like’ cross-maps
• And more ‘Cynefin-like’ cross-maps
• More on meta-methodology
• ‘tinc’ – a Temporary Inconvenience
• Context-space mapping and enterprise-architecture

Related:

• ‘Two Cryptic conversations‘

This one starts with a note from Belgian enterprise-architect Kris Meukens:

I couldn’t agree more with your post last month on “Architecture is non-functional“, and appreciated it very much.

However, the case is most often made for “system” architecture. With the right arguments – as also my experience has proven – that case can be made convincing to business people. But as soon as one tries to translate the same case to the less tangible “enterprise” architecture, I have been experiencing a lot more difficulty, although I am convinced it translates well.

I was wondering if you have any thoughts on this and/or you could help me on this one, which I consider pretty fundamental to enterprise architecture.

There are at least two different ways you could use to tackle this, depending on the context and who you’re talking with.

One is to take the same approach as Richard Veryard describes in his blog-post on ‘So-Called Non-Functional Requirements‘. In IT architecture, the functions are often relatively straightforward, and wouldn’t change all that much between different implementations. But some of the ‘non-functional’ requirements can demand huge differences in system-design, and will themselves demand different supporting-functionality: consider a system for a low-security context (store-directory for a shopping-mall) compared to a high-security-context (funds-transfer in ATM in a shopping-mall), or a low-bandwidth informational system versus high-bandwidth transactional system versus medical-imaging system for use in remote conditions with unreliable power-supplies. As Richard says:

The architect needs to worry about those ['non-functional'] requirements that have major structural implications, and can mostly leave the functional requirements to the business analysts and developers.

So the same applies to an organisation: it’s relatively easy to plug in new functionality or features into organisation-level systems (which is why projects so often suffer from ’scope-creep’ or even rampant ‘feature-itis’), but changes to ‘non-functional’ themes such as safety, quality, environmental management and interpersonal communication may well demand a fundamental re-think right the way through the entire organisation. In effect, the ‘non-functional’ determines much if not most of the ‘functional’ – especially when we take it right up to the whole-of-enterprise level and view the overall vision and values of the extended-enterprise as the foundational ‘non-functional requirements’ for the business as a whole.

Hence the second approach to this, which is to draw a distinction between organisation and enterprise.

The crucial distinction is that an organisation is bounded by rules and responsibilities, whereas an enterprise is bounded by shared commitment – in effect, by principles and values.

Each organisation exists within the scope of a broader ‘extended-enterprise’: its suppliers, partners, customers, prospects, overall environment and so on. (For more on that, see ‘What is an enterprise?‘) Without that relationship between organisation and enterprise, the organisation literally has no purpose: or, to put it the other way round, the enterprise is the organisation’s purpose. Which, in terms of what we’re discussing here, means that the foundational ‘non-functional requirements’ for an organisation are defined by its enclosing enterprise.

We then link that back to Richard Veryard’s point, that the ‘non-functional’ requirements create more fundamental demands than the ‘functional’ ones.

To do this, we first need to note that organisations form natural hierarchies, and likewise enterprises also form their own natural hierarchies. (Enterprises actually form intersecting ‘communities of interest’, or ‘communities of commitment’, and occasionally organisations do so too; but for these purposes it’s easier to think of them as simple nested hierarchies.) For example, ‘the business’ is often viewed as a single ‘the organisation’, encompassing a structure of business-units consisting of departments made up of sub-departments which consist of work-teams and so on, each with their own explicit rules and responsibilities. And sometimes the boundaries of an enterprise will coincide with an organisation-boundary: for example, each of those ’sub-organisations’ is also an enterprise in its own right – a ‘community of commitment’.

Hence the somewhat misleading notion that ‘the organisation’ is also ‘the enterprise’. It’s misleading because of that point above: the foundational requirements for an organisation (whole-organisation, business-unit, department, work-team etc – whatever its level in the business-hierarchy) are defined by the enclosing enterprise for the respective organisation – not by the organisation itself. If ‘the enterprise’ has the same boundaries as ‘the organisation’, the foundational requirements in effect become self-referential – literally detached from the outside world. Which is not a good idea…

[Update: the term 'Step' below may be misleading, especially for some non-native English speakers - my apologies. Here it's not a step within a process, for example, but means a pace or step outward from the boundary of the organisation. If in doubt, use 'Layer' as an alternative to 'Step'.]

In practice the foundational requirements need to be drawn from an enterprise at least three steps larger than the organisation in scope:

• Step 1: partners and suppliers, including outsource and contract relationships
• Step 2: clients and prospects, including ex-clients and anti-clients
• Step 3: non-clients and community, including government and broader environment

Again, these are nested – so for an IT department, for example, Step 1 might include HR, equipment providers and outsourced help-desk, Step 2 would be the business-contacts, project-managers and general users of the department’s services, and Step 3 would include overall business policy and governance. In a production environment, Step 1 is the incoming side of the immediate supply-chain, Step 2 is the outgoing side and the schedulers, and Step 3 is production policy. At the whole-organisation level, the steps are as described above: partners and suppliers, clients and prospects, and non-clients and community.

Step 1 largely defines your costs; Step 2 largely defines your income. The relationships between them are relatively simple to model – such as with the Business Model Canvas. Hence many business-planners stop there, because those transactions do make straightforward business sense: but that’s a dangerous mistake, because as you’ll see from each of the examples above, governing policy is primarily derived from the commitments and values of Step 3 – not Steps 1 or 2.

In ISO-9000 terms, policy is derived from ‘vision’ – the guiding commitments, principles and values of the enclosing enterprise. In effect, policy is ‘non-functional requirements’ that determine response to change. And as ISO-9000 explains, it is indeed possible to run an organisation for a while without high-level guiding policy: but as soon as there’s any significant change, you’ll run that organisation straight into the ground – which, again, is not a good idea. So as enterprise architects, we need to understand and model all the way out to Step 3, in order to identify the overall requirements for the ’system’ of any type of ‘organisation’ at any level within the organisational hierarchy.

To summarise in perhaps over-simplified form:

• Step 0 (’the organisation’) is the boundary of the ’system’ in scope
• Step 1 (’partners and suppliers’) describes functional requirements for input-side for that system
• Step 2 (’clients and prospects’) describes functional requirements for output-side for that system
• Step 3 (’non-clients and community’) describes non-functional requirements for overall governance for that system

To paraphrase Richard Veryard again, we can mostly leave the functional requirements in Step 1 and Step 2 to the business analysts and developers; the architect needs to worry most about “those ['non-functional'] requirements that have major structural implications” that arise from Step 3.

So perhaps use this as a way to explain to others the criticality of ‘non-functional’ requirements at “the less tangible ‘enterprise’ level” – in other words, how far out we need to model ‘enterprise’ in order to identify the real requirements for ‘the enterprise’ that is the organisation as a whole.

Hope this is useful, anyway – and as usual, constructive comments / suggestions etc would be gratefully received!

Several people have asked me for more information about the book I’m writing at present, ‘The Business Anarchist‘, so here’s a quick summary of the themes and structure.

Who or what is a ‘business-anarchist‘? Anyone who works with inherent uncertainty in business in an intentional, disciplined way – working with the uncertainty rather than trying to ‘control’ it. Often it’s not so much a person as part of a business-role – a necessary part of that business-role. (Most of the examples in the book will come from my own field of whole-of- enterprise architecture, but the same principles apply in just about every other type of business-role.)

Why ‘anarchist’? Anarchy is about working without rules, working ‘outside the box’. When ‘business as usual’ breaks down, a disciplined form of anarchy is probably the only way through to something new that works well in the new business context.

‘Kiddies-anarchy’ and real anarchy: Anarchy has had a very bad press in the past, mainly because of what I describe as ‘kiddies-anarchy’ – an overdose of presumed ‘rights’ without responsibilities, especially in terms of causing disruption and destruction without any awareness or respect of the consequences for anyone else. Real anarchy is very different – arguably the most difficult of all political forms, because there are no easy rules to fall back on or to blame. Some entire organisations have been run on anarchic lines – the Quakers have done so for centuries – and even some businesses – such as Ricardo Semler’s Semco Group – but here we’re mainly focussing on an often-unnoticed yet everyday set of roles and responsibilities within an ordinary, everyday type of business.

What kind of business? Any business, and any type of business – for-profit, not-for-profit, government or social – from a huge global conglomerate right down to the local bridge-club or the school parent/teacher association.

Business-analyst and business-anarchist: Business-analysts deal with certainty and predictability: they refine the figures, crunch the numbers, track the trends. When your business world is reasonably stable, you need your analysts to help you optimise efficiency and maximise returns. But when your business world is not certain, not predictable, that’s when you’ll need your anarchists. And you’ll need your anarchists then, too. Your analysts can only tell you how to do more of the same, better – which is good, of course, in its own context, but it doesn’t help when what you really need to do is something different.

What’s different about how business-anarchists work? The quickest one-line answer is that analysts rely on rules and algorithms; anarchists rely on guidelines and principles.

What principles should business-anarchists rely on? Obviously this varies from one context to another, but from my work in whole-of-enterprise architecture the three most important design-principles seem to be these:

• There are no rules;
• There are no rights; and
• Money doesn’t matter.

These three principles, and a fourth follow-on principle, Always enhance adaptability, provide the overall structure for the book.

There are no rules: Rules provide a spurious sense of certainty that can let us down badly when our business-world changes around us. The real world is much messier and more complex than any system of rules that we could devise. Hence at times it’s necessary to start off from the assumption and expectation that there are no rules: instead, we have to rewrite the rule-book, by working back to the core-principles from which the rules originally arose. A simple everyday business-example of this is embedded in the ISO-9000 standard on quality-systems:  work-instructions provide ‘the rules’ that we need for real-time practice and process, but when the world changes, we need to rewrite the work-instructions by working upward to procedure, policy and, if necessary, overall vision.

There are no rights: ‘Rights’ are an important social fiction, but as with rules, they don’t actually exist in the real world, and in themselves they tell us almost nothing about how to create the conditions that such ‘rights’ would require. In practice, apparent ‘rights’ arise from mutual, interlocking responsibilities – so it’s those responsibilities, and not the purported ‘rights’, that are where we need to start. This has important implications for business-architecture and enterprise-architecture that will be explored in some depth in the book – for example, we need to ask serious questions about “What do shareholders own?” if they possess all the ‘rights’ for the business but without any real responsibilities.

Money doesn’t matter: Money is important for every business, of course, especially in a commercial context – but as with rules or ‘rights’, it’s not the place where we need to start. Money is also only one small part of the overall economy in which the business operates: reputation, trust, attention and respect all need to exist before any money will be placed on the table. And if we state – or show – that we’re only interested in ‘making money’ from our customers and community, why would anyone want to engage with us? As with other ‘rights’, money is solely a social fiction, and profit is an outcome of being ‘on purpose’ to values: to achieve the profits that we may desire, we first need to start from values, with a values-architecture that describes how we engage with everyone within the extended-enterprise of the business.

Always enhance adaptability: Change is the only certainty: we therefore need to design for that fact. Mistaken notions about rules, rights and money often serve only to slow us down, placing the business at risk as the world changes around us. This sections of the book explores how to embed the ‘business-anarchist’ principles into everyday business-practice, especially in business-architecture and enterprise-architecture.

—

More details to follow over the next few days, including book-cover, cover-blurb, ISBN numbers and so on. Publication-date is fixed as late-April, so I need to keep moving!

(This series of posts explores a concept of ‘problem-space’ versus ’solution-space’ which in part demonstrates alternative uses and interpretations of the Simple / Complicated / Complex / Chaotic categorisation originally described in the Cynefin diagram. It must be emphasised that this is not about the Cynefin Framework; for details on Cynefin, please contact Cognitive Edge.)

This post represents yet another attempt to describe certain fundamental differences in approach from twf (aka ‘That Welsh Framework‘ – so-called because we’re no longer allowed to use its official name at all) and to find an alternative term that might reduce the ongoing friction in that quarter.

To do this, we need to go right back to first-principles: the core concept of context-space, which eventually leads us to context-space mapping.

(Another long-ish post: more after the ‘Read more…’ link.)

Read more…

Not actually ‘cryptic’ in the usual sense – just that the cafe in the Crypt below the church-cum-concert-hall of St Martins-in-the-Fields is a useful and pleasant place for meetings in the middle of London. (It’s just off Trafalgar Square, and a very long time since it was literally “in the fields”, next to the garden of the convent that is now known as Covent Garden.)

Anyway, two great conversations yesterday with Chris Potts and Sally Bean on enterprise-architecture and an assortment of other related topics. More details after the ‘Read more…’ link.

Read more…

As can be seen from the comments to the previous post, the demands that we find another name for this framework-that-has-no-name have become increasingly strident.

Various urgent online and in-person conversations have ensued. The only directly-meaningful name we came up with was ‘solution-space mapping‘, but several people have disagreed with that, and in any case there is already a well-established usage of the acronym ‘SSM’ in this context, namely Checkland et al’s Soft Systems Methodology.

There’s a long-standing software tradition of assigning arbitrary names as working-titles for projects. Someone suggested ‘Eric’, which was a name they’d used when developing an IT system for an airline, and which reminded me of a nonsense-phrase I’ve often used, that “anything unknown is called Fred”.

But even an arbitrary proper-name seems too concrete for something that is necessarily abstract and, as a name, necessarily temporary. We couldn’t think of any meaningful acronym, so we played with sounds for a while, until someone came up with this:

tinc

It’s the sound of the penny dropping, as someone ‘gets it’; the small bright sound that the imaginary light-bulb makes at the ‘Aha!’ moment in solution-space. A quick, recursive echo of a sound. And it’s also a contraction of what this name really is: a temporary inconvenience.

Since it’s clear we’re not even allowed to use the name of the framework that this isn’t in order to describe what it isn’t, we would have to apply the same process to give us a temporary name for that. So we might note that in Welsh the plosive sound ‘toof!’ would be spelt as twf, which should give us a relatively-safe acronym for That Welsh Framework. (’Twf‘ is also the name of the Welsh Language Board website, by the way – “Cymraeg o’r Crud, Two Languages from Day One”.)

So there we have it: tinc, for the framework, and twf, for the-framework-that-it-isn’t. A temporary inconvenience, but it’ll have to do for now.

(This series of posts explores alternate uses of the Simple/ Complicated / Complex / Chaotic categorisation originally described in the Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the Cynefin framework proper, please contact Cognitive Edge. The term ‘beyond-Cynefin’ is solely a placeholder to indicate this separation of concerns.)

Back to theory again – apologies… – following on from comments on the previous posts, especially ‘On meta-methodology‘.

The aim of this post is to try to create a bit more clarity around the notion of ‘problem-space’ versus ’solution-space’. To do this, I’ll draw on a variety of sources, ranging from dowsing to enterprise-architecture, Sigurd Rinde’s work on ‘barely-repeatable processes’, activity/response-models such as OODA and PDCA, and much more besides.

Will again be long, hence more after the ‘Read more…’ link.

Read more…