Monday, January 31, 2011

Learning Architecture (Or Anything really)

I spent most of 2010 travelling the world teaching Architectural Thinking for a client. (Here is a reasonable description of some of what this covers. It's the best publicly available description I can find but please contact me if you would like more information on this class).

I always reckon that you learn just as much as a teacher as you do as a student (or should do) so here's some stuff I learnt myself. This is not rocket science and many people may consider this obvious but for those for whom this is not the case I hope you find it useful.
  1. People learn best when they have some fun. This doesn't mean you have to be a great comedian to deliver an effective training class however it does help if you can arrange some fun activities as part of the learning. Quizzes (that also inject an element of competition) work well as a way of re-enforcing peoples learning.
  2. Ensure that at least half the time (and preferably two thirds of it) are spent on getting the attendees to do something. This does not have to be a full-blown case study (though you certainly need one of those) but should at least include plentiful opportunities for discussions and Q&A sessions (where the questions are not just asked by the students).
  3. Less really is more. When delivering a lecture, or a complete class, especially one you are very familiar with. It is tempting to cram more and more information in as you deliver more classes. People ask a question, you answer it and think "hey, why don't I create a slide for that for next time". Don't. Slide-creep is one of the great evils of our time. Rather thank thinking "what can I add" think "what can I remove". Hand out detail as additional reading. Keep the main-deal brief.
  4. Try, whenever you can, to tell stories rather than deliver dry facts. For me a teacher is, above all else, an experienced practitioner. Introducing your own "war stories" at appropriate points is what makes a great and teacher.
  5. Great public speakers (Richard Feynman, Steve Jobs, Banjamin Zander) inject passion into what they have to say. If you are not passionate about what you are saying then maybe you should not be standing up in front of others saying it! Think about what first made you interested in the topic you are delivering and weave that into the storyline. Injecting some of your personal self into a subject helps engage the audience and make them believe in what you have to say.  

Finally take a look at this great advice from Seth Godin on organising a retreat. It may not be a full blown retreat you are organising but it contains great advice for just about any learning event where you want to get the best out of people.

Friday, January 21, 2011

2011 Architecture Survival Guide

An article in last Sundays Observer newspaper about Facebook has set me thinking about how we architects can not only survive in today's rapidly changing technological environment but also actually make a positive difference to the world (even if it's not on the scale of Facebook, assuming you think that has made a positive impact on the world).

The article by John Naughton examines the claim by the Winklevoss twins that they were ripped off when they reached a settlement with Mark Zuckerburg in 2008 after they claimed it was they who had invented Facebook. Their claim is that the number of Facebook shares they acquired was based on a false valuation. For an entertaining view of this see, or rent, The Social Network which goes into the history of how Facebook came into being. The article goes on to pose the question: would we now be looking at a social networking service with 600 million users if the Winklevoss twins had been the ones to develop Facebook?

Naughton thinks not and goes on to explain that although the Winklevoss twins were not stupid they probably "laboured under two crippling disadvantages":
  1. They were, and probably still are, conventional people who may have been good at "creating businesses in established sectors but who find it hard to operate in arenas where there are no rules".
  2. The twins weren't techies and so had no real insight into the technology they were creating and its possibilities. They were therefore less likely to "spot the importance of allowing Facebook to become a software platform on which other people could run applications".
