Twitter的盈利之惑–WEB2.0互联网公司的痛
看到如下文章《Twitter的盈利之惑》，《Twitter的商业模式猜想》。其实如何盈利是所有WEB2.0公司的痛，从目前看到的情况来说，广告是每一个互联网公司的首选，大如淘宝、Facebook、MySpace等亦是如此（除了那些提供产品增值的互联网公司）。对于全球来说，广告市场的总额是相对稳定的（增长、递减也比较平缓），互联网渠道市场的增大，只是消减了传统广告渠道市场的份额，而这几个渠道到达总会到达一个平衡点，任何一个渠道都不会消失。
与WEB2.0公司竞争的公司有：搜索引擎公司、门户类公司、垂直门户等等公司。竞争程度可谓激烈、惨痛。
对于WEB2.0公司、未来的互联网公司来说，开创新的盈利模式是当务之急，否则完全依靠广告，即使大到Google、Yahoo也会出现增长趋缓的情况。
Facebook connect 再进一步，开放会员
facebook继续沿着信息是属于的理念在前进，其关键产品Facebook Connect已经供业界使用。该产品提供了如下特性：
- 可信身份验证功能，可以参考下面这篇文章《Passport vs OpenID vs Facebook Connect》
- 真实身份
- 朋友关系
- 动态隐私授权（可以解决每次需要到主站去授权的麻烦）
- 外部网站行为可以发回Facebook，分享给朋友
再一次，Facebook领先了其它互联网平台，它把自己置身于更底层的服务层，就像银行一样，它为客户存放身份和信息，客户能够在任何与银行对接的地方使用自己的身份、信息、关系等。虽然之前，Passport，OpenID炒作了很多年，非常遗憾，这些都没有能够获得大家的认可，因为它们只把自己定位为认证服务提供者，而Facebook更进一步，把自己定位为信息保管者（一个信息平台 — 基本可信的信息）。
无论短期市场反应如何，我相信“想的有多远，就能走多远；胸怀有多宽，就能占多宽的市场”。
山寨与拿来主义
今日同事发了一个有趣的链接《这是一个全民工业学山寨的年代 - 附多图》,看完之后就想到了拿来主义、抄袭、软件业。顺着机会就再读了一遍鲁迅先生《拿来主义》一文，原本期望获得些什么，很失望，它已经不符合今天的时代特征了。看来需要有大家重做一篇拿来主义，在拿来的同时，鼓励送出。
在上学的时候，身边就同学喜欢拿来主义，抄袭一边了事，最终被老师狠批一边；有些聪明的孩子，比较会抄袭，它不是100%的拷贝，而是略加修改，甚至有所创意（也有些人画蛇添足，创意错了），不但完成了“任务”，而且获得了表扬。记得当时这些人中的一部分以自己深刻领会鲁迅之拿来主义而自豪，认为别人的东西混合了自己的东西就是创新，就是新东西 。我想鲁迅先生本意应该不是如此吧，他鼓励在思想，方法论，自然科学，哲学等领域，拿来这些知识，提高自我，再开创新东西。
看看今天我们的身边：
- 知识领域内拿来主义盛行，看起来我们发表了多少多少重要的研究结果，结果很大部分是抄袭，缺少那些开尊立派的文章，缺少那些从本质上促进了本领域知识进步的文章。
- 工业领域，拿来主义更是剩行，不过比较好的一面是，这些领域一些企业已经从拿来走到了创新阶段，算是比较成功的；大部分企业却依然义无反顾的拿来，荣耻不知。
- 软件业的拿来主义更是盛行，特别是开源的东西越来越多的时候，我们国内软件业的山寨们只多不少。大的有Linux这类操作系统，小的有各类软件框架，近期又有SNS（之前有过chinaren等校友录类的网站，为什么Facebook能够从校友录之类的初级想法变为成功的SNS，而chinaren们却失败了哪？根本原因就在于，拿来了，缺少创新）。我们已经看到了Linux的失败，SNS能否成功，能否有所创新，拭目以待。
我很怀疑上学时那些拿来主义的大师们是否就是今日我们身边拿来主义的实践者们。
有许多山寨并不可怕，有许多拿来主义者也并不可怕。最怕没有创新，只想着日日拿，次次拿，乐此不必。
2008年9月Facebook开发者会议之参会感
2008年09月13日在北京参加了Facebook开发者会议。起初以为这是一个官方的会议，后来才知道，这是由Facebook赞助，圈内人士自主组织的一次会议（组织者提供了很多点心，饮料，水，甚至定了一些批萨–还是很周到）。有点类似，前不久大辉与InfoQ合作在杭州组织的《QClub 杭州站》。
我到达会场的时候，距离开始还有30分钟，自认为是提前到达，没有想到，会场内已经坐满了2/3，初步估计已经有100人左右，且有漂亮的女人（当然人数比较少）。大家背景也个不相同，有些是Facebook插件开发者（这些人也同时是国内一些SNS网站插件的开发者），有些是其它SNS网站的人（例如:校内，51，开心，一起，MySpqce等），也有Google,百度，Sina，Sohu，IBM，SUN等公司的员工；很让我吃惊的是，看到了AOL的工作人员，在国内很少能够听到他们的声音。
整个会议分为2个阶段，第一阶段是和美国Facebook视频沟通；第二阶段是参会者分享主题，由大家投票选择前20个主题，在5个小会议室中分别进行。
可能考虑到参会者大多数中国人，因此美国那边也准备了一位华人（朱伟）为大家演讲和互动。
在这位老哥演讲和大家互动的过程中，涉及到了如下几个话题：
- 用户定制：Facebook的所有信息都容许用户定制，有用户来控制自己信息的安全和隐私。安全策略在核心业务层就起到信息过滤的作用，而不是展示层。
- News Feed：从技术角度它的核心是推和共享；从产品的角度就是让朋友了解自己的一切，例如：看过的新闻，玩过的游戏，使用过的插件等；从营销的角度就是达到病毒效果，在最短时间内传播东西到相关的人。
- 【正在开发的一个产品connect】：与外部网站合作的一个产品平台，假如淘宝使用了该产品，那么淘宝商户同时又Facebook账户，可以把自己在淘宝的商品，或购买商品的信息推送到Facebook上，再通过News Feed传播。【这种产品设计思路非常值得思考，如何把外部有价值的资源通过已有的产品平台放大】
- 【用户信息所有者】：Facebook始终认为用户信息属于用户自己，而不是网站，Facebook只是用户信息的保管者。因此，Facebook将逐步开放用户，允许外部网站从Facebook引入用户，同事获取用户信息（前提是用户授予该网站获取的权限，事实上已经有很多网站从Facebook引入了上千万的用户，获得了共同繁荣）。且不说实际上，Facebook开放用户信息的粒度，单其核心用户价值理念，已经高于所有互联网公司一筹，这或许也是其能够被业界称为继微软，Google之后，能够搭建一个产业”平台“的原因之一吧。业界下一个最有可能成为平台的公司是淘宝或者EBay（开放商品库为主，开放用户为辅）。
- 移动领域：已经为IPhone开发了一个移动版本的Facebook，同事开发了移动版本的API。
- 信息保护：Facebook开放信息的保护措施有，合同约束、用户定制、技术上采用随机算法展示信息（没有很明白这个地方），存储信息不能超过24小时。
- 【开放营收渠道】（Facebook开发者提出的一个理念）：让第三方开发者也能够从Facebook平台获取更多利益，同事标准化某些东西等等。
在第二阶段，所涉及的话题都与SNS有关，例如:移动的SNS演讲、校内开放平台大赛获奖者心得，51的开放平台的汇报，Web Game，AOL的一个关于开放平台（基于Falash技术的Wigets平台，且免费）的介绍，还有一个会议室内一圈人在聊搜索话题（语义关系的搜索，是大家都关心的一个话题）等等。
大部分演讲都比较技术化，缺少较为创新的话题，也缺少关于如何盈利的话题（估计都没有想明白）。比较有价值的地方是：
- 国内SNS网站都意识到了开放的问题，但都没有达到Facebook的思想高度。
- 移动进入SNS领域，难道它不会进入其它互联网领域吗？特别是3G时代，它同时控制着终端平台，它或许将成为3G时代国内移动互联网领域平台的拥有者（虽然在互联网领域，在应用层面上，它的影响力还是比较小）。
- 大家都在思考通过什么方式盈利，都在进行尝试。
构建架构的思考
（说明：以下内容仅仅是一种思考，而不是某家公司的具体内容，在此过程中，参考了多篇 DBA Notes上关于一些公司互联网架构的介绍，在此表示感谢！同时参考了其它一些关于架构介绍的文章。很欣赏我同事[程立]的一句话，用中国古典文化阐释架构的源和重要性 — 老子说”道生一、一生二、二生三、三生万物”。在业务愿景的技术实现过程中，假设”道”为愿景、一为方向、二为战略的话，三就应该是架构了，架构既出，万物化生可矣。”）
关于什么是架构，已经有很多文章在讨论了，本文不予以探讨。
关于架构的类型，业界的定义也各不相同，《架构的类型》对这个问题进行了探讨，可供参考。
此处所探讨的架构可能包含了企业架构、系统架构、软件架构、信息架构、SOA架构等方面的部分要素，所适用的行业，也仅限于互联网行业。在此，引出了构建良好架构的第一个基本原则：依据业务特征选择架构。例如，Amazon、EBay、FaceBook、YouTube等互联网企业的架构都非常的不同，每家公司都有自己独特的架构特征，首要因素就在于第一要素。
之所以称之为哲学原则，首先它们比较虚，就像黑洞那么虚；其次度量起来比较困难，没有一个统一的标准，也很难定义标准，例如不同机构对客户满意的定义就不一样；再次它们的确很通用，在架构的各个阶段、各个层面、各种粒度都适用。
它包含如下子元素：
- 使客户(所有直接或间接使用这个系统的人都是客户)满意 – 功能、质量、使用、体验
- 良好的投资回报率 — 复用、免费产品、成型产品
- 足够敏捷，适应业务的发展，且能够快速推出新业务 – 可发展性
- 支撑企业核心竞争力
- 简单又实用
- 强壮又稳定 （ 架构设计必须考虑到故障—业务故障的可恢复性、技术故障的可恢复性，非常状态的故障：电力不足、机房断网、自然灾害等，冗余和错误恢复也是达到稳定的必要手段）
- 术语一致性（有点像统一思想、统一口径）
- 可维护性
- 支持未来的发展
- 对运营友好 （尽可能自动化，是对运营不错的支持）
“量变是指事物单 纯数量上的增加或减少，事物保持其质的稳定性。质变是指事物根本性质的变化，在这阶段，事物处于剧烈的变化之中，其平衡静止被打破，旧的事物转化为新事 物。事物的变化总是先从量变开始的，待量变积累到一定程度后，才会发生质变，其中量变是质变的必然前提，质变是量变的必然结果，量变→质变→新的量变是事 物发展的基本规律”。这条哲学规律同样适用与系统架构，每次大的系统架构的变化，背后的动因都是”量”引起的【类似window这样的系统架构变化的动因，不在此处的探讨】。在互联网领域，如下主体的量起到很大的作用：
基本量：
- 用户 — 总量/日访问量/并发量/增长率
- 访问量（PV） — 日访问量/并发量/响应周期
- 产品 — 数量/业务领域量
被动量：
- 业务数据 — 历史总量/日变化量/并发量/增长率
- 系统日志 — 一段区间总量/日生成量
- 业务日志 — 历史总量/日变化量/并发量
- 事务量 — 日变化量/并发量/响应周期
- 外部网络 — 流量/并发量
- 内部网络 —并发量
- 网络连接 —并发量
- 图片 —总量/日访问量/并发量/增长率
- 项目【包括日常升级、日常BUG维护】 — 平均开发周期/项目组成员增长率/测试周期/发布时间
- BUG — 确定原因周期/响应周期
- 系统服务（SOA角度的服务） — 总量
- 设备 — 总量
- 内部抱怨 — 声贝的大小
- 停机维护 — 次数/时间
基本量是基础，它驱动被动量的变化，例如用户，日访问量会引起业务数据、网络连接等的变化，基本量的变化对架构的影响最大，时刻关注基本量的升降。
【注意：】不用业务领域，重点关注的主体略有差别
上面是针对互联网产品的一种架构【产品架构和业务架构是都需要针对自身的特点进行划分，不具有通用性】。
- 产品架构的目的
能够描绘当前产品的关系、分类；
能够体现公司的核心价值、核心竞争力；
能够实现公司的战略意图；
能够支撑现有产品的管理和标准化进程、以及未来产品的规划；
能够指导产品的可持续发展、创新；
为技术架构提供产品输入。
- 业务架构的目的
能够描绘当前业务的关系；
能够支撑公司的战略；
能够支撑产品在既定方向上发展；
能够支撑业务的发展和敏捷；
为技术架构提供业务输入。
- 技术架构的目的
能够描述当前的IT状况；
能够支撑对产品的发展；
能够为客户提供高质量的服务【非功能性方面的需求】。
为技术架构选择的几个子架构域：
-
信息域
此处的信息特指用户交互层面的信息、跨系统的信息、内部管理的信息。本域内关注用户信息展示、信息聚合、信息共享、信息交换、信息分析和挖掘等。
-
基础技术域
支撑IT的基础设施，该域包含硬件基础、系统基础、应用基础环境、通用技术（例如：工作流、ESB、搜索等）、程序驻留环境（类似FaceBook的开放平台）等。
-
数据域
支撑数据的存储（数据库存储、文件存储【例如：BigTable】、甚至存储在S3中）、访问（透明统一的访问）、分布（物理分布、水平切分数据、垂直切分数据）、缓存、备份、归档等。
-
部署域
支撑系统（此处单指一个独立的物理整体，例如运行在一个JVM上的所有的内容）和服务（单指SOA服务）的运行、管理、发布、分布（同城、异地）、日志等。
-
治理域
为公司业务的运营提供不同粒度的（硬件、系统粒度、产品粒度、服务粒度、客户粒度等）监控、报警、控制、隔离，以及服务的版本管理等。
-
安全域
为公司业务的安全提供硬件、软件、业务等方面的支撑。
-
测试域
为产品提供测试环境、生产环境、沙箱环境、性能环境等的支撑。
-
分析域
支撑公司运营、管理、客户分析、智能系统等（从简单的URL分析、到服务路径的分析、定向客户分析等）。
架构的三要素（产品、业务、技术）以战略为核心，战略影响三要素的发展；业务支撑战略、产品实现战略、技术实施战略。
架构的三要素之间互相支撑、互相制衡。
从低级生物到高级生物、从小企业到大企业都遵循了进化的原则，大凡违背这些原则的事物都会消失、失败。架构也是如此，从简单到复杂，逐步进化，逐步发展，每经历一个痛苦阶段，都会带来质的飞跃，都能够再次适应当前的环境，从而获得生存和发展。
1）、决定系统不做成什么样子， 与决定将它做成什么样子同样重要
不去满足所有的需要， 而是让系统具备可扩展性， 使其能够向上兼容。
2）、有进有退
在架构进化的过程中，是所有要素都同步进化吗？我们看看生物的进化过程，在不同的时期有些部件会进化，有些部件会保持不变，甚至有些部件会退化，这是自然选择的结果。架构也是如此，商业环境的变化，公司战略的变化，必然要求我们作出选择 — 可能加强、可能弱化、可能维持现状。
3）、进化的要素
对于产品架构、业务架构的变化主要依赖第一要素、战略、业务指标、营收指标等商业方面的输入。
技术架构层面，具体那些要素应该变化、变多少、如何变，依赖产品和业务架构、第二要素、第三要素的组合输入或者单个输入。例如，第二要素的强壮性，要达到这一目标，可以选择增强测试、增强基础技术架构、增强信息域、加强治理等要素来实现。具体选择哪一个域中的那些要素来开展？这就需要架构依据环境做出适当的选择。
4）、控制节奏
一个好的架构进化过程，就象一曲优美的乐章、一台完美的多幕剧，让所有受众都赏心悦目，赞叹不已。
案例：Amazon 、FaceBook、EBay等，从创立之初到今天，每一家公司的架构都发生了翻天覆地的变化。
架构的规划，指在当前情况下，为一段期间内明确路线图，确保我们的进化是有序的，可控的，清晰的；以及容量的规划（系统不是无限可伸缩的，到了一定量级，必然要提前进行质变）。
架构的预测，指在量能不断变化的过程中，提前预估架构可能存在的风险，从而提前实施调整和相关的准备工作。例如：提前研究新产品、提前研究新技术等。
备注：
A：新增表等类型的操作，不属于数据域变化的范畴【此处探讨的更多是架构一个层面的问题，例如：涉及到数据的分表，那么就属于架构范畴】。
B：用户数量变化时，对于做产品独立销售、SAAS软件等等类型的公司，其作用效果与本文所指有所不同。
C：忽略的意思是不要为其考虑专门的架构，而不是不进行对应域的相关工作。例如测试域，可以不做测试架构方面的工作，但测试却是必须的，即使只有一个人使用的软件，也要考虑测试，部署等方面的问题。
D：描述某一要素的词语”忽略”、”简单”、”仔细”、”专业”等，只表明了一种重视程度，而不是必须达到某一级别。毕竟进化时的选择，是所有外部因素集体作用的结果，而非单一因素必然促使某些要素必然发生变化。
-
鼓励异步
不仅仅是技术的业务，业务也要考虑异步
-
虚拟化组件
减少物理依赖，增强部署灵活性
-
数据切分
按照某种原则分布存储数据；读写分流
-
Cache
缓存一切值得缓存的，不得不缓存的内容
-
避免cluster方案
带来的麻烦比好处还多
-
SOA思想
它是一个宝库，在架构的每个层面，都有丰富的研究成果，可供我们汲取
-
无状态
把状态都放在存储中，避免带状态的服务
-
定制部分关键技术架构组件
通过购买商业软件、使用开源软件可以极大的降低成本，同时加速技术架构的成型，不利之处是：这些通用软件总会存在不适应症、以及不能完全满足我们的非功能性指标。通过对各大网站的架构进行分析，可以发现，对于某些关键技术架构组件的定制，是解决问题的最好方式
-
技术架构标准化、简单化
技术架构尽可能标准化，避免不断引进新技术，一切以简单为原则，切忌为了技术而复杂化架构。例如，不是每家公司都必须构建和Google一样的基础技术平台，简单的技术平台一样能够为客户提供高质量的服务；架构的变化一定要遵循量变引起质变的原则，为2年的量而改造当前系统失败的几率会很高。
程序员杂志采访摘录–Alipay使用SOA的概况
支付宝从05年开始规划、研究SOA；在06年开始实施第一个SOA项目，同年引入ESB产品，对SOA相关的思想、技术进行验证和探索；经过几个项目的实施，我们完成了第一阶段的规划和目标，实现了几大核心业务的SOA化，构建了一套支撑SOA的技术平台。
从理论到实践上，都积累了丰富的经验，下一阶段，我们将会在深入业务SOA的同时，不断完善和发展我们的SOA技术平台。
在采用SOA思想的过程中，我们从下面2个方面入手：
首先，从业务层面入手，用SOA思想梳理业务架构。化解业务敏捷的要求，同时支撑支付宝的开放战略。在此之前，我们在进行业务架构分析的时候，更多的是关注业务的合理性，可行性等，在业务发展的初期，这种做法能够满足我们快速开发系统，及时占领市场的需要。在05年中，我们预见到现有的业务架构，将不能支撑我们公司快速发展的需要，例如：我们的注册会员飞速奔向1亿。此时，我们就开始探讨和规划SOA思想。因此在06年，我们果断的引入SOA思想，用SOA的思想不断重构我们的业务架构。在这个过程中，随着数次公司战略的调整，业务架构都能够灵活应对，达到了业务敏捷化的目的 — 这也是SOA思想的核心。
业务架构的SOA化，是我们开展技术SOA的一个充要条件，没有这一步，我们将会非常艰难，甚至无从下手。
接着，技术层面的SOA，构建一个适合支付宝的SOA技术平台，来支撑业务SOA化的需要。针对支付宝的业务特点和要求，我们优先考虑实现如下SOA要素：
A：以服务为基本单元。技术平台提供与之对应的组件编程模型，业务层面的每一个服务，都能够方便的封装位技术层面额一个组件，例如：客户系统中的注册、登录等，都对应一个组件，每个组件都是独立的，在部署的时候，我们可以灵活选择和组合,可以依据SLA的要求，做出多种部署策略。
B：基于统一标准。在此，我们选择了ESB产品提供支撑，对外提供SOAP、REST、Hessian等标准的支持；对内统一采用定制的标准。
C：分布的能力。所有的服务都能够透明的分布，为外部消费者使用。
D：鼓励扩展。技术平台提供扩展的能力，例如：客户注册后的业务扩展点，业务部门要求依据客户注册来源、客户所在省、客户年龄等，进行不同的业务处理，而且这些业务点有些要求在事务中，有些要求在事务之外。如果每次新的需求出现，都在原有系统直接进行修改，那么不但可能破坏原有的业务，而且可能导致系统可维护性变差。提供扩展点功能，将把扩展逻辑和主体业务逻辑进行有效的隔离，能够彻底解决上面的问题。
E：支撑业务敏捷。支付宝的交易流具有流程类型多，流程过程繁杂的特点，业务流程每个月都会提出多种新的交易业务，同时我们的业务从单一交易业务流向整合型业务流发展。因此，我们引入了BPM相关的技术和工具，帮助我们方便，灵活的组合服务，定制流程。
网络公司架构师角色探讨
这几天和同事聊天的时候，一张图是否能够把我们头脑的“架构”表述清楚，最终都不是很理想。原因就是架构本身就是多视角的，不同的视角，看到的图是不一样的。后来发觉以我等的能力至少需要3张图[产品视图、业务试图、技术视图]才可以表述清楚：战略与产品、业务、技术，产品与业务、技术，业务与技术。【还有一个层面的视图也很重要：数据视图】
架构师角色可以切分为数据架构师、技术架构师、业务架构师、产品架构师。
- 数据架构师
- 技术架构师
- 业务架构师
- 产品架构师
- 首席架构师
负责数据相关的架构，例如：数据库，文件数据，分布式数据架构，数据切分，数据规划，统一数据视图，数据分析，数据备份等方面的内容。
（和技术架构师一道，构件类似google的文件存储、Ebay的统一数据访问层等，对于系统伸缩性、性能、迈入云计算等价值巨大）
制定数据相关的规范、标准流程。
审核系统、项目中数据相关的内容。
关注整体系统架构，通过技术架构对业务架构提供支撑；研究基础技术，通用技术；解决系统稳定性、可靠性、性能、一致性、安全性、可用性等；关注生产率。
制定软件设计、开发、测试等方面的标准、规范、指南等。
参与核心系统设计、开发、测试等。
各类规范的审核，review。
评估系统规模，风险等。
【说明：】系统分析员不是技术架构师，但技术架构师能够胜任系统分析员的职责。
关注业务架构，对公司战略，客户需求，内部需求进行抽象，组织，规划。例如：taobao的B2C、C2C业务，会员业务，评价体系，淘宝交易等业务本质的抽象是什么的研究，业务之间的关系的组织，业务发展的规划等。技术架构师可以通过业务架构来选择技术架构，研究未来支撑业务发展的技术。
关注业务的敏捷性，能够随着战略的变化而变化。
（业务架构师抽象的业务模型，如果能够保证自身数据的一致性，异步性，那么对技术架构师将产生巨大的帮助）
制定业务相关的规范。
关注产品架构，利用核心业务包装为不同的产品或产品平台，把公司的核心业务展现给用户，把公司的战略目标具体化。例如：google的WEB搜索产品、手机搜索产品、桌面搜索产品等，同一个搜索业务，包装为不同的产品。产品架构师对产品的规划为业务架构师和同时为技术架构师提供参考。
（产品和业务最终体现了公司的战略，业务是本质，产品是外延，2者缺一不可；产品和业务的规划，发展节奏也代表了公司战略的节奏；产品和业务的发展性也代表了公司战略的持续性）
制定产品相关的规范。
制定公司的长期技术路线图。
是公司技术方向和技术组合的重要决策者。
【其它架构师角色】
对于大型网络公司来说，系统管理员的角色的职责并未完全被技术架构师代替。
测试架构师，（看看一个招聘要求：开发和设计测试框架； 纵横全局的考虑产品的功能及非功能需求，设计高精的测试系统；负责研发特定的测试技术；提高整体测试效率；领导公司测试技术的发展和测试策略的方向；前瞻性的考虑未来的版本的测试策略和技术；计划 / 设计测试平台，关注着产品的测试过程；具备测试技术、测试方法学上雄厚的知识。）
【参考】
《谁来当首席架构师？》的相关内容
架构师
10条你不需要软件架构师的理由
软件架构师_21ks.net专题辅导资料
系统分析员、系统架构师、项目经理的区别
什么样的产品人才是人才
良好的编程习惯是成长的助推剂
近来看到、听到一些很小的问题，却导致了系统故障（甚至更严重的问题）。
- 案例1：等号（==）导致的损失
- 案例2：少传递一个参数导致的损失
- 案例3：默认返回结果的乐观，导致的损失
- 案例4：偶然停止的一个系统，导致系统停机
- 案例5：2个参数没有设置，导致外部系统故障的内部传递
- 案例6：大小写，导致某类业务失败
- 等等
事后看这些问题，发现都很简单，都是由于程序员的粗心导致的。或有有人会说，我们应当允许犯错误，我也是非常认可的，但对于一个企业来说却是非常可怕的，上百个程序员，每人都犯一次这类错误，恐怕企业会有些受不了。
如何规避这些问题哪？
- 制度保证
- 测试保证
- 程序员良好的编程习惯
通过下面几个例子，简单说明良好编程习惯对成长的助推作用。
首先，通过观察，发现上面所列的问题，都是一些编程习惯导致不是很好的人身上发生的。
其次，通过和一些同事交流，虽然他们自己没有遇到过这类问题，但良好的编程习惯帮助他们避免了这类问题以及克服了其它困难。
再次，同样一起进入公司的新毕业的学生，工作时间、加班时间也一样多，1年后，发展却非常不同。通过观察，我发现：排处天然因素，后天因素中很重要的一点就是良好的编程习惯帮助他们获得了成长。
良好的编成习惯包含很多方面，综合我身边这类人的特质，总结了下面几点：
- 坚决按照业界认可（或公司认可）的编程风格编写代码
- 开发、调试、测试过程中遇到的问题，不是简单的解决问题，而是进行深入的思考，挖掘现象背后的基础层面的东西
- 对于别人、外界出现的一些BUG，不是简单的听听即可，而是进行试验，思考
- 对于别人无法解决的BUG，总是尝试各类方法，不解决问题，决不罢休
- 不断总结-〉实践-〉再总结
SOA是可持续的战略，不是一次项目
常常听到如下关于SOA的说法：
- 我们完成了SOA化改造。
- 我们的SOA化，已近实现了80%。
- 这次项目是为了实现SOA化，因此要请有这方面经验的公司来实施。
- 从技术角度层面来说，我们达到了SOA化的目标。
- 这是我们最后一个SOA个项目
- 等等
如果这些话出自程序员，项目经理等人员，也是无所谓的；如果出自IT管理层的人员，哪就是一种可怕的想法了。因为他把SOA仅仅看作是一次项目了，而没有把它作为战略。这样的后果也是可以预见的，最终本次投资将会失败。
因此，建议那些准备实施SOA的公司，首先回答这个问题：SOA是贵公司的一个战略吗？
为什么要回答这个问题？
- 从SOA概念来看
- 从SOA目标来看
- 从IT管理角度来看
- 从系统分析角度来看
- 从技术特征来看
关于什么是SOA，我有几篇文章，可以参考（《这些都不是SOA》,《ESB产品升级准备：SOA、ESB、JBI、SCA、OSGI概念再学习、再理解》,《SOA，想说爱你不容易》）。丛概念上可以看出，SOA不少技术问题，它是一种思想，一种架构，因而不可能通过一个项目就把这种思想或架构完全实现；思想也是会发展得，今天的思想在明天或许就会不适应。
SOA的目标是解决业务敏捷性问题。如今，大环境复杂多变，任何一个公司都不敢说自己的业务就是这几个、自己的业务会一直不会变，很多企业，在很短的周期内，就会推出各类产品（特别是服务类企业，例如：银行、互联网企业等）。只有那些能够快速适应变化，主动寻求变化的企业才能够生存下来，发展起来，例如：会跳舞的大象IBM，IT行业最大的特色就是变化快、发展快，如果IBM的业务不能敏捷的适应这种变化，它还能跳舞吗？正因为IBM深刻理解了SOA的目标，因而它把SOA看作一种战略–可持续的战略。
对于IT主管，一定要确保本公司的IT战略是可持续的，不能今天一种想法，明天又看到什么好思想，就换了一种想法，或者换个主管，就彻底换了战略（这种做法，就像我们国内的城市建设，路总是修不好）。既然从一种思路切合到了SOA领域，那么再次切换的成本将会更高，也不可能多种思路同时进行（吃得多，嚼不烂）。此外，谁能保证一次项目就确保几年内业务变化的需要？从我们实施的经验来看，必须持续的进行SOA化，才能确保SOA持续的发挥效果。
每次项目都要进行系统分析，都是基于当前的业务进行，那么不可避免的就会有一些盲点（从认知的角度看，人不可能一次就抓住事物的本质，何况大多数系统分析员不具有这种能力）和不合理支出。这些问题，只有在实施后一段时间才能发现（我们自己的实践经验）；此外随着补丁的实施，原有的系统已经恶化，和最初的SOA化目标越来越远。此时，如果不能再次用SOA的思想重新审视系统，就将彻底失去了SOA带来的好处。
SOA非但不能让系统架构变得简单，反而变得复杂了（系统设计要求变高了、系统部署复杂了、发布复杂了、各类SOA相关技术的引入增加了对人员的要求），这也是为什么要引入SOA治理。从这一点来看，只有持续的SOA化，才能最终发挥SOA技术架构的好处。
再次提醒将要进行SOA化的朋友和已经进行了SOA化的朋友，把SOA当作贵公司的可持续的战略来看，而不要认为它紧紧是一次项目。
