Tom Graves / Tetradian

Folks, we have an important issue on terminology that we need to address.

In two comments to my previous post, Dave Snowden has made it clear that he objects to any reference to the term ‘Cynefin‘ that does not conform exactly to his specification for that term.

This includes any usage of the term ‘Cynefin-categorization’, which I’ve been using in order to distinguish (and advise others to distinguish) the usage of the ‘Simple, Complicated, Complex, Chaotic’ category-set, from Cynefin-proper. Snowden has made it clear that the term ‘Cynefin-categorization’ is not acceptable for this or any other purpose.

We are reminded that Cynefin-proper is a sensemaking-framework, and that in general the term ‘Cynefin’ should not be used in relation to any form of categorisation. If the term is used to describe categories, that usage must include all five Cynefin categories, including the central domain of ‘Disorder’. Under no circumstances may it be used to indicate the four-item category-set of Simple, Complicated, Complex, Chaotic. We are also reminded that the Cynefin framework has a very specific graphic-format, and that the term ‘Cynefin’ should never be used in relation to a simple 2×2 matrix.

The practical problem is that the ‘Simple, Complicated, Complex, Chaotic’ category-set and its variants are in common use throughout the enterprise-architecture discipline and many others, and have been so for many years. Although I seem once again to have taken the brunt of Snowden’s ire on this, the reality is that a lot of people are using that type of category-set and describing it as ‘Cynefin’ – usually as a result of (mis)-reading the Cynefin page on Wikipedia. A lot of people – as in Nigel Green’s example – are using that type of category-set with a 2×2 matrix and describing as ‘Cynefin’, or ‘based on Cynefin’. It’s clear that we cannot and must not do this any more.

Obviously the full category-set ‘Simple, Complicated, Complex, Chaotic’ is too long for routine use, which is why many have used ‘Cynefin’ as a convenient shorthand. Again, we cannot and must not do this any more: hence we need an alternative shorthand term.

The obvious choice is the simple acronym: SCCC for Simple, Complicated, Complex, Chaotic. (It could be shortened to SC3, but I’d prefer not… )

Could we perhaps adopt this from now on?

Or does anyone have a better alternative? Suggestions, please?

— —

On a separate but related matter, Snowden’s comments to that post once again make clear his opinions on the (lack of) quality and value of my work, such as stating that the tools and techniques that I’ve developed for sensemaking and the like are inherently “invalid … in certain essential aspects”, and insinuating that the cross-map techniques for ‘context-space mapping’ described in my book Everyday Enterprise-Architecture and elsewhere should be dismissed as a ‘hash-up’.

Which, I’ll admit, does hurt: critique is important, and I do value genuine critique, but this feels more like wholesale destruction just for the dubious enjoyment of doing so… Oh well.

There’s no question Snowden is entitled to his opinion, of course. And I’d certainly agree that he’s forceful in asserting those opinions. But unlike some others, I do suffer from deep and persistent self-doubt, and I’ll admit that this has thrown me straight back into that space again, seriously doubting whether what I’ve been doing has any value to anyone at all…

So I’m asking for your honest advice in this: is Snowden’s opinion the right one here? Does my work have any value to you, or to any others that you know, in enterprise-architectures and elsewhere? Should I just accept his view that what I’m doing is valueless to everyone, and the implication that I really ought to give up and walk away from it all, to leave you and him and everyone else  in peace? Or if you consider that it does have any value, what can I do to make it better, and perhaps more resilient to the kind of dismissals and denigration that we see here and elsewhere?

Comments/suggestions? Over to you, if would?

Many thanks, anyway.

Architecture is non-functional.

I’ll bet that statement raised the blood-pressure a few notches for some folks, yes? Defensive? Irritated? Sarcastic? “Waddayamean, non-functional, hey?”

Good point, because ‘non-functional’ is not the same as ‘has no function’ – although it’s often misread that way…

The problem all stems from an arbitrary and amazingly unhelpful categorisation of project-requirements as either ‘functional’ or ‘non-functional’. In this case, ‘functional’ means ‘what the project/object/thing/whatever does‘, whilst ‘non-functional’ is a generalised grab-bag for any requirements about anything else at all. But because ‘functional’ implies ‘useful’, or ‘working’, whilst ‘non-functional’ kind of implies ‘not-useful’ or ‘not-working’, this categorisation means that so-called ‘non-functional’ requirements are often assigned a much lower priority, or even ignored altogether. Which is not wise, because ‘functional’ requirements only cover the ‘what’ and ‘how’ of a project – and usually only a subset of ‘what’ and ‘how’ at that. Everything else is probably classed as ‘non-functional’: when, where, who, how much, how well, how often, and so on – and ignoring those needs is not wise at all. (The one question that’s often missing from any list of requirements – ‘functional’ or ‘non-functional’ – is why: sometimes it seems that people automatically forget how to ask pertinent questions once ‘The Requirements’ have been defined…) Which is a worry – to say the least.

