(2012-02-15 16:18)
首先对上图做一个解释。原来架构设计比较多关注的是横向的分层，即数据层，逻辑层和UI层。而组件化架构必须同时关注纵向的隔离和解耦。在分层和分模块后，每一个业务组件由三层各自存在的部署包组成，包本身是一个包含了技术组件和服务组件的一个结合体。由数据层，逻辑层，界面层三层的三个业务包可以构成一个完整的具备独立功能的业务组件。在业务组件和业务组件之间通过内部ESB进行总线式集成，在业务组件内部的三个业务包仍然通过总线式注册和集成。在组件化架构设计中，需要遵循如下一些原则，这些原则有些属于传统分层架构设计中的原则：
UI层调用逻辑层，逻辑层调用数据层，不应该出现逆向调用。
业务组件间的调用，或说跨模块的调用需要通过服务组件暴露的服务接口进行，跨模块调用
WBS和工作包
很多时候我们简化后的项目管理都是有任务活动，没有WBS和工作包的概念。对于工作包是WBS分解的最低层，有工作包的好处工作包是独立的可验证的输出，所有任务和活动都可以归集到工作包上方便项目进行核算，工作包重点关心项目范围而不关心完成者，同时工作包是进行项目挣值分析的基础。
估算
对于IT项目管理一定会提到估算的概念，严格意义上的方法往往强调首先估算项目规模，再估算项目工作量。常用的功能点估算方法则是首先估算出功能点，再根据功能点生产率折算到工作量。估算和项目范围明细往往相辅相成，项目范围和估算才是真正制定详细项目进度计划的基础。在这点上和标准PMBOK进度管理顺序是有区别的。估算直接影响到项目计划执行准确性，但是往往又没有严格意义上精确的估算。
缓冲
提到缓冲的概念也如同前面所说的，缓冲是风险管理和风险应对的一个具体活动。包括关键链项目计划更加强调缓冲时间段的管理，关键链的确定。而很多时候我们的项目往往根本就没有缓冲，更加谈不上缓冲区的合理安排和使用。缓冲的核心仍然是进一步将项目过程和任务中的缓冲能够剥离出来留到项目最后，而不
偏差
偏差意识是很重要的一个项目意识，有目标，有项目执行现状才会产生偏差。要有目标和执行就必须有计划，有执行过程记录。有偏差就会有风险和预警，有问题跟踪和解决。所以当谈偏差的时候，其实将我们项目管理常说的目标驱动，风险意识，数据说话等东西会全部涵盖进来。而分析偏差和问题产生的原因，又涉及到多因素影响和系统思维。
迭代
迭代的目标还是为了降低项目风险，迭代认为大系统或大产品可以分为相当独立的多个版本进行交付，迭代和传统任务分解和里程碑区别在于迭代强调每个迭代周期产出的可独立交付性。而尽量去对每次交付版本和组件进行解耦。要知道传统软件生命周期强调需求，设计，开发和测试的阶段划分；而迭代更加强调的是各个模块和组件之间的解耦。
约束
项目本质是在已有资源情况下达成期望的目标，不存在资源约束的项目不是好项目。项目经理解决约束的过程是一个多因素决策和平衡的过程，这个决策本身就是一种系统化的思考。任何追求单要素和目标最优化的决策往往都不是最优决策。任何过渡追求平衡而丢失了用户核心目标和价值的决策也不是最优决策。平衡不是简单的拆东墙补西墙，
REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。REST提出设计概念和准则为：
1.网络上的所有事物都可以被抽象为资源(resource)
2.每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识
3.所有的操作都是无状态的
REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符（Universal
Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP
规范定义的。其核心操作只有GET,PUT,POST,DELETE。
由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。
对于SOAP Webservice和Restful Webservice的选择问题，首先需要理解就是SO
对于EDA事件驱动架构，CEP，发布订阅模式等前面文章已经做过相关的讨论，特别是ifttt网站的出现进一步引发我对该问题的思考。基于满足某种业务规则的事件和消息的订阅将成为后续互联网和移动互联网发展的一个重要方向。
对于传统的RSS博客订阅已经现在新出现的微博客，都属于一种订阅模式，微博进一步增加了碎片化知识的简单阅读性和大量的web2.0交互特性。而不管是上面哪种基本都是基于指定人的订阅，微群的发展可以建立主题，但是并无法保证微群发布内容和主题完全相关。而很多时候我们需要的是基于内容的订阅，而基于内容订阅必然进一步发展到基于内容和自定义业务规则的订阅。
传统互联网为订阅规则和内容的创作方，而移动终端为内容消费方。而内容本身不在于复杂，内容本身就是一种简短的有意义的消息，其真正复杂的地方应该是在业务规则的定制上面。我们可以试想一些完全可能存在的有价值的业务场景，比如：
1.当我的好朋友生日到时候，自动以我的名义发送短信生日祝福
2.当我的老家存在极端天气变化的时候，能够短信通知到我的亲人
3.当我居住的某个范围大商场有大的促销活动的时候及时通知我
4.当有关注
以下思考比较零散，想到哪里说到哪里。
产品和项目完全是两回事，如果我们基本都是项目型的产品，要想从项目化系统演化为成熟的产品是相当困难的，同理如果是定制项目型一开始要考虑太多的产品化要素也相当困难。项目型往往是磨合，熟练业务和技术，形成产品化和平台的意识，很多时候真正要做产品化的产品，还得抛弃掉原来的系统重新做。
什么叫真正的产品化？真正的产品化产品重点是模块化和可定制，一套产品要满足多个用户的需求。可定制又包括两个方面的内容，一个是用户本身可配置，一个是用户本身可以通过组件提供的接口进行二次开发。越是成功的产品往往模块化和可定制能力越强，产品本身变化为一个产品平台，而产品平台本身重点又在核心基础组件和技术组件，核心功能组件，核心底层数据架构和模型的提供。
产品化产品和快速开发平台是两回事情，很多时候我们一说到做一个产品化产品就容易理解为要做一套快速开发平台，数据建模，界面可视化表单设计，可视化工作流等全部都得做。产品化产品本身分两类，一类是本身确实就是一个快速开发平台，这类适合单纯的业务表单+工作流流转的，如现有的各个厂家推出的BPM产品，原来ration
还是先说明基于组件化开发带来的优势，首先原有到系统级的粗粒度控制细化到了到组件级别的细粒度控制，一个复杂系统的构建就是组件最终进行集成后的一个结果。每个组件都自己独立的版本，组件可以独立编译，独立打包和部署。其次产品组件化后可以真正实现完整意义上的按组件进行产品配置和销售，用户可以选择购买哪些组件，组件之间可以灵活的进行组装。另外包括我们说的配置管理，开发，测试，打包，发布完全控制到组件层面，带来额外其它很多好处，如我们常说的如果一个组件进行小版本升级，如果提供给外部的接口没有任何变动，其它组件完全可以不用做任何测试等。
组件化开发思路在SOA之前已经有成熟的组件化开发方法，只是在SOA出现后，SOA咨询，需求分析，设计实现方法论进一步融入到组件化开发中。各种底层基础技术框架的发展和完善，为组件化开发提供了根据完整的支持，推动组件化开发的发展，特别是在B/S架构下的组件化开发。回到软件生命周期，我们再来阐述下组件化开发的核心思路和逻辑。
业务建模和业务组件阶段
流程驱动IT以及SOA思想的进一步融合，再次改变原有的组件开发重点关注技术组件层面的问题。业务建模阶段重
庄子内篇《德充符》可以讲是很励志的一篇，从形全，才全到德不形，来讲如何真正的充实自我的德行。道生万物，德孕育万物，道为体，德为用，道为内，德为外。《德充符》讲如何以道的指引来修德，如何修德而不住于德，真正做到德不形。《德充符》本身又是很励志的一篇，德全和形全本身没有任何关系，德不在外表而在于真正道指引的内涵，真正得大德者往往都是形不全的人，真正得他人所尊敬的也是德不形而不是形全者。
鲁国王骀断了脚，而鲁国的人都希望得到他的教化，空手而去满载而归。孔子称之为圣人，孔子也想拜其为师，这里讲两点，一是想去而未去，一是自称不如我的人也得去。庄子很多文里面是看不起孔子的，孔子是才全和德全者，而非真正的德不形。王骀之德在于行无言之教，在于领悟生死，在于万物皆一和物我同化。而不仅仅是忘形和忘身，更重要的是忘心和忘真。
以其知得其心，以其心得其常心。知是认知作用，而心是认知作用的主体，以知得自我认知之心，而明心见性又不约束于自我之心，心化为常心而融为万物，天地万物本一体。人莫鉴于流水，而鉴于止水。唯止能止众止。
心若止水，人不应该以流水为鉴而以止水为鉴，知止而后定，定而能静，
对于IT规划，涉及到业务，流程，数据，信息技术，基础设施多方面的内容，涉及到业务驱动IT，涉及到业务架构和应用架构，涉及到从规划咨询到实施落地的全过程。IT规划之难度不在于IT本身，而在于流程，不在于技术本身，而在于业务。
IT规划所涉及到的大的方面包括了流程管理和分析，咨询方法论，信息化架构，技术架构，应用系统分析和设计，项目管理和实施。从企业战略到业务目标，从业务目标到应用蓝图，从应用蓝图到分阶段实施落地，任何一步骤的稍微脱节将导致规划内容的无法落地，再完美的规划和架构，如果脱离企业业务目标和实际，不能带来企业业务价值的提升，那么一切都只是废纸。
对于IT规划的一般逻辑，和前面谈到过的咨询的一般逻辑是类似的，其仍然是包括了现状分析，目标提出，差距分析，蓝图规划，实施规划几个关键步骤。现状分析包括了业务现状和IT现状，根据企业战略提出业务目标和发展规划，分析现状和目标之间的差距提出和整理问题集，根据差距和问题给出蓝图规划，根据目标和问题分解到的子目标和子问题多维度评估和确定优先级，确定后续的实施计划。这就是IT规划的一般逻辑。
整个IT规划始终围绕业务和IT两条主
在路上，因为有你们，一直以来虽不乏坎坷曲折，但是我们一路走来，我们一起挺了过来，我们的团队在不断的壮大和发展，前途虽然仍有太多不确定性，但是光明始终在前方。最近一年来我感触很多，任何一个人的成功相对整个团队取得的成绩都微不足道，唯有团队让我底气十足，充满信心去开拓新的疆土。
团队不可能一开始就完美无瑕，它有缺陷，有不如意之处，但是我从来不否定团队的战斗力，团队的重点就是合力而不是靠一个人单打独斗。职业化外还需要专业化，严谨认真又不是死板而无生气，形散而神不散，关键时候不掉链子，顽强不屈而不被一点点挫折打倒，这就是我们的团队。我们有缺点和不足，有太多期望改进的地方，但是这些丝毫不影响我们是一个优秀的团队，是一个有战斗力的团队。
外面有太多诱惑，公司发展也从来不可能是一帆风顺，人来人往，最后还是有你们和公司一直走到了现在，我们一起走过了比较艰苦的日子。我一直觉得中途离开的人并不是说对公司没有感情，而是我们的团队建设跟不上，我们的企业文化跟不上，里面充满太多的遗憾，但是很多时候真的需要检查和耐得住寂寞，万山孤寂而我们始终有一颗在路上的心，你渴望成功看到的就是希望，当
添加到我的博客
