Wednesday, April 28, 2010

Are Architects Cogs or Linchpins?

I'm reading the book Linchpin - Are you indispensable? by Seth Godin. It raises in my mind a number of troubling thoughts about architects and whether we can be viewed as being cogs or linchpins according to Seth's world view. According to Seth a cog is someone who:
  1. Relies on left (lizard) brained skills
  2. Keeps their head down
  3. Follows instructions (or a process)
  4. Creates widgets
  5. Works hard but just does what is needed
  6. Shows up on time
  7. Gets jobs by providing a CV (AKA resume)
  8. Is easily replaced (by another cog)
whereas as linchpin is someone who:
  1. Relies on right (creative) brained skills
  2. Raises their head above the parapet
  3. Makes judgment calls and leads others
  4. Creates art
  5. Focuses on connecting people and ideas
  6. Work to no fixed schedule or agenda
  7. Gets jobs by pointing prospective employers at their web site, blog, latest work of art or project
  8. Is indispensable
As with any job IT architecture is x% slog and routine and y% creativity, inspiration and creating great ideas or opportunities. By working on the linchpin attributes rather than the cog attribute you can hopefully increase y at the expense of x. I think this resonates well with these skills and my manifesto here.

Tuesday, April 27, 2010

PowerPoint Makes Us Stupid (Says the US Military)

A timely follow-up to my recent blog post. I got this via Seth Godin's blog entry here. According to the US military (as reported here) "PowerPoint makes us stupid". Brigadier General H. R. McMaster, who banned PowerPoint presentations when he led the successful effort to secure the northern Iraqi city of Tal Afar in 2005, likened PowerPoint to an internal threat. He says: "it’s dangerous because it can create the illusion of understanding and the illusion of control. Some problems in the world are not bulletizable".

US commanders say that "the program stifles discussion, critical thinking and thoughtful decision-making. Not least, it ties up junior officers — referred to as PowerPoint Rangers — in the daily preparation of slides, be it for a Joint Staff meeting in Washington or for a platoon leader’s pre-mission combat briefing in a remote pocket of Afghanistan".

Incredible! Has the world gone mad? Imagine if PowerPoint had been around in the time of John F. Kennedy, Winston Churchill or Mahatma Gandhi? Would their speeches have been enhanced by using a PowerPoint presentation with bullet points summarising their key messages? I think not. As Seth Godin goes on to say "guns don't kill people, bullets do".

Architecture AntiPatterns: Pattern #6 - Architecture Thinking Not Doing

AntiPattern Name: Architecture Thinking Not Doing
General Form:
An organisation or enterprise embarks on an initiative to retrain their designers and developers to be 'architects'. They set up education classes, assign new roles to their people with the word 'architect' in their job title and may even pay them some more money to match their 'elevated' status. However after a period of time (could be 6 months, could be longer) the initiative dies, developers just keep developing, designers just keep designing and no true system architectures materialise.  
Symptoms and Consequences:
  • People return from training but make no changes to their behaviour. They revert to whatever it was they were doing previously.
  • The person(s) responsible for the initiative move on and as it was "their baby" the initiative dies.
  • Management think that training is sufficient and that once students have been trained they will "know what to do differently".
  • People want to put into practice what they have learnt but have no idea where to go for help or guidance.
Refactored Solution:
  • Architecture thinking has to be turned into architecture doing. Follow up training with projects which make immediate use of new skills. 
  • Identify early on who the real leaders are and get them to mentor others.
  • Obtain a critical mass of core people who will continue to develop their skills and be advocates of the new approach even once the initial hype has died down.
  • Ensure the initiative to train architects has support from the highest (i.e. CxO) level of the organisation.
  • Get buy-in from the business as well as IT. Convince the business of the need for architecture by showing them time to market and quality will improve and their will be less maintenance costs.
  • If the organisation is immature but keen to learn 'buy-in' experience either by hiring experienced people or working with good technical consultancies who have a proven track record (or some mix of both).
  • Follow up training with good quality, written down guidance (including guidelines, examples and templates) which is readily available and easily found (preferably in the companies website).
  • As part of the training get a written-down commitment from each student that describes one thing they will do differently as a result of attending this training. Follow this up and see if they did it. If not find out why not. 