But there is another way to view the notion of ‘non-functional’ – an alternative term that much better describes the real meaning or purpose of those requirements, and the architecture role with it. I was reminded of this as I skimmed through the presentations at the the current Open Group Enterprise Architecture Practitioners conference in Seattle, and came across the following table in a presentation on ‘Business-Driven IT Strategy‘ by Sam Ishak of First Canadian Title:

The ‘role’ row caught my eye because the same ‘driver/navigator’ metaphor had been used by several people in yesterday’s discussion on strategy. But then I noticed the ‘responsibility’ row – and a light-bulb lit up in my head: “Govern the quality of the solution”. The project-manager deals with the ‘functional requirements’ for the project itself; the architect deals with all the other ‘non-functional requirements’, ensuring that the end-result is not merely efficient in a functional sense, but effective overall. The PM ensures that the end-result works, within the available time and budget; but the architect ensures that it is useful – which is not a trivial matter at all.

So a more general term for ‘non-functional’ is qualitative – ensuring that whatever-it-is not only works, but also does what we want, how, where, when, with whom and, especially, why we want it to do so. There’s not much point in any focus on function alone without also including those qualitative concerns.

Architecture is about quality. Architecture is ‘non-functional’ – and that is what is should be, because its purpose is to “govern the quality of the solution”.

So yes, architecture is indeed ‘non-functional’. But perhaps we ought to be more openly proud of that fact?

My post yesterday on “Annoyed at ‘Enterprise 2.0′” seemed to touch a nerve with quite a few folks – it’s had more responses and ‘twitter-play’ than all my other posts in the past month put together. But although there are some aspects that are specific to the ‘Enterprise 2.0′ term, there’s also a more general point that was the real focus of the post: that real dangers arise whenever terminology is ‘hijacked’ by any kind of special-interest group. The dangers are particularly serious when a ‘natural term’ for a domain is hijacked to describe only a subset of that domain, leaving no possible term to describe the remainder of the broader domain.

This is a huge problem for me professionally, because most of my work is about integration across broad domains. Whenever a term has been hijacked by a subset, all discussion of the domain is constrained into the discourse of that subset: it then becomes all but impossible not only to describe any real view of the whole domain, but also any interactions that occur only between other subsets of the domain. For my present work, two key examples are the terms ‘enterprise architecture’ and ‘enterprise 2.0′, and I’ll return to those later; but to illustrate the problem, and just how serious its impacts can be, I’ll use the example of another ‘term-hijack’: domestic violence.

To say that the domain is emotive and politicised is an understatement: I’m well aware that it’s very dangerous to hold any public opinions on this, especially if they run counter to current ‘political correctness’. But as it happens, I’ve been involved in aspects of the field for several decades, right back to the follow-ups to Erin Pizzey’s groundbreaking work, first published in 1974 as her book “Scream Quietly or the Neighbours Will Hear”. I was involved in a major review of the Duluth model for violence resolution, and part of my enterprise architecture work for a state-government department a couple of years back included review of provision of domestic-violence support-services. And throughout the field, the single most difficult problem – and the one that most actively hinders progress in resolving the issues – has been the impact of a term-hijack: the assertion that domestic violence is always and only about violence against women.

No-one doubts that violence against women is a serious matter. But it’s not the only form of violence in the domestic context, and the form usually portrayed as ‘domestic violence’ via the term-hijack – violent male partner against defenceless woman – is quite a small proportion of the whole: probably quite a bit less than ten percent, according to the few defensible statistics that we have. Which means that if – as required by the term-hijack – we focus all of our attention on that one subset, not only do we fail to address the ‘bigger picture’, but our interventions are extremely unlikely to work well. Yet we will be unable to see why our interventions don’t work, because the term-hijack prevents us from seeing any of the many ‘unintended consequences’ elsewhere in the domain.

(Recognise the parallels with IT-centric ‘enterprise architecture’ and ‘Enterprise 2.0′ yet? You should…)

In Britain, the term-hijack started soon after Pizzey first publicly presented her work on the first women’s shelter, Chiswick Women’s Aid, and was firmly in place well before the end of the decade. Pizzey herself was one of the few who fought against the hijack, pointing out that violence occurred in many forms in the home – for example, she showed that one of her main problems in the shelter was to stop women from taking their aggression out on their kids once the male partner had been removed from the context. But in one of the more shameful episodes in feminist history, she was publicly denigrated and aggressively silenced, and remains a pariah to much of ‘the sisterhood’ to this day.

