IT Architecture as taught by Monty Python

One of my friends and mentors, Bill Vass of Liquid Robotics, has consistently advised IT professionals to understand, respect and use the power of well formed IT architecture.  Bill has often reminded me and others that architecture is design.  If you have poor design, or if you have good design that is ignored, then the architecture is worthless or even counter productive.  If you have good, actionable design that is focused on mission needs and used by enterprise decision-makers then IT is better able to deliver workable solutions.  Bill also emphasizes that well done architecture begins with the end in mind.

That last point means, that before building your design you need to know what your mission requirements are.  And you need a good relationship with your customers and how they serve the mission.

If there was ever any doubt of that, I'd like to point out a great example highlighted by Monty Python in a skit named... "Architect Sketch." In it John Cleese plays an architect who seems to have created his design without an approved business architecture. The result is a design that does not meet the intended mission needs. (In the same sketch, Eric Idle, seems to have a design that reflects mission needs, but shows signs that it might not be executable).

The sketch is a great way to drive home many lessons in IT architecture, don't you think?  Here are a few that come to mind:

  • IT customers should very clearly spell out the requirements that need solving (by the way, most are are not very good at this)
  • IT architects must ensure they are designing to mission needs
  • Sometimes poor technical designs are picked because they are the only thing that comes close to meeting the mission
  • Sometimes designs are picked because of relationships

If you are a customer of IT is is your duty to describe requirements in clear, understandable ways so the IT architects have a chance of designing the right solution.

If you are an IT architect you have a duty to ensure you are designing things to meet mission needs.  You don't design something just because that is what you are good at (John Cleese's character said "You see I mainly design slaughter houses.").   And if you design something that customers reject in design review, don't do a Cleese on them.  Although he does have a way with words when it comes to pushing back on user concerns:

"Well, of course, this is just the sort of blinkered philistine pig-ignorance I've come to expect from you non-creative garbage. You sit there on your loathsome spotty behinds squeezing blackheads, not caring a tinker's cuss for the struggling artist. You excrement, you whining hypocritical toadies with your colour TV sets and your Tony Jacklin golf clubs and your bleeding masonic secret handshakes."

(That kind of in-your-face interaction with customers is probably not conducive to a productive, healthy, long-term relationship with your customers).

Which raises another point this skit humorously highlights.  In the end, the customer choose the poor technical design over the good one because it was closer to meeting the mission, and because the architect had a relationship with the customer, as evidenced by the well executed masonic secret handshake.

Lesson overall: Good enterprise IT is always about people and the mission.  When enterprise IT is designed without a good understanding of the mission, disaster can result.

Connect Here

Bob Gourley

Partner at Cognitio Corp
Bob Gourley is a Co-founder and Partner at Cognitio and the publisher of CTOvision.com andThreatBrief.com. Bob's background is as an all source intelligence analyst and an enterprise CTO. Find him on Twitter at @BobGourley
Connect Here
About Bob Gourley

Bob Gourley is a Co-founder and Partner at Cognitio and the publisher of CTOvision.com and ThreatBrief.com. Bob's background is as an all source intelligence analyst and an enterprise CTO. Find him on Twitter at @BobGourley

