Think Like An Architect

A previous entry suggested hiring an architect was a good idea because architects take existing components and assemble them in interesting and important ways. So how should you “think architecturally” in order to create things that are not only interesting but also solve practical, real-world problems? Architectural thinking is about balancing three opposing “forces”: what people want (desirability), what technology can provide (feasibility) and what can actually be built given the constraints of cost, resource and time (viability).

It is basically the role of the architect to help resolve these forces by assembling components “in interesting ways”. There is however a fourth aspect which is often overlooked but which is what separates great architecture from merely good architecture. That is the aesthetics of the architecture.
Aesthetics is what separates a MacBook from a Dell, the Millau Viaduct in France from the Yamba Dam Bridge in Japan and the St Mary Axe from the Ryugyong Hotel in North Korea. Aesthetics is about good design which is what you get when you add ‘significance’ (aesthetic appeal) to ‘utility’ (something that does the job). IBM, the company I work for, is 100 years old this year (check out the centennial video here) and Thomas Watson, IBM’s founder, famously said that “good design is good business”. Watson knew what Steve Jobs, Tim Brown and many other creative designers know; aesthetics is not only good for the people that use or acquire these computers/buildings/systems it’s also good for the businesses that create them. In a world of over-abundance good design/architecture both differentiates companies as well as giving them a competitive advantage.

Six Non-IT Books for IT Architects

There are now several myriad books out there on the topic of software architecture, including this one I have contributed to. There are other skills an architect needs to do their job which are not just to be found in IT books however. Here are six books which have helped me in my job together with a few reasons why I think they are useful:

  1. Change by Design by Tim Brown. Tim Brown is the CEO of IDEO a design company based in Palo Alto, California. Introduces the concepts of “design thinking” that can be applied to any problem and shows how empathy, play, storytelling and prototyping can all be bought together in coming up with new and innovative designs. Top tip: Deploy interdisciplinary teams of multi-talented people (i.e. true versatilists) to solve hard design problems. Even if you don’t get the book at least visit the link I’ve given to view the wonderful mid map.
  2. Presentation Zen by Garr Reynolds. Garr is the master of giving advice on how to create simple, clear and relevant presentations. Here he applies the zen principles of simplicity that will change how you think about creating presentations using PowerPoint or Keynote. Top tip: Picture superiority effect. Pictures are remembered better than words. Humans are hardwired for using images to communicate. Go visual wherever and whenever you can.
  3. A Whole New Mind by Dan Pink. Dan describe how, if we are to survive in the 21st century world of work, we must make more use of the left side, the creative side, of our brain rather than the traditional right (logical thinking) side. Top tip: Use stories to help illustrate your ideas. Stories represent a pathway to understanding that doesn’t run through the left side of the brain.
  4. Notes on the Synthesis of Form by Christopher Alexander. Alexander recognises that problems come with multiple, poorly understood requirements that interact with each other, creating conflicts and contradictions. Something we in IT have known for years. This book describes an approach for dealing with often multiple conflicting requirements to come up with the “best fit” solution. Top tip: It is difficult to specify a complete set of requirements that need to be met to achieve a “best fit”. A practical approach is to define ‘good fit’ as the absence of ‘misfits’, since these are usually what makes the problem obvious and can be ascertained through inspection of prior designs. Although designers may argue over the importance of a particular misfit, they are less likely to disagree on whether the misfit exists.
  5. Ignore Everybody by Hugh MacLeod. Hugh is an artist that makes a living creating art on the back of business cards, selling wine and running an extremely insightful web site on applying creativity to help you improve your job as well as your life. Top tip: Don’t try to stand out from the crowd, avoid crowds altogether.
  6. The Presentation Secrets of Steve Jobs by Carmine Gallo. Great book with lots of example on how Steve Jobs creates, prepares for and delivers his presentations to introduce new Apple gadgetry on the world. Top tip from book: Use plain English and photographs rather than techno mumbo-jumbo and slides densely packed with indecipherable text and bullet points.

On Thinking Architecturally

Tim Brown (CEO of IDEO) has written a great book on design thinking called Change by Design. Check out the link to see his mind-map of what the book is about.The basic premise of the book, why its about design thinking rather just design, is that design thinkers take a far more holistic approach to solving design problems. They use an interdisciplinary approach, think around the problem, including viewing the constraints as enablers rather than what should be fought against, and come up with ideas that would otherwise not have been thought of if ‘ordinary’ design had been applied. One of the case studies Tim uses in the book is the setting up of a live laboratory in the Mayo Clinic in Rochester, Minnesota to develop new approaches to patient care which involved designers, health care professionals, business strategists and patients to develop ideas for the “patient-provider experience”. A methodology called SPARC (See-Plan-Refine-Communicate) was adopted (which is I suspect based on the Deming Cycle) to show how design thinking could be applied not only to product design but also service design.

Returning to the mind-map that is on the inside front-cover of Change by Design its two starting points are ‘What’ (is it we are trying to do/solve) and ‘How’ (are we going to approach the design). This fits nicely with my own concept of what we term ‘architectural thinking‘ where we add an additional ‘node’ which is ‘Why’ (are we doing it this way). I prefer to illustrate this as a Venn diagram as shown below. The intersection of the three sets is what we consider when ‘thinking architecturally’.

  • What – The requirements we are trying to address. Architectural thinking focuses is on those requirements (functional, qualities and constraints) we think are architecturally significant in some way.
  • Why – Captures the key decisions we are making. Architectural thinking focuses on the architectural aspects which lead to major structuring, placement or procurement decisions. Could be explicit (as a fully documented decision with options looked at and rational for making the decision we did) or implicit in a diagram or model.
  • How – The design and implementation of the system. Architectural thinking focuses on those elements of the design that are significant to the architecture (maybe patterns applied, key principles adopted etc).

