跟很多人一样，我的职业生涯从软件开发开始，从前辈那里得到指导，和团队一起工作，交付软件系统。久而久之，我也开始设计软件系统中的一小部分，最后我的职务变成了这样：承担我现在认为是设计软件架构的任务。
我的职业生涯多数是为IT咨询机构工作，这意味着我参与过的大多数项目要么是为 客户构架软件系统，要么是和客户一起 完成构建。IT咨询机构要发展壮大，就需要更多的人和团队。要组建更多团队，又需要更多的软件架构师。这就是我写这本书的理由。
1.软件架构应该容易理解 。第一次设计软件架构时，尽管有一些优秀的导师，但我还是搞不清自己该干些什么。的确，有很多软件架构方面的书籍，但它们的写作视角不一样。我发现其中大多数都偏研究方向，甚至完全是学术派，而我是一个寻求现实建议的软件开发者。我想写一本对我职业生涯的那个阶段有用的书，即面向软件开发者的软件架构书。
2.所有软件项目都需要架构 。我真心喜欢敏捷方法，但其中很多方法缺乏对软件架构的明确重视，这让我如坐针毡。敏捷方法不是说不应该做任何预先设计，但它们通常也不明确探讨这一点。我发现这会让人们得出错误的结论，我也看到了缺乏预先思考可能造成的后果。我非常清楚大型预先设计也不能解决问题。我感觉适当地做一些 预先思考能提供一种愉快的中间状态，而这特别适合与不同经验和背景的团队一起工作的情形。我更喜欢轻量的软件架构方法，这样我就可以尽早让一些 结构单元到位，从而提高成功率。
3.传播轻量级软件架构实践 。这些年我学习和实践了很多对设计软件架构很有帮助的做法。这些实践涉及软件设计流程，并通过发现技术风险来沟通和记录软件架构。我总是认为这些实践都合理，但情况并非如此。过去几年，我向上千人教授这些实践，并见证了他们的变化。写书可以帮助我把这些想法传递给更多人，希望其他人也能从中受益。