The “Answer” Is Always 42

Filed in Episode 3 by on March 20, 2013 2 Comments

Douglas Adams, for those who may possibly not be aware of him, was an English author best known for his The Hitchhiker’s Guide To The Galaxy series of books (originally a radio show). His genius was to offer us little pieces of wisdom – insights into the human condition and the strange workings of our world and the universe – whilst making us laugh – with him, at his characters, at ourselves.

He managed to make 42 just about the most famous number in the world in a story featuring a super computer called Deep Thought, some hyper-intelligent, pan-galactic beings (actually white mice) and planet earth. Deep Thought takes seven and a half million years to compute the answer to “the ultimate question of life the universe and everything“, which turns out to be 42. But what actually is the point of the story? We can all laugh at the stupid computer that took so many years to arrive at its meaningless answer or at the not so hyper-intelligent beings, who gave it such a vaguely worded question. We can laugh at their subsequent construction, planet earth, that spent millions more years coming up with a question to which 42 wasn’t the answer. Was Adams just having a laugh? Unfortunately he’s no longer around to tell us but I like to think that he was pointing us at our stupid habit of seeking “answers” to everything.

Deep Thought 2

A few things got me thinking about this recently. The most significant was Umair Haque’s provocative piece Let’s Save Great Ideas from the Ideas Industry in HBR. This is a passionate plea against the cult of instant wisdom.

Einstein’s great equation is not a “solution” it is a theory — whose explanations unravel only greater mysteries and questions. It offers no immediate easy, quick “application” in the “real world,” but challenges us to re-imagine what the “real world” is; it is a Great Idea because it offers us something bigger, more lasting, and more vital than a painless, disposable “solution”.

Then there was another provocative article, Six Sigma “Killed” Innovation In 3M by Ryan Huang. I have nothing against Six Sigma and neither, I think, has Huang. The point is that it may be the “answer” in the situations for which it was envisaged but that it isn’t in others. Or maybe it could be if it weren’t applied as a formula but rather a guiding principle.

Other triggers were some discussions I’ve been watching on the LinkedIn Enterprise Architecture group and some conversations I had during an architecture training course I gave last week.

For me architecture is first and foremost a way of understanding a complex situation and helping other people understand it, define their requirements on it and ask better questions about it, so that they collectively can make something they’re happy with and proud of. It’s not a question of applying some neat methodology, where you feed in the question at one end and the right answer pops out at the other. There are lots of tools available to help us in our visualizations, to add discipline to our process or to provide checklists of the things we might otherwise forget. But each instance, each “project” is different and meets different challenges along the way. The tools that worked for the last project may be totally inappropriate for this one. We may not and often don’t have the luxury of starting in a green field and we don’t always get to start at the beginning of our favorite methodology or framework  - which is absolutely no problem as long as we understand that the framework is there to help us think and not to generate answers.

Unfortunately architecture and in particular enterprise architecture seems also to suffer from the 42 problem. That may not be true for architecture in its original sense, the building industry (although I suspect it may be) but in the various virtual architectures it definitely is. Too many people want to be told which model to use when under which circumstances and what a “right answer” would look like when they get there. And even if they don’t want to be told that there are too many people who want to tell them. Should we use the Business Model Canvas or the Business Motivation Model?  Which one is best? What’s the right Business Process model? These are stupid questions, which result in simplistic answers. What we should be asking ourselves is “which one of these inspires me and helps me discover things I’d otherwise have missed?”, “what things can’t it tell me?”, “who do I know who’s used it and under what conditions?”. We need to figure out what will work for us in a particular situation. That can be determined by scope and context but also by the people we’re working with: what they respond well to and what puts them off, where the hands-off boundary lies.

There are so many great ideas available to us. Not all of them are theories. Some of the most useful are just insights into some particular area of concern. Exactly that fact requires us to understand them and apply them with intelligence, including at those ah-ha moments where we’ve never thought to use them before.

Einstein

Great ideas help us think. In the areas to which they’re applicable they do allow us to find specific solutions to specific problems. These problems and solutions are instances. A general theory wouldn’t be much use if it only gave an answer to a single problem, would it?

 

Share

Tags: , , , , ,

Comments (2)

Trackback URL | Comments RSS Feed

Sites That Link to this Post

  1. The Interconnectedness of All Things | The Open Group Blog | April 11, 2013
  1. sorry for the typo’s.
    AGAIN.

    - The best model is the company reference grid.
    - that Six Sixma kills innovation is known for a long time

    My opinion is that ICT opinion makers are more led bij making money than by providing wisdom and proved practices.

    So, my advice: don’t listen. Trust your own eyes and ears.Run your own race.

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>