Wednesday, November 30, 2011

Social Objects as Instruments of Architecture

According to Hugh MacLeod a social object: 

“is the reason two people are talking to each other, as opposed to talking to somebody else.” 

also:

"social networks are built around social objects, not vice versa. The latter act as “nodes”. The nodes appear before the network does."

In discussions around architecture there can often be much confused talk around what is needed, what an architecture looks like and what decisions need to be made in order to make it so. There are three useful architectural social objects that help cystalise our thoughts and  allow a network of related artefacts to be created. These are:
  • Use Cases or Scenarios - Illustrate what I am trying to do via real-world examples that use human actors to illustrate what we are trying to achieve.
  • Architecture Overview - The main architectural elements (components) that the system is comprised of.
  • Architecture Decisions - What decisions am I making, what options did I consider and why did I choose the ones I did.
These social objects seem to apply to all levels of architecture from the smallest application to the largest enterprise architecture. Of course they are by no means all you need but serve as a pretty good starting point for all that follows.

Monday, November 28, 2011

Educating an IT Workforce for the 21st Century

A report on the BBC Today programme this morning argues that the "Facebook generation needs better IT skills" and that UK schools should be providing courses in programming at GCSE. The report bemoaned the fact that so called Information and Communications Technologiy (ICT) GCSEs did little more than teach students how to use Office programmes such as Word and Excel and did not prepare students for a career in IT. The backers of this report were companies like Google and Microsoft.

