即使没有翅膀，心。。。。。。也要飞翔！

在新年前一天预祝大家新年好，在新的一年里工作顺利，身体健康。

前一阵公司给我下达了任务，一直在忙着打造面向SAAS的企业级微信平台，彻底实现零代码配置，小小一个微信，当面向企业级而且是SAAS时，呵呵，还真的有许多需要注意的地方，非常感谢公司内最强的业务架构师我们的大姐设计出来这么优秀的一款全动态微信业务。所以写完了中篇，一直没时间来得及写下篇。

下篇的开头，大家也看到了标题：即使没有翅膀，心也要飞翔！！！

为什么提这个标题呢？企业IT项目开发之七宗罪上、中篇大家看后很多人都说：目前形势就是这样，有什么办法？也有人说：道理都懂，大环境这样，有什么办法。

对，对，说得都不错，我们无法去改变环境，我们天生不是天使，我们没有“翅膀，可这就代表我们要就此沦落吗？

NO！

我们的心一样可以飞翔！

环境落后没有关系，可悲的是心态也落后。

以下我拿一个数据来说明问题，2005-2011年世界上只有3家IT公司保持着每年利润超10亿美元，利润超10亿美元哦，哪三家？

NO1. IBM，抛弃了Laptop后反而更强了，为什么？

NO2. TCS, 塔塔，世界上最大软件外包，网友们要问了，一个外包，做这么大，对吧！为什么？

NO3. APPLE，那是勿庸置疑的！

我们不说APPLE，只说TCS 和 IBM。

IBM，大家如果注意IBM的人会发觉,IBM的WAS系列即Websphere系列经历了2次变化。

一次是WAS7开始IBM专门规划出了一个SOA产品区，里面有Websphere Process Server(ESB）, Business Process Management, IBM iLog规则引擎，TAM，WebSeal，MQ，然后把WAS归在了这个区。

第二次变化是再次把WPS（Websphere Process Server)，BPM，ilog等又划出了SOA，归成了中件间产品。

为什么IBM要对其经典的产品，去做这样做两次大的变动呢？我们放在下文中说，我们先举例子，因为太多的道理你可能一下子不能够去接受，回过头你再来看，你就会明白了。

欧债危机持续，企业客户没钱啦

随着经济危机，主要是欧债危机引起了金融保险行业的大规模的萧调，大家都知道，金融系统的IT往往都是大型的业务系统，当金融业受到了影响，IT业势必也受到了很大的影响。

那么我们国内很多IT公司都是怎么生存的呢？

国内IT公司在经济危机之前的生存之道

大部分都是做项目的，或者是卖人头的，对吧！

就是我前篇讲到的学好SSH，货卖帝王家，SSH满天飞。

根据客户的需求，业务要求，做4个月，6个月的开发项目。

有的项目短，做个2个月，搞个项目，然后按照人月数用UCP，FP什么的estimation方法一估，然后报给客户多少多少钱。

在欧债危机前，因该是2008年前，或许我们靠着公司好的名声，经营之道，管理有方，好的PM，好的客户关系，或多或少是可以不断的接到这样的单子的。

往往做这样的单子的时候，我们用最简单的“软件开发生命周期”，就是我们说的七步曲即：确定问题、需求分析、设计、开发、测试、布署上线、维护。

项目管理基本分成两种模式：瀑布式项目管理和敏捷项目管理，对吧，这个大家都知道。

关键的问题在于这个地方，即不管任何一个需求，项目大小，你都必须要走确定问题、需求分析、设计、开发、测试、上线、维护，如果在项目中或者是项目后期有超出需求的部分，我们把它定为：需求变更，一个需求变更也必须要走完这7七步。走完这七步不算完，还要把以前开发过的代码和工程再重新测试、布署、上线。

如果有了BUG，BUG的修改也是要走这七步的，对吧？

因为你的需求变化了，不代表我只完成变更后的部分就完成了任务了，因为你的变更可能会引起我已经开发好的功能上出现了BUG，这个问题想必大家都是碰到过的，这样的BUG叫Regression Bug。

