Archive

Posts Tagged ‘enterprise canvas’

More on the ‘This’ game for enterprise-architecture

October 30th, 2011 1 comment

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?

This: an exploratory game for service-oriented EA

October 29th, 2011 2 comments

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?

Getting down to work in a different garden

October 16th, 2011 5 comments

When I said I was moving on, in the previous post ‘Time for this on toad to move on‘, yes, I was serious: I’m moving out of mainstream ‘enterprise’-architecture.

Am I giving up? No, not at all.

Am I actually leaving the entire enterprise-architecture domain? Nope. (Sorry to disappoint a few folks there, but you’ll just have to put up with that. :-) )

So what exactly am I doing, then?

All I’m doing here, metaphorically speaking, is that I’m moving along the road a bit: a few metaphoric houses up the road, if you like. Similar sort of work to what I’ve always done, in many ways, but a much bigger picture this time. A much bigger picture. I’m not going to be looking (much) at the ‘enterprise’-architecture of some small bits of detail-level IT any more: I’ll be looking at the ‘enterprise-architecture’ of the whole darn planet…

Arrogant sucker, ain’t I? :-)

In a way, yeah, of course it is, to say something like that. But if you look around on this blog and elsewhere, in effect that’s what I’ve already been doing, for years. All that’s really different now is that I’m making it a bit more explicit.

And to be blunt, looking around a bit, it really does feel as if I’m one of the few people anywhere who has a freakin’ clue about what’s really going on out there (answer: an MQ-9 mythquake [kind of like a worldwide Richter-9 earthquake, only worse]), what chance we have to stop it (answer: none at all), what won’t work (answer: just about everything we might think of as ‘normal’ or ‘business-as-usual’), and what might work (very-tentative-suggested-answer: something on the lines of a responsibility-based service-oriented enterprise model for a global economics, with systematic eradication of any concept of possession – including all concept of ‘rights’ – and total restructure of every possible aspect of politics at every level. In other words, just a few minor changes here and there… :-) ). Seems like there might be a real need, then, for someone with my kind of background in futures, social-dynamics, skills-development, creativity, complexity, innovation, sensemaking and strategy, across a whole swathe of different companies, climates, cultures and continents. Oh, and there’s also enterprise-architectures, of course: reckon that might possibly be useful, too.

Yes: a real big need for that.

Kind of a big anti-want for it, though.

A very big anti-want.

Oh well.

But no problem, really. Do I think I can make a living out of it? Nope, of course not: I’m not that crazy. But I’m not making any kind of viable living out of enterprise-architecture, either, so what’s the difference? As long as I can pay my way somehow in this increasingly-insane ‘economic system’, that’s all I’ll need. And given that I’ve survived somehow for all these years, without ever having suffered the indignity of being a so-called ‘permanent’ employee, I reckon I’ll manage to keep going for a while yet. Somehow. Doesn’t really matter that I don’t know how: the way things are going, pretty soon no concept of a ‘plan’ is going to make sense any more, so perhaps I’m just getting in early to beat the rush? :-)

Yeah, sure it’s lonely at times: I don’t have any real support at all, no family, no partner since literally decades ago, and at my age pretty unlikely ever again. Good: it means that there’s no-one else to get hurt on my behalf if I screw things up.

Sure it’s scary, desperately insecure: I don’t even have a home of my own any more. Good: nothing particularly to lose, then; nothing of that kind that can be used as leverage against me. And I can just up-sticks and go anywhere that I’m needed. Easy. (In principle, anyway… :-| )

I’m useless at organising anything, events, stuff like that. Good: instead of desperately pretending that I can do everything myself, let other people do that stuff instead – they’re much better at it than I’ve ever been or ever will be. Just do my part of the work, and let others get on with theirs. Simple. (Interesting challenges on trust, of course… :-| )

Turn every obstacle into an opportunity. Live this stuff that I’ve been talking about: rather than ‘making a living’, much better to go for ‘making a life’.

Crazy? Sure. Of course it is: never said it wasn’t. But then I come out of a family-background with a long anarchist-style tradition (of the more constructive if occasionally-quixotic Quaker variety, rather than the brainless bomb-throwing kind), and it’s about time I put those principles into real-world practice. Time to give something back – especially as, at age 60, I probably don’t have that many years left in which to do so. That fact matters, a lot. It also brings its own rather interesting sense of urgency…

So what does all this mean, in plain, ordinary, everyday terms?

Various things I won’t be doing:

  1. I won’t do any more work here on detail-layer analysis of IT-oriented ‘enterprise’-architecture such as TOGAF or Archimate (unless anyone specifically asks me for an opinion or whatever).
  2. I won’t be presenting myself for any more contract-work as an ‘enterprise-architect’. (I’ll still be available to do spot-work commercial consultancy or training for most types of EA, in just about any industry that isn’t finance, banking or insurance – but I will expect to get paid for that, every time.)
  3. I won’t offer any more ‘free’ advice on enterprise-architecture or whatever to people who can darn well afford to pay for it. (I’ll still be more than happy to help anyone in any other way – especially any of the upcoming ‘new generation’ of enterprise-architects.)
  4. I probably won’t be going to any more ‘enterprise’-architecture conferences, not least because I won’t be able to afford it (unless someone pays at least my expenses, of course).
  5. I won’t pander any more to people who to me seem arrogant, bullying, unwilling to think, and otherwise acting in an asinine or irresponsible manner (and yes, there’s been a lot of them I’ve put up with way too often over the past few years…)

