Sunday, October 31, 2010

Five Things Not To Say When Presenting

Whilst I cannot confess to have never said any of these myself here are five phrases that you should avoid at all costs when delivering a technical (or indeed any) presentation.
  1. I'm sorry you can't see this at the back. Are you really sorry? I suspect not otherwise you will have made sure everyone could see what you are presenting before showing the slide. Know how big your room is and how big the screen is. As a matter of course never make any font size less than 24 point. Better still avoid words altogether and use pictures or diagrams instead.
  2. I'm just going to skip over the next few slides. Why? Either the slides are relevant to what you have to say or they are not. If they are not then they should not be there. There is always a great temptation to include extra slides "just in case". Don't! You should include only that which is relevant to what you have to say and discard everything else.
  3. Sorry but the colours on this slide don't show up very well. Using colour in presentations is a great way of getting across information. When used properly colour can be used for emphasis as well as categorising data or information. However, be aware that the way colour can appear on a computer screen and how it can appear on a data projector can be very different. Always use bold colours and, if possible, check out the projector you are going to use before starting your presentation.
  4. You probably can't hear this but I'll play it anyway. Use of sound and video can be a great way of getting information across and also helps to keep your audiences attention. However if you are using sound make sure you have an effective sound system and don't, what ever you do, rely on the speakers on your laptop. If you are using sound or video make sure there is adequate kit in the room. As a standby carry a set of portable speakers with you but these will only have limited reach.
  5. I've only got 30 minutes and we need t get through 75 slides. Or any other large number that will be impossible in the given time. Actually there is no golden rule for how many slides you can present in a given amount of time. If each slide has only a single word or picture then 75 slides in 30 minutes is entirely reasonable. However most times those 75 slides are densely packed with information which is impossible to assimilate in the amount of time allotted. As I've said elsewhere don't pack too much information into your presentation. Instead just focus on the key points and use handouts for detailed stuff.

Saturday, October 23, 2010

Why Didn't I Do That?