The key thing in all this is that the thinking applies to the significant elements not everything. The key skill of the architect is to understand which things are important and which can be left to someone else to fret over.

We Need More Women (IT) Architectural Thinkers (Duh)!

Yes I know, a statement of the blindingly obvious. People of have been bleating on about this for years but nothing much seems to change. My recent and current experiences of teaching IT architecture for a number of different clients rarely has more than 10% of the classes being made up of women (and its usually 0%!). Even more depressingly, from what I’ve seen of university IT courses, there seems to be a similarly small number of female students entering into careers in IT. So why does it matter that 50% of the worlds population only have such a poor showing in this profession?

In his book Change by Design Tim Brown, CEO and president of IDEO relates the following apocryphal story. Whilst working on a kid’s product for Nike IDEO gathered a group of kids at their Palo Alto design studio to brainstorm ideas. The boys and girls (who were eight to ten year olds) were split into separate groups in different rooms, given some instructions and left to get on with it for an hour. When the results were analysed it was found that the girls had come up with more than two hundred ideas whereas the boys had struggled to come up with fifty. The reason for this? The boys were eager to get their ideas out there and were barely conscious of of the ideas of their fellow brainstormers. The girls on the other hand “conducted a spirited but nonetheless serial conversation in which each idea related to the one that had come before and became a springboard to the one that came next”. According to Tim one of the key rules of brainstorming is to “build on the ideas of others” and it would seem girls have an innate ability to do this whereas boys, possibly due to their more competitive tendencies, want to force the ideas to be the ones that “win”.

Although this story relates to a group of eight to ten year olds my own anecdotal evidence indicates it is equally applicable to all age groups. When observing how team members interact on case studies that we run as part of our architecture classes there is inevitably better and more informed discussion and end results when the teams are mixed (even when females are in the minority) than when they are made up of all males.

My hope is that we are entering a new age of enlightenment when it comes to how we put together project teams that are made up of true versatilists rather than traditional teams of “hard-core” IT techie types. Versatilists by definition have good skills across a range of disciplines whether it be in the arts, humanities or sciences. It is, I believe, only in bringing together both this range of disciplines together with mixed genders that we can hope to address some of life’s harder problems. Problems that not only require new ideas but solutions that build on the ideas of others rather than re-inventing everything from scratch in the usual brute force, testosterone charged way we typically seem to approach problem solving in IT.

Tim Brown on Design Thinking

If you don’t watch any other TED podcasts watch this one by Tim Brown. IBM sponsored TED at Oxford last year (no invite for me unfortunately) and Tim Brown (CEO of IDEO) presented on Design Thinking and had these ideas which I think apply equally to architectural thinking (is it different anyway).

  • Big problems need big solutions. Back in the 19th century Isambard Kingdom Brunel imagined an integrated transport system (he thought big). His vision was that of a passenger boarding a train in London and leaving a ship in New York. Big problems (global warming, health care, international security) need big thoughts to provide solutions. Focussing on the small may provide incremental change but will not provide solutions to some of the big, hairy problems we are faced with today. If we could focus less on the object (the individual system in IT terms) and more on design thinking (systems of systems) we might have more of an impact and be able to solve more of the really difficult problems there are out there.
  • Design thinking begins with integration thinking. Design thinking needs to balance a number of fundamental “forces”: what people want (desirability), what technology can provide (feasibility) and what can actually be built given the constraints of cost, resource and time (viability).
  • Design is (or should be) human centred. Although it needs to be both feasible and viable if it is also to be desirable then that needs to start with what people need. Here the needs we are considering are not what we want from the next version of iPod or Porsche but a safer, cleaner, healthier world. Understanding the needs of the multiple stakeholders that there are out there when building big systems is crucial of the systems are to be not only desirable but also useful.
  • Learning by making. Don’t just think what to build but also build in order to think. In todays model-driven world where we architects can often go off into a huddle for months on end we sometimes forget that the important thing is not a very fine model or specification but the thing itself. Prototyping is as important today as it’s ever been but we sometimes forget that getting our hands dirty by and building small-scale throwaway parts of systems is an important way of learning and understanding those systems. As Fred Brookes said, you might as well plan to throw one away because you will anyway.
  • From consumption to participation. Design of participatory systems where everyone is involved will lead to new and innovative solutions which may not have been envisaged initially. This is the idea that the whole is greater than the sum of the parts and in IT terms is best articulated in Web 2.0 and the whole social networking phenomenon.
  • Design is too important to be left to designers. Often the important innovations come not from the people charged with designing the system but from the people who are using  the system. Don’t forget that the most important stakeholders are the everyday users or the current system.
  • In times of change we need new alternatives and new ideas. We are living in times of great change and our existing systems are no longer fit for purpose. Design thinking needs to explore new and unthought of ideas without being constrained by current systems and ideas. Design thinkers need to be multi-talented, left and right-brain thinkers. Hint: this will also increase dramatically your chances of staying employed in the coming years. Good design thinkers know that the key to a good and better design is asking the right question or at least framing the question in a way that will not constrain the solution. So, rather than asking “how do I build a better benefits system” ask “how do I build a benefits system that will result in more of the benefits reaching the people who need them most and less in paying people to run the system”. Of course this is hard because answers to such questions can sometimes have difficult or unpalatable side-effects such as people losing their jobs. The first step of design thinking is to ask the right question.

There are lots of ideas here and many of them resonate with the practice we in IBM call Architectural Thinking. I will return to some of these ideas in future blogs.