开发者对平台-产品平台-产品线架构的探讨
平台是当前互联网的热点，大家都在想着建平台，特别是开放平台，这个Facebook，逼得大家都往这个概念上飞奔。对于我们技术人员来说，就得考虑怎么建这玩意。
探讨1：建平台，那么啥是平台？以前看到一篇文章《用平台的思想观察互联网》写的非常好。平台是一个供多方参与者获取价值诉求的环境。从这个定义中，可以分析到平台的几大要素：参与者，价值链，环境。
- 参与者：只有一个参与者，肯定没戏，原始社会不就这样吗？因而参与者必须是多个，所扮演的角色各相同，但基本上有这几类，利益输入者（换取另外一种价值），利益获得者（提供价值，换取利益），环境搭建者（维护、运营环境），游戏规则制定者（如何均衡的分配利益，满足利益获得者；如何客观的评估价值，满足利益输入者）。
- 价值链：“天下熙熙皆为利来，天下攘攘皆为利往。夫千乘之王，万家之侯，百室之君，尚犹患贫，而况匹夫“。这是平台存在的根本，也是商业性所要求的，是驱动参与者进入平台的“原力”，共产主义形式的平台目前还没看到。需要几条价值链？一般以某一核心价值链为中心，想多条也可以。
- 环境：参与者玩游戏、交换价值的地方。也是技术人员最关心的东西。
探讨2：产品平台与平台是啥关系？产品平台是平台的环境部分。在互联网领域，它首先提供容纳的能力，标识参与者的能力，支持利益获得者运行服务，支持利益输入者体验服务，支持游戏规则制定者有一只强力的手来调控价值链。对于技术人员来说，要搭建平台不是简单的一个技术平台，先得请我们的业务人员把平台的第一，第二要素搞清楚，否则失败的概念会挺高。
探讨3：开放平台与产品平台是啥关系？对于不同的平台，其开放的意义是不同的，但有一点是相同的：容许价值链的某一个点（或多个点）让第三方群体参与。例如，移动通过审批机制，允许SP参与到短信平台；Amazon开放商品供应点，允许第三方参与；淘宝开放平台的API，允许第三方提供网店的功能扩展。开放API只是开放的一种表现形式，而不是开放的本质，Amazon和移动就是很好的例证，开放的本质是价值链的开放，特别是利益获得者价值的开放，无利，开放了也没有价值。
探讨4：产品线与产品平台是啥关系？产品平台是平台的环境部分，与公司的价值链相对应；产品线是业务的实体部分，与公司的业务域相对应。一个或多个产品线可以运行在产品平台上；产品平台也可能是一个产品线。
探讨5：产品线是啥？围绕某一核心价值展开的系列产品，产品线中的产品承担的角色依据策略而各不相同，有的是核心价值的附加，有的是核心价值的放大器等等。比较典型的有:Google搜索产品线，支付宝的支付产品线。
探讨5：产品线架构与产品线是啥关系？产品线架构与平台、产品平台不具有直接关系。产品线架构是针对产品线的，为产品线里的产品提供共同的支撑，例如，共同的业务架构、共同的技术架构。产品线架构首先提供可重用的基础业务，支持产品的多样性、系列化、或形成“价值附加族”（以某一产品的核心价值为中心，研发的依赖核心价值而存在的其它产品，具有增强、放大核心价值的能力）；从技术上提供相同的基础环境、规范、工具等，简化产品的研发和缩短周期。
探讨6:如何构建产品线架构？以《架构的支撑框架和运营》一文为指导，实践之。
ManicTime时间跟踪的利器
常常为记录每日时间的消耗情况和每日周报而痛苦吗？常常为时间管理无法跟踪而痛苦？ManicTime，绝对的利器（安装的时候，要下载.Net Framework3.5，因而有些慢，请耐心）。
架构的支撑框架与运营
| 更多内容在： |
架构专栏 |
在《对架构的另类定义》一文中对架构进行了定义，虽然利用了事物本质来阐述，依然比较抽象，理解起来比较困难，因而再定义一个支撑框架。这种做法与事务研究方法是对应的：“架构定义”是概念，“支撑框架”是本体，“运营中的架构”是运动体。下图展示了这个理念：
【图示说明：】
- 第一个领域是需求域，包括R1，R2，R3。R1代表当前实际的需求；R2代表了目标，例如，企业战略指标，系统容量指标等；R3代表了当前架构，如果还没有系统，那么R3为空。R1，R2来自于受益人，此处的受益人可以是具体的业务部门，也可以是抽象的系统（此时简介受益人是组织）；R3来自于客观存在。
- 某人，这个角色在实际中有很多职能部门的人来担任，例如CTO，CIO，产品经理，用户体验师，咨询公司，外部公司等，它的职责是提出解决方案。
- 目标架构，是解决方案的一部分（重合度可以是100%），目标架构是架构理论的具象，也即架构本体。
- 传道者，负责把架构理论，架构支撑框架，架构运营策略传递到公司。
- 下面的大方框内部是支撑框架的主体。在实际运作时，这个框架最好以项目的形式运营，这样是为什么有项目经理角色存在的原因。
- 支撑框架，横向包括5层：过程框架层、内容框架层、实践指导框架层（即过程A — 过程F），角色层，能力框架层；遵循包含3大类，6个子类，列与过程框架的交叉点上最终业务目标，列于内容框架的交叉点上子业务目标列的下面节点都是对业务目标的纵向支撑。
- 过程框架包括定义了过程路径和基本里程碑，P1->P2->P3-P4是基本过程；P5表示一个反馈和改进行为。这一部分与架构定义流派的决策派是有些映射的，只是具体基本里程碑的出发点是不一样的，例如，对于产品架构来说，本体过程包含了设计-研发-测试几个行为。
- 路径P6是一个特殊，它的行为是“比较”，通过对当前架构和目标架构的比较，找出差距，从而定制计划。
- 内容框架包括需求、概念、设计、本体、环境、运行体这6个子域，每个子域都有其特殊的内容项、内容格式。这一部分与架构定义流派的组成派是有些映射的，但也不是完全匹配，但目标是一致的：描述清楚架构的构成。
- 实践指导框架，本质上是把现有的各类方法论分门别类的放到对应的列上，再提供详细的过程指导。
- 角色层，定义清晰的角色，根本目标是定义视点，架构绝对不是一个视点的产物，它是多种视点汇聚而成的综合体。每个角色也可能有多个视点，不同角色之间，可能共享视点，但偏角不同（侧重点不同）。角色是整个框架的中枢，它纵向串起了一个价值链路，形成如下场景：经过某个认知过程，角色A具有了需求能力，该能力依赖于某些领域知识A1和某些技能A2，具有该能力的角色以实践过程A为指导，产出了需求内容。横向串起了领域，领域的顺序代表了认识事物的深入，由模糊到抽象，由抽象到具体，由静态到动态。
- 能力框架表示某个角色要达到某个业务目标，需要掌握的知识和技能。能力是做事的充分条件，但不代表没有这种能力的人不能做这件事。通常，对于不具备能力的人来说，首先按照能力体系的要求学习知识，掌握一定的技能；对于组织来说，就要培养这样的人具有该角色所要求的能力；对于项目经理来说，安排人干活时，首先要评估其能力，否则就要把这一点列入风险管理。
- 项目框架，把整个支撑作为项目来运作，而不是简单的一个活动或者学习，才能够确保：高效、高质、合适成本的得到目标框架。
【作用】通过该支撑框架，能够获得如下作用：
- 定义了清晰的工作目的–解决方案、目标域、目标架构
- 完整的工作指导–过程体系
- 完整的内容指导–内容框架
- 可操作的工作内容–执行P6过程的结果
- 树立客户意识–角色层，前一阶段的结果是后一阶段的输入
- 清晰的职责划分–角色层
- 员工培养–能力框架、角色层
- 交货意识–项目框架
- 风险意识–项目框架
- 成本意识–项目框架
- 质量意识–项目框架
- 改进意识–执行P5过程的结果
- 里程碑意识–过程框架
- 单项目标的可操作性–纵向价值链路
- 自我提升指导–理论体系
好的架构，是企业的核心资产之一，如何运营好这部分资产？（没有想太明白，但它依然非常重要）
Mule是啥玩意
Mule基于Java平台，是一个轻量级的消息框架，可让您快速，轻松地连接您的应用程序（外部系统、内部组件、甚至一段脚本），使他们能够交换数据。
Mule的架构风格是 Enterprise Service Bus (ESB) 架构，它也属于ESB产品一组，就如下图所示，具有如下品质特征：
- 互联互通。
- 低的耦合性。
- 高扩展性。
- 高可重用性。
- 易维护性。
Mule框架的一些说明：
- Mule框架具有高可扩展性，用户可以自己定制连接器（说实在的，Mule提供的一些东西，只能算是参考品，例如TCP连接器质量一般，必须定制Mina、Grizzly等强壮点的通信框架，自己实现一个连接器；老的那个XFire连接器，也很不好用，换成Jetty也得Fix一些BUG。要不是看它的框架还算巧妙，早丢弃了），拦截器，转换器等连接组件，同时能够把自己业务领域的计算组件或领域组件部署在Mule容器中；
- Mule框架支持面向服务的架构（ SOA ），能够通过JMS ， Web服务，数据库， HTTP等等连接器，无缝地整合应用系统；
- Mule框架可以独立部署，也可以嵌入；
- Mule已经与Spring实现了无缝整合；
- Mule框架有企业版和社区版，社区版是免费的，BUG多一些；其中企业版需要付出点费用；
- Mule有一个很长的授权文件，可惜E文不是很好，没有完全看明白，倒是记得了一句：“The Original Code is MuleSource Mule The Initial Developer of the Original Code is MuleSource Inc. All portions of the code are Copyright (c) 2003-2007 MuleSource Inc. All Rights Reserved。”，所以上市公司，请再仔细读读该文件。
- Mule不是对JBI的实现，但提供了JBI扩展。Mule使用起来比JBI要简单，也不像JBI强制要求SOAP堆栈，协议比较灵活，在分布式计算领域，性能也还是可以接受的。
