第一，技术与业务的耦合，在使用开源产品的发展型公司中，这是普遍存在的一个现象，技术中包含业务，业务中包含技术。出现的结果是：技术只为使用它的业务服务，难以持续发展；技术的重视变为一种口头禅，想单独发展也困难；技术管理变得虚弱，甚至不存在；不断refactor，技术架构与业务架构联动；开发人员的能力要求等同化，不利于培养和发展；遗留问题边缘化、遗弃化。【看参考《闲话通用技术之二 ：苦中作乐》与系列文章】

第二，产品与产品的横向耦合，产品之间的耦合表现为模块接口耦合、数据耦合、业务模型耦合（解决它是具有巨大挑战的。出现的结果是：被耦合度产品，关联度越高，越难以维护，越难以发展；数据上的一丝变化，就导致业务故障；任何被耦合度模型，即使一个小的变化，就需要重新设计其它模型；为了应对多样性的存在，产品提供的相似接口有一打。

解决以上两种耦合度方法是：技术产品化、架构平台化、耦合协议化与规约化、产品体系化。

• EBay商品页面
• 淘宝商品页面
• 百度有啊商品页面
• Amazon书籍商品页面
• Amazon其它商品页面
• 拍怕商品页面

看完这些页面，会发现EBay、淘宝、有啊、拍拍长得挺像，这也难怪，大家都是一个商业模式。在此处我重点不是要说这些，重点是通过看每个详细页面来看看各个公司后面的技术实力。

EBay详细页面包括：商品描述、卖家描述、商家推荐、物流介绍、退货政策、支付方式。淘宝详细页面包括：EBay的基本内容、商品评价、销售记录、关联商品推荐。有啊详细页面包括：EBay的基本内容、商品评价、销售记录。拍拍详细页面包括：EBay的基本内容、销售记录。

Amazon详细页面包括：商品描述、关联商品推荐（按客户）、相关商品类目中销售最好的商品推荐、相似商品的分类标签、广告推荐（Customers Viewing This Page May Be Interested in These Sponsored Links）、商品评价、Customer Discussions、Feedback、Where’s My Stuff、Your Recent History 和 Continue shopping: Customers Who Bought Items in Your Recent History Also Bought；对于图书，又有打包促销（Best Value）、客户对该书打的Tags（Tags Customers Associate with This Product）、促销活动等。

从页面反应的内容看：EBay不是很出色；Taobao在学习的同时又增加了评价（引入信用概念），关联商品推荐；有啊完全学习了老的淘宝，反而把他的强项关联搜索没有加入；拍拍也学习了老的淘宝。单独从功能来看（抛开数据量的原因，其实这几家公司都有大数据处理的丰富经验），这几家公司的技术实力差距不是很大。但这几家公司与Amazon相比较，就会发现缺少了很多东西（功能），而缺少的这些东西恰恰是一般技术所不能解决的（对分析、智能的要求更高，Amazon在加强Web2.0的同时，已经悄悄迈向Web3.0），由此可见Amazon实力的深厚。这几家公司，需要加强再加强软实力的建设，在同一业务领域内竞争的同时，看看旁的领域内的领先者。

其实Amazon的这些能力也不是一天之内加入的，而是逐步的增加进来的，直到今天所看到的这些内容。如同武侠中练习内功一般，一年一个脚印。如果把技术比喻为内功，商业比喻为外功，那么最终的胜利者一定是内功高且外功也不差的公司，妄图以外功获取全胜，可能性还是比较小。比较有趣的是Amazon引入的WEB2.0的2个概念：discussion，加强用户交流和体验的功能，把社区与商品结合；引入Tag，加强商品信息是信息的本质特征，同时加强用户参与度。这2门外家功夫还是值得我们学习，也提示我们Web2.0在商务领域同样有市场，一旦这个市场拓展开了，一定也会百花齐放，期待ing …..

这里面透露出来的一个关键问题是“用户点评信息”的所有权问题，只有确定了所有权，才能确定最终谁有权利来确定信息是否允许共享的问题。如果信息归网站所有，那么用户相当于免费替网站生产信息了；如果信息归用户所有，那么网站将不能随意决定信息的外部使用策略，那么会有一大批的网站需要调整自己的产品了；如果信息不隶属于任何一方？就更惊奇了，希望不是这个结局。