在经济危机没有来时，你这样做,OK的，客户理应给钱，因为是他自己要变更需求的吗，对吧，否则的话你需求变更我也能做啊，但是没钱因此我的质量就不给你保证，客户也怕，所以愿意掏这个钱。

现在经济危机来了，企业怎么生存啊，还能这样生存吗？

《哈佛商业评论》上面有一篇文章文章说，IT已经不像以前那么关键了，因为IT的普遍应用，就像水电一样，成了一种基础设施，不再是企业核心竞争力的来源。

经济危机，就是企业没钱啦，没钱，但IT一样需要，”不再是企业核心竞争力的来源“不代表我就不要IT了，不代表技术无用论，这边的“不要了”只是代表“相关技术的普及"了。

普及就是SSH，J2EE, EJB，Webservice这种东西，你会我会大家都会了。

于是，大量的还在拿SSH做项目的公司面临着比以前多2倍，不。。。是10倍之多的竞争对手。

于是，你会我会大家会。

于是，大打价格战，你卖40万，我卖30万，成了自由叫卖市场。

于是，工程价格是下来了，GDP上升了，平均工资上升了，程序员的工资还是要付的。

于是，加班不要钱，会个SSH，工作个5，6年还拿着一个月8K，9K，1万块钱到头了，没有年终奖了，Team Building取消了。

于是。。。。。。还有很多。

最后，于是，程序员成了民工还不如了，哈哈哈哈哈。

但是，但是，说多了于是还有一个但是。always 有一个但是，导演总是不给我们一个happy ending，呵呵，像一些美国大片一样有多个结局哦！！呵呵！！

但是，还是有一部分企业在这种大环境下脱颖而出，挣足了钱

这些企业越做越好，人头数就是head count反而年年越来越多，在这样的大环境下，还能持续的挣到钱，这些公司的IT人员反而越来越脱离业务越来越走技术路线了，反而比原来那些天天“业务业务”挂口头的公司挣得更多了。

这还是要从客户的角度去出发。

前面说了，经济危机，客户没钱，项目一样要做，按照以前那样，我的一个项目，走完软件开发生命周期7步，如果有变更再按照瀑布或者是敏捷开发来走一遍需求变更，对不起，客户受不了。

反正以前的项目已经做了差不多了，新的项目客户要求的是：

业务上的功能可以随时变，当这个变更需要被提出时，如果你是开发商，你说：我们需求都可以做，给时间，然后我们翻代码，对不起啊，客户不会再让你这么做了。

如果你是开发商，你和客户说：你的需求我们都能做，然后重新估算，走变更流程的话，告诉你，你从2008年后开始就很难接到新的项目了。

可能，以前你可以一年接1000万到2000万的单，2008年后你可能一年不如一年，一年能接个500万，300万就了不得了，有的连100万的单子都接不到了，真的，于是你就要面临危机啦！！！

喂喂喂喂，知道了吗，危机感啊！！！

那有人说了，我业务上的需求功能都变化了，原来是a+b+c*(x/y)现在成了a+b*(x+c-d)了我还不变代码啊？

业务彻底变了我还不改动程序啊，改动了程序后我还不重测试，重布署啊，这都是人力啊，都要给钱的啊。

当然不是说全部100%能够做到，但至少可以说70%以上的需求可以做到不改动代码，就算改动代码了也只需要重新测试新开发的功能就可以了。

这就是SOA提倡的东西，这边不是说SOA的原则，我们说SOA可以做到什么。

SOA可以做到什么？我们粗看一下，有的人觉得很空洞，有的人觉得“很深奥，看不懂写点什么”，那就先来看一段SOA架构理念吧：

1. 模块和模块之间耦合度降到最低！

2. 业务间的规则可以由客户自由定义！

3. SOA不是一种软件，它是一种设计、实现的思想，它帮助一家企业建立起一个业务的infrastructure！