Over much of the intervening decades, the term-hijack has been all but complete. The main domestic-violence legislation in the US is the Violence Against Women Act: it does not acknowledge any other form of violence in the home. Many US states still operate mandatory-arrest policies in which, in any police call-out to a inter-gender ‘domestic’, the man – and only the man – is to be arrested and charged with assault, automatically, without regard to context or to whom (if anyone) is injured, even if this is contrary to evidence. The Duluth model defines violence in all its forms as an exclusively ‘male’ characteristic, and explicitly rejects any notion that any woman can ever be violent; yet despite these and many other all-too-obvious flaws, this supposed ‘standard’ is now mandatory for domestic-violence resolution in the majority of US states, and in many countries elsewhere.

Partly as a result of the hijack, much of the so-called ‘research’ in this field is highly politicised, and frequently of very poor quality indeed: in one colleague’s meta-analysis of research in Australia, not a single study was found that had a defensible methodology – most failed at even at the most basic levels, such as egregious errors in arithmetic(!), circular reasoning, or arbitrary extrapolation from very small self-selected sub-groups. The few defensible studies that cover the whole scope are consistent in several key themes: for example, the lifetime risk for both sexes is about 10% (a figure which has been stable for at least four decades); males make up somewhere between 20% to 40% or more of the emergency-room DV case-load, and up to 70% of the ‘severe injury’ class; the most violent class of relationship (by a huge margin) is lesbian; and even women themselves self-report that they initiate violence in the home significantly more often than men. (Apologies for absence of links here: I dumped most of my references on this when I pulled out of the field some years back, but I should be able to dig ‘em up again if anyone insists.) There are also many different forms of violence and abuse, with non-physical forms usually more damaging than physical in the longer term; and there are many different transaction-types such as partner male-female, partner female-male, codependent interactions, sibling-sibling, parent-child, child-parent, adult-elder, elder-adult and even human-animal. There’s also great deal of ‘pass the parcel’ violence and abuse, jumping around from one form and one person to another. So to resolve anything, we have to be able to deal with it as a whole. But because the focus is held rigidly on one subset of the problem, we’re forced to try to resolve the problems with ‘solutions’ that are all but guaranteed to fail – such as requiring men to be legally responsible and culpable for women’s behaviour, or removing a father from the relationship so as to ‘protect’ the children from a mother’s attacks.

(I hope the analogues in IT-centric ‘enterprise architecture’ and IT-centric ‘solutions’ for ‘Enterprise 2.0′ will already be evident here?)

It gets worse. In part of my EA work for that state-government department, I took a whole-of-system view of their DV-services provision – which apparently no-one had done before. The state’s entire policy on DV had been written by a single women’s-activist group: no other views had been allowed, and the document had apparently been through no formal review at all before it was adopted as state policy. Its key assertion was that because more women than men took out Apprehended Violence Orders (protection orders) against their partners, DV services were to be reserved exclusively for women. The department’s DV literature – displayed in hospitals and elsewhere – stated that violence in the home was solely the fault of men; the help-line service was staffed exclusively by women; and operating-instructions made it clear that any calls for help from men were to be referred automatically to police, for arrest and criminal charges. The operating-manual also recommended that all women callers should be advised to take out an AVO, and to be provided with this service at no cost, with no evidence required. (It was possible for men to take out AVOs against partners, through the courts, but only with incontrovertible evidence, and only at considerable financial and other cost.) No-one seemed to have noticed that this entire mess was completely circular: the skewed proportion of AVOs was used to justify the policy which itself automatically skewed the proportion of AVOs. This kind of circular policy was extremely common, and many places still is – and again, guarantees only that the problems will be made worse. Which, again, is used to justify the ‘need’ for the respective service-providers’ ‘services’.

(Again, I hope the analogues to the role of vendors and consultancies in IT-centric ‘enterprise architecture’ and ‘Enterprise 2.0′ will be clear here.)

There are at last some signs of change: for example, much more recognition that males too can be victims as well as perpetrators (though still very little public recognition of the scale of that victimhood). Whilst formal shelters for ‘battered husbands’ are extremely rare – the usual ‘shelter’ is a park bench, a hostel for the homeless or even a prison cell – there are now several DV shelters which will support a father to look after mother-abused children rather than forcing the children into even more problematic foster-care; and there are also much-needed support-services for women wanting to face their own violence against themselves and others. A more integrated approach to ‘domestic’ violence is becoming more common, addressing the full gamut of issues and the interactions between all parties in a given context – including much more recognition of the huge risks of social-workers and other ‘involved outsiders’ being used as pawns in mutual blame-games and other third-party abuse.

(If you’re interested in how these same violence/abuse issues play out in the business environment, and what to do about them within a whole-of-enterprise architecture, see my book Power and Response-ability: the human side of systems and the matching free-download ‘manifesto‘ on power and responsibility in business. There’s also the SEMPER metric/diagnostic, described in another of my books, SEMPER and SCORE: enhancing enterprise effectiveness, and on the sempermetrics.com website.)