我们再来看看业界其它几个事件与该事件的关系：淘宝屏蔽搜索，这儿的关键就是商家信息是属于谁的问题，当业界在争论对错的时候，其实忽略了这一实质问题；因而对于淘宝来说，本案例的判决将会影响到它的信息开放策略。再看FaceBook开放其平台上的客户身份、客户信息，但控制权在用户自己，用户有权决定信息的外部使用策略，它默认信息属于用户。

胡思乱想一下：这个案例的判决，是否会影响到未来互联网技术和信息的走势？这个案例的判决，也会影响虚拟资产的判决（信息也是一种虚拟资产）？

友人平时不喜读书，然善于实践，今日与我聊天，大有一发不可收拾之态，他心中有很多东西希望说出来，与人分享，同时获得一些建议。由此可见他平时缺少沟通，因而他也就缺少了一个获取经验的途径。我身边有时候，也多有此类情况，人们往往因各种原因，而少交流，甚至不交流，从而缺失了一道快速获取经验的渠道。此处的交流不是闲扯、说些无用的官话、废话，而是有意义、有思想的一些东西的碰撞和互通。

当我们频繁使用交流、实践、阅读之道的时候，会快速积累大量的经验。然如何把经验变为一种学识（识：一种判断、辨别的能力）、把经验与意识融为一体？唯有领悟。佛家常讲的“悟性”大体如斯。领悟是种非常自我的东西，很少能够通过其它3种途径获得，只有依靠自己坚强的毅力不断自我冥思和自省，发挥潜意识，逐步构建。曾子曰“吾日三省吾身”，这个过程也是”悟“的过程，今日我们是否也能够做到与曾子一样哪？。

目前已知的除了人类会通过记录传递知识外，生物界普遍是通过实践、交流、领悟来获取经验，再仔细观察，那些能够杰出的动物，除了身体原因外，还非常聪明（聪明指：除了大脑反应快之外，应该还非常有经验，非常有学识）。再考察其成长过程，基础条件都差不多，为啥结果差别那么大哪？”悟“是关键，正是这个主观的作用，形成了个体的巨大差异。

看完贴子，我想起了“亮剑”中的一个人事调动，李云龙从被服长到独立团，最后成功“带”出了独立团；关明生在阿里的作用，与老李有点像，他“带”出了一个公司。关帮阿里建立的这种文化，与李云龙毕业论文“亮剑精神”的作用有点像。一个团队没有这种文化作为支撑，怎能可持续的获取胜利。在IT界，看看微软和Yahoo，就是一个明证。

在议论中，最具有争议的话题是“今天的最好表现是明天的最低要求”，关于这句话的理解，我认为“思践”说的很对，摘录如下：

1、高执行力的保障

阿里的各部门中，按说最不具备创造力最枯燥乏味单调的工作就是商机编辑，也就是用户提交的公司和产品资料的审核人员。但是这个部门创造了不少奇迹，从一个人一天能够审核200条信息（不光是审核，大量不规范的提交内容都需要逐一确认并且修改，而非打回让用户自己修改）。最早这个部门一个人一天能够审核200条，但是最后，这个部门创造了一个人一天能够审核编辑2000条的结果。怎么做到的，其中经历了两个过程。第一个过程——把人变成机器人；第二个过程，把人变成智能机器人。第一个过程是有天花板的，但是厉害的是第二个过程，一个编辑要完成机器人到智能机器人的转变，最终他变成了客服+PD+UED+BD+社区运营。在这个部门出现了最大量的产品创新和改进。

2、逼得你创新

除了保证执行力，更重要的是这样的文化下，逼得每个人必须重新，因为按照老路，根本不可能做到“昨天的最好表现是今天的最低要求”，因为KPI的指标也是按照这个原则制定的，只能升，不能降。即使是在销售上，也有大量的创新。所以真正能够长期稳定在阿里工作的人，往往具备了创新的意识和能力（当然也有很多创新也会因为急功近利而留下隐患）。

]]> http://www.esbzone.net/2008/11/07/lo/feed/ http://www.esbzone.net/2008/11/07/firs/ http://www.esbzone.net/2008/11/07/firs/#comments Thu, 06 Nov 2008 16:10:49 +0000 邓芝 http://www.esbzone.net/?p=53 首次总是会给人流下深刻的记忆。

听一朋友曰：来了一高手，1周才把环境搭建起来，2周才把系统跑起来，3周才摸到了点门路。初次听来，似乎很夸张，不可能吧？我就体验过这种“首次”【至于其中的基本状况，可参考《闲话通用技术之二 ：苦中作乐》一文中的第三阶段】。对于一些新进入编程领域的人来说，这种情况给他带来的挫折是非常巨大的，即使有2-3年经验的人，也很受打击呀，从而出现了某些人很长时间才能融入环境，才能安心开始“正式”的编程事业。