4. 它可以迅速实现客户的需求，为客户提供垂直的业务需求，可以快速的把客户的业务从需求直接变成IT实现！

当然还有很多，我先就举上面几条市面上见得最多的”行话“，怎么去理解上面4句话呢？我们用大水词来理解吧，上面这4句说的就是：

1. 我新做的东西，应该按照模块化开发思想，就是你原来的系统给新接入的模块将来的接口要预留好（有人说了，我2011年开发的东西怎么知道你2012年的模块是什么样的，怎么给你预留接口啊，对的，可以预留看，你看下去）。

2. 由于我接口已经予留好了，新的模块就像搭积木一样，就是乐高积木啊，把新的东西”插“上原有的模块就可以用啦，如果这个模块不好了，旧了，我拿掉它，再换一个模块。甚至可以做到本来一个项目，10个模块，每个模块都由一个开发商去实现，然后再找第十一个开发商来搭积木一样的去完成前10个模块的集成啊。

3. 然后就是诸如：a+b+c*(x/y)现在成了a+b*(x+c-d)这样的业务变换，我不需要去用个eclipse打开工程然后改动里面的代码，一改就是改jsp, action, service层，dao层对吧，改完后急着上线，然后BUG又是一堆，改不完的BUG，加不完的班，不要，程序员不要走这种路了。

4. 像这样的业务改变，你有一个界面，让业务人员就可以自己去通过拖拖拽拽自己去实现需求的变化了啊，这边的业务人员指的是企业里面用你开发的这套系统的最终用户，他们自己经过简单的培训就可以用你的系统自己去定义自己的业务变更啦。

如果你的系统能够满足客户这样的需求，啊呀，在现在这个大环境下，当人家公司接不到项目时，你一定能够接到项目。

那又有人说了，客户都可以自定义化了，我这个项目结束后不就没有后期维护，后期开发任务了吗，我就不能够长期的稳定的去获得一个客户这边的项目来源了吗？

你错了，客户的需求是不断的在变的，由其是业务系统，那个业务变化太大量了，就说一个CRM系统，一个CRM系统它面临的是每个月都在变的业务，为什么？促 销，打折，双11，双12，圣诞打折，这些业务都在变啊。

我的系统因为耦合底低，可以做到模块间的任意互换，然后我又有这种业务人员自定义规则的界面，所以我新做的模块可以0影响到原有的已经布署的代码，而且我新做的模块的布署是不需要原有的服务器在某天的零晨停一下，然后我重去布署一下这种做法的，取而代之的是24*7的一种模式，所以我管你客户需求怎么变，新的需求拿来，我都是只需要重新估算新的功能的工作是量，可能新的功能里面有70%的业务是可以由客户中的业务人员去自定义完成的，因此这70%我留给客户，30%这个人工费我会收，客户也觉得应该给你。

因为你做的东西不影响原有系统的功能，不影响原有的系统运行，不会有太多或者就算有regression bug也是降到最底的度，因此客户才会源源不断的每个月，给你个20%，30%，10%，然后过几年系统大升级，软硬件中间件一起换也找你，就算客户新的模块是找另一个开发商做的，但是在集成时碰到问题还是要咨询你啊。

于是，项目钱，这个大头是可以挣到了。

于是，维护费，每个月定期的，而且这种维护因为不是传统的那种翻写原来的工程，改动原有的系统，而只是搭积木一样的，你可以雇用相对便宜的年纪轻的程序员，利润也有了。

于是，你还可以收咨询费。

从原来的几个悲惨的“于是”，变成了多条腿走路，多方位收钱的于是啦，呵呵！

关键是这样的项目是怎么做的，说了这么多，这样的项目是长个什么样的呢？

记得我当年在公司里面临第一次升职选择时，公司给了我两条路：PM道路和技术道路。我选择了技术道路。于是我第二天接到了美国总部一个Chief Architect，就是主任架构师的第一轮考核电话。

老外，很牛B，你们知道他是怎么考核的吗？相当的夸张：