You know how annoying it is when someone does something that is so blindingly obvious in retrospect you ask yourself the question “why didn't I do that”? I'm convinced that the next big thing is not going to be the invention of something radically new but rather a new use of some of the tools we already have. When Tim Berners-Lee invented the world-wide web he didn't create anything new. Internet protocols, mark-up languages and the idea of hypertext already existed. He just took them and put them together in a radically new way. What was the flash of inspiration that led to this and why did he do it and not someone else? After all that is basically the job of a Solution Architect, to apply technology in new and innovative ways that address business problems. So why did Tim Berners-Lee invent the world-wide web and not you, I or any of the companies we work for? Here are some observations thoughts.
  1. Tim had a clear idea of what he was trying to do. If you look at the paper Berners-Lee wrote, proposing what became the world-wide web, the first thing you'll see it has a very clear statement of what it is he's trying to do. Here is his statement of the problem he's trying to solve together with an idea for the solution: Many of the discussions of the future at CERN and the LHC era end with the questions - “Yes, but how will we ever keep track of such a large project?” This proposal provides an answer to such questions. Firstly, it discusses the problem of information access at CERN. Then, it introduces the idea of linked information systems, and compares them with less flexible ways of finding information. It then summarise my short experience with non-linear text systems known as “hypertext”, describes what CERN needs from such a system, and what industry may provide. Finally, it suggests steps we should take to involve ourselves with hypertext now, so that individually and collectively we may understand what we are creating. Conclusion: Having a very idea or vision of what it is you are trying do helps focus the mind wonderfully and also helps to avoid woolly thinking. Even better is to give yourself a (realistic but aggressive) timescale in which to come up with a solution. 
  2. Tim knew how to write a mean architecture document. The paper describing the idea behind what we now call “the web” (Information Management: A Proposal) is a masterpiece in understated simplicity. As well as the clear statement on what the problem is the paper goes on to describe the requirements that such an information management system should have as well as the solution, captured in a few beautifully simple architecture overview diagrams. I think this paper is a lesson to all of us in what a good architectural deliverable should be.
  3. Tim didn't give up. In his book Weaving the Web Berners-Lee describes how he had a couple of abortive attempts at convincing his superiors of the need for his proposal for an information management system. Conclusion: Having a great idea is one thing. If you can't explain that idea to others who, for example have the money to fund it, then you may as well not have that idea. Sometimes getting your explanation right takes time and a few attempts. The moral here is don't give up. Learn from your failures and try again. It will test your perseverance and the faith you have in your idea but that is probably what you need to convince yourself it's worth doing.
  4. Tim prototyped. Part of how Tim convinced people of the worth of what he was doing was to build a credible prototype of what it was he wanted to do. Tim was a C programmer and used his NeXT computer to build a working system of what it was he wanted to do. He actively encouraged his colleagues to use his prototype to get them to buy into his idea. Having a set of users already in place who are convinced by what you are doing, is one sure fire way of promoting the worth of your new system.
  5. Tim gave it all away. In may ways this is the most incredible thing of all about what Tim Berners-Lee did with the web; he gave it all away. Imagine if he patented his idea and took a 'cut' which gave him 0.00001¢ every time someone did a search or hit a page (I don't know if this is legally possible, I'm no lawyer, but you get the idea). He would be fabulously rich beyond any of our most wildest dreams! And yet he (and indeed CERN) decided not to go down this path. This has surely got to be one of the all time most altruistic actions that anyone has ever taken.

    Friday, October 15, 2010

    Architecting Out of the Box

    I got this from a blog by Seth Godin. He was thinking about it in respect of marketers but it so applies to what we do as well.


    Most of the time, we (IT architects or anyone else) think of our job as a set of tasks that take place in a box. We take inputs from upstream, add some value(hopefully) and create some outputs that we send downstream. 

    It turns out, though (according to Seth), that if we go upstream and alter the stuff that comes to us, it's a lot easier to do great work. And if we go downstream and teach people how to work with what we created, the final (work) product is better as well. 

    Seth gives as an example how a medical doctor can consider her work in the box of the examining room. But if she figures out how to get people to quit smoking before they come in, her results are better. If she figures out how to get people to take their pills after they leave, same thing.

    As Seth says “the challenge lies in spending a lot of time and money on the upstream and downstream parts of the work, instead of always assuming that your [box] is just what happens inside your cubicle, or as a direct result of your actions”. 

    So here's how I would translate this for the humble IT architect:
    • Visit your business sponsors by walking over to their desk (or calling them up on the phone if they happen to be on a different continent). Talk to them. Ask them what is troubling them today and see how you can help.
    • Take a long hard look at those requirements and make a point to go back to the person that wrote them if you don't understand them. Don't just assume stuff.
    • One persons architecture is another ones requirements. What you create will be used by designers and coders to build systems from. Make sure they really understand what you want. Go and visit them (possibly virtually) to see what makes them tick.
    • Here's a really revolutionary idea. Write some code to a) convince youreself you can remember how to do it and b) show your downstream designers/implementers that you know what you are doing and have some empathy.
    Most of what we do all day, intentionally or not, is aimed at keeping us in our boxes. Buck the trend and make an effort to get out of that box and make a difference.

    Monday, October 11, 2010

    Challenging What Architects Do

    For most of this year I've been fortunate (sic) enough to travel around several countries (and indeed continents) delivering a series of architecture workshops to a client. These workshops aim to teach, through the use of instructor led case studies, best practice approaches to building solution architectures. The workshops take a holistic approach to developing architecture by ensuring both the application as well as infrastructure aspects are considered together and both the functional and non-functional requirements are taken into account.

    An enjoyable side-effect of these workshops is I get to meet lots of different people who like to challenge the approach and test my understanding (I sometimes think I'm learning more than the workshop participants). Here's one such challenge (paraphrased) I received recently: “The problem with architects and the work products they produce (for example models built using the Unified Modeling Language) is that the work products become an end in their own right and we can easily lose track of the fact that actually what we want to build is a system with running code on real hardware”. The clear implications behind this challenge could be described via three architecture anti-patterns:
    • Antipattern: Architecture Overkill. Symptoms: Architects create work that no one understands or cares about. Multiple artefacts with overlapping content get created that no one actually reads. They are too large, too complex and may even be delivered too late.
    • Antipattern: Ivory Tower Architecture. Symptoms: Architects are out of touch with real-world technical aspects. Instead they just sit in their ivory-towers making their pronouncements (which most of the time no one listens to).
    • Antipattern: Work Creation. Symptoms: The role of the architect becomes self-fulfilling. They create work products which only they understand and therefore need more architects to help create these work products.
    Here's my response:
    • Any architectural work product needs to have either an up-stream (e.g. to the business) or down-stream (e.g. to the implementers) justification. Each of these groups of stakeholders needs to be able to recognise how the architecture, as encompassed in the work products, addresses their particular concerns otherwise the work product really is only for its own sake. There are other stakeholders who will have interests or concerns in the architecture but I just focus on these to illustrate my point.
    • The role of the architect needs to be clearly defined and work produced around that role. The role may change as business needs etc evolve but the work created should be in tune with that role and ultimately fulfil the needs of the business. This does not, of course, mean that part of what architects  do is research new technology or try out new ideas. Indeed if they don't do this the next point will be tricky to fulfil.
    • One of the difficulties with the role of the architect is that it can mean the architect easily becomes out of touch with the latest trends etc in programming. This can be caused by a number of things including: architects are paid too much to do programming, architects are too senior to do programming, architects are too busy to do programming etc. This particular problem is particularly endemic in many services organisations where architects may be charged out at premium rates and where the role of programming is seen as almost too “menial”. What to do? It's vital that this is not the case. There must always be time allowed in any software architects work day to stay in touch with the stuff that gives him his reason for being.

    Friday, October 1, 2010

    Enterprise Architecture is Dead. Long Live Interprise Architecture

    ZapThink have recently been drip-feeding a series of ZapFlashes predicting the end of Enterprise Architecture (possibly allowing them to derive some further consulting/education business by creating a little fear, uncertainty and doubt). Here are some of their predictions and my thoughts. Comments welcome.
    • The secret to 21st century software innovation. Is, according to ZapThink, in harnessing the power of complex systems (i.e. rather than just enterprise-wide systems). A complex system is one that shows some form of emergent behaviour where the properties of the system as a whole exhibit behaviour that the individual components do not. Most people don't get this confusing systems that are just complicated with ones that are complex. For me this is spot on. As the enterprise morphs into basically the whole of the internet traditional governance models breakdown. The boundaries of the enterprise can no longer be nicely defined and who is in the enterprise and who is not becomes harder to pin down. People who get this and who can successfully harness the “interprise” (my new word of the month) by using the positive effects of social networking etc will win out over the next few years. Of course this involves huge risks not least of which around how will enterprises keep control of their data and intellectual capital.
    • RIP enterprise software. Enterprise software as provided by the large package providers is seen as large and inflexible and not delivering on the benefits promised by SOA. Companies are finding themselves encumbered with expensive and hard to maintain software they can't “bend” to do what they want. ZapThink's take is that whilst enterprise software may have failed SOA has also failed to deliver on its promise of providing flexible business processes that can be quickly adopted to new needs. My take is that like everything else in our industry nothing is given chance to bed in before the next wave comes and sweeps everyone along with it. Many clients I see are still grappling with getting an effective process in place for developing traditional systems let alone service-based ones and definitely cannot deal with complex systems properly. 
    • The beginning of the end for Enterprise Architecture frameworks. Architecture frameworks (especially enterprise ones like Zachman and DoDAF) are counterproductive to developing an effective EA strategy. These frameworks are inflexible, sometimes encouraging what ZapThink refer to as checklist architecture. Checklist architecture focuses on achieving goals laid down by the architecture framework rather than the changing needs of the business. True but having no framework at all leads to even greater chaos in my experience. A framework is a structure which is meant to contain relevant guidance and work products to deliver real-world solutions. Frameworks that become too theoretical are always doomed to fail as they should. I hope this forms the basis of something more relevant to the real world.
    So how would I characterise “interprise architecture”?
    1. Interprise architecture recognises that it is not enterprise architecture that is dead but trying to constrain architecture by the bounds of the enterprise that is no longer achievable. The 'architecture' bit still applies, but not the 'enterprise' bit.
    2. Governance models need to recognise that this extended enterprise includes people and other systems that are not controlled by the IT department (people using social networking software who will periodically 'overlap' with the enterprises systems).
    3. The 'architecture' bit needs to take into account the fact that systems are complex (in the emergent sense of the word) and it's not always possible to tie down the requirements in a nice orderly way. Indeed fully defining the requirements may be counter-productive and not allow emergent behaviour. Processes for developing such complex systems need to take this into account.
    To be sure this is not a complete list. This idea is not yet fully-formed in my own mind and needs a bit more time to 'emerge' properly. Watch this space as they say.