An enterprise-architects’ mantra

Quick, brief and practical – three phrases that every enterprise-architecture should know by heart, and act on, too:

  • I don’t know… (but I know how to find out, or find someone who does)”
  • It depends… (and I know how to find out what it depends on)”
  • Just enough… (and I know how to find out what that ‘just enough’ is)”

The indefatigable Len Fehskens once said that his colleagues (at HP, I think?) had presented him with a rubber-stamp with ‘It depends’ on it, because he’d used the phrase so much. In that spirit, here’s a meme-graphic to stick on your desk or wall or whatever – or even use as a business-card, perhaps? :-)

(click for full size)

(Many thanks to Stuart Boardman, who spotted this in my recent ‘“Which EA school?”‘ post, and who first described it as an ‘EA mantra’.)

 

 

Tagged with: , ,
Posted in Complexity / Structure, Enterprise architecture
17 comments on “An enterprise-architects’ mantra
  1. Jack Doyle says:

    I resemble that mantra, so I must be doing something right :-) Thanks Tom.

  2. What about helping people to help themselves:

    What is your opinion/proposal/recommendation/etc?

    • Tom G says:

      Thanks, Kai

      This wasn’t meant to be an exclusive list! – it’s just what came up in that particular post. (I picked up on Stuart’s suggestion to emphasise it, that’s all – in this case via its own separate post.)

      If you think about it for a moment, ‘I don’t know’, ‘It depends’ and ‘Just enough’ are all ways of helping people to help themselves. With the ‘I don’t know’ item in particular, we pull back from the pretence of omniscience (and/or prevent others from dumping that pretence upon us), and bring the focus back onto their knowing rather than ours. Another related way we’d do this is to keep the focus on framing questions, so that people arrive at their own answers.

  3. Len Fehskens says:

    IIRC, they gave me two rubberstamps, one that said “It depends”, and the other that said “Yes, but…”.

    It was at Digital, pre Compaq acquisition of Digital, pre HP acquisition of Compaq.

    Regarding “Just enough”, I refer to it as the “Goldilocks principle”, in the sense of “just right”. The group that gave me the rubber stamps version of it was “Doing architecture right is like spelling banana; you have to know when to stop”.

    I also regularly remind myself of the six blind men and the elephant, the cobbler’s children, and Zumbach the tailor.

    len.

    len.

    • Tom G says:

      Thanks for the corrections and updates, Len – and for the advice and addenda, too.

      I love that comment about “spelling ‘banana’: you have to know when to stop”! :-)

      For the ‘six blind men and the elephant’, I also like de Bono’s variant of that, that “Everyone is always right, and no-one’s ever right” – people are always right from their own perspective, and no-one has the whole story.

      • Len Fehskens says:

        “Everyone is always right, and no-one’s ever right.”

        That’s the key — the predisposition in the EA community seems too often to be “there’s only one right answer, and it’s mine, so you’re wrong”, rather than looking for the integrative/holistic perspective (why does that sound so familiar?) that would make everybody right.

        len.

        • Tom G says:

          Strongly agreed!

          The catch, of course, is that that in itself kinda makes out that we’re the ones who are ‘right’ about the need for an integrative/holistic perspective, and that others are ‘wrong’ if they insist on a narrower/exclusive view. And the fact that we recognise this, and admit it, means that others can then assert that we’re the ones who are ‘wrong’, which means that they must be ‘right’. Which brings us further into the questionable joys of recursion, deeper and deeper down the rabbit-hole… :-( :-)

  4. Tom G says:

    There’ve been quite a few comments and addenda on Twitter about this post, which I’ll list here as separate comments (with my own notes added where appropriate).

  5. Tom G says:

    Twitter comment #1, by Nick Gall (@ironick):

    RT @ironick: @tetradian shouldn’t the #entarch mantra be “i know how to find out”?

    Agreed, though as I said above to Kai, the ‘mantra’ set is not an exclusive list!

    One point is that there’s a lot we should know already: certainly in my own experience, I try to be interested in pretty much everything, though I’m careful to apply the ‘Just enough’ principle to all of that as well. If we know nothing whatsoever about the business context, we probably shouldn’t be trying to work on that business’s enterprise-architecture?

  6. Tom G says:

    Twitter comment #2, by Brenda Michelson (@bmichelson):

    RT @bmichelson: @ironick @tetradian how about: I know how to help. #entarch

    Yes, again, agreed. The catch (for me, at least), is that typically, at the start of the questions, I don’t know how to help – not properly, anyway – other than at an abstract or pattern-oriented way: a key part of my task is to find out how and in what ways I can help (and also get clear on where I can’t help, and thence need to hand over to others).

  7. Tom G says:

    Twitter comment #3, by Ron Parker (@scmunk):

    RT @scmunk: @tetradian @ironick @bmichelson If you are a #DesignThinking thinker it could be “How might we…”, works for #entarch

    Strong agree on the collective-nature of this (‘we’, not solely ‘I’). From a responsibility-perspective, though, it’s always ‘I’ first, before the collective can exist – about personal skill, personal knowledge, and the personal responsibilities to share with and teach others that go with that.

  8. Tom G says:

    Twitter comment #4, by Kai Schluter (@ChBrain):

    RT @ChBrain: @tetradian @ironick @bmichelson I prefer: I know how you could help yourself.

    Kind of a combination of the earlier responses above, really – the “I know…” bit, and keeping the focus on others.

  9. Tom G says:

    Twitter comment #5, by Nick Gall (@ironick):

    RT @ironick: @ChBrain @tetradian @bmichelson top this one: let’s help one another. ;)

    Again, strong agree, yet that isn’t quite what the ‘mantra’ is about… (More on that in a moment, in response to the next Twitter-comment, by Peter Bakker.)

  10. Tom G says:

    Twitter comment #6, by Peter Bakker (@mapbakery):

    RT @mapbakery: @ironick +1 the other #entarch mantra stuff is much to egocentric and passive: I know… I know… I know…@ChBrain @tetradian @bmichelson

    Okay, I take the point, yet there seems to be a fundamental piece of misunderstanding here: a ‘mantra’ is said to oneself, not to others. Once we realise that point, then the ‘mantra’ is neither ‘egocentric’, nor ‘passive’: it’s about active and personal responsibilities to ‘run and find out’ (to quote Rudyard Kipling) about those things which we do not know. (Importantly, if we don’t know how to ‘run and find out’, on our own and/or with others, we probably shouldn’t be doing enterprise-architectures… certainly we’d run the risk of ‘knowing just enough to get into trouble, and not enough to get out of it’.)

  11. Tom G says:

    Twitter comment #7, by Kai Schluter (@ChBrain) (in response to comment #6 by Peter Bakker):

    RT @ChBrain: @mapbakery @ironick @tetradian @bmichelson A hippie approach to #EntArch … Interesting idea, I fear: no answers = no questions = EA dead.

    Strongly agreed on this one: ultimately, someone has to know ‘the answers’, all the way down to whatever level of detail is required for action and enaction. The key point here is that it doesn’t have to be us (the enterprise-architect or whatever) – though in general it is part of our job to know who the right (type of) person would be for that required answer. Ditto with questions, for that matter – although our work often does focus more on finding ‘the right question’ rather than ‘the right answer’.

  12. AS says:

    +Don’t worry (as I also the answer)

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Books by Tom Graves
Ebooks by Tom Graves
Categories
Archives