Are Architects Cogs or Linchpins?

Peter Cripps architecture, creativity

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.

PowerPoint Makes Us Stupid (Says the US Military)

Peter Cripps presenting ,

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 Anti-Patterns: Pattern #6 – Architecture Thinking Not Doing

Peter Cripps architecture ,

Anti-Pattern 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

How to Create Effective Technical Presentations

Peter Cripps presenting , ,

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 animations.
  • 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.

Software Complexity and the Breakdown of Civilisation

Peter Cripps Technology

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!

Architecture Anti-Patterns: Pattern #5 – Death by (Technical) Presentations

Peter Cripps architecture ,

Anti-Pattern 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

When Is It Time To Quit?

Peter Cripps Technology

Whilst teaching an IT architecture class in Moscow this week I was asked the above question by one of the students. The question was in relation to projects and when you should realise the project is not going to deliver and should therefore be cancelled rather than carrying on regardless. I hate using the phrase “it depends” in answer to a question like this but this was one case when that’s all I could think of! However, having had a bit of time to reflect on this (on a long journey back home) here are a few thoughts that I’ve had since then. This is also related to my previous blog entry.

In some ways working on a software delivery project is a bit like fighting a war (though admittedly you don’t usually risk losing your life). In a war you may not win every battle and may sometimes need to retreat and reconfigure however, the important thing is to focus on the strategic battles that will lead you to get to the overall objective (and win the war). In a software delivery project winning the war is to successfully deliver the system or application on time and within budget. The battles are what the architect and project manager must fight every day to address the technical and other issues which arise and must be overcome for fear of letting the project get out of control. So what are the battles, which if not won, are going to cause the project to fail and, more importantly for this topic, will lead to surrender if the cost gets too high? Here’s my top five in order of importance:

  1. No, or poor, sponsorship.If there is no clear (and strong) sponsorship from the right level in the enterprise then you may as well pack up and go home immediately. Even if the project does get to the delivery stage the chances are no one will really want or need the system. The job of the sponsor is to evangelise, convince and cajole a sometimes reluctant workforce of the need for the new system and the change that it might bring about. Weak sponsors will be unable or unwilling to do this.
  2. Not having a water tight business case.If the business case for why the new system is needed is not well thought through with a clear cost-benefit analysis then there is a danger that the project could be cancelled at any time. I once worked on a project that was cancelled days before we were due to exit system test because a review of the business case revealed a flaw in the return on investment (ROI) of the new system so the client decided to pull the plug on the project rather than deliver something that would not make the cost savings that were expected of it. Painful but probably the right decision!
  3. Not engaging all stakeholders. Not identifying and engaging (i.e. talking to, convincing, schmoosing, wining and dining or whatever it takes) all the stakeholders is a bit like death by a thousand cuts. Although you will start off well, entropy will gradually set in and and things will start to fall apart. Stakeholders who should have been informed early on will learn about the project through the grapevine and will not only not support it but may actively try to kill it. They may see it as a threat or may treat it as sour grapes, “no one bothered to tell me about it so why should I support this”?
  4. Underestimating the complexity of building interfaces to legacy systems. Very few projects have the luxury of a clean sheet of paper when starting out. There is nearly always some old, creaking legacy system that needs to be interfaced with, even short-term or temporarily. In my experience one should never underestimate the complexity of these legacy system interfaces. And I don’t just mean technology interfaces. Many times IT departments will see it as a threat to their existence that what starts out as an interface may ultimately lead to a complete replacement of the system that they run and manage so lovingly and will therefore do whatever they can to derail the project.
  5. Not having regular and viable releases of the system/application. Gone are the days when a project could go off for many years before delivering anything of value to the key stakeholders (or I hope they have). I cannot emphasise enough the importance of delivering something of value that users can get their hands on and starting using that will give them some business benefits. This not only shows them the value of the new application but also gives them a belief that IT can actually deliver stuff and will also get them to “buy-in” to the new system and may well have the useful side-effect that they become sales-people for the new system and will convince colleagues of its benefits.

I believe that if one or more of these issues exist on your project you should either take very serious steps to address them or consider looking for another job because there is a greater than 50% chance everything is going to get very messy and is going to end in tears or much, much worse.

Why Do Complex Systems Projects (Still) Fail?