Various things I will be doing:

  1. I will be doing a lot more research and exploration on ‘big-picture’ themes, developing new types of tools and techniques to tackle those issues in a much more constructive way than as at present; and working with others to develop new toolsets and training-materials for these needs. (It’d be nice if someone else paid for some of that work, but being realistic I wouldn’t expect it, unless anyone else that I’m working with is getting paid for it too.)
  2. I will be doing various types of consultancy-work with non-profits, citizen-groups and other organisations that are reaching towards a more constructive world. (Again, it’d be nice if I got paid to do some of that, but I’d only expect it from commercial organisations or government bodies, who should be able to afford to subsidise some of that other work at least.)
  3. I will show the EA community and others how to apply those ideas, tools and techniques, within the conventional business context, such as with Enterprise Canvas and the like. (It would likewise be nice if sometimes people would at least offer to pay some of my expenses for doing this, but I do acknowledge that there are too many of us already in this same boat that I am with regard to ‘real-EA’.)
  4. I probably will be going to a wide variety of conferences and other gatherings on broader-scope societal-change topics. (As ever, the real limit here will be my probable near-nonexistent income: so if you really want me at your gathering, please do find some way to subsidise my travel-expenses at least.)
  5. Much of my work and writing will be a lot more ‘political’ and challenging for a lot more folks: in which case, sorry, but that’s just too bad, because none of us can afford to tolerate outright irresponsibility and abuse any more. (I am very clear about what is and is not abuse in the social context, by the way: see the ‘manifesto‘ on that, from my book Power and Response-ability.)

So that’s it: getting down to work in a different garden – a garden that’s a rather better fit, than that of current mainstream ‘enterprise’-architecture, for this admittedly somewhat-strange kind of toad.

Comments / suggestions / requests, anyone?

Time for this old toad to move on

October 16th, 2011 10 comments

Strange things, metaphors: they kind of have a life of their own sometimes…

My mother tells the story of the first house she and my father lived in, some small place way up in the north of England somewhere, back when my elder brother was still a babe-in-arms. The garden they’d inherited there was an overgrown tangle, and they didn’t have much of a clue about gardening, but it seemed a friendly sort of place. It even had its own toad, hiding in the humid dankness underneath a sprawl of strawberry-creepers that had crept in from under the fence from next-door.

It didn’t take long to see why the toad was there. Next-door’s garden was regimented, ordered, everything under control, just so. And all a bit sad, because nothing was thriving there. Beneath all that would-be perfection, the strawberry-patch was a mess of slugs and snails, stunting all the growth; what few fruit were left were all tiny. Yet over on my parents’ side of the fence, those same plants were producing a lush spread of abundant greenery, enough strawberries to keep a grocery going all on its own – and one very happy toad, who’d made very sure that there was not a single slug to be seen.

My mother realised what was happening in the next-door garden, and even offered to send ‘their’ toad over there. But the neighbour was adamant that she wasn’t having “that disgusting creature” in her perfect space: no way! And continued to fret over the fact that her once-imagined idyll was indeed dying…

Hence interesting that I’ve been writing about ‘the toad in the road‘, because I guess that’s what I am myself right now, in this garden we call ‘enterprise architecture’. A toad in the road: right idea, wrong place. Right idea for somewhere, I’d hope. But wrong place for here-and-now. Oh well.

Yeah, enterprise-architecture. You know, this could be a really nice garden? Especially if you got rid of most of this mess of concrete, and let those tired plants in their cracked concrete tubs get their roots down into the dirt at last. Plenty of potential and all that: to get the water flowing again, you might have to take a stick of dynamite to that ugly-looking paddling-pool that the last lot of kids built for themselves, over in the corner called ‘IT-centrism‘, but hey, it’s all here. Why not do it?

You’d wondered where all the wildlife went, but can’t you see there’s not much that can thrive in this kind of desert? A few bugs and wood-lice and a lizard or two, perhaps, but that’s about it. If you want it to work, perhaps plant a few things that can actually grow here: get a bit of shade going an’ all that. There’s a few plants of my own that might grow well here too, if given a halfway-decent chance: the Enterprise Canvas, perhaps, or that notation-agnostic metamodel; or maybe even a bunch of ideas about value-trees, about the service-oriented enterprise and the structure of management – kinda strange-looking at first, I know, but they really do work in this kind of climate. Only a suggestion, of course: it’s your garden, after all.

I’ll have to admit, though, that this isn’t really my kind of place that you’ve got here. Partly my fault, perhaps: I do know I’m kind of an Outsider – always have been, I guess – though I really have tried, I promise you. It’s just I really can’t cope with all the broken-down bits of machinery parked all over the place, and the possessiveness that still pervades everything: they do kinda get in the way all the time. And a bit too grey, too cold, too lifeless: too corporate, I suppose you could say? I’m gettin’ old, I s’pose: I need somewhere that’s a bit more comfortable with having real people around the place, a bit more aware of the anarchic nature of, well, nature itself? I guess I could do with a bit more of the bigger picture, too: and I don’t mind all those mythquakes that we can see coming down the road a ways, though I know they do worry some other folks a lot.

I’ll still be around, of course: if you need me, you know where to find me. And I’m always happy to drop by in your garden – especially if you find a way to bring it more back to life again.

But yeah, I gotta face the facts: this kind of ‘enterprise’-architecture garden ain’t no place for the likes o’ me – and out here at present I’m just another toad in the road.

