开发架构：为了满足开发时的需求所做的决定，主要是软件根据分工开发、测试验证流程等需求划分的软件层次和区域以及各种接口设计，也包含使用的软件包、组件库、开发工具，以及编译构建的方法。一个好的开发架构，可以让沟通成本降低，开发速度提高。
部署架构：现代软件系统，基本上都包括了客户端和服务端程序，如何快速、高效、稳定地部署和发布这些程序，如网络机房的分布、服务器硬件的搭配、监控和维护工具软件的安装、开发测试网络和运营网络的设置。可以获得安全性的配置，良好的部署能力，能推动软件进行更频繁、更全面的测试，从而提高软件质量和开发效率。
数据架构：数据是软件项目的核心财富，关于数据的结构，数据的存放、备份、传输会直接影响到运行性能、业务功能、部署、安全等需求。在面向对象的开发模式下，数据到对象的ORM架构也是很重要的设计。一个完整的数据架构包括了数据流图、数据字典、ORM结构(如果需要的话)、数据索引和备份机制等几个方面。
相信大部分公司都有评审这个环节，评审可以包括方案评审、代码评审、项目专项议题的评审，比如对存留Bug的处理评审等。而这些评审，常常会变成一个挑毛病的会议。要解决评审给产品带来的负面影响，同时发挥这个活动的优点，韩伟指出，需要注意以下几个方面：
评审由谁发起：相对比较好的是，由负责此项目的“领导”来召集人员评审，并且一定要有负责开发的人员参加评审。参与评审的受邀请人员可能会与方案提交者就一些问题有分歧，但提交者有最终决定权。要把权力给有能力承担它的人。这样做可以让“防止风险”的一部分人和“注重效率”的开发人员形成平等的意见交换。
什么时候做评审：应该在每个迭代、每个较大的版本开工前，或者仅仅是某个认为比较重要的决定做出前，都来一次简短的评审。如果开始时只是做一个DEMO，那么需要评审的东西也比较少，而随着不断的开发，评审也能遍历所有的开发。
做评审的方法：真正对项目有帮助的，是了解项目的需求，分析面临的难点，思考方案为何这样做，提出自己的解决方案，给项目开发者以建议和启发。多说“我建议这样解决这个问题”，而不要仅仅去说“这样做可能有问题，应该添补这样的功能”。以建设性的心态和思路去做评审，而不是以找问题的思路去做，这就是两种做法的最大区别。
除此之外，韩伟还讨论了分层开发、尽快运行、非功能需求决定成败、追求代码质量、搭好测试这个安全网、自己掌控开发方向、告别救火队员、绩效评估等问题，管理层在了解这些知识之后，可以更加得心应手地管理技术人员。