Peter Cripps architecture , ,

Depending upon which academic study you read, the failure rate of complex IT projects is reported as being between 50% and 80%! I thought I’d test this against my own experiences and took a look back over my career at the number of complex systems I have worked on and how many could be counted as being successful. Clearly the first thing you need to do here is to define “complex” and also “success” so I’m defining complex as being a system with:

  • Multiple stakeholders involved.
  • Multiple systems interfaces.
  • Challenging or high risk non-functional requirements (including delivery schedule and budget).

and “success” as being:

  • Delivered on time and within budget.
  • Met the stakeholders requirements.
  • Went into production and ran for at least 12 months.

By my count I have worked on 18 projects which meet the first set of criteria and of those I reckon 8 meet the second set of criteria so can be thought of as “successful”. So that’s a slightly under 50% success rate! Not brilliant but within the industry average (which is of course nothing to brag about).
As you might expect there is a wealth of information out there on the reasons why IT projects fail. Top amongst these are:

  • Lack of agreed measures of success.
  • Lack of clear senior management ownership.
  • Lack of effective stakeholder management.
  • Lack of project/risk management skills.
  • Evaluation of proposals driven by price rather  business benefits.
  • Projects not broken into manageable steps.

These typical failings were highlighted in a joint British Computer Society/Royal Academy of Engineering report from 2004 called The Challenges of Complex IT Projects. That was six years ago and I wonder what has changed since then? Anecdotaly I suspect not much. Certainly newspaper headlines about failed government IT projects of late (see, for example The Independent on 9th January 2010: Labour’s Computer Blunders Cost £26bn) would seem to indicate we are still not very good at delivering complex systems.

The interesting thing to observe about the above list of course is that none of these problems are technical in nature, not directly anyway. Instead they are to do with governance and process (or lack thereof) and what you might term “soft” aspects of systems delivery, how we manage and understand what people want. One of the right-brain activities which we IT folk sometimes fail to exercise is “empathy”. Our capacity for logical thought (i.e. left-brain activity) has gone a long way to creating the technological society we live in today. However in a world of ubiquitous information that is available at the touch of a button logic alone will no longer cut the mustard. In order to thrive we need to understand what makes our fellow humans tick and really get beneath their skin and to forge new relationships.

Happily this is not something that is easily outsourced, at least not yet! There is still something we can do as IT professionals therefore in engaging with stakeholders, understanding there wants and needs and trying to deliver systems that meet their requirements that can only be done with direct, personal contact.

V is for Versatilist

Peter Cripps creativity ,

On the IT architecture class that I teach in IBM we have a thing about saying IT architects should be T-shaped. What we mean by this is shown below.

Ideally an architect should have a good range of general skills and at least one deep skill. So an architect might be a good Java programmer for example but also have a broader range of skills including project management, negotiating skills, SOA or whatever.

A Gartner research note I discovered recently called The IT Professional Outlook: Where Will We Go From Here? (from 2005) predicted that by 2011 “70 percent of leading-edge companies will seek and develop “versatilists” while deemphasizing specialists.” It defines a versatilist as someone “whose numerous roles, assignments and experiences enable them to synthesize knowledge and context in ways that fuel business value”. This diagram better shows the versatilist skills therefore:

I like this because not only is the versatilist a V-shaped sort of guy, denoting a broad range of skills at a greater depth of understanding and practice, I believe these skills should be cross-discipline and yes, maybe even consist of right-brain as well as left-brain skills.

As mentioned in a previous post I believe that we architects need not only breadth, to quite a level of depth, but also a good range of skills across all disciplines if we are to come up with new ways of thinking to solve some of the wicked problems out there. Architects should therefore by V(ersatilist), not T-shaped.

Skills for Building a Smarter Planet: A Manifesto

Peter Cripps creativity , ,

IBM is currently doing a big advertising campaign called Smarter Planet. I recently put together a lecture for a group of university students which tried to weave together a number of themes which I am currently interested in:

Here’s my manifesto:

In the 21st century IT professionals must adopt more of a systems thinking approach if they are to solve the wicked problems the world faces. If we are truly going to build a smarter planet then we need a new breed of versatilists who are able to solve these problems.

There are a number of themes here I plan to return to in future posts.