嘿，你，看看公司的员工内部系统，里面有考勤，在线学习资料，请假，报销，你在公司这些年一直用这个系统吧，现在请给我写一下，如果让你设计这个系统，你会怎么去设计？给你30分钟，嗯。。。。。。对，就30分钟，现在是4：10分，请你在4：40分把你写的东西通过email发给我，as much more as you can think。

我花了25分钟，最后他用了一个excellent把我给录取到了公司的架构师队伍，从而我成为了中国这边唯一一个能够进入到美国核心技术队伍的成员。

那我是怎么写的呢，当然，我也只是给大家参考。 我是这样写的：

首先，这个系统不管是考勤、请假、报销都有一个”流程“性的东西，因为每做一步，系统都会有相应的EMAIL告诉你或者是某个环节的审批人：你目前有一个什么什么样的任务，还经常会收收到系统的EMAIL要求我上传这个附件，那个附件，驳回，拒绝，通过啦等等等，因此我会采用工作流，如果客户是大型企事业客户我会推荐他们去用一些商用软件如：IBM Lombardi，或者是Oracle的Pega Rulz。如果是中小型客户我会推荐一些开源的工作流如：jbpm, aris或者是activity。

其次，该系统中存在大量的”上传单据“，”发票复印件“，”病历扫描件“，”会议文件“，”PPT“等文件上传文档的接口，因此，我不会自己去拿个common upload去做这么多的界面。

首先，如果我自己做，如果时间允许，我会去做，但是我自己做这些上传文件的界面和系统，我还面临着上传完后根据我的上级，上上级，上上上级这样的一个”按照权限“查看附件的一个权限系统问题。

那我自己做了上传系统后，除了解决按照权限查看调阅这些文件系统外我还需要面临着去做，我上传了第一次，传了不够，加点东西，传错了撤销重上传这么一个版本控制的问题。因此我会选用CMS即Content Management System。

比较适中的好的CMS系统如：Microsoft Soft Share Point Server即MOSS系统，或者是纯免费开源的OPENCMS进行二次开发来帮助我做到上述这些事情。

然后，这个系统有考勤，有报销，有请假，有在线学习资料课程管理，我肯定会按照模块一个个开发，然后模块与模块间的集成怎么办？对吧？这个系统是单点登录的，这个勿庸置疑，你登录了企业公司内的AD域就可以登录这样的一个系统，模块和模块间又要低耦合，那就是按照模块分离开发和布署原则，那只有上PORTAL了，所以Websphere Portal Server或者是liferay portal纯开源免费的这个是。如果不用portal那就是模块和模块间用web service接口，即组件合开发SCA概念。但是组件开发如果按照Webservice来对接，就意味着如果我新做一个模块，需要和原有模块的webservice间的连调问题，因此我们可以考虑采用esb统一webservice路由后所有的新做模块按照这个统一的接口，然后像搭积木一样把新的模块“搭”上去。

还有就是这个系统，同时还连接着公司的财务，进销存等其它系统，它们之间肯定会有类似自动”定单“的东西或者是数据交换存在，那就存在着异步调用，那我肯定会用JMS,但是JMS里队列我要自己去实现，你有那个能力那个精力自己去实现一个企业级的队列？

给我时间，又说给我时间。

人家企业开发集成4个月，6个月哪有这么多时间给你去自己光开发一个队列系统，你当人家企业是小白鼠啊，经济危机，没钱没时间，OK，所以我会上MQ，开源的我有activeMQ给企业选择，如果是商业级的我推荐用IBM Websphere MQ。

前面刚才说到了单点登录，这个单点登录是逃不掉的，而且你光单点登录是不够的，还要去集成企业内的权限系统，你自己去重头写一个？当然如果现在是一个新产品开发，你可以花2-3个月甚至更长时间把个权限系统做完美了，现在是企业级开发，业务系统，我肯定会去想，如何拿灵活的，组件化的模块，成熟的组件去实现我这个需求，因此我会选SSO组件和企业权限组件如：IBM TAM，或者是WebSeal或者是YALE CAS去集成这个SSO和权限，这样，利用这些组件本身强大的访问LDAP即AD的能力我可以把精力专注在如何去组成这个系统上而不是拿个SSH，天世界的天天敲代码把这些东西重头到尾做一遍。