See Pattern #5

Sunday, April 25, 2010

How to Create Effective Technical Presentations

One of my great bugbears in life is the dire nature of the average technical presentation produced by IT folk in general and architects in particular. I'm not saying all architects produce bad presentations or that architects are the only culprits. It's just that I tend to see more presentations from this particular group so am more inclined to comment on them. The main problems I see are:
  • Too much text/information on a slide.
  • Text too small to read unless you are in the front row and have 20-20 vision.
  • Inconsistent use of colour.
  • Poor layout.
  • Use of dreadful and completely irrelevant clip-art.
  • Far too many slides given the length of the presentation.
  • Unnecessary and confusing aimations.
  • I could go on...
Before I go any further I confess I have produced some pretty dreadful presentations in my time where I have fallen foul of most, if not all, of the above at some point. However I've recently been reading the books (Presentation Zen and Presentation Zen Design) and blog of Garr Reynolds and thinking how what he says can help with people who need to produce technical presentations. Here are five tips based on the advice from Garr's books that will help you next time you have to create a technical presentation.
  1. Don't put more than you need to in the presentation. The first, and I think best piece of advice, is to recognise the inherent limitations of presentations as a communication mechanism and try and mimimise the amount of information you present. Hopefully the audience is there to listen to what you have to say not to see how good you are at slideware. Presentations should summarise, mainly in pictures and in as few words as possible, what you have to say. If you do need to provide additional information then hand this out as a supplement at the end of the presentation. Never just hand out your slides, that's just cheap and shows you don't care! Anyway, a good presentation should, by definition, not stand alone. It should only work when the speaker is there to present it.
  2. Make use of all the space on a presentation slide. This means removing all the unnecessary garbage that can often be found on a presentation template. You know the sort of thing I mean, there is a header and footer showing various aspects of your companies logo that take up more room than the presentation content itself! The only place a company logo should appear is on the title page. After that you should have complete use of the limited space you have available to you. Whilst talking about space you should not feel you have to fill all of the space with content. Sometimes having empty space is just as important as the content as it can provide contrast and at the same time help direct the viewers eye to the positive elements.
  3. Use words rarely. This is the most difficult piece of advice to take. It is tempting to fill a slide up with words because you are worried you will forget some important piece of information so you have to write this on the slide. Unfortunately giving a good presentation does mean you should practice, practice and practice and memorise what you want to say as much as possible. If you are in a rush and don't have time then use cue cards but don't read the words on the slide. Where you do need to use words to summarise key points then I like to try and follow what I call the five by five rule. That's five words in a line and a maximum of five lines (yes really). Finally text should be viewable from people in the back row. To check this put PowerPoint in slide sorter mode, make the slides 100% and make sure you can read the text without squinting at the screen. This is the view people in the back row will have. Actually, I lied, that wasn't the final point on this. You should also use consistent and clear typography throughout. Don't go overboard with lots of different fonts and font sizes.
  4. Use colour, layout and other design techniques for diagrams. Technical presentations by there very nature often include lots of diagrams. By necessity these will usually need to be simplified in order to get the key points across. Make use of colour to show contrast, lay things out in a consistent and meaningful way and follow some basic design techniques such as the rule of thirds to ensure your diagrams have maximum impact. 
  5. Use pictures wherever possible. I'm a recent convert to this. I love the idea of using pictures to get across key ideas and concepts. As a keen photographer I try and use my own images wherever I can however where I need something that I don't have to hand I use stock photos (yes, which I buy with my own money). Don't be a cheapskate and download low-res images from the web. Spend a few £££'s or $$$'s and get good quality stock images from somewhere like istockphoto.  
This is a very short introductory set of ideas for making effective technical presentations. Try some of them next time you have to do a presentation and see what comments you get.

Finally, if you want to view some good quality presentations take a look at the technical presentations at slideshare.net.

Friday, April 9, 2010

Software Complexity and the Breakdown of Civilisation