Here's my takeaway from this if you want to come up with new ideas, at whatever scale, no one else has thought of.
  1. Don't think conventionally.Conventional thinking will end up creating conventional business models. Conventional means doing what you've been told or what your peers do. Someone once said "fear of our peers makes us conservative in our thinking". Zuckerburg was not only fearless of his peers (the Winklevoss twins) but had no qualms about using (some would say stealing) their ideas and using them for his own ends. I guess it poses an interesting moral dilemma about when it is right to steal someone elses idea because you think you can do more with it. Facebook paid for this by handing over cash and shares to the Winklevoss twins but have benefited from this 'investment' many times over.
  2. Don't think like everyone else. Walter Lippmann (a writer and political commentator) once said "where we all think alike, no one thinks very much." Some people claim that Zuckeburg (if you believe the movie at any rate) exhibits characteristics that place him on the autistic spectrum. (actually as having Asperger syndrome). One of the characteristics of someone with Aspergers is that they display behavior, interests, and activities that are restricted and repetitive and are sometimes abnormally intense or focused. Zuckeburg not only thought differently to everyone else but took an idea and focused on it intensely (many, many hours of programming) until Facebook was created. 
  3. Think visually. Interesting related to number 2. People on the autistic spectrum are often more visual thinkers than those who are not. We often joke about "back of an envelope" or "back of a fag packet" designs but setting aside the medium the ability to visualise your thoughts quickly and succinctly is a key characteristic it's worth fostering. One of my more memorable ad-hoc design sessions took place over a meal in a restaurant where we used the table cloth as a our drawing canvas. Luckily it was a paper table cloth!
  4. Don't get out of touch with technology. One of the dangers of becoming an architect in order to make yourself "more valuable" (see Dilbert below) is you not only lose touch with technology but you lose the ability to exploit it in ways others may not see. Making Facebook an open platform has been one of the key factors in its runaway success. I've discussed before the importance of being a versatilist (broad in several disciplines and deep in a few specialisms) and this ones all about picking your technology (we can't all be good at everything) and specialising yourself in it!

Thursday, January 13, 2011

Software Developments Best Kept Secret

A few people have asked what I meant in my previous entry when a said we should be "killing off the endless debates of agile versus waterfall." Don't get me wrong, I'm a big fan of doing development in as efficient a way as possible, after all why would you want to be doing things in a 'non-agile' way! However I think that the agile versus waterfall debate really does miss the point. If you have ever worked on anything but the most trivial of software development projects you will quickly realise that there is no such thing as a 'one size fits all' software delivery lifecycle (SDLC) process. Each project is different and each brings its own challenges in terms of the best way to specify, develop, deliver and run it. Which brings me to the topic of this entry, the snappily titled Software and Systems Process Engineering Metamodel or 'SPEM' (but not SSPEM). 

SPEM is a standard owned by the Object Management Group (OMG), the body that also owns the Unified Modeling Language (UML), the Systems Modeling Language (SysML) and a number of other open standards. Essentially SPEM gives you the language (the metamodel) for defining software and system processes in a consistent and repeatable way. SPEM also allows vendors to build tools that automate the way processes are defined and delivered. Just like vendors have built system and software modeling tools based around UML so too can vendors build delivery process modeling tools built around SPEM.

So what exactly does SPEM define and why should you be interested in it? For me there are two reasons why you should look at adopting SPEM on your next project.
  1. SPEM separates out what you create (i.e. the content) from how you create it (i.e. the process) whilst at the same time providing instructions for how to do these two things (i.e. guidance).
  2. SPEM (or at least tools that implement SPEM) allows you to create a customised process by varying what you create and when you create it.
Here's a diagram to explain the first of these.

SPEM Method Framework
The SPEM Method Framework represents a consistent and repeatable approach to accomplishing a set of objectives based on a collection of well-defined techniques and best practices. The framework consists of three parts:
  • Content: represents the primary reusable building blocks of the method that exist outside of any predefined lifecycle. These are the work products that are created as a result of roles performing tasks.
  • Process: assembles method content into a sequence or workflow (represented by a work breakdown structure) used to organise the project and develop a solution. Process includes the phases that make up an end-to-end SDLC, the activities that phases are broken down into as well as reusable chunks of process referred to as 'capability patterns'.
  • Guidance: is the ‘glue’ which supports content development and process execution. It describes techniques and best-practice for developing content or 'executing' a process.
As well as giving us the 'language' for building our own processes SPEM also defines the rules for building those processes. For example phases consist of other phases or activities, activities group tasks, tasks take work products as input and output other work products and so on.

This is all well and good you might say but I don't want to have to laboriously build a whole process every time I want to run a project. This is where the second advantage of using SPEM comes in. A number of vendors (IBM and Sparx to name two) have built tools that not only automate the process for building a process but which also contain one or more 'ready-rolled' processes to get you started. You can either use those 'out of the box', extend them by adding your own content or start from scratch (not recommended for novices). What's more the Eclipse foundation have developed an open software tool, called the Eclipse Process Framework (EPF) that not only gives you a tool for building processes but also comes with a number of existing processes, including OpenUP (open version of the Rational Unified Process) as well as Scrum and DSDM.

If you download and install EPF together with the appropriate method libraries you can use these as the basis for creating your own processes. Here's what EPF looks like when you open the OpenUP SDLC.

EPF and OpenUP
The above view shows the browsing perspective of EPF, however there is also an authoring perspective which allows you to not only reconfigure a process to suit your own project but also add and remove content (i.e. roles, tasks and work products). Once you have made your changes you can republish the new process (as HTML) and anyone with a browser can then view the process together with all of it work products and, most crucially, associated guidance (i.e. examples, templates, guidelines etc) that allow you to use the process in an effective way.

This is, I believe, the true power of using a tool like EPF (or IBM's Rational Method Composer which comes preloaded with the Rational Unified Process). You can take an existing SDLC (one you have created or one you have obtained from elsewhere) and customise it to meet the needs of your project. The amount of agility and number of iterations etc that you want to run will depend on the intricacies of your project and not what some method guru tells you that you should be using! 

By the way for an excellent introduction and overview of EPF see here and here. The Eclipse web site also contains a wealth of information on EPF. You can also download the complete SPEM 2 specification from the OMG web site here.

Thursday, January 6, 2011

Architecture is Architecture?

At OT 99 (that's Object Technology 1999, now known as SPA for Software Process Advancement) I attended a session by Kent Beck called Software is Software - Beyond the Horseless Carriage. The basic premise of Kent's talk was that it was about time the software business "grew up" and its practitioners recognise it for what it is, a discipline in its own right which no longer needs to continuously borrow terms and techniques from other industries and disciplines. The title of the session refers to the time when the automobile was first invented and people called them horseless carriages because horse-drawn carriages were the only frame of reference they had. Unfortunately, 12 years later, I don't think we have quite got around to jettisoning our horseless carriages, especially in the upfront work that is done in trying to map out the major system components and their relationships, sometime referred to as architecture (a word which itself is borrowed from another profession of course). On the face of it this may not seem to be a problem; after all those other industries (civil engineering, auto-engineering even film making) have been around a lot longer and so must be able to offer good advice and guidance to the business of software mustn't they? Actually, I think there is a problem and Kent Beck was, and still is, right.
  • The business of 'making' software is fundamentally different from any other human endeavor. Software is infinitely malleable and potentially changeable right up to (and sometimes after) it has gone into production. No other engineering discipline has that flexibility. At some point drawings and blueprints have to be signed off, factories and production lines have to be built, building sites prepared and production begun. After this any change becomes prohibitively expensive. With software the perception (and sometimes the reality) is that code changes can be made right up to the moment the software ships.
  • Most other engineering disciplines have fairly well defined job roles, often with their own professional organisations, training programmes and qualifications and well understood and mature tools. These roles are usually carried out by separate individuals (in the construction industry it's unlikely the architect will roll her sleeves up and start laying bricks).
  • The engineering and manufacturing approach, or process, is by and large pretty well understood and has been refined over a long period of time (sometimes hundreds of years). The approaches can be taught and are an integral part of the role of being an architect or aero-engineer. Further, these approaches are built around a common language which is also taught and well understood by its practitioners. 
A rigorous approach to the field of software architecture needs to recognise the differences whilst at the same time understanding its constraints and build a solid, engineering based approach to its development. This should include killing off the endless debates of agile versus waterfall or structured versus object-oriented and any of the other interminable 'religious wars' that we seem to love embarking on and focus in on what matters: applying IT in a reasoned and structured way to solving real-world (and sometimes complex) business problems.

As we enter the new year lets celebrate the field of software development for what it is and help forge the right amount of rigor and discipline in creating a 'proper' profession that finally loses the shackles of all those other industries. After all as this guy says (far more eloquently than me) "the processor is an expression of human potential" and is "akin to a painter’s blank canvas" (see this great drawing). I'd like to think of us architects as the painters ready to fill that canvas with great art. Oh heck, but that means we are now comparing architecture with art and that would never do.