然后是安全上的考虑，我会考虑：

1. 我要从应用层面上来说防止跨站式入侵，SQL入侵，脚本注入入侵，中间人攻击入侵等

2. 我要从系统层面上来考虑病毒的入侵，恶意的DDOS攻击等

3. 数据的传输安全层面我要考虑数据如何保护，哪些层面，哪些传输是需要加密需要保护的

4. 硬件层面的时间同步

5. 由于系统中很多层面上用到了加解密认证等东西，我肯定要考虑一个证书、口令管理系统，不可能我只把个证书放在WEB-INF目录下就完了，什么certificate.bin这样的东西就可以整个项目都拿来用了，这是不对的，不能这么干，肯定要有自己的证书和加解密管理库的。

扩展性上的考虑：哪些层面我是可以集群的，由于是组件化设计和开发，因此哪些面可能面临数据集中访问，访问量大，可以集群扩展，一上集群后你原有的开发的程序会有很多东西需要做同步，和改动,这些我是怎么考虑的。

兼容性上的考虑，有些客户有钱，有些客户没钱，有钱的上WAS, WEBLOGIC，没钱的上TOMCAT, JBOSS，那我的系统不可能做4套，对WAS一套，WEBLOGIC一套，对TOMCAT一套然后对JBOSS一套。我系统肯定只有一套，在WAS, WEBLOGIC, TOMCAT, JBOSS上都可以运行或者只需要装相当有限的扩展LIB库就可以运行起来对吧？

数据库层面，JAVA跨数据库，我肯定要最起码支持主流的ORACLE, DB2, MSSQLSERVER吧，不可能会为这几个数据库各做一个版本，我肯定是只有一个版本，然后我的SQL语句就可以在DB2时支持DB2, ORACLE时支持ORACLE, MSSQLSERVER时支持MSSQLSERVER吧？（提示：当碰到绕不过去的必须使用到某个数据库的特性来写SQL时，请参照hibernate dialect的原码即实现原理去写你的SQL）

基本写了上述这些，然后后面几天的面试与考核当然就是围绕着我第一天写的这篇文章里的技术点进行详细考核了。

大家不知道看出来没有，出现了一堆的新东西，由其是最后3项，安全性，扩展性和兼容性。

这里不是说我列一下这些名词就可以了，你必须把这些列出的名词都玩一把吧。

而且我说了”商业的我会选用哪款产品，为什么，开源的我又会选用什么产品，为什么“。

所以，要成为架构师不是说嘴上能够列出一些名词就可以了，你必须都玩过，就拿个Webservice来说，你说你会Webservice，OK，用Axis2怎么实现，JAXWS怎么实现，XFIRE怎么实现，SPRING-WS怎么实现，QOS是什么，这些你都必须学过用过才能够说得出一个所以然啊！！！不是说我光会个jaxws就说：我精通webservice了！！！

对于实现上述这样的一个系统错误的做法是什么样的呢？

自己设计一套数据库去做权限，很多公司这么做，就是基于RBAC原则，当然，我们可以这么做，前提是：你做的是核心系统，就是一家企业的系统从没有到有都是让你来做的，那么我们先会从权限系统下手，可以重新设计一套。

但是当你触及到的是业务系统时，你大多时间面临的是去集成客户的权限系统和你自己的系统，因此你要想清楚如何去拿你模块自身带有的权限系统去集成客户已有的权限系统，而不是试图去用你已有的权限系统去劝说客户走你的权限模型。

碰到审批流程化的东西时，如大量的用VISIO画出来的逻辑去写一堆的IF, ELSE，SWITCH CASE语句，HOHO，千万不要这么做。

