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.