很多人谈架构师，其实有两种架构师，一种是业务架构，一种是技术架构。我的经验和教训局限于技术架构，所以本文特指技术架构师。

毕业前一年，毕业后7年，大约8年的技术领域经验和教训，参加过大小项目若干，有被人传颂的成功经验，也有惨痛的失败教训。在以前一直作为技术尖子，在不同的领域逐步填充各方面的知识，最近一年开始做架构设计。以下是我的一些看法。

技术架构师要有责任心

比如说，过去经历过的一个大项目（数百开发人员，基础引擎数十人），这个大项目有一个基础模块，早期设计不良，有比较严重的性能问题，结构混乱，职责不清，很多人早期就发现了这个问题，众所周知。但是一直没改，说法是，改动的成本太大了，其他的部分要跟着改。但是,越晚改定,付出的成本就会越多。这个基础组件的在随后导致了多个严重问题，包括性能问题（占用内存多），开发效率问题（结构混乱，使用麻烦），等等。多年后，还问起这个组件时候，相关的同事都说，某某组件太烂了，没办法改啦。经常会想起这件事，想这究竟为什么会这样，怎么解决他。责任心是其中最重要的问题，当时的技术架构师没有负责任把这件事情解决了，让他拖下去。

谈到技术架构师的素质，当然要技术功底深厚，但这是基本素质，不是关键素质。我认为技术架构师的关键素质是责任心。作为架构师，你来设计这个架构，它是你的心血，你要“爱”它，为它的长久发展打好基础，甚至牺牲一些短期利益。

我们都是在成长的，经常遇到机会，做超出自己能力范围的事情，架构师在设计第一个架构时，甚至第N个架构师时，都有可能是超出自己能力了，然后在实际的工作中，把能力逐步提高。早期的设计可能是不够好的设计，同时已经应用在实现中了，但是你的能力随后提升了，认识到其中的问题了，你需要改正它，改正是需要成本的，作为架构师，要有责任心，敢于承担责任，对过错负责，把他改过来。

很多项目的顽症都是没有人敢于承担责任留下来的！而作为架构师，就一定要负责任，为万世开太平！

技术架构师要有坚持

有一次，我做了技术架构方面的一个方案，要执行它，大家（包括一些经理）都持反对态度，但是我最终一意孤行，坚决推行，最终取得非常好的效果，成为这个技术架构中最关键的技术之一。

作为技术架构师，可能你在团队中技术把握能力最好，比其他人思考的更多。如果你相信你的技术决定一定正确，那你就坚决推行它，不顾政治，不顾诸神！

遇到不擅长的问题怎么办？

作为架构师，面临的问题多方面，总会又遇到不擅长的领域，这时候，找其他同事，征求他们的决定，一起制定方案，或者干脆完全把决定权交给擅长这方面的同事。一定不要不懂装懂，外行管内行。

做错了，怎么办？

总会有做错的事情，怎么办呢？不要太顾面子，少找借口，接受批评，迅速改进。挨打要立正！别人也不会因为你一个错误而否定你全部的。根据经验，做错了事情然后改进的人，通常更受重用。原因是，错误发生了，领导们知道这个问题的难度，你解决了，就说明你解决了一个有难度的问题。

要深入了解实际情况

Ivar Jacobson最近讲到技术架构师，说执行代码比宏观架构更重要。古今中外，有一个共同的道理，就是细节决定成败。也有说法是“魔鬼总是在细节中”。架构的一些问题总是反映在实现细节中，或者使用细节中。作为技术架构师，你最好能够经常阅读使用架构的开发人员的实际使用情况，打开工程，阅读代码，然后把程序跑起来，观察执行情况。在最近作的一个技术架构中，其中多项重要的技术方案，都是观察了开发人员的代码之后总结然后做的改进方案。

技术架构师要面临的技术细节很多，例如分层细节，数据库命名规范，代码规范，spring配置文件管理，ibatis配置文件管理，日志输出规范，findbugs定期检查，作Eclipse插件把一些技术方案固化下来，经常维护wiki知识库，作code review，整理项目依赖，日构建制品输出管理，等等。每个具体项目的细节都不一样，细节处理不好，就会产生“魔鬼”。