如果有一个流程的分支改变了，先不说你自己用IF ELSE实现的艰巨与复杂，如果一旦你改变了，可能你能够通过分析以前一堆的IF ELSE代码找到你将要新加的IF ELSE的地方，也可能因为你多加了一个IF ELSE而让原先跑得通的流程全部作废，坏掉。用引擎吧。

如果有一个诸如：原来是a+b+c*(x/y)现在成了a+b*(x+c-d)，请考虑使用规则引擎，而不是去写一堆的store procedure，因为规则引擎提供了客户自定义规则流，规则描述的图形化界面从而可以让客户去自己修改规则。

逆波兰表达式不是让你用在这边来做复杂的企业规则的实现的，编译器原理学了不是让你自己去开发引擎的，除非你做的是科学计算机，企业级开发里请尽量使用规则引擎吧。

因为有了规则，你可以任意去改变客户的业务规则，因为有了规则，你可以把DAO, SERVICE打包成规则上传后规则会通过CLASS LOADER自动加载而运用到客户现有的系统中从而实现不重启机器又能达到改动规则的目的，因为有了规则引擎，改变规则的事情可以交由客户的业务人员去做，因为他们自己的业务是经常的在变的，而我们程序员要做的就是给客户提供这些A,B,C,D,,E,F,G的元素，然后让客户自己去组合。

我还看到过有用”伪规则“的开发商，这样的开发商真的要被人骂了，就是他已经有了规则这样的思想了，把规则的组织去交由客户，但是他没有用规则引擎而是做了一堆的STORE PROCEDURE，差不多有2百个之多。然后客户如果要改规则了，只要改其中的20几个STORE PROCEDURE，然后他们还会教客户如何拿个ORACLE的PLSQL/DEVELOPE客户端去让客户自己写CASE WHEN。。。天哪，把客户的业务人员也变成了IT开发人员，你够牛B，不多评价了。

请考虑PORTAL，或者是基于WEBSERVICE的SCA编程模型，而不是自己做一堆的WAR包，然后WAR包间互相用api调用的方式来依赖，本来你已经把模块分离了，这下好，模块又依赖到了一起，伪耦合。

有时在面对大量上传，文档管理模块时请考虑使用CMS系统或者理念，而不要自己去用记数据库的方式去实现版本控制，更不用提CMS所具有的权限整合能力了。

做一个工程，涉及到工作流，规则引擎，CMS，SSO，PORTAL，本来这个工程已经挺大了，你除了把要实现的业务代码实现一遍，你还要自己拿个SSH，去实现工作流，规则，CMS, SSO, PORTAL本已经有的那些底层功能，那我问你，到底是在做项目还是在做这些产品，你说我都自己实现，HOHO，你牛B，等你做出来后，客户早就飞走了，项目早结束了。

回过头来看IBM与TCS为什么成功

所以回过头来，我们说因为IBM把它的精力集中在了开发这些BPM, CMS, SSO, BUSINESS RULZ ENGINE中间件上面了，同时，许多企业也认清了目前的大环境以及现在的客户对于项目的这一系列快，变更不触及到原有，任意替换，分析模块等要求，因此这些开发商需要有相应的，成熟的，稳定的组件拿来用啊。

所以IBM专做这些组件，靠这些组件它发了财了。

IT界有句笑话吗，说：有人说山上有黄金，于是来了许多人去挖黄金，结果谁都没发财！那谁最后发了财呢？山底下那个卖铲子的老头发了财了。

那TCS呢，TCS凭借着他第一个是印度人廉价的优势，第二个它及时的把从原来的做外包，变成了”方案外包“，就是我不只，不光光只有人头给了你，而是我能够为你的项目，你的需求，从软硬件上提出一个整体的solution，就像我在回答我们的那个美国的chief architect的问题时所说的那些，数据库层我怎么样做，安全层我怎么样做，扩展性怎么样做，对于上传文档管理我是怎么去解决的，对于流程化的东西我是怎么去解决的。