So it’s “goodbye and thanks for all the slugs”, I guess? – because it seems like it’s time for this old toad to be a-movin’ on.

Rebalancing top-down management-architectures

September 29th, 2011 4 comments

One of the points that came up in the previous posts on the management-architecture theme is that most management-structures are top-down, which doesn’t fit well with the ‘everything is just another service’ nature of most service-architectures – especially at a whole-of-enterprise scope. Yet if so, how can we create a better balance in the overall management-architecture? What can we do about that, in an enterprise-architecture sense?

Quite a lot, as it happens. There are a fair few models that are explicitly designed to tackle this rebalance problem, and plenty of practical real-world tactics, too. In this post I’ll summarise the mechanisms that support this in Stafford Beer’s Viable System Model; a real example from the 1960s that uses some of the same principles as in the VSM; and two more recent examples, one from an engineering research-laboratory, the other from current Army doctrine and practice.

(Not too long this time, I hope?)

Read more…

Management as ‘just another service’

September 27th, 2011 12 comments

What do I mean when I say that, in a service-oriented architecture of the enterprise, we need to view management and the like as ‘just another service’?

This came up in a comment to the previous post ‘Why are the elite the elite?‘ The notion of ‘just another service’ is worth exploring more – especially as it has corollaries and implications that do have serious impacts on enterprise effectiveness.

(Just to make things clear: this is about enterprise architecture, not politics. Yes, as we’ll see, there are some significant sociopolitical ramifications from this, but that isn’t the focus here: the primary purpose is to explore some of the practical issues we encounter when scaling up a service-oriented architecture to a full whole-of-enterprise scope.)

Although I’ve said ‘enterprise’ above, what we’re dealing with here is mainly about management within ‘the organisation’ (organisation and enterprise are not the same).

What we’re actually dealing with is a paradigm-problem. On the one side, there are two fundamentally-different concepts of the organisation: organisation-as-machine, typified by Taylorism and the like; and organisation-as-living-organism, typified by various ‘systemic’ views such as those from Deming, Senge or Beer.

These two perspectives lead to two fundamentally-different views of the nature and role of management – which in turn have, as above, significant sociopolitical ramifications. But to get there, and to contrast those two views, we first need to do a couple of side-steps.

One of these side-steps is about purpose and the organisation.

In the machine-view, purpose is extrinsic: the purpose of the organisation is defined from outside the organisation. It’s just a machine: everything and everyone within it is, by definition, just another ‘purpose-free’ component of that machine. The machine itself is guided – or defined, perhaps – by the aims of the organisation’s owners, who provide the capital for ‘the enterprise’ and “the animal spirits of the entrepreneur” to set it in motion.

In the organism-view, purpose is intrinsic: the purpose of the organisation is defined from within the organisation. The biological metaphor here is the urge the survive and thrive, within a broader ‘enterprise’ represented by the ecosystem within which the entity exists. The organism is self-guided, self-directed, largely autonomous in the literal sense of ‘self-defined’ or ‘self-owned’. The classical concept of an external ‘owner’ doesn’t really make sense here – other than by stretching the view to include a metaphoric ‘farmer’, perhaps.

Which brings us to another related side-step about owners and rulers and property, because there are two fundamentally-different concepts there as well: feudal/hierarchical versus free-form/ecosystem.