This raises an interesting question of who should be funding such education in these austere times. Is it the role of schools to provide quite specific skills like programming or should they be providing the basics of literacy and numeracy as well as the more fundamental skills of creativity, communication and collaboration and leave the specifics to the industries that need them? Here are some of the issues related to this:
  1. Skills like computer programming are continuously evolving and changing. What is taught at 14 - 16 today (the age of GCSE students in the UK) will almost certainly be out of date when these students hit the work force at 21+.
  2. The computer industry, just like manufacturing before it, long ago sent out the message to students that programming skills (in Western economies at least) were commoditised and better performed by the low-cost economies of the BRIC nations (and now, presumably, the CEVITS).
  3. To most people computers are just tools. Like cars, washing machines and mobile phones they don't need to know how they work, just how to use them effectively.
  4. Why stop at computer programming GCSE? Why not teach the basics of plumbing, car mechanics, cookery and hairdressing, all of which are in great demand still and needed by their respective industries.
  5. Public education (which essentially did not exist before the 19th century, certainly not for the masses) came about to meet the needs of industrialism and as such demanded skills in left-brained, logical thinking skills rather than right brained, creative skills (see Sir Ken Robinson's TED talk on why schools kill creativity). As a result we have a system that rewards the former rather than the latter (as in "there's no point in studying painting or music, you'll never get a job in that"). 
In an ideal world we would all be given the opportunities to learn and apply whatever skills we wanted (both at school and throughout life) and have that learning funded by the tax payer on the basis it benefits society as a whole. Unfortunately we don't live in that ideal world and in fact are probably moving further from it than ever.

Back in the real world therefore industry must surely fund the acquiring of those skills. Unfortunately in many companies education is the first thing to be cut when times are hard. The opposite should be the case. One of the best things I ever did was to spend five weeks (yes that's weeks not days), funded entirely by IBM, learning object-oriented programming and design. Whilst five weeks may seem like a long time for a course I know this has paid for itself many, many times over by the work I have been able to do for IBM in the 15 years since attending that course. Further, I suspect that five weeks intensive learning was easily equivalent to at least a years worth of learning in an educational establishment.
 
Of course such skills are more vital to companies like Google, Microsoft and IBM than ever before. Steve Denning in an article called Why Big Companies Die in Forbes this month quotes from an article by Peggy Noonan in the Wall Street Journal (called A Caveman Won't Beat a Salesman). Denning uses a theory from Steve Jobs that big companies fail when salesmen and accountants are put in charge of and who don't know anything about the product or service the company make or how it works. Denning says:

"The activities of these people [salesmen and accountants] further dispirit the creators, the product engineers and designers, and also crimp the firm’s ability to add value to its customers. But because the accountants appear to be adding to the firm’s short-term profitability, as a class they are also celebrated and well-rewarded, even as their activities systematically kill the firm’s future".

Steve Jobs showed that there was another way.  Namely, to keep playing the offense and focus totally on adding value for customers by creating new and innovative new products. By doing that you can make more money than the companies that are milking their cash cows and focused on making money rather than products.

Companies like Google and Microsoft (and IBM and Apple) need people fully trained in the three C's (creativity, communication and creativity) who can then apply these to whatever task is most relevant to the conmpanies bottom line. It's the role of those companies, not government, to train people in the specifics.

Interestingly Seymour Papert (who co-invented the Logo programming language) used programming as a tool to improve the way that children think and solve problems. Papert used Piaget's work of cognitive development (that showed how children learn) and used Logo as a way of improving their creativity.

Finally, to see how students themselves view all this see the article by Nikhil Goyal's (a 16-year-old junior at Syosset High School in New York) who states: "for the 21st century American economy, all economic value will derive from entrepreneurship and innovation. Low-cost manufacturing will essentially be wiped out of this country and shipped to China, India, and other nations" and goes on to propose that 
"we institute a 21st century model of education, rooted in 21st century learning skills and creativity, imagination, discovery, and project-based learning". Powerful stuff for one so young, there may yet be hope for us.

Thursday, November 17, 2011

Parkinson's Law of Triviality (Applied to Architecture)

Parkinson's Law of Triviality (as proposed by C. Northcote Parkinson in 1957) is that people give disproportionate weight to trivial issues. Parkinson gives as an example a hypothetical (planning) committe deliberating on the building of a nuclear power plant and a bicycle shed. Parkinson stated that "the time spent on any item of the agenda will be in inverse proportion to the sum involved." Clearly a nuclear reactor is vastly expensive and complicated and the average person is unlikley to understand it because it is so far outside the realms of their daily experience. A bike shed, on the other hand, everyone understands (or thinks they do, which can be even more dangerous). The result is that people will be reluctant to discuss for long the nuclear reactor either because they assume those working on it understand it or because they are to fearful of making themselves look foolish in front of the experts. The bike shed however can result in endless discussions because everyone involved wants to add their "feature" and show that they have contributed. While discussing the bikeshed, debate rages over what the best choice of roofing should be, whether there should be windows, whether it should be fully enclosed with walls and a door etc, etc rather than whether the shed is a good idea or not.

Parkinson's Law of Triviality is something that frequently creeps into architecture discussions. When requirements are being discussed and how best to realize them architecturally it is frequently the case that when the domain under discussion consists of parts that are familiar and ones that are not it is the former that will often receive inordinate amounts of discussion whereas the latter do not (but usually should). A good example to illustrate this is that of e-commerce systems. Because most people have used such systems everyone will have an opinion on the bits they are familiar with (the actual look and feel of the shopping experience for example, do you call it a shopping basket or a trolley, do you allow goods to be placed in the basket before you have logged in or registered and so on). The part of the system that deals with payment however (i.e. that goes off in the background and does credit checks etc) or checking stock level is not seen so people will probably have less of an opinion on it. This part, at least as far as the web site owner is concerned, is the most important however because if that does not work he will lose money. Worse however is if the "payments specialist" says that this is the way payments will work, and no one else feels they have the expertise or authority to challenge her. Doing something because that's the way we always do it is an example of the Golden Hammer anti-pattern and does not always result in the most innovative or creative new systems.

So how to protect against falling foul of Parkinson's Law of Triviality?
  1. Good architects need to develop deep domain knowledge and know how to, and be fearless in doing so, challenge expert opinion. Frequently appearing foolish by challenging the blindingly obvious is a small price to pay for occasionally highlighting a problem which everyone else overlooked because they were following conventional wisdom.
  2. Ensure complex problems receive proportionately more discussion than simple ones. In other words cut the discussion of addressing the simple problem sooner to allow time to discuss the complex ones. Better still if in a meeting there are several problems to be discussed prioritise them by complexity and start with the most complex first. Leaving simpler ones till the end means you can rush those through when everyone gets tired or you are out of time.
  3. Recognise that everyone has an equal say and it is often the people who know least about the problem that ask the daft, but hard, questions. This of course would seem to go against number 1. If everyone is an expert doesn't that mean no one will be naive enough to ask the simple but challenging questions? No. A good team has a diverse mix of skills, knowledge and opinions and should allow everyone to comment.
  4. Leave your ego at the meeting room door and do not use your relative position in the hierarchy of the company to trivialise other peoples ideas or prevent constructive discussion because it is not "going your way".
  5. Finally capture all decisions in a systematic way (recording at the very least what the decision was, what options were discussed, the rationale for choosing the one you did and any related decisions or implications).

Tuesday, November 8, 2011

What Can Architects Learn from Steve Jobs

I've just finished reading Steve Jobs by Walter Isaacson. In case there is anyone out there who doesn't know it yet, this is the authorised biography that Jobs asked Isaacson to write which was completed a few weeks before Jobs untimely death aged 56 last month. Jobs insisted that Isaacson would have complete control over the contents of the book saying he would not even read it before it was published adding "I don't have any skeletons in my closet that can't be allowed out".

Jobs is clearly a very complex personality, on the one hand a creative genius whose zen like focus on simplicity and efficiency helped create some of the most beautiful and useful gadgets of our time (some of which we never even knew we needed) whilst on the other he was a bully and a tyrant who knew exactly how to "size people up, understand their inner thoughts, and know how to relate to them, cajole them, or hurt them at will". One of jobs girl friends, who later went on to found a mental health resource network in California, even went so far to say that she thought Jobs suffered from Narcissistic Personality Disorder (NPD) in which the individual is described as being excessively preoccupied with issues of personal adequacy, power, prestige and vanity.

Whilst it is to be hoped that NPD is not a prerequisite for being a software architect Jobs did have vision and understanding of IT that we as architects can learn from. Six big ideas that stand out in this respect are:
  1. Engineering matters. When jobs met with President Obama in 2011 he implored the President to reform the US education system and to create more engineering students. Jobs said "if you could educate these engineers we could move more manufacturing plants here". Whilst there was always an uneasy tension between engineering and design at Apple Jobs recognised and valued the importance of there being an engineering led rather than sales led team at the top of the company berating companies like Microsoft (under Balmer), IBM (under Akers) and HP (under their last several CEOs) for putting sales people in charge rather than engineers. For software architects, engineering clearly translates to being intimately knowledgeable with the technology you are using, knowing how to put the working parts together. The best architects I know are passionate about technology.
  2. Artistry and design matters just as much as engineering. This is a theme that Jobs emphasises over and over again. From when he dropped out of college and instead took a course on calligraphy to his sometimes maniacal focus on the smallest details of design to make the product as satisfying and aesthetically pleasing as possible. He even emphasized that circuit boards, which no one would ever see once the product was fully assembled, should be laid out in as clean and uncluttered was as possible. It is this aspect of design that most matters for architects. Provided that functionally a system does what it is meant to do within the required constraints and system qualities one could argue it does not matter how messily the software is assembled. Whose going to see it anyway? This misses the point though.Great design, as opposed to just good enough design, means the system will be easier to maintain, take less effort to learn and generally be more enjoyable for those that need to carry on working on it once the architects and developers have moved on.
  3. Simple is better than complex. Apple had a design mantra: "Simplicity is the ultimate sophistication" or as Jobs said "very simple, and we're really shooting for Museum of Modern Art quality". Jobs felt that design simplicity should be linked to making products easy to use.So much of the software that we create today is far too complex and feature rich and as a result is very hard to use. People will often say that it has to be like that because just look at all the features you are getting. Unfortunately a lot of the time many of those features are not needed but add to the general bloat of the systems we build making them hard to use as well as difficult to maintain. Sadly building a complex system is often easier than building a simple one and it is not many architects that see value in stripping out functionality rather than adding it.
  4. An unremitting focus on detail is key to creating a great product. Jobs was unique in that he was able to hold both the big picture view as well as zooming in to fine details. He would often sweat over the smallest detail until he was satisfied it was just right. This could be anything from the colour of a screw on the back plate of the iPod to the angle of the bevel on the iPad to make someone want to pick it up. This capacity for holding both the big picture view whilst also being able to zoom right down and question low level details is probably one of the hardest things architects have to do but being able to do so gives a definite advantage and enables greater integrity as well as better execution of vision.
  5. Customers don't always know what they want. In September 1982 when Jobs and his team were designing the original Macintosh he held a retreat for the Mac team near Monteray where he gave a presentation on his thoughts for the Mac. At the end someone asked whether or not they should do some market research to find out what customers wanted. "No", replied Jobs, "because people don't know what they want until we've shown them". He then pulled out a device the size of a desk diary and flipped it open, it turned out to be a mock-up of a computer that could fit into your lap with a keyboard and screen hinged together like a notebook. "This is my dream of what we will be making in the mid- to late eighties", Jobs said. Apple supposedly never did do any market research preferring to follow the Henry Ford approach who said he never asked what people wanted because they would have just asked for a better horseless carriage. Whilst it is probably the case that people can often see how to make incremental improvements to products they usually cannot see how to make disruptive changes that introduce a who new way of doing things, possibly making everything that went before it redundant. It is the job of the architect to show what is in the realms of the possible by creating new and innovative systems.
  6. Putting things together in new and creative ways is sometimes more important than inventing things. Jobs was not the first to market with an MP3 player, a mobile phone or a tablet computer. Others had already innovated and built these things. What Jobs and Apple did were to tweak things that already existed. As Isaacson says "he had noticed something odd about the cell phones on the market: They all stank, just like portable music players used to". Jobs applied his design skills to these and came up with a (far) better product and in fact a whole new platform as well (i.e. the computer as the digital hub. Architects to need to learn that its often putting together existing components in new and innovative ways that really counts and gives a competitive and business advantage.