Clay Shirky has written a great entry on his blog called The Collapse of Complex Business Models which has set me thinking about the whole issue around complexity; especially as it applies to complex software systems.

The article uses Joseph Tainter's book called The Collapse of Complex Societies for the basis of its premise. In that book Tainter looked at various ancient, sophisticated societies that suddenly collapsed (the Romans and the Maya for example). Tainter postulated that these societies "hadn’t collapsed despite their cultural sophistication, they’d collapsed because of it". His theory was that as societies become more organised and efficient they find themselves with a surplus of resources and managing this surplus makes the society more complex. The spare resources go more into "gilding the lily" than creating what is strictly required. Early on the value of this complexity is positive and often pays for itself in improved output. Over time however the law of diminishing returns reduces this value and eventually disappears completely at which point any additional complexity is pure cost. The society has then reached a tipping point and when some unexpected stress occurs it has become too inflexible to respond. As Tainter says when "the society fails to respond to reduced circumstances through orderly downsizing, it isn’t because they don’t want to, it’s because they can’t".

Shirky's theory is that today, the internet means many businesses are facing similar challenges: adapt to a new way of working or die. In particular the media industry is failing to recognise it has built hugely complicated edifices around the production of media (that's TV, movies, newspapers and music) that the internet is wiping away. Media execs like Rupert Murdoch are looking for ways of maintaining their status quo by just using the internet as a new delivery channel which allows them to continue with their current, costly and complex, business models. What they don't realise is that the internet has changed fundamentally the way the media industry works with practically zero production and delivery costs and unless they change their complex and expensive ways the old order will die out.

So what's this got to do with software systems? Although we might think the systems we are building today are complex we are about to start building a level of complexity that is an order of magnitude (at least) above what it is today. If we are to address some of the worlds really wicked problems then we need to make systems that are not just the siloed systems we have today but that are systems-of-systems interconnected in ways we cannot yet imagine or envisage. Whilst such interconnected systems might enable collaborations that help solve problems we should remain aware that we are adding new levels of complexity that may be hard to manage and even harder to do without if we ever hit some unexpected "stress" situation. In 1964, science fiction author Arthur C. Clarke wrote a short story called "Dial F for Frankenstein". In the story the phone network (this was before the internet had even been thought of although, interestingly Tim Berners-Lee, the inventor of the web, suggested this was the story that anticipated that technology) had become so large and complex it was effectively a giant brain that becomes self-aware. Not only could it not be turned off, it started to think and eventually took over the world! Clarke himself even says "Dial F for Frankenstein is dated now because you no longer dial of course, and if I did it now it wouldn't be the world's telephone system it would be the internet. And that of course is a real possibility. When will the internet suddenly take over?"

We should be very aware therefore, if we are to learn anything from the history of those ancient civilisations, that adding more and more complexity to our systems is not without cost or risk. Although in the short-term we may reap rewards, in the longer terms we may yet regret some of the actions we are about to take and therefore make sure we remember to provide an on/off switch for these systems!

Tuesday, April 6, 2010

Architecture AntiPatterns: Pattern #5 - Death by (Technical) Presentations

AntiPattern Name: Death by (Technical) Presentations
General Form:
A presentation on a technical topic contains many, many slides of tightly packed text with overly complex diagrams that are difficult to read close up let alone from any distance away.   
Symptoms and Consequences:
  • You're invited along to a presentation where the architecture will be "presented".
  • The presentation consists of 167 slides in mainly 12pt font with closely packed words on each page.
  • The presenter often says things like "I'm sorry you can't see this from the back" or " I'm going to skip over this slide as it's not really relevant".
Refactored Solution:
  • Read this book and visit Garr Reynolds blog for ideas and inspiration
  • Architectures should be created as models in a legitimate modelling tool. It's okay to cut and paste pictures into a presentation tool such as PowerPoint as long as they can easily be viewed and are meaningful.
  • Make sure presentations are consistent in their use of layout, colour and fonts.
  • Don't attempt to put all the information in a presentation. Refactor to contain the key points only.
  • Put the detailed information in handouts which are given out after the presentation.
See Pattern #4