Tom Graves / Tetradian

Continuing on the theme of the ‘This’ game for engaging people in enterprise-architecture exploration and development, as described in the two previous posts ‘This: an exploratory game for service-oriented EA‘ and ‘More on the ‘This’ game for enterprise-architecture‘.

The final note in that last post was about EA toolsets, and the need for appropriate support for the output of the game – and perhaps even the game itself – within the toolset. And that point actually brings together a whole stream of different threads that I’ve been tracking for some years here: enterprise as story, toolsets and their user-interfaces, metamodels and architecture-repositories, whole-enterprise scope, notation-agnostic modelling and a whole lot more.

There are (at least) two fundamentally-different viewpoints on enterprise-architecture: as structure, and as narrative. Most current EA toolsets focus only on the ‘structure’ side, and do so variously well; but there’s almost nothing to help us tackle the narrative side of the story, and even less to help us bring those two sides together. Which, in practice, is a serious problem, because story is actually what engages people in the architecture…

In short, we need our EA toolsets to help us bring a better balance between structure and story in the architecture.

To put into context, consider a few scenarios:

Scenario 1: The team reckon they’ve done well with their work on the new business-model, all laid out on the wall on a Business Model Canvas. But how are they going to implement it? Will it actually work in real-world practice? What are the pitfalls and hidden ‘gotchas’ that could cripple the new model’s viability?

To address these concerns, they set up for a game of ‘This’. One of the architecture-team leads, Maria, takes on the role of modeller, using an application on her iPad, the screen hooked up to a data-projector on the wall, but also coupled to the other team-members’ tablets and laptops. (The screen will also show the current manually-selected or randomly-selected ‘This’ question-card.) She also sets up a conference-microphone to capture an audio-channel.

Maria uses the camera on her iPad to take a snapshot of the current model on Business Model Canvas, and pulls the photo into the application. There, she marks up the graphic with zones and links, each of which – behind the scenes – is also noted as a Service or flow-relation in the underlying Enterprise Canvas.

The team choose an arbitrary starting-point, and build outward from there, as per the guidelines for the game. Instead of using the rather sparse Enterprise Canvas notation, Maria pulls up more-descriptive icons and images from a palette – trucks, parcels, people, machines, money, whatever – and places them on the screen as the current ‘This’; behind the scenes, though, the application stores the information in Enterprise Canvas notation. The audio-channel is attached both to the overall model, and to the entity for the current ‘This’; later, the audio-track can be played back, highlighting in matching sequence each of the items described in the model.

During the game, the discussion indicates that some changes will need to be made to the initial business-model. Maria uses the underlying Enterprise Canvas to recreate a new version of that model, in Business Model Canvas layout.

Scenario 2: Two days after the business-model meeting, Maria re-checks some of the people-connections captured in the Enterprise Canvas model during the ‘This’-session, for the purpose of building a list of stakeholders for one of the side-projects arising from the new business-model. She notices that she didn’t capture one person’s name, the process-owner for a related business-process – she remembers that his first-name was Steve, but not the surname. She clicks on the respective icon, and plays back the audio-channel that was captured at the time: Steve’s surname – Cartwright – is now clear, and she types the full name into the model. As she does so, a link to the company’s HRM-system brings up further contact-details for Steve, including several photographs. She selects one photograph, and sets it as the surface-view for that icon in Enterprise Canvas.

Later that day, Arjun reviews the business-model, using the zooming model-display. In the drill-down into the ‘Key Activities’ section of the Business Model Canvas, Steve’s photograph now appears in place of the previous abstract ‘person’-icon. Clicking on the photograph, Arjun sees all of the information on Steve’s role in the proposed business-model, and can also play back the captured audio both from that meeting, and another discussion that took place earlier in the day.

Scenario 3: Juan has been tasked with developing the IT-architecture for the e-commerce component of the new business-model. His business-unit has standardised on Archimate notation for all IT-architecture models. He opens the Enterprise Canvas model, and, using it as an active backplane, identifies Canvas entities that would map directly to Archimate equivalents: Canvas ‘Service’ to Archimate ‘Business Service’, ‘Application Service’ or ‘Infrastructure Service’, Canvas ‘Exchange’ to Archimate ‘Business Interface’, ‘Business Object’ and so on. He explores the additional detail recorded in the ‘This’ session to identify Archimate ‘Business Function’, ‘Business Event’, ‘Business Actor’ and the like. As he adds these entities to the Archimate model, they’re also attached to the Enterprise Canvas model in the backplane via composition-relation links into the respective Canvas ‘Service’, ‘Exchange’ entities and flow-relations.

Scenario 4: The following morning, one of the business-model team, Vasily, remembers that more detail was needed about warehouse configuration, for potential locations – both physical and logical – for new sensors that will be needed for logistics-tracking in the new business-model. He goes down to the warehouse, takes his smartphone out of his pocket, calls up the Enterprise Canvas model, selects the ‘New Sensors’ entity, and starts a new game of ‘This’ with that entity as its starting-point. He manually selects the question ‘What are the locations of This?’, and attaches to that card the photos that he takes, direct from the phone’s camera application.

In the Enterprise Canvas, Juan has already been identified as one of the people responsible for the ‘New Sensors’ component of the business-model. He receives a notification that new items have been added to the Enterprise Canvas; he opens that part of the model, reviews it, and adds new entities to his Archimate model, which are automatically linked back to the Enterprise Canvas.

So there we are.

Plenty of other scenarios we could add, too: about a meetup in a cafe, about people exchanging ideas in the elevator, about how this information might be used by a project-manager and her team, by a process-designer to gather feedback from the factory floor, by managers using a dashboard in high-level resource-planning, and so on. But that’s detail enough for now: four interlinked scenarios, all working on the same models in different ways, with different software-applications, on different hardware-platforms, for different purposes, all supporting each other.

So is that what actually happens in practice at present? Is that how we do our everyday architecture work?

Uh, no…

In which case, why not? Seriously: why not?

On the surface, it’s all straightforward enough: the work itself is essentially what architects and others do already. The only trouble is that it’s well-nigh impossible to do most of this in any existing EA toolset: most tools now should be able to cope with the Archimate-specific part of the modelling, but that’s about it – and they probably wouldn’t be able to link any of that model to anything else. As for the rest? – well, forget it, guys, you’re outta luck…

Ouch…

It should all be seamless, pretty much exactly as described in those scenarios above. In practice, it isn’t. In fact, the way we have to do it at present is a frustration-filled, kludge-ridden, error-prone mess of manual translations, bits of paper, scribbled notes, anguished phone-calls and worse. Hence no surprise that it often doesn’t work very well – if at all.

Yet there really is no need for it be that way, and no reason for it to be that way either.

To which the only remaining question is: Why? Why is it this way?

To me at least, it seems that the only real reason is that the current EA-toolset market is crippled by its own lack of imagination – and that’s all that’s holding us back.

Okay, yes, sure, there’s a sizeable amount of development-work required. But seriously, none of it would be hard to an experienced developer, someone who’s familiar with the current generation of development tools. Everything I’ve described above is already available in various apps and elsewhere – there’s nothing new as such in any of it. The only reason I haven’t done it myself is that I’m way out of date on that whole area, and it would take me months or years to do what a current developer would know how to do in days.

Have a wander around this blog: I’ve already done most of the conceptual work that’s needed for this, on toolset-ecosystem, overall requirements, metamodels, user-interface, underlying notation-agnostic structures and so on. For example, take a look at these posts:

• The toolset-ecosystem
• More on that enterprise-architecture ‘help-needed’
• EA metamodel: two questions
• EA metamodel – the big picture (and the small picture too)
• Simplifying the Enterprise Canvas
• Using Enterprise Canvas as a service-viability checklist

So I’m serious about this: it’s all there – a huge market, just waiting for the first person with the nous to pick this up and run with it.

Is anyone up to this challenge? And if not, what do we enterprise-architects do about it?

Comments/suggestions, anyone?

A great session yesterday with Kevin Smith, brainstorming ideas for the ‘This’ game for service-oriented enterprise-architecture.

I’d originally envisaged ‘This‘ as a kind of card-game, with questions and supporting-information printed on playing-cards:

There would be that small set of mandatory ‘setting-the-scene’ questions – perhaps printed on cards with a different-colour back – but all of the others would be in a card-deck that could be shuffled into random order.

(Note, though, that playing-cards would be just one form of implementation: there are plenty of other ways to implement the same idea, some of which could make great use of current consumer-technology. More on that later.)

In an early stage of the game, we would ‘Start Anywhere’, picking any appropriate point (or item, rather) as our ‘This’ with which to start. Once we’d done the ‘What is This?’ questions, we would pick random cards for new questions, add any new items to the model as suggested, and then use any ‘move’-options from the questions to move to another item that we’ve just created, to use it as our new focus, our new ‘This’.

At some point we would have populated enough of the model to see the larger picture start to emerge. From there we can go back and start to populate the detail of the model in a more systematic way, using the question-cards in structured sequences rather than solely at random.

The current text of the questions – ‘What is This? – tends towards an ‘as-is’ model. It might be better to reframe the questions for a ‘to-be’ model, creating ideas about the future rather than the present or past; the catch is that in English it leads to an awkward structure - ’What would This be?’ - in which we lose that useful reinforcement-emphasis of ‘This’ at the end of each question. Probably simpler just to use an implied future-tense for the whole of the game – ‘In the future, What is This?’ – and keep the text as it is.

One theme that came out of that brainstorming-session was a literal gamification: if you’re going to call it a game, said Kevin, why not make it into an actual game? For example, award points for asking questions; award even more points for answers. Perhaps different numbers of points for different types of answers: some for an answer that adds detail about the current item, more points for answer that adds further items to the model.

We could use multiple sets of question-cards – each participant with their own set of cards, perhaps. That would introduce even more serendipitous randomness into the exploratory stage, and perhaps further opportunities for gamification.

The game can be a distributed game, with people in different locations, and also at different times. Imagine a bunch of executives, each with their iPads or whatever, all accessing a shared screen, showing the action, sharing the annotations, exploring multiple perspectives and multiple views, with a facilitator updating the shared screen (and the model beneath it) in real-time. The ‘card-game’ notion helps keep the focus on one item at a time, whilst allowing a lot of individual freedom and space for ‘positioning’ within the game. Each interaction also feeds towards the overall model.

We can also imagine this as a personal game, hosted on a smartphone or other handheld. The device screen shows just the current question-card, with space to enter responses – which, depending on device-capability, could include audio-, photo- or video-capture as well as text or simple sketch-graphics.

(Conceptually at least, this ‘personal game’ should be quite straightforward to implement as an app, because most of it is little more than access to hosted-backend, display a card with predefined text and graphics, and support appropriate information-capture – all of which is supported as standard in most app-APIs. Access to the backend-host doesn’t even need to be in real-time: it can be done by batch-download, local-store, and then batch-update with feedback to resolve any merge-issues. There are some complications in displaying the Enterprise Canvas model being created in the background, but even those should not be hard to resolve, as it doesn’t involve any actual real-time drawing of links between entities: they’re generated from the responses to questions, not by direct user-interaction.)

In modelling with This, (almost) every link implies a flow – because that’s one of the key modelling-constraints in Enterprise Canvas. If it isn’t a change in layer-of-abstraction – a realisation-relation – or a decomposition to another level of granularity – a composition-relation – then it must be a flow-relation: those are the only three choices we have. And a flow-relation always implies that there’s something exchanged: so what is that Exchange? What are its content, structure, protocols, driving events, values, trust-concerns, and so on? There’s a lot of information there that we need to capture, explore, discuss… Unlike the association-relation in so many other notations, we can’t get away with saying, “Well, they’re just sort-of-related, aren’t they?” – we need to explain what that relationship between those entities is, what it entails, what it brings to the overall enterprise. A useful challenge in itself.

The more I explore this idea, the more I see it’ll need a new kind of EA toolset – one that supports a much better balance between structure and narrative, a different way of engaging everyone in the overall architecture. More on that in another post, though.

Any comments so far? Any ideas of your own on This?

For a while now I’ve been brewing a kind of ‘exploratory game’ for enterprise-architecture, with the somewhat uninventive title of This.

It’s based on the same service-oriented view of the enterprise as Enterprise Canvas – in fact we would typically use the game as part of modelling some aspect of the enterprise with Enterprise Canvas, usually with the ‘simplified notation‘. We can also use it in conjunction with the Enterprise Canvas service-viability assessment described in an earlier post.