他能够提出大量的这样的solution，然后它把咨询顾问人员派到你客户这边，然后开发人员在印度、在China这边的这种“offshore（离岸式）”方式来进行开发。

然后这样的一个系统一旦上线，我们说了，因为它是一个”解决方案“级别的，那围绕着这样的系统会有一堆的需求变更，后续开发，集成，甚至和第三方集成，那都是会被TCS吃下来的。

这就叫”斩首行动“，就是我吃掉了你的”大头“后面的零碎的其它的外围系统就都是我的了。我要吃时，随时可以吃，我不想吃时，分点羹给你啊，对吧！

所以国内的一些企业，由其是传统外包，巨头外包或者是一些一直做项目而现在发觉项目越来越难接的公司，你们需要转形了。

对这些企业我想引用我前公司的的一位领导，他同时也是我的技术人生第一导师的话来说：外面其实有很多项目，但是它们不来找你，而你，找不到项目适合你来做。

基本我先总结这些吧，所以，程序员们，你们看看，你们要学的东西还有哪些？

SSH不是没有用，SSH是基础，是1+1=2，是九九算数表，因为你在做接口时，在开发一些底层的东西时还是需要用到SSH的，而对于一些只有“组件”才能做的事，留给组件去做吧。

SSH不是没有用，SSH更重要了，因为它已经成了你迈向更高阶的一个踏板，没有了这个踏板，你很难上车，就算上了车你也是骑不稳的。

如果你还还处在迷茫中，那么就是说你还没有翅膀，但你也想飞翔，那么这些东西够你学一辈子的了，相信拥有一双翅膀绝对是值得你去追求的吧？

SOA是一个理念，现在的SOA又包括了云计算，社交网络，企业级MOBIE应用的混合应用，SOA+云，SOA+MOBILE, SOA+云等等等是近20年可能仅有的挣钱的机会了。

因为SOA把原有的企业级开发人员，再次变成了真正的IT开发人员，在SOA理念的指导下去开发系统，IT开发人员更需要去关注于技术和业务的infrastructure即业务组合的架构和技术框架上去，而不是去实现业务；实现业务交给了业务人员，这是一种返璞归真即重新回到了IT人员做技术，业务人员做业务的时代中去了。

我当然这边也只是发表一下自己的意见。

我自己总结了一下，由其是还处在迷茫期的程序员，有人说：到底我干了4年，5年我还能干技术吗？还要学点什么，还差点什么，那我总结出来下面这么一张图，从上往下看：

这张图我把它分为3层。

从上面第一层来看，我列举出了一些行业界的优秀组件，这些组件都是和业务无关的，但又都是用来组合和集成大型业务系统时所需要用到的。因此我觉得是有必要都去熟悉，学习，运行一下的，如果有志向，应该每一个都会用并且知道分别可以在哪种场景下运用以及它们在运用和集成到你的框架时的优缺点、注意项。

当中这一层，我觉得是一个准备走技术道路的J2EE开发人员所必须具备的，要不然你无从去了解和设计出一个跨数据库，跨平台，扩展性，安全性的J2EE系统了。

最底下一层，是为了去满足当中这一层和最上面这一层所要具备的”基本功“，这就和1+1=2一样，这个不会，你也不要去谈四则运算了。

要学的东西还有很多。

你如果要来问我：还学点什么，相信此文可以回答你的问题。

谁说技术道路走不到底？谁说30岁左右就要换PM的角色？

技术道路也可以走下去啊！

software engineer, senior software engineer, team leader, architect, senior architect, chief architect, principal architect。

嗯，principal architect，差不多到了这层我应该是vice president的待遇了，哈哈哈哈，估计那时我已经50岁了吧，可我依然走技术，嘿嘿！

而我今后的篇章在前面有了SSH，性能调优，几个主要的APP SERVER的使用和调优，以及为面试准备的基础技术重温后，也将逐渐引入一个个组件化的应用，并且会在相关的例子中来向大家展现一个灵活的业务架构是怎么去设计、实现和搭建的。