迈向系统架构师
一个产品的经典开发步骤通常需要经过系统需求调研、系统分析、系统设计、开发、测试、部署实施等一系列的步骤
而系统架构师，则在这个过程中，起到了承上（面对业务专家/系统分析员）和启下（面对软件工程师）的作用。所以说，系统架构师，在整个产品开发周期内是一个核心角色。如果说市场和销售决定一个产品是否好卖的话，系统架构师则直接决定着这个产品的开发是否成功。从某种意义上说，这也是众多程序员未来的梦想职业。
要想成为一个优秀的系统架构师，并非一朝一夕之功所能达到的，“冰冻三尺，非一日之寒”，除了要有很深的专业技能外，还需技术全面、成熟练达、洞察力强、经验丰富，具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考。如果说系统分析员、业务专家只需要对一个产品的业务负责，可以不关心一个产品软件开发语言的话，而一个优秀的职业系统架构师，不仅要对产品背景和产品背后的业务逻辑熟悉，而且要对所用的软件开发语言（例如Java/C#/C/C++/J2EE），也要非常熟悉才可以，两者缺一不可。否则就起不到承上启下的作用，当然也设计不出良好的软件架构。在美国，一个合格的系统架构师的薪水甚至比部门经理或产品经理要高很多，这也是美国为什么三四十岁甚至五十岁的程序员也很常见的原因。
事实上，软件开发中碰到的很多问题，归结起来都可能和当初的架构设计有关，所以架构师要想不成为众矢之的，决不是件容易的事情。基于此，我认为，要想成为合格的系统架构师，首先要从程序员做起，只有有了多年的一线软件开发经验，深刻体会到了程序员的艰辛与不容易，才能设计出易于扩展、易于修改、易于维护、“不难为”程序员的架构出来。一个系统架构师，首先要能做出能够“自圆其说”的原型，才能跟程序员进行有效的沟通，而不是只是设计出来一个架构，就完全交给程序员来做了，这样，后期开发出来的产品风险很大。以我现在参与开发的产品为例，这个产品只是公司核心战略产品的很小的一部分，当然，虽然小，却是核心中的核心。这个产品配了3个系统架构师（年龄都在40岁以上，有数十年的软件开发经验），6个程序员、5个测试，还有一个负责产品打包的工程师。这3个系统架构师也都参与核心代码编写。
其次，合格的系统架构师，对所要开发的产品的业务背景，也要相当的熟悉才好，否则，设计出来的产品就不是客户想要的产品，当然也就不是成功的产品。还是以我现在参与的产品为例，这个产品是SCA规范的一个实现，3个系统架构师的其中一个，就是SCA标准规范的参与者与制定者，对SOA/SCA标准，有着相当的功底，否则，做出来的产品，就只能围着大公司，在他们屁股后面天天追了，别人做什么，自己也做什么，别人标准修改了，自己也赶快跟着修改。
第三，作为系统架构师，要经常阅读一些关于产品背景资料和系统架构设计方面的最新书籍。虽然现在技术方面的书籍，出得太滥，精品极少，大部分是从网上抄袭一些资料攒出来的，但是经常阅读一些国外大师的一些精品图书，还是能给自己带来一些新的思路和设计理念的。
第四，作为系统架构师，一定要有自信，既不要保守，也不要人云亦云，千万不要迷信于大师和大侠。别人说J2EE好，自己的产品就基于J2EE开发；别人说.NET容易开发，开发成本低，就转做.NET；别人说Ruby很敏捷，自己就说自己的产品是基于ROR开发的。一定要结合公司、市场和项目的实际情况，采用合适于自己的开发语言，设计出合适于自己的架构。比如，《J2EEWithoutEJB》那本书，提出了著名的“不要造新轮子”原则。如果大家都不要造轮子，都利用别人现有的框架和产品，怎么可能有技术的进步和百花齐放、欣欣向荣的景象呢？Spring的作者还不是看到经典J2EEEJB框架的诟病，才设计出来自己的Spring轮子了吗，为什么自己有了Spring轮子，就劝别人不要另造轮子了呢？GavinKing造出来了Hibenate这个轮子，为什么又参与EJB3.0的制定呢？并又参与设计出Seam这个轮子？我个人觉得，一个系统架构师，一定要造出自己的轮子，才算是真正的系统架构师，而不是拿着一大堆开源框架进行拼凑。
第五，对于开源的架构设计，要批判性地继承。要多阅读这些框架的源代码。以J2EE和Eclipse插件开发为例（因为我专注于这两个方面的开发），从前些年流行EJB,再到Struts→J2EEwithoutEJB→Spring/Hibernate→AJAX，每一个框架的流行，都有其深刻的历史背景，有一些现有框架解决不了的难题在里面，这些框架都是为了解决一些问题而出现的。我们经常阅读这些大师的源代码，精神上是一种享受，对锤炼自己的功底，也是大有好处的。例如，在做Eclipse插件开发的时候，常常会遇到一个问题，怎么才能监听到用户保存的事件，虽然Eclipse提供了资源变化监听机制，但是直接利用其机制，是很原始的，任何资源的变化，比如，添加/删除/移动一个图形，都会引起这个事件的调用，而我只想监听用户存盘的一刹那那个事件，以前在做项目的时候，想尽各种办法也没解决好。后来，在另外一个产品的源代码中，就看到了别人很好的解决方案，自己看到那段源代码，真的是领悟到很多。有时候，Eclipse的源代码和J2EE的源代码，在架构上是可以互相借鉴和补充的。比如，Eclipse的Adapter扩展机制和事件、资源监听机制，我们一样可以拿到J2EE框架中来，作为设计自己产品的设计模式蓝图。
第六，优秀的系统架构师还要拥有优秀的沟通能力，用以进行说服、鼓励和指导等活动，并赢得项目组成员的信任。一个系统架构师设计出一个良好的框架后，如果不能跟程序员进行有效的沟通，不能对程序员进行良好的指导，则这个良好的框架就不能很好的贯彻到产品开发的每个环节中去。有的程序员可能还是按照老经验对程序中的一些关键环节进行处理，等到这个架构师发现问题时，可能已经很晚了，说服、教育、培训和处罚到那时已经没有意义了。另外，如果一个系统架构师不能赢得项目组成员信任的话，那么他设计出来的架构就不具备说服力，程序员遇到困难，就会抱怨系统架构师设计的框架有问题，不能充分调动起来程序员的责任感和主观能动性。所以说，一个优秀的系统架构师，无论在精神上，还是技能上，都是一个程序员良好的导师。
第七，系统架构师要分清自己和系统分析员、项目经理或产品经理之间的角色和关系，不能负责一切，也不能只负责技术架构。由于系统架构师在整个产品开发周期内处于承上启下的中间地位，和程序员打交道的时间比系统分析员面向程序员的时间要长，有时候甚至比项目经理和程序员之间还熟悉，使得程序员很容易认为系统架构师对所有的需求和架构都负责，容易造成系统架构师职责过重。
成为优秀系统架构师的路，是一条漫长而任重道远的路。在这条道路上，要不断说服自己，不断抵制各种诱惑，要能在深夜无人的时候，挑灯阅读别人的源代码，还要有承受住各种压力的能力，能跟项目经理一起抵制住老板的无理工期要求，还要在困难的时候，鼓励项目组成员一起渡过难关。总之一句话，要想成为系统架构师，不是很容易。“路漫漫其修远兮，吾将上下而求索”。