[To keep things short, I'll assume that you're already familiar with the models and mappings I've used in my work, particularly Enterprise Canvas and its layers of abstraction ('extended-Zachman layering'), service-content checklist ('single-row extended-Zachman') and mapping between Business Model Canvas and the Enterprise Canvas core; the market-model / market-cycle; and the Five Element model, particularly its variants that focus on service-flow content. If not, all but the last of these - and their graphics - are described in that post on the service-viability checklist; for the service-flow content-model, see the posts 'Not quite VPEC-T' and 'More on 'Not-quite VPEC-T''.]

The aim of the game is simply to elicit whatever information we need about the context, and model it as required as we go.

We elicit that information by asking questions about the current item in focus, which is always called ‘This‘. Some of the questions enquire for more about This; others ask us about how This relates to other items; and some questions invite us to move the focus to another item, a new This.

In most cases, the questions can be asked in almost any order: I envisaged them being printed on a deck of cards, each question accompanied by an explanatory diagram or other descriptive information. We could pick the cards at random – “choose a card, any card!” – or work in a more structured way: it’s up to us.

We use much the same ‘Start Anywhere’ principle to choose where to start. Since in Enterprise Canvas we assert that everything is or represents a service, and everything is connected in some way to everything else, it actually doesn’t matter where we start: we can pick any item that seems appropriate, anywhere within the enterprise, at any level of granularity or abstraction. It can be a Service, a Product (proto-Service) or a Flow (Service as movement) or whatever – it doesn’t matter.

So, pick an item; any item. Think of it for now as a service, or representing a service. In that basic Enterprise Canvas notation, place it on the table, scribble it on the back of the napkin, scrawl it on the wall, or draw it on the screen:

For now, this is our current focus, our current centre of attention – our ‘This‘. And until we explicitly move our attention elsewhere, all of our questions relate to this This.

For any question that points to a ‘Who’, optionally create a new entity to represent that person or group, again described as a service. Optionally, move the focus to this new entity, as the new ‘This’.

A few scene-setting questions we need to ask first:

• What is This? - give it a name (or just call it This)
• What type of description will we use for This? – applicable layer of abstraction (selected layer constrains some of the questions and the details within the questions)
• What categories apply to This? – if categorisable, those categories may point to other questions about This

All of the other questions can apply in almost any order, though as we’ll see, some of them tend to cluster into groups that make more sense together.

Any question that includes a [*], [^] or [v] marker allows us the option to change our current ‘This’ to an item pointed to by the question. (An [*] marker indicates that any new item would usually be at the same level of abstraction; an [^] marker for a new item one or more levels up; and a [v] marker for one or more levels down.) That other item now becomes our new current ‘This’; typically we would re-start with the initial scene-setting questions on this new ‘This’, and continue onward from there.

Some questions about value, and relation to enterprise vision and values:

• What is the purpose of This? [^] (what drives This?) – vision and values
• What is the larger picture for This? [^] - abstraction
• What is the business-meaning of This? - where it fits in the big-picture
• What is done by This? [*] - value-creation
• What is the value of This? [*] - value-proposition
• Who would value This? [*] - value-connection to customer-segments, also connection to suppliers, engaged non-customers

(From these we might place Vision and Value entities onto the workspace, or sketch out a model of the overall enterprise and market.)

Another set of questions help to link a business-model from Business Model Canvas into this part of the architecture, via the cross-map between Business Model Canvas and the core Enterprise Canvas partitioning:

• Who or what uses This? [*] - service-consumers
• What connects with This? [*] - preliminary view of relationships/flows - expand with Supplier, Customer, Partner, flows etc
• Who or what supplies to This? [*] - service-providers, suppliers
• What delivers This? [*] - customer-channels, also supplier-channels
• Who or what works with This? [*] - partners
• What is used in This? [*] - key-resources – include asset-types as per service-content checklist
• What happens in This? – key-activities
• What are the processes within This? - use BPMN etc (an alternate way of asking about activities)
• How do we talk with others about This? - customer/supplier relations
• What are the costs of This? - cost-structure (what kinds of cost)
• What are the returns from This? - revenue streams (what kinds of value-returned?)

A set of questions based on the service-content checklist:

• What items are used or referenced in This? - assets in service-content checklist
• What are the functions of This? - functions in service-content checklist - links to asset-types used or referenced
• What are the places of This? - locations in service-content checklist - includes asset-types for schemas (plus location in Time as abstract)
• What skills and capabilities are needed for This? - capabilities in service-content checklist - includes asset-type, skill-level; also note skill-level limits to machine, IT, human
• What events drive This? - events in service-content checklist – includes asset-type
• What decisions guide This? - decisions/reasons in service-content checklist - includes skill-/complexity-level
• What standards, laws and regulations apply to This? – externally-imposed rules
• What principles and business-rules apply to This? – internally-imposed rules

Some questions about flows between ‘This’ and other items:

• What’s the transaction-lifecycle for This? - apply Market Cycle sequence
• What are the flows for This? - apply (original) VPEC-T for flow

(In Enterprise Canvas, we might model these as flow-relationships between Services, optionally with Exchange entities along the flow-relation.)

Some related questions on service-metrics and quality:

• How do we measure This? - metrics, service-level agreements
• What information do we need about This? - qualitatives, often in parallel with performance-metrics; also coordination-info, event-info
• What is success for This? - linkage between metrics and values
• How is quality assured for This? [*] - linkage to validation-services (create awareness, enhance capability, apply in practice, verify)

Some questions that link to the ‘guidance services’ in Enterprise Canvas:

• How do we manage This? [*] - links to direction-services (mainly ‘Run the Business’)
• Who or what defines strategy for This? [*] - links to direction-services (mainly ’Change the Business’ or ‘Develop the Business’)
• How do we change This? [*] - links to direction- and coordination-services (mainly ‘Change the Business’ in each)
• What is the change-strategy for This? – links to coordination-services for change-strategy (mainly ‘Develop the Business’)
• Who or what coordinates This? [*] - links to run-time coordination-services (‘Run the Business’)

Two questions address the Investor and Beneficiary relationships modelled in Enterprise Canvas:

• Who invests in This? [*] - investors (what forms of value?) - always crosslink with Beneficiaries to check balance
• Who benefits from This? [*] - beneficiaries (what forms of value?) - always crosslink with Investors to check balance

Some questions about responsibilities and stakeholders:

• What leadership is needed for This? - leadership as per Five-Element (5+5+1)
• Who is responsible for This? [*] - apply RACI
• Who knows about This? [*] - designer, developer, archivist, documentation-keeper, subject-matter expert (SME), supernode etc
• Who are the stakeholders for This? [* ]- extend out into the organisation, and further outward to the market and extended-enterprise
• Who might be anti-clients for This? [*] - ‘inherent anti-clients’ (e.g. environmentalists vs oil-industry), ‘betrayal anti-clients’ (identify risks that might lead to sense of ‘betrayal’)

Some questions about composition, decomposition and implementation:

• What is another variant of This? [*] - info about siblings or alternate paths
• What are the components of This? [*] - decomposition into sub-services
• How do we implement This? [v] - implementation-detail, sub-services etc

Some questions that use the SCORE method for strategy/tactics review:

• What are the strengths of This? - SCORE assessment – crosslink to Challenges, also risks, opportunities, effectiveness
• What are the challenges for This? - SCORE assessment – always crosslink to Strengths, also risks / opportunities / effectiveness
• What are the risks for This? - include ‘normal’ risks plus kurtosis-risks; always crosslink to opportunities, plus strengths / challenges / effectiveness
• What are the opportunities for This? – include ‘normal’ opportunities plus ‘Black Swan’ / ‘Blue Ocean’ opportunities; always crosslink to risks, plus strengths / challenges / effectiveness
• How do we enhance the effectiveness of This? - sub-questions on Efficient, Reliable, Elegant, Appropriate, Integrated

Some questions around requirements, conflicts and dependencies:

• What is the pain around This? – describe the pain-points that underpin requirements for change
• What are the requirements for This? – describe the requirements (functional and qualitative), the authorities for those requirements, etc (e.g. as per Volere requirements-template)
• What conflicts with This? [*]- list other services or requirements, and the nature of the conflict
• What depends on This? [*] - list the dependent services or other items, and the nature of the dependency

Some questions around the lifecycle of the item itself:

• What is the history of This? – describe past versions, past uses (outline an as-was to as-is)
• What is the future for This? – outline intended future versions, uses etc (develop an as-is to to-be)
• What is the lifecycle for This? – what creates, reads or references, updates, deletes or disposes of this? (or, optionally, the lifecycle IN This – the lifecycle of whatever this service acts on, i.e. a CRUD usage-lifecycle)

And finally (for now), some questions that focus on narrative-knowledge and the narrative aspects of enterprise-architecture and service-design:

• Tell me a story about This?
• What is a use-case for This?
• What is a scenario for This?
• What is a customer-journey that uses This?

(Typically we would record those stories in freeform format, perhaps as an audio- or video-recording attached to the item-entity within the toolset.)

Obviously there are many, many other questions we could ask in the same way – though remember that part of the aim here is to support modelling with Enterprise Canvas. The key theme throughout is that it’s about creating engagement in the architecture – this isn’t done solely by people with an ‘architect’ job-title, but anyone at all, in a form and format that is usable by just by anyone, even in the midst of their everyday work.

More later on how we could apply this in practice – but any comments for now on the basic idea?

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?

A follow-on to the previous post ‘Where do we start with EA? – a practical question‘, to address a number of comments and questions that came up via the Twitterstream.

Again, I’ll keep the emphasis on the ‘how-to’, and hold back on the theory this time. (Have a wander elsewhere through this blog for the theory-bit! )

A quick reminder about the context of the previous post. A colleague of mine, Alan, has found himself in a new job, company and industry. What’ he’s used to doing is IT-oriented ‘enterprise’-architecture for utilities-management. His new company is in retail and e-retail – a lot of IT, sure, but a fundamentally different type of business, for which a conventional IT-centric version of EA may well be more of a hindrance than a help.

So the recommendation in the previous post was to start off with a focus, in parallel, on five distinct themes:

• the politics and pragmatics of architecture
• setting the stage – the ‘big-picture‘
• finding allies – people who know ‘the trade’
• establishing standards
• finding the story

The post gave a quick summary on each of those themes – enough to get started, I’d hope, though obviously each could be a book (or several) just in itself.

What followed in the Twitterstream was interesting. Some of it was from Alan, some from others – I’ll paraphrase a bit to protect people’s identities and get it into a more usable sequence:

• I know I can’t get same performance as last job right now, but feeling frustrated with this low performance at start.  // I doubt they have same background, it’s new for everyone on strategy/leadership side.
• First week there: trying to find some point to start, there is no architecture there yet. //  I need some kind of quick-start to show EA value first. // I’m trying to start with TOGAF, but is so big for a people without EA culture.
• Everything depends on environment you’re in (culture, timing, IT strength) to propose a quick move
• Is dangerous trying to say something execs want, and end up doing something wrong. Get to know background first // What is the company mission/vision here? – is a good start for any EA.
• So, need to be calm, take a deep breath, do baby-steps on each thread with execs’ participation?
• Do you know why PEAF doesn’t have Security and Governance principles examples on this “starter-set” ? // Maybe new edition of the PEAF book soon with these principles?

Let’s explore each of those in a bit more detail. (From here on I’ll use a ‘you’-format rather than ‘we’, for simplicity and to make it more direct, but it’s important to realise that this is generic, not solely advice to a single person.)

First, about frustration. Yeah, that’s very real at this point. The short answer is that it’s normal, absolutely to be expected, nothing wrong with it, yet you do have to deal with it, because the bald fact is that this is going to take time.

A good enterprise-architecture is a kind of conceptual infrastructure: and without it it, you are going to get poorer performance: no doubt about that. But like all infrastructure, it’s easy to not notice it, or to forget about all the effort that went into building it. The one time you do notice it is when it suddenly isn’t there…

It’s really easy to blame yourself here for poorer performance, to think that the poor performance is somehow your fault, your responsibility. But don’t, because without that infrastructure in place, you’re in a situation of ‘reduced response-ability’ – literally, a reduced ability to respond. The responsible action at this point is to deliver the best that you can within the constraints of that inadequate infrastructure, and set out to enhance that infrastructure. Which is exactly what you’re doing. But yes, it will take time, and effort, and everything else.

Getting lost in frustration won’t help. Saying that the infrastructure ‘should’ be there already won’t help. What will help is “be calm, take a deep breath, do baby steps”, and follow the programme. Which is exactly what no-one wants to hear, I know – but unfortunately it is the only way that works.

The need for a quick-start is very real. We need quick results, but above all we need to get the interest and, if possible, real excitement, going right from Day 1. We have to make sure that EA matters to everyone, in their context, their workspace – because without that engagement and excitement, this ain’t goin’ nowhere.

I’ll have to be blunt about this: don’t try to start off straight away with TOGAF, or any of the other ‘heavyweight’ frameworks. They do have very real value, in later stages of EA (though often only in specific sub-domains of EA). But at the start, as that comment in the Twitterstream makes clear, all they’ll do is scare people off. For this earliest stage, we need something simpler.

I usually describe EA-development in terms of six distinct steps:

• Step 0: Get started (initial setup to do EA at all)
• Step 1: What business are we in? (big-picture)
• Step 2: Clean up the mess (horizontal optimisation)
• Step 3: From strategy and execution (top-down)
• Step 4: This is the real-world calling (bottom-up)
• Step 5: Resolving the pain (spiral-out)

TOGAF and the like tend to come into their own in Step 2 and Step 3: the old TOGAF 8 was excellent for Step-2 clean-up of the IT infrastructure and application-landscape, for example, whereas TOGAF 9 is more focussed on Step-3 strategy and the like. But before that happens, we need to have done the Step-1 work of establishing the enterprise-context (which TOGAF’s so-called ‘Business Architecture’ does not do well); and before that, we need to have established, in Step-0, the reason and desire for doing EA at all (which TOGAF’s ‘Vision’ is probably supposed to do, but doesn’t). And it’s in that very first proto-step that PEAF in particular comes into its own.

Do take a look at PEAF’s structure, especially its startup phase. To me at least, PEAF doesn’t compete as such with TOGAF or the like, because it describes what you need to do before going anywhere near any of the ‘heavyweights’.

And what PEAF emphasises is that the very first step after someone in the organisation decides to do something about EA is a first-stage training, education, above all communication. In PEAF, that first-stage introductory workshop includes slidedecks for each of these topics:

• EA – Why I Don’t Need It
• EA – Frameworks
• EA – Enterprise Debt
• EA – Model vs CMDB
• EA – Traits of an Enterprise Architect

It’s structured so that senior execs need be there only for the first few items: in particular “Why you don’t need EA” and the core concept of “Enterprise Debt”. The more detailed information is relevant only to those who need to be more actively involved in everyday EA.

[Notice the unusual negative, 'Why you don't need EA': it's a deliberate 'anti-sell', showing the value of something by being open about where it does not add value - and not presenting it as 'The Answer To Everything', as happens so often elsewhere...]

Perhaps the most crucial point is that there is a step-by-step process here: and it really is important to follow those steps, because that sequence and content is the end-result of a very careful study of what doesn’t work…

The ‘executive’ part of that workshop is no more than half a day; the remainder of that entire process probably doesn’t take much longer than a week of elapsed time. In other words, it’s not a lot of work. But you cannot skip it: more to the point, if you do skip it, you can can guarantee that the enterprise-architecture will be going nowhere, slowly, with a lot of frustration. Your choice, really…

Getting to know the background is also crucial, though most of it will happen after that first ‘Step-0 stage’ proto-step. In the previous post, this is what ‘setting the stage’, ‘finding allies’ and ‘finding the story’ were all about. The summaries from the previous post should be enough to get started: for example, the ‘setting the stage’ theme must include concerns such as identifying vision, values and mission – and also being clear about the crucial difference between ‘the organisation’ and ‘the enterprise’, because they’re not the same.

Another really important point here: don’t fall into the ‘TOGAF Trap’ of describing enterprise IT-architecture (EITA) as ‘enterprise-architecture’ (EA). Everything up to this point has been, and must be, about real whole-enterprise architecture – because we must establish the overall scope before we can focus in on any specific subset such as EITA or security or business-architecture or process-architecture anything else. If we constrain the scope too early, we’re then left with no adequate means to connect to the other domain-architectures – which again would guarantee architectural failure, especially over the longer term.

[This, by the way, is another reason why we don't try to use TOGAF for EA until such time as we do want to focus specifically on the IT-related domains. It's very good for EITA, but way too constrained for real-EA: it's really important to understand the difference!]

The other theme, around principles and standards, is something that we shouldn’t worry about too much until we’ve already gone some way down the track. This is why a question such as “Do you know why PEAF doesn’t have Security and Governance principles examples on this ‘starter-set’?” kind of misses the point. In its current design, PEAF’s primary role is at that Step-0 / Step-1 stage, when we’re still only just starting out: and at that point the only thing we need to say about principles and standards is that we are indeed going to need principles and standards, and how to apply those principles and standards to real-world practice. That’s it. Hence the example-principles in PEAF are just that – they’re examples.

Any competent architect – which you would be, if you’ve been in an EA role for some while elsewhere – will know that yes, we will definitely need Security and Governance principles. But in the early stages – particularly the Step-0 ‘Gain Agreement’ stage of PEAF – all you need to do is add them to that list of examples. It doesn’t need anything more that that, for that stage.

Later on, yes, you’ll need a lot more detail. And that’s the point at which we would start to use something like TOGAF, because it does have a very good descriptions of how to specify principles and define reference-architectures and their related standards. But we don’t try to do that too early: all it’ll do is confuse people, drowning them in too-much-detail and putting them off, just at the point when we need to gain their engagement.

So, quick summary: find a way to live with the frustration, because it’s going to be there for a quite a while, whatever you do; and do settle down to do everything step-by-step, because it is the only way that works.

Hope this helps, anyway.

You’re an experienced enterprise-architect, having spent most your working life in one industry. You now have a new job, in a new company, in an industry that’s entirely new to you. And the company at present has no architecture at all: you’re ‘it’. Where on earth do you start?

That’s the situation my friend Alan finds himself in right now. An interesting challenge – and some very real, very practical questions to face. Right here. Right now. Today.

[I guess this post can also start to answer in part the question from the previous post, 'How do we make EA make sense?'.]

So: in essence, we start from scratch.

Which means that several threads need to start straight away, somewhat in parallel:

• the politics and pragmatics of architecture
• setting the stage – the ‘big-picture‘
• finding allies – people who know ‘the trade’
• establishing standards
• finding the story

The first point is that everything about any form of enterprise-architecture is intensely ‘political’, in several different senses – which means we need to face the politics of this straight away, right from the start. One of the best guides to this is Kevin Smith’s PEAF (Pragmatic Enterprise Architecture Framework). In essence, it’s a step-by-step guide on how to get enterprise-architecture going within an organisation: see the website and book for more details. [Disclaimer: I edited the book.] The details are all there on the website anyway, so you don’t even have to buy anything (though no doubt Kevin would like it if you did! ).

Probably the single most important concern is to get ‘buy-in’ at senior level – certainly from the respective CxO for the main focus area (e.g. the CIO, for enterprise IT-architecture), but preferably from the CEO and entire executive. To be blunt, if you don’t have that ‘buy-in’, you’ll be going nowhere: you need to get the executive on-side.

As PEAF emphasises, the key to getting the executive on-side – and everyone else on-side, too – is communication. One valuable aspect of this is to get them personally engaged in describing the big-picture of the overall ecosystem in which the organisation operates, and where the organisation fits within that ecosystem. In effect, what we would do here is identify the high-level ‘why’ for which the organisation is a ‘how’ – in other words, the ‘why’ that provides the anchor for all of the organisation’s strategy.

There’s a lot of detail on how to do this in the chapter ‘Step 1: Know your business’ in my book Doing Enterprise Architecture – that chapter is part of the ‘sample-ebook’ version that you can download for free from here. (See the post ‘Tools in action‘ for some photos of those techniques in live use in an executive-level workshop.)

What I also usually do is plough through the publicly-available sources such as the organisation’s website, publications, advertisements, intranet and annual-report. There’s usually enough information there to build some preliminary models with which to get started: or at least, enough for people to tell us that the models are wrong – which is a nicely sneaky way of getting them engaged in telling us their ideas about what it should be. :-) You’ll also notice in that ‘Tools in action’ post that we included people’s own photos on some of the larger wall-mounted models: this again is a good way to get people engaged, and to get conversations going between them about what they can do to improve their own work-context.

Whilst we’re doing this, we need to be looking for any allies – people who are already committed to other themes that connect with enterprise-architecture, and would be likely to see the value of synergy between those areas of interest. This is really important if we’ve only just started with the organisation, because – in my experience, anyway – enterprise-architectures depend greatly on person-to-person conversations and connections: knowing who to talk with, and how to talk with them, will depend in turn on backgrounds and credibility and personal-networks within that organisation that typically take at least five or more years to develop.

Those are people we need as allies: and finding them is one of our first and most urgent priorities as soon as we start work at new place. One tactic I’ve used for this is to sit in the cafe or whatever with a few interesting-looking diagrams spread out over the table: anyone who’s interested enough to stop by and chat is likely to be that kind of ‘connector’, or will at least know someone who is. Again, despite all those models and the rest, what really drives the architecture – what makes it happen, in real-world practice – is person-to-person conversations.

Another concern that those allies can help us with straight away is in identifying the standards that apply in the context. Some standards would apply to just about every industry, but we’d be likely to know those already. Other standards will be generic for the industry as a whole, but they’re usually not hard to find: for example, for this case, in retail, a quick web-search on “retail reference architecture” turned up a swathe of IT-oriented standards from Oracle, Microsoft, Cisco and IBM, together with articles on how to put them to practical use. This is also where TOGAF and the other enterprise-architecture ‘usual suspects’ will start to be of real value – though to be honest they can often be more of a hindrance than a help before this stage.

What we’re also looking for are all the other standards and guidelines and workarounds and the like that are specific to this organisation, some of which – perhaps many – may not exist anywhere in any written form. And that again is where our allies can be really helpful, because otherwise we’d have little chance to know what these are. (And yet everyone else would expect us to know them, because, after all, we are ‘the architects’, aren’t we? – we’re the ones who are supposed to know all this stuff… )

And we’ll also need to be on the lookout for standards that should be there, and aren’t. Which can be a little bit tricky, from a political perspective – not least because it tends to highlight issues that people ‘should’ have known about already, and didn’t… Once again, our allies will be invaluable here, in finding suitably-stealthy ways to introduce these ideas, and to smooth out any ruffled-feathers that may arise.

One trap to watch for is to beware of bringing too many assumptions from our previous organisation and industry: many of those assumptions will not work in this new context. The skills and experience of ‘how to do architecture‘ are probably the only part of the work that will remain unchanged: we need to able and willing to challenge ourselves on just about everything other than that.

Almost all of that above is about enterprise-architecture as structure. The other side is about about architecture as story, the second of Matthew Frederick’s ‘two points of view‘ on architecture:

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

Although hardly acknowledged at present in mainstream ‘enterprise’-architecture, this is enormously important: story is emotive; story embeds meaning; story engages. Stories matter: in a very real sense, everything about the architecture is or represents or describes a story. Even the enterprise itself is a story. Which means that it’s well worth while to go ‘looking for the story’, much like a journalist or filmmaker or any other storyteller would.

What I usually do for this is ‘go for a walk’, either metaphorically via the website and intranet and so on, or – preferable – literally go for a walk, in person or with one of my new ‘allies’, around some of the organisation’s sites and spaces, looking for all of those interweaving stories that hold everything together. Some of these stories are straightforward enough: every transit through a business-process is a story; every customer-experience or ‘value-journey’ holds a story; every transaction is part of a story that extends far beyond the transaction itself.

Yet there are also the many stories that employees and others tell themselves, and tell each other, about what works, about what doesn’t, about what is or isn’t valued in practice within the organisation, about workarounds or special-cases that no-one’s gotten round to documenting but without which the store or warehouse or whatever won’t work. Those stories are often really important from a structure-perspective, too.

And there’s the story – or stories – that the organisation tells about itself, about how it positions itself in the market, about what it values most and would most like to share with others; and the stories that others in turn tell about the organisation – including whether they believe that the organisation holds to its purported values. Those last stories are some of the most essential real-world feedback for strategy – which in turn feeds back into changes in structure, in the what and how and where and when of the conventional enterprise-architecture.

Best stop there for now, I guess. But, yes, starting a new architecture is always a real challenge – yet always an interesting and worthwhile one!

I hope this has been useful, anyway: and good luck!

How can we ensure that the ideas and models that we use are appropriate to the context? What methods can we use to evaluate new ideas? Perhaps more to the point, how do we protect ourselves from ideas that won’t fit in our architecture-ecosystem?

This extends the previous post on ‘Coping with the toad-in-the-road‘, where the ‘toad’ is “a clear, simple, easy-to-understand wrong answer” – in other words, something that isn’t appropriate or useful in the context.

(Again, I want to emphasise that the ‘toad’ here is an out-of-place idea or model or theory – not a pejorative description of a person!)

In general I use the idea of a ‘living system’ as my core metaphor for an enterprise – which in turn suggests other metaphors such as an ecosystem or, on a smaller scale, a simple suburban garden.

So imagine that the ‘garden’ describes the ways in which we ourselves do our enterprise-architecture. It’s a garden of ideas and models and tools and techniques – an environment for ideafarming, perhaps. Some people’s gardens might be formal, constrained, regimented, rather like that at a classic French chateau. Other people’s might be large enough to contain the kind of sweeping vistas of which Capability Brown might be proud. I’d have to admit that my own idea-space is, uh, a bit more eclectic? – the style sometimes referred to as cottage garden’, with its own definite charm and vibrancy and bright colours everywhere and occasional surprising juxtapositions, but with so much semi-intentional ‘unorder’ that some people might at first see it only as a mess. Oh well.

Whatever the style of garden, though, we need to be careful what we introduce. Some ‘good ideas’ can run rampant if they’re let loose in the wrong place: consider the damage done by now-wild rhododendrons in northern Wales, or gorse (furze) or rabbits in Australia. Which, in turn, brings us to the metaphor of the toad-in-the-road.

I like toads. We used to have one that lived very happily for years in the laundry-drain just outside the house: we had to remember to take it out of there before we did any washing, and politely put it back again afterwards. (True story. ) They’re often very long-lived; some can survive drought for decades, hibernating in a little patch of damp somewhere beneath the surface, popping up again as soon as the conditions are right. And although there are some toads that we won’t want in a garden – or anywhere, really – most of us wouldn’t mind a toad that will fit in well with our ecosystem. Toads are wonderful for keeping down the slugs and other garden-pests: if we have a strawberry-patch, we definitely want a good toad. But we don’t want that toad in the road – or anywhere else where it doesn’t fit, is probably putting itself at risk in any case, and is demanding our attention when we could really do without it being there.

Hence, the same with ideas that are out of place for the context: the metaphoric toad-in-the-road.

It’s not ‘an elephant in the room’. It’s not ‘an eight-hundred-pound gorilla’, or ‘a bull in a china-shop’. It really is quite small: it’s just a toad in the road – an idea that’s in the wrong place. (If it was in the right place, it’d be back under the strawberry-patch, happily munching on slugs. Metaphorically speaking, anyway.) But it somehow looms much larger in our attention than it really is – especially when it’s sitting out there, in the road, in the way, and generally making a right old nuisance of itself. Sigh… “oh no, not again”… yep, that kind of feeling.

In the previous post, I came up with a list of four categories of toad-in-the-road:

• the friendly toad that gets in the way a bit, but is really useful in the right place
• the not-much-use-for-anything toad that gets a bit too much in the way, especially when it’s over-excited
• the bloomin’-nuisance toad that we’re best off to toss out of the garden, and keep out as best we can
• the darned-dangerous toad that we need to keep out of our space at any cost

In reality, though, there aren’t any categories as such: they’re all toads, each with their own characteristics. And in terms of working out what to do with the toads – especially those that have just arrived in our garden – it might be more useful to take a somewhat different approach:

• what is the natural habitat for this toad? [where does this idea or model really belong?]
• are there any seasonal concerns, such as mating-season? [where is this idea in terms of the 'hype-cycle' and the like?]
• are there any behavioural characteristics of which we need to be aware, such as aggressiveness or excessive timidity? [in what ways is this idea promoted, and by whom?]
• is it likely to be toxic or invasive in our ecosystem? [does this idea tend to destroy, override or block out other more-useful ideas?]

Every toad-in-the-road has its own distinct combination of these themes – and the combination will usually vary over time or context, too. Hence it’s probably more useful to take this approach than some overly-simple set of categories.

Every idea has its own habitat – the place or context where it would most naturally fit. When evaluating a new idea, a key part of that task is to identify where it claims to fit, versus its ‘natural’ fit – because often there’ll be a mismatch. In many cases, the mismatch will arise from a conflict on terminology: a term that has a specific meaning in one context has a significantly different meaning in another context – which creates a toad-in-the-road when the previous meaning is carried through to the new context.

One example from the previous post was Roger Sessions’ work on minimising ‘complexity’ in IT-systems: it’s a very good idea that does make sense in an IT-context, where ‘complex’ is a kind of synonym for ‘extremely complicated but controllable’ – but it doesn’t make sense in non-IT enterprise-architecture, where ‘complex’ means something that, by its nature, cannot be controlled. In that sense, its ‘natural habitat’ is IT: we need to ensure that it’s only used in IT, and gently dissuaded from wandering anywhere outside of that domain. We might describe that as negotiating with the toad to help it find its way home.

Some of the most useful ideas are ‘mash-ups’ – a fertile hybrid resulting from a re-mix or re-use of an idea in another perhaps-’unnatural’ habitat. Perhaps the most important point in evaluating these is that it’s technology, not science – almost by definition it can be unlikely to make sense in strict ‘scientific’ terms, because it’s doing a mix-and-match across domains. For the same reasons, evaluating such ‘mash-ups’ may require quite a lot of contextual skills and experience – a lot more than the simple logic-proofs that apply in the straightforward ‘exact-sciences’. We should also note that whilst people who are over-enamoured of science-like certainties may rail against ‘miscegenation’ and the like, fact is that ‘mix-and-match’ is an important part of evolution, and hybrids often bring vigour back into a tired environment.

We don’t have to look far to find examples of valuable ‘mash-up’ ideas: they’re common in almost every environment, though in some cases they have to be hidden for a while from the ‘truth police’ until they prove their value – the story behind the discovery of quasicrystals, which won the 2011 Nobel Prize for Physics, being one infamous example of the latter. (We also see fascinating examples in the natural world: for example, blue-tits and other small birds taught each other how to peck through the metal-foil caps on milk-bottles in Britain to get at the cream underneath.) Mixing metaphors a bit – and why shouldn’t we, in this case? – we might describe this as an ‘ugly duckling’ kind of toad: we need to work with the toad to help it find out who it really is and where it would truly belong.

Some ideas are just plain wrong – often because there’s not enough rigour or muscle behind them, or because they’re a kind of sterile hybrid from the wrong kind of re-mix. This, of course, is the flip-side of ‘mix-and-match’: many of the mash-ups just won’t work in any domain. The evaluation-rules will vary according to context – science for science, art for art, and so on – so we need to take especial care when an idea bridges across domains, whence multiple and often conflicting evaluation-rules would apply.

An example of a cross-domain mismatch – also mentioned in the previous post – is the notion of ‘engineering the enterprise’, embedded in parts of the Zachman framework, implicit in almost all of Taylorist ‘scientific management’ and its derivatives, and also in many of the ideas about ‘enterprise ontology’. This notion might make sense if ‘the enterprise’ was some kind of machine: but by definition it’s a human construct – “the animal spirits of the entrepreneur” and suchlike. The only way that ‘engineering the enterprise’ can be forced to make sense is if we force people to act as if they’re machines – which rarely delivers good outcomes for anyone. Sadly, once we’ve evaluated this kind of idea and found that there really is no way it could work, the only kind thing to do is put it out of its misery: we could describe this as respectful euthanasia for the toad.

Some ideas may be too simple to survive on their own – usually the result of too much repetition in the same place, slowly wearing away all of the useful rough-edges and exceptions. Simplicity is not inherently a problem – in fact it’s often of real value when we look for a starting-point for new hybrids, or a mix-and-match to address true complexity. What we’re evaluating here is the crucial difference between ‘simple’ – which often isn’t simple at all – and overly-simplistic – which isn’t much use to anyone.

Every ‘law’, ‘rule’ or ‘regulation’ – whether scientific or otherwise – is an abstraction of some kind, a simplified version of some aspect of the real world. There are no shortage of examples: in most contexts we’re surrounded by them, everywhere we look, and there’s no question that they do usually make work and life more simple. It can become a toad-in-the-road, though, whenever anyone starts to believe that the world really does work accordance with that purported ‘law’ or whatever: because the blunt fact is that the real world is rarely that simple. If it is too simple, yes, it does still have its uses, but we need to acknowledge its limitations: we could describe this as finding a sheltered space for the toad, protected from the rough-and-tumble of the real world.

Ideas may have their own seasons – often following the ‘hype-cycle’ or some other lifecycle. For any new idea, the early part of the hype-cycle is like a breeding-frenzy – and however useful the idea may turn out to be in the longer term, we’re not going to get any sense out of anything until that mating-season is over. We need to catch the idea either before the breeding-frenzy starts, or wait until all the dust and hype settle down again.

On the IT side of enterprise-architecture right now, obvious examples include the hype around cloud-computing and IT-consumerisation and, of course, the wild proliferation of ‘certification schemes’ (or scams, as some would put it…). For business-architecture it’s all the excitement about business-models rather than business-plans. We can also see that previous breeding-frenzies around ideas such business-process outsourcing, Agile development or Six Sigma have faded back enough for us to be able to evaluate what aspects might be useful in specific contexts. But whilst the breeding-frenzy is in full flow, just about all we can do is put up large warning-signs, and hope for the best.

(By the way, that triangular symbol above is the standard ‘Migratory Toad Crossing Ahead‘ warning-sign: UK DOT 555.1, to be precise. An essential item for your enterprise-architecture office! )

Ideas can be aggressively territorial – it ‘hogs the space’, blocking out everything else. Often this will be associated with a ‘term-hijack‘, where a narrow subset of a context is purported to be the whole of that context – actively blocking out any view of the rest. These types of ideas can be a serious pest, because they’re so busy claiming and defending ‘their’ territory that they can make it all but impossible for other often-more-useful species in that ecosystem to survive. When evaluating new ideas or models, we need to test for any such tendencies: these are usually typified by over-simplification or over-certainty, endless repetition of its catch-phrases, habitual attempts at term-hijack, and a strong tendency – sometimes backed by force – to redirect any straying attention back to itself.

In enterprise-architecture, the most obvious example at present is the IT-centrism inherent in TOGAF and the like, though a new ‘business-centrism’ is also now coming to the fore. In both cases the underlying driver – in addition to the rather pointless ‘need’ to dominate the entire ecosystem – is an overly-simplistic misuse of the notion of a ‘centre’ to the architecture. (In reality, there is no single centre to the ecosystem, but rather that everywhere and nowhere is ‘the centre’, all at the same time.) There are all too many other examples of the ‘territory-grab’ problem, of course, in just about every aspect of enterprise-architecture. As for tactics, we may need to put up metaphoric warning-signs – as for any idea’s breeding-frenzy – but our best approach here is to always emphasise the whole ecosystem, and adjust the structure of ecosystem as necessary to dissuade this toad’s dominance.

Ideas can be too noisy in the way they promote themselves – ‘too noisy’ in the sense that, again, they drown out out other potentially-valuable ideas, but more by actively demanding our attention rather than blocking our view of everything else. This tends to happen a lot when the hype around some new idea is building at full blast, and especially so where the idea is forcefully promoted by some charismatic figurehead. It’s difficult to evaluate any ideas at all when we can barely hear ourselves think, let alone hear about anything else…

A good example for enterprise-architecture was all the hype around the earlier versions of Andrew MacAfee’s ‘Enterprise 2.0‘. The notion of using social-network software within a business was – and still is – a good idea: but the initial over-focus on technology above everything else was plainly absurd, and describing it as ‘Enterprise 2.0‘, implying an entirely new kind of enterprise, was even worse – a ludicrous if largely-unintentional term-hijack. But again, this is only one of all too many examples: the current over-hype of ‘anything-Cloud’ is another ‘noisy toad’ that we’re dealing with right now. Probably the best tactics here are to block out the sound where necessary, and emphasise our other senses instead.

Some of the most useful ideas may be too quiet for us to notice – the converse of ‘too noisy’. There are a lot of good, useful ideas out there: but they’re often so diffident and quiet that it can be difficult to identify their potential value to our ecosystem when we find them, or even to find them at all.

For me, in enterprise-architecture, one example would be Nigel Green‘s VPEC-T. Another would be the stream of ideas on sensemaking and the like on Cynthia Kurtz‘s StoryColoredGlasses website, and especially her crucially-important concept of ‘unorder’; which leads in turn to the work on business-story work by Shawn Callahan and colleagues at Anecdote. Everyone has their own examples, no doubt. But given the cacophony and near-chaos that’s always around us in the idea-garden, we do need to make a deliberate effort to understand the deeper needs of our ecosystem, and keep our eyes and ears and other senses open for the ‘the quiet ones’ that often matter most.

Some ideas are naturally toxic – they make it impossible for other ‘competitor’-ideas to thrive, or even survive, in that context. These are the cane-toads of our idea-garden: and whilst any idea can be toxic in some sense, it’s especially common with out-of-place paradigms, because by definition they purport to be a complete or final ‘the truth’ about the whole of a ‘world’ – and hence will always attempt to exclude every other possible view. When evaluating new ideas, we need to note how much they depend on asserting that something else is ‘wrong’ – and if so, why. We also need to identify the contexts to which it does apply, and which it doesn’t – because any ‘territory-grab’ beyond its natural context will automatically tend to make it toxic to other more-useful ideas in that broader space.

There’s a subtle point to watch here. In a sense, any idea that’s over-territorial or even over-noisy is sort-of-toxic: it will certainly tend to block out everything else, for a while at least. But in the case of ‘cane-toad’ ideas – truly toxic ideas – it’s not a behaviour as such: more that they poison everything, just by their very existence. As I said in the previous post, we probably don’t have many true ‘cane-toads’ in enterprise-architecture as such – though IT-centrism certainly comes close – but in the broader business sphere and beyond, such ‘cane-toads’ definitely do exist. Examples include the near-feudal concepts that still dominate most management-models; the absurd over-obsession with money as a measure of value in business; the insanely-inadequate notions of ‘economics’ on which our world supposedly depends; and, going deeper, the dangerous delusions of ‘rights’ and, deeper still, the all-pervasive, ever-pernicious paradigm of possession. (Those last are so toxic that, to be blunt, we need to kill them off before they kill us all…)

We do need to careful not to harm something that’s simply out of place, so for most ‘cane-toads’ the preferred tactics would be to isolate and remove, and publish warnings to other ‘gardens’ about the risk. Yet for any lethally-toxic toad – one that poses an existential threat to every ecosystem – the only safe tactics are to eradicate and exterminate entirely: and we do need to face up to the fact that on rare occasions that is the only option we have.

Many ideas can hibernate, re-emerging whenever the conditions seem right – and we need to note that this applies even to the most toxic of ideas. Every ‘toad in the road’ is “a simple, clear, easy to understand wrong answer”: and because they’re simple, because they seem clear, and because they’re easy to (sort-of) understand, that tends to make them very attractive, and very popular. Which means that despite the fact that they’ve long been identified as a ‘wrong answer’ – in some cases a ‘wrong answer’ for any question – they still on keep coming back, and coming back, and coming back, like a toad re-emerging with the rains after a drought. The catch with ‘idea-toads’ is that they often change their surface-appearance each time: but underneath it’s the same mistakes, the same old shallow, stupid, over-simplistic ideas – hence that dread feeling of “Oh no, not again…”.

For our discipline, probably the classic example is Taylorism – or rather, the vapid belief beneath its supposed ‘scientific management’ that everything can successfully be made subject to a simplistic sense of ‘order’. We know it doesn’t work, other than in quite narrow and clearly-constrained contexts: that fact has been proven time and time again, not least by Deming and others at the ‘front-line’ of production and elsewhere. But the same mistake still keeps coming back, time after time, for the simple reason that people want to believe in the myth of ‘control’. Hence, for example, Davenport and Hammer & Champy’s ‘Business Process Reengineering‘, an almost unmitigated disaster – other than in the few cases that didn’t try to use technology as the sole basis for complex business processes. Hence, for example, the many misapplications of Six Sigma, which by definition only makes sense in a context where there are literally millions of identical events. And hence, at present, the sad struggles of proponents of ‘business-rules engines‘ to get them to deliver any real value in business-contexts that, again by definition, are often inherently beyond any feasible rules’. Oh well…

For any of us blessed – or cursed – with long memories, dealing with the vampire-like return of yet another formerly-vanquished toad can be both sad and extremely frustrating. So in evaluating any supposedly-’new’ idea that has aspects that we sense we might have seen before, we need to check its anatomy and underlying structure – and we need to be especially careful to do so whenever the conditions are right for the return of any well-known toxic-toad.

Ideas may take on any combination of these characteristics – and the combinations may vary even for a single idea in different contexts or in different stages of its lifecycle. In evaluating ideas, and testing for a potential ‘toad in the road’ we do need to be careful of applying assumptions that themselves may not be valid in a different time or place. We also need to respect the nature of the toad itself: applying ‘scientific’ criteria to evaluate an artistic idea has never worked well – and the inverse has rarely been much use, either…

We see a lot of these ever-changing combinations in enterprise-architecture. For example, IT-centrism is a Simple idea that keeps re-emerging from the depths, no matter how much we push it away; and as soon as it appears again, it has an immediate and usually very-noisy mating-frenzy with whatever the current technology might be. It’s much the same with Taylorism, as above. Right now, the ‘big noise’ is around ‘cloud-computing’ and related ideas such as ‘platform-as-a-service’ – which, once we think about it for more than a minute or two, is just a current hybrid of some very old ideas (centralisation, service-orientation) and some somewhat-newer ones (access-from-anywhere, any-platform). So whenever faced with this, or any other ‘new’ idea, all we need to do is apply the various tactics described above – and erect the appropriate ‘Toad Warning’ signs wherever they’re needed.

Do remember, though, that it’s ‘Toad Warning’ – not ‘No Toads!’ (A nice shiny triangular sign, as above – not the more threatening circle-with-a-slash-through-it type of sign.) We like our idea-toads; and even if we don’t want to touch them (ugh…? yuk!), most toads are good – in the right place, such as out in the garden, protecting our precious plants from parasites and pests. So all that we don’t want here is – yikes! – a Toad. In. The. Road!

In short, be kind to your idea-toads, treat them well, treat them with respect, find them their proper place if need be – and remember, that next toad-in-the-road that you meet could well be one of yours…?

What do I do, and how do I do it? What’s the nature of my work, and the methods that I use? And for that matter, why?

That’s perhaps the shortest summary to a request by Anthony Draffin, in a comment to my previous post ‘Not quite bus-pass day‘:

On a selfish note… It’s apparent that the common thread to dowsing, printing and enterprise architecture is your ability to look at a field holistically and apply logical thought to extract inconsistencies and errors, as well as looking at new ways of doing something more efficiently to meet the original aims. That’s a rare skill. Have you given thought to documenting how you go about doing this? While I imagine it’s the application of a number of taught skills, the way you put these together must be far from ubiquitous. Have you considered teaching this? Personally, as a 27 year old, I want to soak up as much of your approach and thought process as you’re willing to offer.

(Warning, this is going to be another (very) long one, mainly because there’ll be several case-studies.)

Read more…

Given the responses to my previous post ‘Guess I could do with some help here…‘, seems it’d be useful if I clarify a bit more what kind of help I most need. (Or we need, rather, as an industry and discipline: probably the only ‘I’-part here is that I seem to be one of the few at present who’s asking these questions?)

To be honest, we don’t need much help in thinking about the nature of enterprise-architecture or the like: that’s already well covered, and it’s actually quite straightforward anyway.

Where we need help is in rethinking the toolsets that we use for enterprise-architecture and the like.

To me it’s clear that if we’re to make sense of the enterprise, and support viable decision-making about the true whole-enterprise-scope within which our organisations operate, we’re going to need some kind of holographic approach to modelling.

We already have plenty of frameworks for enterprise-architecture. We also have plenty of methodologies to work with those frameworks. Each of those is constrained to some variously narrow view into this holographic space, and usually constrained by placing some particular point as ‘the centre’ – hence IT-centrism, business-centrism, health-and-safety-centrism and so on. And those constraints are useful in practice: no doubts whatsoever about that. So to my mind there’s nothing whatsoever that’s inherently ‘wrong’ about any of those frameworks or methods, other than their own occasional internal inconsistencies and than that they too-often position their own very limited perspective on reality as ‘the only possible’ view on reality. That’s the only problem there, and it’s very easy to fix, by acknowledging the value of a single viewpoint as a viewpoint yet also insisting on cross-viewpoint generics. We can choose anywhere as ‘the centre’, for some given purpose, yet must also insist that everywhere and nowhere is ‘the centre’, all at the same time.

Hence, as such, we don’t need any new frameworks or methodologies for enterprise-architecture. We have more than enough of them already, to be honest.

What we do need are better ways to manage and make sense of the information we have about this ‘enterprise-hologram’.

Which is where toolsets come into the picture. And that‘s the part that I really need help on – or we need help on, rather, because it’s definitely too large a context for any one person, or even any one group, to tackle on their own.

What we need most is clarity on the question we’re aiming to address. I think it’s an Einstein quote that says “if I had an hour to solve a problem, I would spend the first fifty-nine of those minutes on the question, and only the last minute on the answer” – because the right answer tends to fall out all by itself when we have clarity on the question.

One thing we do know, though, is that there are many different players all trying to tackle different aspects of the same enterprise-holograph – for example:

• enterprise-architecture and all the other domain-architectures and solution-architectures – an emphasis on structure and purpose, and how they link together to deliver useful value
• knowledge-management – an emphasis on how knowledge-items link together (especially narrative-knowledge, stories and ‘subjective truth’)
• change-management – how everything changes and can be changed over time
• process-management – how activities link together, and entities flow between them, to add value across supply-chains, value-networks and so on
• service-management – the human and technical aspects of keeping everything going and ‘on purpose’
• futures and other business-intelligence – how to trawl through the enterprise-space for sensemaking and the like
• simulation, ‘gamification’ and other skills-development – how to apply ‘what-if’ to any part of the overall context
• skills-management – identifying the skills needed, and the training and/or recruiting needed to cover present or future gaps
• performance-management – identifying required metrics and their impacts (especially, to avoid ‘gaming the system’)
• governance – identifying requirements and responsibilities, assuring assignment and ability to comply, and verifying compliance

In principle, yes, they’re all views or viewpoints into the same overall context. Yet each of those views also carries information or requirements that are specific to that view alone – in other words, more like an orthogonal dimension. And there are a lot of those distinct dimensions in there – an n-dimensional space, where n could literally be any number. (Certainly a lot more than are accessible in the simple flat images so typical of so many current ‘EA’-toolsets, anyway.)

Then there are all the different uses for all those distinct views: an architectural view shows us relationships between structure and purpose, for example, but do we need that view to decide on future strategy, to plan investment, to compare different implementation-options in trade-off analysis, to guide scenarios and substitutions in planning business-continuity and disaster-recovery? The views we’d use might at first seem similar, but the focus and emphasis and model-dynamics in each case might be very different.

At first glance this all might seem impossibly huge. Yet it’s not as hard as it seems. Most of the technology we’d need to deal with all of this complexity does already exist. Despite the huge spread of the overall toolset-ecosystem, most of the key software components we’d need are already easily available, at little or no direct cost, running on a wide-range of easily-available existing devices. Conceptually speaking, the underlying data-structures are straightforward enough: for example, it could be done with little more than freeform tagging in an object-database of some kind, with some kind of filters applied to the tagging. The same applies to search, and filtering: pretty much everything we need already exists somewhere, if we knew where to look. And even if display-technologies are not yet quite capable of showing a true n-dimensional holographic space, they’re certainly capable of simulating one. Given the right people and the right ideas, the technology side really isn’t all that hard these days.

But if the technology isn’t hard, the user-experience part is hard. And seems to me that that’s where we most need to focus our attention at the moment.

In many cases, we simply don’t have the right metaphors for model-relationships:

• some of it can be usefully described as a matrix – but it’s definitely more than a simple matrix as per Zachman
• there are some contexts in which a metaphor of hierarchical layers will sort-of make sense – but it’s definitely more than a simple ‘stack’ as per TOGAF or Archimate, or even a multi-axis matrix-stack as per CapGemini IAF
• there are flows of information and materials – yet it’s much more than a simple supply-chain
• there are identifiable relationships, including realisation, aggregation and so on – yet much of it tends to follow a modal logic of possibility rather than solely a simple true/false logic of presence or absence
• there are identifiable trails of derivation and decomposition – yet there’s more to it than a simple Zachman layering, or the classic ‘current state’ versus ‘future state’

And perhaps more important, we don’t yet have adequate user-interface metaphors:

• drag-and-drop for entities can be misleading – is it a class or an instance? how do we link back an instance back to a parent class? are we editing the instance only, or the whole class? are we affecting other instances elsewhere? or other versions of the same nominal instance? what happens if the parent disappears over time, but the instance continues as re-linked to something else?
• notations can be confusing – especially where the same nominal entity would appear in multiple views with different notations or visualisations or images
• aggregation (as in Zachman primitives versus composites, TOGAF ABBs versus SBBs [Architectural Building Blocks versus Solution Building Blocks]) can be very confusing – especially where entities can recombine in many different forms, and at different levels of abstraction or realisation
• zooming (as per Prezi) works well to describe a ‘containment’ or hierarchical concept of structural-decomposition – but it’s hard to make sense, if entities aren’t fully ‘contained’, or if there are more than two orthogonal axes
• timelines (as in Gantt-chart relationships, or Apple OS-X Time Machine backup/restore) provide a good means to step through time-related views – yet the views themselves may change over time
• multi-axis user-controls work well for up to three or four exactly-orthogonal dimensions – but become exponentially harder to use with increasing numbers of dimensions and other variables, and probably cannot cope when the dimensions themselves blur into each other

In short, we urgently need new user-interface metaphors to navigate through n-dimensional holographic space, where the nature of the space itself may change as we go.

(Oh, and it has to be easy to use, too, such that both the navigation and what’s visible in the view will make immediate sense to anyone. Of course.)

To use another Einstein quote, “Everything must be made as simple as possible, but not more simple”. Simple to use; yet actively dissuade overly-simplistic ‘solutions’ such as IT-centrism and the like.

That’s the challenge.

And that’s also where Agile and the like come into the picture – and, most of all, people who are experienced in Agile-style software-development for toolsets and the like. We seem to have quite a lot of methodologists and the like around here, who tend to be great on the theory. But what we need most are developers who know how to think seriously-sideways and put it into practice.

We can’t just talk it into existence: we need to get past the ‘talking about it’ stage now. Given the blunt fact that we’re very unlikely to get it right first time, we need something to play with, to test in real-world practice, to review and rethink our ideas, to help us clarify what the question really is that we’re facing here.

More thinking-about-thinking, about the theory and the like, well, yes, we’re always going to need it, it’s always going to be a ‘nice to have’, and so on. But right now, we’ve done more than enough thinking-about-thinking: it’s time to get down to the doing, of creating this new kind of toolset.

Anyone interested in helping with that? Please?

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

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

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

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

Please?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

and

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

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

Thanks in advance, anyway.