(Note that this won’t suggest that one is somehow inherently ‘better’ than the other: they’re not. It’s more about ‘fit’ to the requirements of the context – ‘better’ only in a contextual sense, not an ‘absolute’ one. If you’re familiar with Spiral Dynamics model of social contexts, feudal/hierarchical is essentially Red/Blue, nowadays with a thin veneer of Orange; free-form/ecosystem requires system-awareness, and hence is in the Gold/Turquoise range. [Ignore the 'historical determinism' in Spiral Dynamics, by the way: to be blunt, it's garbage. But the core 'vMeme' model is sound, and can be very useful as a cultural-assessment frame in enterprise-architectures.])

A feudal/hierarchical culture is one in which there are strict relationships (‘fealty’) of roles that are ‘above’ or ‘below’ each other, and that identify respective authority, ‘rights’, responsibilities. A true feudal model has a single ruler (‘monarch’) at the ‘top’ of relationship-tree; a more literal hierarchy instead has some form of abstract concept (such as ‘God’, or ‘the Law’) that is nominally ‘above’ all others, but in essence and in practice comes to much the same as a feudal model. In both variants, each ‘inferior’ is the ‘subject’ of the respective ‘superior’ – literally, classed as a semi-autonomous extension of the ‘superior’, with no independent identity, existence or will.

(For an extreme near-present-day example, consider Gadaffi’s Libya, with Gadaffi himself as ‘Brother Leader’ who thinks for all, decides for all, and possesses all – and whose merest whim is Law. In principle, if fortunately not so much in practice, the Pope provides much the same role for the Catholic Church – subject only to the perceived ‘will of God’.)

‘Modern’ capitalism arose in the late 17th and early 18th centuries, in cultures that in essence were still largely feudal – in practice, at least, if not necessarily in theory. Aristocrats still held most of the land; but increasingly, the new merchant class held most of the money, and hence could claim a near-equal stake at the top of the tree-of-control. Beneath them in the tree were a wide range of agents: the bailiff, the steward, the factor, and so on. In modern-day parlance, these were the ‘managers’. And beneath them, as the ‘subjects’ of everyone else, were the ‘workers’ – the providers of Labour, to use the term from classic capitalism.

Taylorism in essence reflects and embodies exactly this type of feudal model: a rigid three-tier class-hierarchy. At the top we have the owners, who actually don’t get much of a mention in Taylorism as such: they set the purpose for the ‘machine’, issue commands accordingly, and are deemed to have the exclusive ‘right of possession’ over everything and everyone else. (Note, though, that with the invention of the ‘limited-liability company’ and other related changes in law, the old feudal mutuality of responsibilities is gone: all others are still responsible to the owners, but not the owners to their ‘vassals’ or to anyone else. In effect, the ‘social contract’ becomes one-way only: an obvious huge kurtosis-risk that few now seem willing to acknowledge…) Beneath them we have the managers, who in Taylorism do all the thinking for the ‘machine’, and maintain control: they interpret the wishes of the owners, and relay them as orders to those who in turn are ‘beneath’ them. And at the base of the tree, we have the workers, who do all of the ‘doing’ of the ‘machine’, and in essence are classed as mindless robots, subjects of everyone else’s ‘rights’ to ‘command and control’.

So in Taylorism, as in the Victorian battlefield, everyone has a fixed role in a fixed structure of top-down ‘command and control’ – owners own; managers think; workers do – and no-one can move outside of those preordained roles. Everything and everyone is a component within ‘the machine’.

By contrast to all of this, the ecosystem-model has no hierarchy at all: no-one has ‘rulership’ over anything else, there’s no command, and in many ways there’s no control either. The organism or ecosystem simply is. Sometimes there’s no real order as such – as in a colony of extremophile bacteria, for example. Often, though, there is some form of apparent order or collective purpose that emerges from the interactions in the overall context: the structure of a human body is one example of which we all have direct first-hand knowledge. :-) Within a human body, it doesn’t make sense to use a ‘rulership’ metaphor, that “the heart rules the head”, for example, or “the kidneys rule the throat”. (Okay, people may well use such metaphors, but they don’t actually make sense in physiological terms, anyway…) Instead, the most accurate metaphor is that each cell and organ and structure offers its services in support of the whole.

So: what next? – especially in relation to the organisation and its management?

On the one side, we have the machine-metaphor. In Taylorism and the like, this aligns with a feudal-style tree-structure of ‘command and control’, a hierarchy of ‘bosses’ and ‘subordinates’. All of this is bounded by predefined rules and algorithms – hence ‘scientific management’. Everything and everyone is considered only to be a component – a nested structure of components within components within components.

On the other side, we have the living-organism metaphor. This aligns with a network-type structure, often with fluid roles and dynamic changes in relationship and connection. There is no identifiable hierarchy as such; instead, relative ‘positioning’ tends to be derived in an emergent way from the interaction of the whole. Instead of predefined roles, each entity – at every level of granularity or decomposition – offers services that contribute in some way to the emergent workings of the whole.

So how do these two models apply in the real world?

On the surface, most organisations still seem to use the machine-metaphor: there are explicit ranks, each with authority ‘over’ others, and so on. The nominal role of management is still a Taylorist ‘command and control’.

However this type of structure is very unwieldy, and slow to respond to change – certainly far too unwieldy for anything involving fast real-time action or real-time change. Even armies don’t use it any more – not on the battlefield, anyway, where ‘command and control’ has long since been replaced by a much more free-form ‘Commander’s Intent’. The same applies in Agile-style product-development, or in successful customer-service: the classic ‘command and control’ call-centre is frankly despised by almost everyone, especially those who struggle to survive within them…

So in practice, most organisations still present themselves as top-down command-and-control. But the reality is that, other than in a few quite narrow contexts, that isn’t how they actually work. Instead, to get the speed of response that’s needed in a real-time world, just about everything is structured around services – except for management, which still tries to cling on to command-and-control.

One of the real problems is that if we move to a service-oriented model – which we need in order to support the required agility and emergence in the market-’ecosystem’ – one of the crucial side-effects is that management can no longer be viewed as ‘special and different’. It’s not like the hierarchies of Taylorism: a service-architecture is a network-structure with no top, no bottom, and usually no identifiable centre either. In a true service-model, management is just another service, one that happens to provide management-type services to the whole. (I’ve described those services in some depth back in the various posts on Enterprise Canvas, hence no need to repeat it all again here?) And since in a service-architecture there’s no hierarchy-tree, no top, no bottom, no centre, management has no reason whatsoever to try to claim automatic or inherent priority over anyone or anything else: it’s just another service.

In a classic business-architecture, the first thing we usually do is try to map out the ‘org-chart’. What we discover very quickly is that that tells us almost nothing about how the work is actually organised. To get any sense of what’s really going on, and what and how and why anything connects with anything else, our best bet is to turn to a enterprise-architecture that starts from one very simple principle: that everywhere and nowhere is the centre, all at the same time. In other words, a strategy that leads naturally into a service-oriented approach to the architecture.

That’s pretty much where we’re at now with enterprise-architecture, and why a service-oriented approach to the architecture gives the best fit for most current business needs. But we keep on hitting up against that huge stumbling-block and bottleneck that we’re apparently not supposed to notice: namely that the hierarchical concept of management, that everyone seems to want to cling on to, simply does not make sense any more. Instead, the only thing that does make sense is the view that management is just another service, no different in rank or priority or the like from anything else.

Unfortunately, the political ramifications of that fact are huge. For example, if management is ‘just another service’, is there any reason why self-styled ‘senior management’ should always get the top floor and the highest pay? The short answer is no: no reason whatsoever. Oops… Think that blunt fact will be resisted – especially by those who currently claim to have the ‘right’ of command-and-control over all others? You betcha… and it won’t matter one jot that that kind of clinging-on to something that doesn’t make sense will make things worse for everyone, including themselves. It’s very, very hard to let go of privilege, of a sense of certainty in entitlement – especially when the blunt reality is that never were any real defensible grounds for that privilege in the first place. Tricky, that one… very difficult indeed…

Yet before you launch at me with some arbitrary accusation that I’m some kind of crazy ‘communist’ or ‘socialist’ or ‘anarchist’ or the like (okay, as an architect I might perhaps accept the ‘business-anarchist‘ label… :-) ), notice that this is not about politics. It’s only about architecture – nothing else. All that I’m saying here is that a service-oriented architecture points us inevitably at the blunt fact that management is ‘just another service’. What we do with that ‘blunt fact’ is another question entirely: but that it is a fact is not in question.