Yet courtesy of the term-hijack – forcing all DV focus onto the relatively small subset of ‘partner active-male-perpetrator versus passive-female-victim’, and preventing any discussion of anything else – these necessary changes are taking place only decades after the underlying social problems were first brought to public notice.

So it would not be unfair to say that this one single term-hijack has held back progress for more than a third of a century. In doing so, it has cost untold millions of whatever currency, and caused untold damage countless thousands or even millions of lives. The only ‘beneficiaries’ – if we can call them that, because everyone loses from this in the long run – have been the service-providers. And even though they no doubt believed that they were doing their best, their approach to the problems was so blinkered and so incomplete that the ‘services’ that they have provided have been, at best, vaguely helpful, but far more often worse than useless.

Term-hijacks matter. As we’ve seen above, they matter most when the ‘natural’ term for a whole domain is hijacked for a small subset of the domain, preventing discussion or even awareness of the whole. And the damage they cause can be huge.

So, to return to topic: term-hijack of ‘enterprise architecture’, and ‘Enterprise 2.0′. It’s worth looking at each of these as follows:

Term ‘enterprise architecture’:

• natural meaning: ‘the architecture of the enterprise’
• term-hijack: ‘the architecture of the enterprise’s IT’
• typical consequences:
  • portrayal of anything not-IT as ‘the business’, without differentiation between strategic, tactical or operational layers
  • promotion of IT ‘solutions’ for contexts for which IT is inherently unsuitable
  • common tendency to search only for problems which match a preselected ‘solution’
  • ignorance of any forms of information-management not centred on IT – i.e. human ‘tacit knowledge’ etc
  • increased misalignment of and tension between IT and all other business domains
  • poor handling or understanding of end-to-end processes, especially where these transit out of IT
  • failure to grasp the distinction between ‘the organisation’ (representing the limits of a control-boundary) and ‘the enterprise’ (shared with stakeholders beyond the organisation control-boundary)
  • high risk of rejection of the entire domain as irrelevant to real-world business issues
• nominal beneficiaries: IT vendors and consultancies; IT departments
• costs: financially, probably exceeds a trillion dollars worldwide; immeasurable costs in waste of time, effort, commitment, talent etc

Term ‘Enterprise 2.0′:

• natural meaning: implied as ‘the social enterprise’, a more socially-oriented way of communicating about business and doing business
• term-hijack: ‘social software’, IT packages and infrastructures that can be marketed as having some social or collaborative element
• typical consequences:
  • constraining the entire discourse to technical issues only
  • promotion of IT ‘solutions’ for contexts for which IT is inherently unsuitable
  • common tendency to search only for problems which match a preselected ‘solution’
  • ignorance of the psychology underlying social interactions, reputation and responsibility, and the social nature of ‘enterprise’
  • ignorance of intersections with other related domains such as enterprise architecture, knowledge management etc
  • poor handling or understanding of end-to-end processes, especially where these transit out of IT
  • failure to grasp the distinction between ‘the organisation’ (representing the limits of a control-boundary) and ‘the enterprise’ (shared with stakeholders beyond the organisation control-boundary)
  • high risk of rejection of the entire domain as irrelevant to real-world business issues
• nominal beneficiaries: IT vendors and consultancies; IT departments
• costs: financially, already exceeds many billions of dollars worldwide; immeasurable costs in waste of time, effort, commitment, talent etc

In other words, whilst there are some significant differences, these two term-hijacks have very similar consequences. Which is not a surprise, since it’s been much the same people promoting much the same mistakes in each case – as also seen elsewhere with other related themes such as knowledge-management, balanced-scorecard and similar multi-axis reporting, cloud-computing, service-orientation, security, enterprise resource-planning and business process re-engineering. In effect, the real problem is one of mindset: a failure to think wider, to grasp the nature of the whole; a failure to realise that one’s own preferred subset of a domain is not necessarily the sole centre of that domain; and a failure to recognise that wilful ignorance and wilful inaction can have serious consequences.

And in almost every case, the consequences of term-hijacks have been incredibly expensive – in almost every possible sense. Term-hijacks matter: as architects, we need to hammer this point home, in every aspect of our work.

So: three examples of term-hijacks: ‘violence against women’ as the whole of ‘domestic violence’; ‘enterprise IT-architecture’ as the whole of ‘enterprise architecture’; and ‘social software’ as the whole of ‘Enterprise 2.0′. But what other term-hijacks can you see in your own environment, where a subset purports to be the whole? What are the consequences of that term-hijack? What vested interests promote and protect that hijack, and for what reasons? And what can you do to break the hijack in each case?