Comments

  1. ActualTechUser says:

    Ah, so from your comment characterizing the secret handshake as "well-executed," I take it that you yourself are secret Masonic highrise architect as well…. I knew it!Great post, Bob, with thoughtful lessons from an unexpected – and very funny – source. You make an excellent teacher! Let me know when you take up lecturing, I'll recommend them to anyone! Keep up the great writing.

  2. Anonymous says:

    Ah, so from your comment characterizing the secret handshake as "well-executed," I take it that you yourself are secret Masonic highrise architect as well…. I knew it!

    Great post, Bob, with thoughtful lessons from an unexpected – and very funny – source. You make an excellent teacher! Let me know when you take up lecturing, I'll recommend them to anyone! Keep up the great writing.

  3. ActualTechUser says:

    Ah, so from your comment characterizing the secret handshake as "well-executed," I take it that you yourself are secret Masonic highrise architect as well…. I knew it!

    Great post, Bob, with thoughtful lessons from an unexpected – and very funny – source. You make an excellent teacher! Let me know when you take up lecturing, I'll recommend them to anyone! Keep up the great writing.

  4. Thanks for the comment. I laugh every time I see this. Cheers, Bob

  5. Thanks for the comment. I laugh every time I see this. Cheers, Bob

  6. "IT customers should very clearly spell out the requirements that need solving (by the way, most are are not very good at this)"
     
    Perhaps that is because defining the requirements up front – without any sort of feedback loop – is mostly impossible? i.e. the old "you don't know what you don't know" and "if I had asked them what they wanted, they would have said a faster horse"
     
    Consider this quote from the UK's Institute for Government "System Error: Fixing the flaws in Government IT" (http://www.instituteforgovernment.org.uk/publications/system-error):
     
    "Under these traditional approaches, the best solutions are considered to be those that capture all the requirements up-front and design a solution to incorporate as many of themas possible. The greater the depth of the requirements, the more the solution will fit thebusiness need.
     
    From these detailed requirements, the shape of the whole solution can then be developed.By planning and designing in as much detail as possible at the outset, showing exactly how everything fits together, the number of errors discovered in the later test phases are reduced.
     
    In a perfectly predictable world these approaches would work very well. In the real world, inwhich requirements, technologies and ministerial priorities are constantly evolving, they quite literally build failure in to the system."
     
    They go on to state that better "best practices" won't help – we need to change the way we design/build our IT and use more agile techniques: "Agile means adopting an approach to IT that emphasises flexibility, responsiveness to change and innovation. This is achieved through modular and iterative development based on user involvement and feedback."
     
    It's a good document and well worth a read. I'd also suggest reading Neal Ford's series on Emergent Design over at IBM DeveloperWorks.  Especially the one on Evolutionary Architecture (http://www.ibm.com/developerworks/java/library/j-eaed10/index.html). I like the quote he pulls from Martin Fowler: "Architecture is the stuff that's hard to change later. And there should be as little of that stuff as possible."
     
    p.s. tried signing in with Twitter but something was amiss. Can find me @virtualandy though.

  7. "IT customers should very clearly spell out the requirements that need solving (by the way, most are are not very good at this)"
     
    Perhaps that is because defining the requirements up front – without any sort of feedback loop – is mostly impossible? i.e. the old "you don't know what you don't know" and "if I had asked them what they wanted, they would have said a faster horse"
     
    Consider this quote from the UK's Institute for Government "System Error: Fixing the flaws in Government IT" (http://www.instituteforgovernment.org.uk/publications/system-error):
     
    "Under these traditional approaches, the best solutions are considered to be those that capture all the requirements up-front and design a solution to incorporate as many of themas possible. The greater the depth of the requirements, the more the solution will fit thebusiness need.
     
    From these detailed requirements, the shape of the whole solution can then be developed.By planning and designing in as much detail as possible at the outset, showing exactly how everything fits together, the number of errors discovered in the later test phases are reduced.
     
    In a perfectly predictable world these approaches would work very well. In the real world, inwhich requirements, technologies and ministerial priorities are constantly evolving, they quite literally build failure in to the system."
     
    They go on to state that better "best practices" won't help – we need to change the way we design/build our IT and use more agile techniques: "Agile means adopting an approach to IT that emphasises flexibility, responsiveness to change and innovation. This is achieved through modular and iterative development based on user involvement and feedback."
     
    It's a good document and well worth a read. I'd also suggest reading Neal Ford's series on Emergent Design over at IBM DeveloperWorks.  Especially the one on Evolutionary Architecture (http://www.ibm.com/developerworks/java/library/j-eaed10/index.html). I like the quote he pulls from Martin Fowler: "Architecture is the stuff that's hard to change later. And there should be as little of that stuff as possible."
     
    p.s. tried signing in with Twitter but something was amiss. Can find me @virtualandy though.

Leave a Reply