Hope that makes a bit more sense, anyway?

Backbone and business-rules

September 24th, 2011 5 comments

What would be the ‘backbone’ of an enterprise-architecture? And where would business-rules fit into that picture?

This is a perhaps somewhat tangled follow-on from four different threads:

(The connections between these posts may not be obvious at first, perhaps, though I hope to straighten it out a bit as we go along!)

The core idea of the ‘enterprise backbone’ is that it’s some kind of structure – or something, anyway – within the enterprise-architecture that provides a kind of stable reference for enterprise agility.

Peter’s post describes a whole swathe of different views on the backbone theme: for example, Dave Gray‘s idea that some kind of backbone is needed in order to support what he calls a ‘podular’ architecture. We also had the seemingly-inevitable return to IT-centrism, in which one of the people referenced viewed the backbone solely in terms of a carrier for the metaphoric spinal-cord for the enterprise. Go look at that post before reading any further – it’s a very good overview of the various views into this context.

You might notice, though, there’s another whole side to this that doesn’t seem to appear much, if at all, in Peter’s collation of those views: the issue of governance. To me, the complexity of governance in a context that requires high agility is actually the core reason why we need a backbone. And to see why, we need to turn to Carol-Ann’s post, and then to Nigel’s.

Carol-Ann’s field is business-rules. Some of her post will be very familiar territory to enterprise-architects, in particular the Zachman-like tendency for business-rules to gain exceptions upon exceptions upon exceptions until we end with replacing ‘spaghetti-code’ with ‘spaghetti business-rules’. She also makes a very strong point with her ‘epiphany’ about the value of visualisation and visual models. The theme that strikes me most there, though, is her focus on lifecycle – that business-rules do not exist forever, but themselves will change over time and from one context to another:

The point we have not yet discussed much is life-cycle.  I am not referring here to the traditional Governance Process but rather the fact that business rules have a life-cycle of their own and the activities involving them are quite diverse.  It only occurred to me in the past year or so that my needs for looking at business rules keep changing based on my role as a user in addition to the nature of those business rules.

Governance is itself a set of business-rules applied to business-operations and business change – hence with governance of business-rules that themselves will change over time or context, we’re clearly looking at some kind of recursion here. Which is where Nigel’s post can come to our rescue.

(Note: For various reasons I’m very wary about applying the term ‘Cynefin‘ to any part of enterprise-architecture. Cynefin is a large body of complexity-theory and practice developed by Dave Snowden and others for use in significantly different domains than EA, and it’s not a good idea to mix them up. In most cases in EA and the like  - as in Nigel’s post – the only part that’s actually used in practice is its partitioning of a context in terms of Simple, Complicated, Complex and Chaotic, for which it’s probably more polite to use the explicit term ‘Cynefin-categorisation’ rather than ‘Cynefin’ itself. But I digress…)

In his post, Nigel actually uses the Cynefin-categorisation in much the same way as I do, as a base for cross-maps, and with the ‘Chaotic domain’ not as descriptor for true chaos (as I believe Snowden usually does), but more as a context of inherent-uniqueness or inherent-uncertainty. What Nigel adds there is a cross-map of various types or business-roles of IT-applications, and another cross-map for the all-important theme of trust – which itself changes in each of the categorisation’s ‘domains’, and which we’ll need to return to later.

For the moment, though, let’s focus on the categorisation itself. In the context Nigel’s used it, and as is general in EA contexts, the categorisation in effect represent a set of quantum-like ‘state-transitions’ within a spectrum of variability or predictability:

The phase-transitions in that ‘predictability-spectrum’ do have some real analogies with the ‘states of matter’ – in particular, that they do form distinct pairs, Simple/Complicated (‘ordered’) versus Complex/Chaotic (‘unordered’).

Within the Simple/Complicated pair, causal relationships can be assumed, either only-direct (Simple) or possibly also indirect (Complicated) – in other words, the realm of rules or algorithms. Straightforward business-rules and straightforward true/false logic will work well here: the same action should always lead to the same result, and – to paraphrase Einstein – it would be crazy to think otherwise.

But in the other Complex/Chaotic pair, simple rules don’t work reliably, or at all. Causality either becomes non-linear (Complex) or makes no sense because there are non-repeatable relationships (Chaotic). We actually end up inverting Einstein’s phrase: here it can be crazy to think that doing the same thing would not lead to different results. This leads us to something that does look much like the classic Cynefin frame – but note that we’ve actually arrived there from a different direction, via a focus on repeatability and business-rules:

The point here is that these Complex/Chaotic domains are qualitatively different to those in which we can use a simple true/false logic: any attempt to use a conventional ‘business-rules engine’ to manage a process with any Complex/Chaotic elements will soon drown in an impossible maze of ‘spaghetti business-rules’, as in Carole-Ann’s post – and it still won’t work anyway. We actually need to accept Complex/Chaotic elements for what they are, and not try to force-fit them into the Simple/Complicated mould – not matter how much IT-folks and business-folks would prefer them to do so.

Which in turns brings to the business need to balance the desire for control and repeatability on one side, and on the other the need for agility and resilience and ability to cope with real-world complexity. We see much the same kind of problems with reference-frameworks in enterprise-architecture and the like. And that, in turn, leads us on to the question of governance – which, in most people’s eyes, seems mainly to consist of applying someone’s rules or reference-frameworks – in relation to Agile – where it often seems that ‘the rules’ either don’t make sense, or by definition can’t make sense. Which can be t-r-i-c-k-y… especially when the business-politics are problematic too…

What we end up with here are several distinct themes that we need to unravel:

  • the limitations of conventional true/false ‘business-rules’, and the need for a contextual modal-logic in Complex/Chaotic contexts
  • the need to balance certainty versus agility in business-operations and business-process
  • the need for governance that can be applied consistently across the whole control-vs-agile spectrum
  • the need for governance that can adapt with life-cycles and business-change

Which is where we come back to what I’ve saying about the ‘backbone’ concept, especially in the ’Architecting the enterprise backbone‘ post – because to me that concept, and implementation of that concept, can resolve all of those threads within one architectural approach or pattern. The simplest guideline here is this:

The backbone is everything that must be the same across any shared part of the organisation or broader-enterprise.

Anything else that isn’t shared can be pretty much as ‘agile’ or locally-specific as it likes.

And this principle applies to anything - information, process, facilities, business-rules, whatever – that is used within the enterprise, and might or might not be shared. To identify the options for the ‘anything’, I typically apply the taxonomy from the ‘single-row extended-Zachman’ – otherwise known as the ‘service-content map’ – that’s used in conjunction with Enterprise Canvas:

So the ‘anything’ that might need to be in the backbone could include not just information and other virtual-assets’ – as in the IT-centric view of ‘enterprise’-architecture – but physical ‘things’, brands (aspirational-assets), consistent business-functions and services (combinations of function and capability) that act on business-relations, common understandings about business-critical-events, and so on. Note that the categories of decisions also align with a Cynefin-style categorisation: Rules for Simple-domain, Principles for Chaotic-domain, and others in between – and some of these too might belong in a shared-backbone, maintained within formal standards, procedure-documents, training-processes or a ‘business-rules engine’.

For each of these items we would have standard references, standard sources, Standard Operating Procedures and so on. Information would typically be maintained under Master Data Management, a ‘single source of truth’ or the like. That’s the ‘backbone’: there’s a lot of information in it, but it’s a lot more than just information.

We would typically identify these items through the process described in the post on ‘Architecting the enterprise backbone’: establish the focus of the overall shared-enterprise, identify the items that are needed across that shared-enterprise, then identify the subset of those items that are core for our own organisation. A particular focus should be on anything that our organisation manages on behalf of the enterprise as a whole – for example, the national mail-service (such as Royal Mail or Australia Post) usually maintains the national information-base on addresses, post-codes, the link between people and address – because those items definitely need to be in the backbone.

At the same time, there are many things that don’t need to be in the backbone – and hence the legitimate role of shadow-IT, of context-local business-processes and so on. The basic guideline is that the more it needs to be shared, and the more consistent it needs to be, the more it will need to be in the backbone, and the tighter the governance will need to be. Conversely, the less it needs to be shared, the less it needs to be in the backbone, and the looser – more ‘Agile’ – the governance can be.

The complication is that in almost anything, even right out on the most agile edge, there will usually be some parts that belong in or will need to come from the backbone. Addresses, for example. Core information about customers. Standards, protocols, interfaces. Some of these will be mandated from outside, such as methods to process credit-cards or tax-record transactions, or health-and-safety regulations. So we need to be able to use those backbone-items, yet still support whatever agility and freeform-governance that may be needed. And that’s where a service-oriented whole-enterprise architecture will pay real dividends, because a service-oriented structure for the backbone should allow us to do any required mashups between ‘controlled’ and ‘uncontrolled’ items.

Hence, again, the need for a very clear understanding of how to use a multi-mode governance-structure that can work across the range of the Cynefin-style ‘domains’. And also the need for clear architectural-governance that can identify items developed out on the edge that need to be shared, and hence need to be migrated towards the backbone. This again leads to another type of lifecycle – which likewise will need its own business-rules and the like – about how items migrate into or out of the backbone over time.

The real role of governance for the backbone is about making sure that things don’t break unless it’s safe for them to do so. Anything in the backbone tends to be business-critical for a lot of people – sometimes far beyond our own organisation. We must handle those kinds of items in a responsible manner: usually a ‘fail-safe’ manner, and certainly with respect to those people who would be affected if it changes or fails. Hence the need, usually, for formal ‘Waterfall’-style governance, so that everyone affected can have their say, or at least be informed with sufficient forewarning to be able to do something in time to adapt to the change. Away from the backbone, we don’t need that level of control – in fact we often want it to ‘fail’, otherwise we can’t experiment with anything new, or adapt to internal or external change.

