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.

I got this idea from Garr Reynolds blog entry 10 Tips on how to think like a designer. Ten is too large a number for my simple brain so instead I’ve picked the five that I think we as software architects can most learn from the world of design.

1. Embrace constraints. An architect often complains about the constraints and limitations she has to work under (especially those related to money, time and resource). The skill is to accept constraints and figure out what you can do with the resources you have. After all, a completely unbounded problem with total freedom on how to solve it is likely to end up never being solved. Remember how the NASA engineers managed to fix the Apollo 13 CO2 filter problem using just what they knew was available on the spacecraft. Now that’s embracing constraints.
2. Practice restraint. This is related to the previous one. As Reynolds says: “any fool can be complicated and add more, it takes discipline of mind and strength of will to make the hard choices about what to include and what to exclude”. As software architects we are often overwhelmed with choice when putting together a solution. There are often many different vendors software products and packages from which to choose and, of course software, by definition, is malleable and can be shaped in many different ways. The trick here then is to practice self-constraint and go for simplicity rather than complexity and cleanness of form rather than clutter and obfuscation.
3. Check your ego at the door. Ultimately all software, no matter how deeply imbedded or how far it is along the food chain, has an end user to cope with. How that user interacts with and understands the system of which your software is a part depends on how well designed it is. The software architect usually has many different people to deal with (people who use the system directly, people who must maintain the system, people who need to ensure the system is secure, the list goes on). Each of these people has a “stake” in the system (hence the name we some refer to them by as “stakeholders”) and a good architect understands the needs of these stakeholders and is empathetic towards those needs. Empathy is a difficult soft-skill to master but is very important to acquire. It is so important that Dan Pink in his book A Whole New Mind states it as one of the key differentiators that will mark out those people who are able to survive the 21st century world of work where everything is outsourced, commoditised or performed more cheaply by a computer.
4. Become a master storyteller. You may have just devised the greatest software architecture the world has ever seen but if you cannot sell that solution it’s not going to be any good to anyone and will most likely never see the light. Much software is, by its very nature, complex and describing what it does and what are its benefits can be difficult. Storytelling, that is weaving a story around your system by illustrating it verbally and using multi-media to back up what you are saying can help. Don’t rely on complex and overly-cluttered PowerPoint slides when trying to describe what the system does but instead relate it to everyday experiences your audience are likely to identify with.
5. Obsess about ideas not tools. As Reynolds says: “tools are important and necessary, but they come and go as better tools come along”. Probably no discipline is more blessed (sic) with tools than ours is. Whilst tools are clearly important to the software architect remember they are a means to an end so don’t sweat over them too much. Instead concentrate on the ideas and use pencils and paper or whiteboards and pens to capture your ideas. These also have the benefits of being readily available and don’t suffer from expired batteries.