对于一个新进入环境的程序员来说，他要面对技术、业务、管理过程等多方面的再学习，所有的都面临“首次”考验。我一直以来有个梦想：“通用技术能否帮助这些程序员降低首次的恶梦，而不再是梦魇的制造者“ — 这也是一位“高手”义不容辞的责任。

韩非子“塞翁失马”的道理总是很快就体验到我们的身边，快乐到一个点，痛苦随着而来；艰苦的熬过痛苦，终于又看到了快乐；然后周而复始；直到那个终点出现（这个终点也是EJB与Spring等的汇合之点。）？看看下面的故事线索：

1. 在网站系统创建的1-2年，是快乐的时候，Spring、WebWork等开源框架，很快就搭建了自己的系统，而且运转的那么好。
2. 第三年，日用户量达到了百万，服务器也增加到了几十台，业务系统也达到10几个，终于进入了分布式领域，引入了SOA、远程服务、分布式事务、消息等技术。痛苦的开始。
3. 第四年，服务器增加到了几百台，开发人员100-200人，解决发布冲突的问题、并行开发的问题等，引入了SCA、OSGI之类的思想和技术；数据量太大了，需要分布存储，引入了分库、统一数据访问、搜索等技术。痛苦在继续。
4. 第五年，所有的指标都增加了翻了一倍，似乎一起都混乱了，需要治理，引入了服务治理、服务器监控、更强大的过程管理工具、更多的技术出现了。有人开始乐乐，有人更加痛苦了。
5. 第六年………………..

日复一日，重复着这些过程，程序员就是这么可悲。开源并不能解决这个过程中遇到的困境，开源也不是上帝之手;一些开源技术把我们带入了快乐，也给我们埋下了痛苦的隐患。

在这个过程中，我们定义了一系列的规范、标准，就像制定EJB的规范一样来制定企业自己的技术规范；开发了一系列的技术，依然不能解决我们的难题。对玩技术的也许有些讽刺，我们在不断的给业务搞技术架构，却很少给自己的技术搞个架构，把我们的技术平台化，产品化，看看那些成功的互联网、软件公司，无一不会通过这种方式来化解上面的困境。看到技术，永远是点，点多了必然会乱；只有把点组织为有机体（产品），才会健康。“众里寻他千百度。蓦然回首，那人却在，灯火阑珊处”，这诗句写的就是好。

【备注：】朋友写的一篇文章：大型网站架构演变和知识体系，进一步证实了这种情况，即使在第九个阶段，也不是最终阶段呀。

在此处我不想对此进行太多探讨，毕竟EJB还在不断进化，使用者也还是有很多；Spring等轻量级框架也在进化，使用者也很多；非Java领域也有很多 东西在不断创新的东西被大量使用。世界本来就是多样性的，关键是个体的选择。在软件领域，架构师对技术平台的选择，可以参考《构建架构的思考》一文的观点 （由三大类要素决定选择架构）。

来看看EJB，Spring的进化：

EJB1.0 –》EJB2.0 –》EJB3.0

Srping –》Spring Application 1.0 –》？？

从大趋势看：EJB标准由复杂走向简单，Spring从框架走向产品。抛开复杂度、个人兴趣等等，只看问题域它们都是一致的：

• 产品化
• 可管理
• 可监控
• 组件化
• 模块化
• 容器
• 事务
• 分布
• 开发者支持（工具等）
• 组装（Ioc特性）

那么它们的终点是否会汇合？

每个网站都会推出许多服务，但能够创新的服务却非常少。在这些服务中，只有很少的杀手级服务，目前已经看到，且被众多成功者都使用的杀手级服务中的三个是：搜索、聚集、交谈。例如如下几个公司：

对比下面2张图，会发现对于facebook来说，open、application也是非常重要的服务。而且事实上，Facebook的开放理念，已经深刻的影响了SNS领域，其它领域也在快速向这2个方向发展。至于聚合、交流这2个较为创新的杀手级服务，虽然目前趋势不是很好看，但相信很快，就会成为表现出来。

FaceBook的趋势关键字：（facebook open， facebook application，facebook search,facebook Conversation,facebook Aggregation）

Twitter的趋势关键字：（Twitter open， Twitter application，Twitter search,Twitter Conversation,Twitter Aggregation）

对于创新的WEB公司来说，寻找一个新的杀手级服务（或出色整合杀手级服务），定能助推其发展。