This would give us a spectrum from front-line context to domain-specific to core backbone, with changing forms of governance, which we could summarise as follows:

The crucial concern is the combination of sharing – or interdependency, rather – and business-criticality. Even right out on the most experimental edge, items are often shared with others. But if that sharing, or the structure of that sharing, isn’t itself business-critical, it actually doesn’t matter if it breaks – hence the governance can be a lot looser, hence more oriented towards Agile and the like. If it is business-critical, and if it does matter to others if it fails or changes, then it needs tighter governance – and that requirement for tighter governance in that specific aspect or context should not be in question, because it matters there.

The complications tend to arise when someone foolishly believes that a ‘one-style-fits-all’ approach should be applied everywhere, to every governance context… Sometimes it comes from the ‘control-freaks’; sometimes it’s from the over-rebellious Agile folks; either way, it misses the point that we will always need different governance for different contexts. A ‘one-size-fits-all’ approach cannot and will not work: hence we will always need something that will help us choose what style of governance should apply in different contexts. To me, the architectural pattern of backbone-versus-agile provides one of the best means to do so, because it provides defined, consistent alignment and balance between:

  • a spectrum of governance from tight-control (rules) to open-choice (principles);
  • a Cynefin-like categorisation of repeatability from Simple (SixSigma-type very high repeatability) to Chaotic (inherently-unique)
  • a spectrum of low context-change (low required-agility) to high-change (high required-agility)
  • defined governance-mechanisms to handle churn into and out the backbone.

One last point comes up in Nigel’s post: the centrality of trust. In some ways rules represent an absence of trust; one of the roles of trust is as a counterbalance to excessive rule-based governance. Ultimately we do have to trust that ‘the rules’ or whatever will be followed in some sense, otherwise all connection with the aims of the organisation and shared-enterprise will be lost. Yet Nigel also suggests that perhaps even the relationship with trust – and hence with governance – will change with the Cynefin-style domain: trust is expected (Simple), mandated (Complicated), developed (Complex) and explored (Chaotic). Some themes there, then then would be well worth exploring further as we go deeper into the deign and development of a backbone-architecture.

Comments, anyone?

Dependency and resilience in enterprise-architecture models

September 22nd, 2011 3 comments

This one’s back on the metamodel theme again, and is a follow-up to a query by Peter Bakker in his post ‘Thinking about Graeme Burnett’s questions‘, in reply to my previous post ‘EA metamodel: two questions‘.

Peter wrote:

I think that the most important question of all is still missing, namely:
– What do you rely on?

(The ‘you’ here is the entity-in-focus, as with Graeme’s original two questions of “tell me about yourself?” and “tell me what you’re associated with?”.)

Peter’s right, of course: it is one of the most important questions we need to ask. It’s one reason why I generally extend Graeme’s second question to “tell me what you’re associated with, and why?”. Yet there’s a practical concern here about just how where the intelligence needed to answer that question should reside – and I don’t think it belongs in the metamodel.

To explain why, we probably need to do a brief detour into modelling in general within enterprise-architecture, and in particular our modelling of dependency and resilience. As I see it, there are two key aspects to Peter’s “What do you rely on?” question:

  • dependency – about what this entity relies on, within the shared-enterprise
  • resilience – about what this entity needs to do, or can do, to get back on track if what it relies on isn’t there

In a systems-theory sense, the first answer to Peter’s reliance-question must be “Everything!” :-) Any shared-enterprise represents a system, and by definition everything within that system depends on the presence of everything else within that system (otherwise it wouldn’t be part of that system). So in practice, from a modelling perspective, there are two additional aspects to the dependency-issue:

  • distance from ‘self’ (where ‘self’ is the entity that’s our current focus of attention)
  • criticality to self – the risk or opportunity represented by the presence or absence within the system of another entity

To illustrate distance-from-self, consider a typical biological-ecosystem: for example, the world of a dung-beetle:

  • distance-1: the dung-beetle relies on the presence of dung
  • distance-2: the dung-beetle relies on dung-producing-animals
  • distance-3: the dung-beetle relies on fodder for dung-producing animals
  • distance-4: the dung-beetle relies conditions that support appropriate fodder for the dung-producing animals in the ecosystem
  • (and so on…)

So if we have an invasive species of vegetation that out-competes the existing vegetation and is either toxic or non-palatable to the local cattle, our dung-beetle could be in trouble… Yet on its own it may have no way to know this, because the connections to the critical issues are indirect, several steps distant-from-self. And the greater the distance-from-self, the more whole-of-system knowledge any given entity will need, in order to understand its contextual dependencies, opportunities and risks.

(By the way, this is one of the main reasons why I’ve been pushing so hard for a ‘notation-agnostic’ metamodel for enterprise-architecture and the like. For example, a UML diagram typically shows only the direct point-to-point connections; so we’d typically need to be able to swap out of that diagram and into, say, a Senge-style systems-dependency model or fishbone root-cause model, using the same entities, in order to understand the systemic interdependencies of each of those items. Currently we can sort-of do this in some of the EA toolsets, though typically only within a single notation-set such as UML: my point is that we need to be able to do this, cleanly and consistency, across all and any notations in the EA space. The base for all modelling should be the entities and the relations and flows between them – not the notations with which we model them.)

