Using Cynefin in enterprise-architecture
This is in part an addendum to the previous post. The main aim here, though, is simply to provide some practical guidance on how and where the Cynefin framework should and should not be used in enterprise-architectures and the like. This advice draws on my own practical experience with use of Cynefin since 2003, and with related frameworks over the past two or three decades and more.
[Note: the focus of this post is solely on practical use and avoidance of misuse, and (I sincerely hope) should not be controversial. (In a few places I do state my personal and professional opinion, but that’s about the limit of what might be construed as ‘controversial’.)]
The core purpose of Cynefin is to support sensemaking in complex contexts, such as occur frequently in the business-domain. As such, it would be of obvious interest to enterprise-architecture and related disciplines, especially in strategy-development and in addressing ‘wicked-problems’ and ‘pain-points’ in the business context.
I regard it as important here, for enterprise-architecture, to view Cynefin as ‘just another framework’. In a sense, it’s comparable with other well-known business-sensemaking frameworks such as Business Model Canvas. The main difference is that Cynefin has more potential for general-purpose business-sensemaking, rather than solely in a single domain.
As a quick overview, the Cynefin framework consists of:
- a core graphic, shown with varying content on a fixed base-diagram
- a set of methods for narrative-enquiry and the like, such as ‘butterfly-stamping’ and ‘clustering’
- a software package named Sensemaker, for visual presentation and interpretation of results
I’ll skim through these in reverse-order.
Sensemaker package
I have not used the Sensemaker package, so will make no comment there, other than to say that, from its published description, its use would seem peripheral rather than central to enterprise-architecture.
Methods
Cynefin methods are only available to those who’ve taken the Cynefin/Cognitive Edge training course.
I took the Cynefin course in 2003, and learnt the set of methods that were extant at the time; to my knowledge, not much has been added since then. Of these methods, my personal experience is that in most cases I haven’t found them useful in enterprise-architecture. (They’re no doubt valid, I just don’t happen to have found them useful for the kind of work that I do.)
For most enterprise-architecture purposes, I tend to use other narrative-oriented sensemaking techniques such as Sohail Inayatullah’s Causal Layered Analysis, and, perhaps especially, Nigel Green’s VPEC-T. I’ve also developed a variety of techniques of my own, as documented in my books on enterprise-architecture – particularly context-space mapping in Everyday Enterprise Architecture, Enterprise Canvas in Mapping the Enterprise, and Five Elements and the SEMPER diagnostic in SEMPER & SCORE.
The only Cynefin technique that I do still use regularly is ‘clustering‘, moving annotations on sticky-notes into clusters that seem to make sense. Note, though, that the same technique is common to most other sensemaking-frameworks, such as Business Model Canvas: see the book Business Model Generation for detailed examples of the technique and its use.
Core graphic
The core graphic is the only part of the Cynefin framework that most people see, and hence know as ‘Cynefin’. Although the layout has remained much the same since the start, the content and presentation have changed somewhat over the years. This is the current version as shown on its Wikipedia article:
Most people seem to see this as four domains in a simple two-axis frame, though without axis-labels. In fact there are not four but five domains, including the central Disorder domain, which is fundamental to the Cynefin model.
[There’s also a sixth mini-domain or sort-of-domain, shown as the little squiggle at bottom-centre. I forget what this represents, but it’s rarely mentioned, does seem to be optional, and does not seem to be fundamental to the model’s use.]
The four domains – Simple, Complicated, Complex, Chaotic – represent distinct ‘ways of knowing’, or ways of making sense of ‘the unknown’, the central domain of Disorder. The central domain always exists; the other domains are, in effect, overlays on top of Disorder.
I’ve not seen any explicit description as to why the domains are placed in this specific layout. The one part that often is explained is a distinction between ‘order’ – Simple and Complicated – versus ‘unorder’ – Complex and Chaotic – which in this layout is, in effect, a kind of horizontal axis. Yet there does not seem to be any vertical axis as such, and there are certainly strong assertions that it should not be interpreted as a two-axis frame.
Various texts are overlaid onto the four domains to identify and describe these ‘four ways of knowing’. Two of these sets of texts are present in the diagram above; I’ve seen perhaps half a dozen other sets over the years, in various versions and presentations. These texts would represent the ‘official content’ for the framework.
There are also two other parts of the framework that are less well-known, and in general only appear in certain earlier versions of the diagram: the Cynefin-dynamics, and the relationship-mappings. The Cynefin-dynamics represent moves between sensemaking-domains, and are important in making sense of a total context, especially over time; the relationship-mappings – typically shown as little ‘pyramids’ – represent strong or weak ties in relation to a hierarchy, and are significant for social-network mapping and the like.
So to summarise, the core diagram consists of:
- mandatory: central domain of Disorder
- mandatory: four sensemaking domains, currently labelled Simple, Complicated, Complex and Chaotic
- mandatory: graphic layout, including curved boundaries (not straight boundaries) between domains
- mandatory: specified sets of text-content, mapped to each of the four sensemaking-domains
- optional: sixth (unlabelled) domain
- optional: order / unorder axis, implied as horizontal on this graphic-layout
- optional: Cynefin-dynamics
- optional: relationship-mappings
There may be a few other optional items, but essentially that’s it. So if we turn this round, we can then see some of the constraints on the potential use of the Cynefin core-diagram in enterprise-architecture and elsewhere:
- any model that does not include a central domain of Disorder is not Cynefin
- any model that does not use four sensemaking domains, or uses other labels for the four domains, is not Cynefin
- any model that uses a different graphic-layout, or that uses straight domain-boundaries, is not Cynefin
- any model that uses any domain-partitioning other than as specified is not Cynefin
- any model that uses any text other than that formally specified, is not Cynefin
- any model that applies any vertical axis is not Cynefin
- any model that applies any horizontal axis other than order/unorder is not Cynefin
- any model that describes any inter-domain dynamics not otherwise formally specified is not Cynefin
In practice, what this comes down to is the following:
- there are very tight constraints on what can be called ‘Cynefin’
- in enterprise-architecture, most usages of what is described as ‘Cynefin’ are actually not Cynefin
Clearly there’s a very important distinction here between usage of Cynefin-proper, and the use of ‘Cynefin-like’ concepts that are either incorrectly described as ‘Cynefin’ and/or used in ways that differ from those specified in Cynefin-proper.
I perhaps need to emphasise this point, for everyone’s sake: anything that does not conform exactly to the Cynefin specification should not be called ‘Cynefin’. In practice, this probably applies to most usage of what is called ‘Cynefin’ in enterprise-architecture.
On usage of Cynefin-proper in enterprise-architecture, my own personal experience is that it can be useful, but is incomplete and even misleading in certain areas – particularly for sensemaking and decision-making on uniqueness and the like in the Chaotic domain, as I’ve described in several posts here. Cynefin does have some potential uses in enterprise-architecture and the like, but for almost all of these there are appropriate alternative tools, techniques and frameworks. Overall there seems to be so much confusion, so many misconceptions, and so much baggage around the whole framework, that, wherever practicable, it’s far safer and far wiser to use those alternatives instead. To be blunt, I would strongly recommend that, unless absolutely unavoidable, Cynefin-proper should not be used anywhere in enterprise-architecture and related disciplines.
Use and re-use of Cynefin-related concepts
Some of those alternatives may incorporate use or re-use of concepts that are either directly or indirectly related to some of those within Cynefin-proper. Key examples include:
- the SCCC categories – Simple, Complicated, Complex, Chaotic
- the order / unorder axis – Simple/Complicated versus Complex/Chaotic
- relationship-strength mapping
- context-space mapping using the Cynefin core-graphic as a base-map
- domains as disciplines, and inter-discipline dynamics
The SCCC categorisation is enormously valuable in enterprise-architecture, with applications in a very broad range of types of sensemaking and decision-making. The categories are often used within a single-axis or two-axis layout, in a wide variety of forms, in a very wide variety of cross-maps. Note, though, that unless it uses the exact layout of Cynefin core-graphic and other constraints as above, this is not Cynefin.
The order / unorder axis and its crosslink to the SCCC categories is also enormously valuable in enterprise-architecture. It indicates, for example, where current IT-systems are likely to work (order) or not-work (unorder). It also indicates the crucial transition from ‘controllable’ (true/false logic) to ‘not-controllable’ (modal-logic, ‘direction’ rather than ‘control’) at which the Complicated transitions into the genuinely Complex – a point which many IT-folk still fail to grasp. And it also marks a key distinction that is fundamental to service-design and much more: that in the order-domains Einstein’s dictum applies, that ‘madness is doing the same thing and expecting different results’, whereas in the unorder-domains the dictum inverts, such that ‘madness is doing the same thing and expecting always to get the same results’. Although it’s used in Cynefin, the ‘unorder’ term was originally developed by Cynthia Kurtz: see her weblog for more details about her own Confluence framework. Note, though, that if used outside of the context of Cynefin-proper, this is not Cynefin.
The relationship-mapping is useful mainly in specific aspects of enterprise-architecture, such as social-network mapping or organisation-architecture. It was incorporated into early versions of Cynefin, but was again originally developed by Cynthia Kurtz: see the updated ‘Braid’ model on her weblog. Again, though, note that if used outside of Cynefin-proper, this is not Cynefin.
As described in the previous post, context-space mapping is a sensemaking technique that uses an arbitrary base-map and arbitrary additional overlays – all selected according to context and need – as a ‘seed’ around which appropriate insights may coalesce. Because of the usefulness of the SCCC-categorisation, the Cynefin core-diagram is often used as a base-map for this purpose. Yet because the core-diagram is used here in a manner that is different to Cynefin-proper, this is not Cynefin.
There are many other frameworks that use a similar layout, typically describing domains as disciplines, and the concomitant inter-discipline dynamics. For example, the book Disciplines of Dowsing highlights an adaptation of the classic Jungian frame, cross-mapped to the SCCC-categorisation, in a format that, with some ‘translation’, is directly reusable in enterprise-architecture. That frame includes a summary of inter-discipline (inter-‘mode’) context and dynamics, such as:
- Role of mode is…
- This mode manages…
- This mode responds to the context through… (i.e. prioritises, for sensemaking)
- Mode has a typical decision-sequence of…
- Use this mode when…
- We are in this mode when…
- ‘Rules’ in this mode include…
- Warning-signs of dubious discipline in this mode include…
- To bridge to [other mode], focus on…
Note, though, that although this and similar frameworks may use Cynefin-related concepts such as the SCCC-categorisation, and may even use the same terms, they are not the same as the Cynefin framework. In other words, this is not Cynefin.
Cynefin-proper is very tightly constrained, and has only a narrow range of potential uses in enterprise-architecture.
‘Cynefin-like’ or ‘Cynefin-related’ ideas and frameworks, as summarised above, are not so tightly constrained, and have a very wide range of potential uses in enterprise-architecture. For example, in practice, most so-called ‘Cynefin’ in enterprise-architecture – such as in Nigel Green’s ‘A thinking framework for Business/IT ‘Systems’ behaviour based on Cynefin‘ – is actually some form of context-space mapping under a somewhat different guise. It’s unfortunate that the term ‘Cynefin’ is used for this, not least because it gives the impression that Cynefin-proper is used far more often in enterprise-architecture than it actually is.
But perhaps the most important point there is that, in the vast majority of usages of ‘Cynefin’ in enterprise-architecture, this is not Cynefin.
And if it’s not Cynefin, we shouldn’t label it as such. Simple, really. 😐
Over to you?
Tom,
This is a very good overview of Cynefin, probably the best I have seen.
From my perspective the failure of the Cynefin model comes from what appears to be a disconnect between the Simple and the Complex. Simplicity and complexity have an intimate relationship with each other, similar to the relationship between heat and cold, order and disorder. I don’t see how to tease this relationship out of Cynefin.
Of course, my issues with Cynefin don’t mean Cynefin is bad. Only that I still don’t see how to use it to solve my problem. I am not trying to understand complexity. I am trying to understand how to get rid of it.
Hi Roger – many thanks.
On complexity, I know we’ve disagreed strongly in the past over different perspectives on the nature of Complexity, yet sometime I’d really like to spend the time with you to properly ‘nut it out’ 🙂 – and get a proper understanding of where you’re coming from. There’s a key paradigm difference there, and I’m acutely aware that I haven’t quite got it yet: I’ll need your help to get my understanding right on this.
“I don’t see how to tease this relationship out of Cynefin” – I think I have a similar difficulty, which is one reason that I fell foul of, uh, this problem. Rather than Cynefin, perhaps go the original source for the ‘unorder’ concept, namely Cynthia Kurtz: have a wander through her ‘Story-Colored Glasses‘ weblog, there are a lot of interestingly different perspectives there, and a real love of deep-metaphor and deep-language that may well be useful for this.
“My issues with Cynefin don’t mean that Cynefin is bad” – I don’t think it’s ‘bad’ either. My point is the same as yours, that “I still don’t see how to use it to solve my problem”. The practical problem in EA has been that so many people misuse it or misunderstand its limitations – including me at the beginning, I’ll freely admit – that it’s been very hard to decipher what is ‘Cynefin-proper’ and what is not. The realisation I came to about half a year ago was that just about everything that I’d used that I’d thought was ‘Cynefin’ actually wasn’t: it came from other sources. And the few bits that actually were Cynefin-proper, I rarely used anyway. So it made the whole point rather moot. All I’m doing here is warning people of a) the ‘it’s not actually Cynefin’ problem, and b) that the real Cynefin actually has very few applications in enterprise-architectures, either of the classic IT-oriented form or even of the extended whole-enterprise form. In that sense, it’s not worth the very considerable trouble and risk involved in using Cynefin. And there are good alternatives anyway, such as VPEC-T and Causal Layered Analysis. Hence, short answer: don’t use it.
“I am not trying to understand complexity. I am trying to understand how to get rid of it” – that I think is the root of our respective paradigm-problem. The key is in the different meanings of the term ‘complexity’. In most IT-systems, yes, I strongly agree with you: the wrong kind of complexity is very bad news indeed, and definitely something we want to get rid of. In human systems, certain types of complexity are likewise bad news; other types of complexity there’s solid proof that there’s no way to get rid of them (i.e. they’re inherent in the nature of the structure); and yet other types of complexity we actually want to encourage, because they’re the root of innovation and suchlike. So it’s a, uh, complex problem in itself? 🙂 Hence, again, something I’d love to discuss properly with you somewhen.
Thanks again, anyways.
On the apparent difference of opinion on “complexity,” I think it has to do with what Fredrick Brooks referred to as accidental and inherent complexity. We should always strive to reduce accidental complexity (which is typically a result of our efforts). Trying to remove inherent complexity, instead of dealing with it, is usually oversimplification of the problem, which causes as many problems as over-complicating; it’s like plastering over cracks caused by a house settling on a bad foundation.
Thanks, David.
Yes, I’m very familiar with that distinction between ‘accidental complexity’ versus ‘inherent complexity’ – you’ll see it mentioned in the last paragraph of my response to Roger Sessions immediately above, as the root of my disagreement with Roger (who _does_ focus solely on ‘accidental complexity’, whereas I don’t). There’s also a visual comparison between the two in slides 133-138 of my 2014 slidedeck ‘The Dung-Beetle’s Tale’, https://www.slideshare.net/tetradian/the-dungbeetles-tale-systemsthinking-complexity-and-the-realworld .
There is a well-known saying, that “to the person with a hammer, everything looks like a nail.” In other words, our view of things is significantly narrowed by the limits of what we know or understand. To this I’d add a corollary: “to the person who only knows the hammer and nail, anything they don’t understand may seem useless.”
In the original post above, there is a critique of the Cynefin framework, largely popularized by Dave Snowden, and the subject of the award-winning HBR article from 2007 that Dave wrote with Mary Boone. Through the lens of my own knowledge and understanding of Cynefin, I felt that the original post above, is significantly flawed. I believe there are a number of points made by Tom that are incorrect, and bear further explanation and exploration. Below are a few of my own points on Tom’s post, and the Cynefin framework:
1) Tom writes that the “core purpose” of Cynefin is sense-making in “complex contexts.” this is not my understanding. Rather, it seems to me that Cynefin describes all possible domains in which problems/challenges/issues may appear in organizational life. The framework’s “purpose” appears intended to help us understand the differences in the ways that patterns and knowing emerge in each domain. From this, we can respond with our own patterns of inquiry, analysis, and action, that are best-suited to the dynamics of the domain we are facing. the “core purpose” then, applies to our interaction with all domains, not just “complex contexts.”
2)Tom describes the methods of Cynefin as mainly being “for narrative enquiry and the like.” As I note above, I believe a plain reading of the HBR article and other Cynefin info, suggest that Cynefin is intended to help us not only inquire and understand, but to understand what is happening in the context of a given domain’s unique patterns/dynamics, and thereby, take action that has a better chance of achieving our objectives.
3) Tom writes that the Cynefin methods are only available to those who take dave Snowden’s course. I have not yet taken the Cognitive edge accreditation course, but it is clear from the Cognitive Edge website that the methods of its practitioners are open source. There is a library of these with detailed application notes, on the Cognitive Edge website: http://www.cognitive-edge.com/method.php
4) Tom notes that most people on viewing the Cynefin diagram, only “see two axis..” I don’t have data on this, and it may be true. But my understanding of Cynefin again implies that these five domains are all present in the world, and that under changing conditions, we may find ourselves moving from one to another. Cynefin then, would appear to be a framework for viewing a muliti-dimensional and dynamic reality.
5) Tom dimisses the small “squiggle” at the center bottom of the Cynefin diagram. He admits he doesn’t recall what it represents. I believe this is intended to portray a “fold” or Cusp. That is, the way that under certain change conditions, we can suddenly and significantly go right over the edge from a simple to chaotic domain. As I understand it, this sort of cusp catastrophe dynamic is not present in the other domain boundaries.
While I am new to the concepts and methods of enterprise architecture, I have been working with concepts and methods based in complex systems dynamics for over 12 years. No framework is perfect, or necessarily useful in every situation. But I believe that the Cynefin framework relates to universal organizational dynamics, and is not as constrained and limited in the ways that Tom suggests. I look forward to further reply and dialogue on these matters. Thank you!
Hi Bruce – Point taken about “hammer and nail”, but I might politely point out that unless you were employed by IBM in the period roughly 2000-2003, it’s likely I do have a longer experience with Cynefin than you have, because when I did the course in Sydney back in 2003, I was told that my colleague and I were the first-ever non-IBMers to go through that course.
You’re welcome to hold your opinion of that post, though it does appear that you don’t have much awareness of the background behind it. Which is a pity, though not unexpected.
I’m sorry to say that I have very little interest in “award-winning” this-that-and-the-other: I’m not interested in pointless prestige-games. What I am interested in is whether something works for a given purpose, and whether it’s structurally sound. As I said in the post, I have no doubt that Cynefin methods may work well in other applications: it’s just that in my experience of enterprise-architecture – which, as you do rather clearly indicate, is over a considerably longer period than yours – the applications of Cynefin-proper are somewhat limited; and the structural problems around its approach to the Chaotic domain – which Snowden continues to ‘resolve’ by the, uh, somewhat limited method of accusing me of lying – are sufficiently serious to render to render it somewhere between inadequate, actively-misleading and/or worse-than-useless for anything that must address that domain. Which happens to be a very significant amount of enterprise-architecture: anything that touches real-time action and exception, for example.
On 1): “help us understand the differences in the ways that patterns and knowing emerge in each domain” – uh, wouldn’t that otherwise be described as ‘sensemaking’?
On 2): Historically, Cynefin was initially designed to operate primarily in the narrative-knowledge space. (For illustration of this, go read the initial Cynefin paper (1997?) on the relationship between knowledge and place – in some ways the ‘Cynefin’ term is a kind of Celticisation of Nonaka’s concept of ‘ba’.) The knowledge-management connection has been somewhat played down over recent years, but I gather from other colleagues that it’s beginning to re-emergence in some of Snowden’s most recent work. You might also note, for example, that the primary input for Sensemaker is narrative-text, typically in the form of anecdotes or tag-lines.
On 3): Unlike you, I have taken the Cynefin accreditation course, though rather a long time ago – prior to the Cognitive Edge period, for example. At that time, the methods were very clearly indicated as being proprietary. I accept that I may well be out of date in regard to that point.
On 4): Yes, you do know how to use the Cynefin-proper frame, with the fundamental importance of the central Disorder domain. Apparently unlike you, I do come across a lot of people who draw a simple two-axis frame with the SCCC-categorisation, and call it Cynefin, because that’s what they’ve seen from other people (not me, by the way) and/or how they’ve interpreted the graphic on Wikipedia.
One interesting point is that the ‘official’ usage does not seem to acknowledge the insights that arise from a recursive use of the Cynefin frame on itself. Try it sometime: you might find it interestingly enlightening, and might also understand why I now tend to regard Cynefin as promoting, all too often, a sadly over-Simple view of the Complex.
On 5): Please, read the text again: I don’t “dismiss” the squiggle. (I would have to say that that pejorative use of “dismiss” there smacks rather too much of the kind of abuse-games of which a certain other person has proved rather too fond, and to be frank I would appreciate an apology about that.) I merely stated – exactly as you said – that I don’t recall what it represents: so yes, thank you for the reminder about what it represents. It’s certainly interesting, yes: however, not central enough for it be highlighted in, say, the Snowden/Boone paper. Hence, in that sense, ‘optional’. So in that sense, what is your objection? – there’s nothing controversial there at all.
Structurally, there’s quite a lot that could be discussed around that interpretation of the ‘squiggle’, by analogy with phase-boundaries in states of matter. I’d agree that in practice the boundaries between Chaotic and Complex, and between Simple and Complicated, tend to be rather more blurry; but actually there seems to be a very similar ‘catastrophic shift’ between Complicated and Complex, the moment of inversion of the Einstein dictum, as mentioned in the post above.
In general, it does sound like you have significant experience in the complex-systems domain – almost certainly more than I have. I’d just point out that my first explicit published work in that field – a book called “Inventing Reality” – dates back to 1986, at least a decade earlier than anything that Snowden produced for Cynefin or its antecedents; and the roots of that part of my work, and its connection to sensemaking, stretch back at least another decade, again in openly published form. Unlike Snowden, I make no pretence of being a ‘scientist’: I am, and always have been, a practitioner, a toolmaker, a creator of conceptual tools and sensemaking-methods. I think you may find that I’m a lot more qualified to assess the validity, usefulness and structural integrity of a tool such as Cynefin than certain people might like you to think; and in that sense, I can certainly advise you that, structurally speaking, Cynefin is a lot more constrained than you seem to believe at present. But that’s your choice, of course.
Anyway, happy to continue the conversation, if you wish. I do, however, ask you to respect Sutton’s ‘No Asshole Rule’, and understand that there were, and remain, very strong reasons why I (and several others, to my personal knowledge) have had to invoke it in that direction.
Hello Tom,
thanks again for publishing my post, and for your prompt and thoughtful response. Please know that I have no knowledge or awareness whatsoever, of any personal history you may have with Dave Snowden or others, regarding the Cynefin development or use. I wrote my response to your earlier post solely on my own understanding of Cynefin, and my sense was that there were some points that could benefit from further discussion and clarification.
With regard to the squiggle, I do not mean my use of the word “dismiss” to be pejorative in any sense. Rather, I meant only that you chose not to discuss the matter because, as you said, you did not recall what it meant.
Finally, with regard to the Sutton book, I have heard of it, but never read it. Had to look up on amazon what it’s about.
If our exchange has stimulated thinking about Cynefin, and helped us and others seek more knowledge and understanding, then I feel that’s a good thing.
With regard to Enterprise Architecture, I am a novice and exploring literature and methods now. My reading to date (and not at all confirmed by discussion with any practitioners or presumed authorities) suggests that EA is fundamentally about IT as a principal lens for viewing an organization. That may be an oversimplification, or even a misstatement. Six months from now, I hope to have a better understanding.
cheers,
Bruce Waltuck, M.A., Complexity, Chaos, and Creativity
@Bruce Waltuck – Thanks, and yes, it’s hard when in effect you find yourself jumping into the tail-end of what has been a very long and at times extremely unpleasant exploration. My apologies.
Apologies in turn also that I over-reacted re ‘dismiss’: certain points have become red-rag-to-bull, which isn’t your fault at all. Oh well.
I perhaps ought to explain that I’ve known Snowden personally for about eight years, and have met him in person on several occasions. The general experience for myself and many of my colleagues is that Cynefin can indeed be useful – though limited in certain key areas, particularly around the Chaotic, as described above and in the previous post – and remains unproblematic as long as one sticks strictly to the model as ‘officially’ determined at the time. However, the moment one deviates in any way from the ‘official line’, or one introduces any comparison with or usage in parallel with any other concept of complexity, it, uh, becomes problematic. So much so that my strong recommendation re usage of Cynefin in enterprise-architecture is “Don’t”.
On enterprise-architecture itself, yes, it is commonly presented as primarily concerned with IT, but the name itself – as ‘the architecture of the enterprise’ – indicates that it needs a much wider scope. I’d strongly recommend Len Fehskens’ article Enterprise Architecture’s quest for its identity‘, on the Open Group weblog, as a useful introduction to the issues there.
If you’re interested in exploring those issues further, you may find my books on enterprise-architecture useful. Note, though, that Snowden himself has described as ‘illegitimate’ the core of the work in the book Everyday Enterprise-Architecture – without, however, providing any evidence or explanation whatsoever to back up that much-asserted opinion…
Happy to discuss this more, if you’re interested. Or perhaps take a wander through this weblog first: there’s a lot here to explore. 🙂
Thanks again, anyway.