Criticality is closely related to specialism; and in turn, resilience is closely related to criticality. The catch is that that criticality can occur anywhere in the system. For example, our dung-beetle may need larger piles of dung for its larvae to live in. As long as it doesn’t need specific nutrients that only come from one species, it’d probably be happy with any of the larger herbivores: cows, buffalo, camels, elephants, whatever. Even forest-clearance mightn’t much affect it, because to our dung-beetle a cow is much the same as a giraffe: criticality for that kind of change is low, hence resilience might seem to be high. Yet if there’s a change from cattle or camels to ‘pellet-dung’ producers such as sheep or goats, our dung-beetle could well be in trouble, because that kind of dung is too small to work with. And without the dung-beetle, the nutrient-recycling processes within the ecosystem may be too slow for self-renewal. Hence not just the dung-beetle but its entire ecosystem may be at risk from arbitrary decisions made by humans in ‘markets’ that may be tens or hundreds or thousands of miles away.

These whole-of-system dependencies and resilience-issues are classic simulation / systems-theory territory, illustrated well by the old military adage of a century or so ago:

For want of a nail, the shoe was lost;
for want of the shoe, the horse was lost;
for want of the horse, the rider was lost;
for want of the rider, the battle was lost.

Whole-of-system resilience is also a common concern in studies on complex adaptive systems, where resilience in one area can sometimes even enhance resilience in other more apparently-fragile areas. And there can also be dependency/resilience issues between nominally-interdependent systems that are in ‘system-of-systems’ relationships with each other: these are common in military contexts, though Nick Gall gives a useful non-military example in the section ‘Models of interdependent networks‘ in his seminal ‘Panarchitecture‘ paper for Gartner.

Identifying those kinds of dependencies usually requires a lot of ‘whole-system intelligence’ – in other words, cross-mapping of dependencies and criticalities that may be many steps distant from each other. There are two classic approaches to this:

  • ‘inside-out’ – each entity knows everything it needs to know about its own system-context
  • ‘outside-in’ – an external observer assesses the interactions across the entire system-context

In practice, neither of these approaches work well, especially for any large real-world system. The ‘inside-out’ approaches assumes high intelligence and information-gathering capability in each entity, which certainly doesn’t apply down at the level of bacillae and bacteria in living ecosystems; the ‘outside-in’ approach requires phenomenal computing-power, and probably can’t cope with any kind of non-linear relationships anyway; and both demand vast cross-context information-flows that can rarely if ever be seen in real-world systems.

Instead, what actually works is observation of patterns of emergence: the ‘intelligence’ – so to speak – arises from the network of relationships, rather from any specific entity either within or (nominally) outside of the system.

Hence, to bring it all back to the EA-metamodel, I suspect that the question “What do you rely on?” may actually be a bit misleading here: it’s certainly a question that we need to ask, and answer, but it’s not a question we can meaningfully answer at the metamodel level. Some kind of intelligence would definitely be needed in order to assess contextual concerns such as whole-system interdependence and resilience: yet the metamodel itself doesn’t have any intelligence as such – it’s just a means to structure information.

Hence for any given entity, it would be meaningful to ask directly each of Graeme’s questions:

  • “tell me about yourself” typically identifies the immediate content of the item [and in this metamodel, also the content of any items within the scope of its related-items list]
  • “tell me what you’re associated with” identifies the immediate (‘distance-1′) relations in which the item is referenced
  • “…and why” identifies the reasons given within those ‘distance-1′ relations

Answering those questions doesn’t require much intelligence: we could easily embed that within an object-method for entities, for example. But as soon as we step beyond that immediate ‘distance-1′ level, the relationships and dependencies become very complex, very quickly – and I don’t think we would be able to embed that within the entities as such. (Okay, we probably could do it, but I doubt that doing so would be effective enough to worthwhile in a practical sense.)

Hence I would suggest that at the metamodel level we should stick to Plan A, and keep everything as simple as possible: Graeme’s two questions (in that slightly-amended form) should be enough to cover most if not all of what we need to support an emergent view of enterprise context.

Your comments on this, of course?

Enterprise Canvas as service-viability checklist

September 14th, 2011 5 comments

One of the more valuable uses of the Enterprise Canvas is as a checklist to verify completeness and viability of services, in any context within the enterprise.

By ‘completeness’ I mean that we check that the service has all the connections and support and flows that it needs to play its full part in the respective layer of the enterprise value-network.

And ‘viability’ here is in the sense described in the Viable System Model, that the interdependencies that the service needs both to operate in the ‘now’ and to change appropriately over time are all in place and in action.

In a service-oriented architecture and and a service-oriented view of enterprise, everything is or delivers or represents a service. Which means that everything in the enterprise will rely on those interlinks and interdependencies. Which is why a model-type such as Enterprise Canvas, which explicitly sets out to model those interdependencies, could be very useful indeed. :-)

So here’s an as-brief-as-I-can-make-it how-to introduction on using Enterprise Canvas for this purpose, creating models with the simplified version of the Enterprise Canvas notation.

Read more…

More on simplified Enterprise Canvas

September 11th, 2011 6 comments

Following on from the previous post on ‘Simplifying the Enterprise Canvas‘, a few more notes on how to use the notation, and some practical matters on modelling.

Perhaps not quite as technical as some of the other recent posts, but I’ll admit that if enterprise-architectures and the like are not of much interest to you, you might want to skip this one. If that is of interest, though, please do read on! :-)

Read more…