读后感
《企业架构-价值网络时代企业成功的运营模式》这本书，是金根（http://www.cnblogs.com/zhoujg）给我们的推荐，我浏览了一遍，并阅读了两遍。
也许是囿于作者的篇幅，也许是由于自己的阅历不够，这本书总体给我的感觉是写的过于笼统，可以作为“企业架构”的入门级或者简介类的书，而无法成为一个工具手册来用。书中虽然设计了一个贯穿始终的例子，但是依然觉得实操性不够，很多结论的得出显得过于突兀。
但是这本书还是给了我很大的收获，总的来说有以下几点：
1. 一种思维的转变；
2. 一种思维的继承；
3. 一个企业架构的方法；
4. 一个继续学习的指引。
一种思维的转变
“传统企业生存和发展的方式是创造价值并与消费者交换。这种由企业个体创造价值的观念正在被行业合作伙伴共同创造价值的观念所替代”。
“以企业和产品为中心的传统价值观，正迅速被一种专业化和共创的价值观所替代”。
这是一个不争的事实，但是却在很长的时间让我不能适应。
我之前曾经做过一个通用的插件框架，在设计的过程中，我坚持所有的代码自己写，即使一些借用的或者参考的代码，也一一修改代码，甚至将代码风格都改成一致，结果是RoadMap一改再改，基线一再被打破。事实上，现在回过头来想一想，我的框架只要实现一个总线即可，很多具体的功能可以使用其他成熟的产品来实现，我要做的只是使用这些产品的接口，或者提供一个适配器即可。在金根的个人管理 － 我是这样偷着做架构的也提到了这样的概念。
另外一个例子，裕元集团，是东莞的一个企业，他们是耐克、阿迪达斯等企业的代工厂，不仅仅如此，他们还负责设计。耐克、阿迪达斯等企业只要将设计风格等告诉裕元，裕元负责设计并生产。换句话说，有些人喜欢耐克，有些人喜欢阿迪达斯，而很有可能他们看到的运动鞋是中国公司设计和生产的，甚至销售。在这个产品链条中，耐克等企业只是负责了市场营销和品牌建设。我们在上个十年还经常提到的原装进口之类的概念，正在逐渐消失，取而代之的是世界是平的、全球分工和理念。
前些日子听到一句话，“什么都做就是农民”。我们不考虑这句话是否包含着对农民的不尊重，至少说明了一个道理：制定企业战略时除了选择要做什么，还要选择不做什么。企业战略不只是决定什么要做得最好，也要决定什么不必做得最好。
我们做业务，做技术也是一样，专注我们的核心价值，对于其他非核心的内容，采用外包的方式来获取。
经过分工，可能在一个行业里面会出现两种基本的角色：
1） 总线：可以认为是一种粘合剂，为了完成一项工作，他将需要的组件粘合在一起，共同为了这个工作服务；
2） 组件：具有专业能力的最小单位，以接口的方式供总线来调用，提供专业的能力。
举个例子，我们要做项目管理系统，这个系统中可能包括人力系统、财务系统、建筑行业过程管理等等，这个项目管理系统可以看成是总线，而人力系统等可以看成是一个个的组件。
我们每个人的职业发展道路也是类似：在工作分工中（以技术为例），有的同事朝广度发展，他虽然不知道各种技术的实现细节，但是知道各种技术的适用范围、优点、缺点、接口等，他能负责一个项目的总体控制；有的同事朝深度发展，在他的专业领域中他就是专家，所有的此专业的问题他都能够解决。
一种思维的继承
“业务组件是指系统中实现的最小业务单元， 组件中会包含实现该项业务的若干步骤和功能，但它们不可再分割，否则将失去业务价值。”
“业务组件具有明确的功能、输入和输出，组件本身是完整、独立的，既可以独自完成一个或一组业务功能，也可以与其它组件协作( 通过组件关系或业务流程 )来完成特定的业务目标。”
业务组件的思想和我一直以来用到的面向对象思想有很多类似的地方，因此从《企业架构》中我得到的第二个收获是企业架构的思维模式能够继承自面向对象。
抽象：指对于具有相近的业务处理（业务功能）、涉及对象（业务实体）的业务活动进行抽提，定义为一个业务组件。这种情况下，业务活动与业务组件是多对一的关系。如“制定物资采购计划”活动和“制定物资集中采购计划”活动可以定义为“物资采购计划”组件。
对于多个业务活动中涉及的相同业务处理，也采用抽象的方法定义公共业务组件。
抽象是业务架构的基础，也是面向对象的基础。
封装：业务组件具有明确的功能，它将实现一项业务的步骤和功能集成到里面，对外提供接口，实现是透明的。也就是说我们在调用一个业务组件的时候，只需要知道需要输入什么，能够通过该业务组件输出什么，具体的实现过程是一个黑箱，是我们不关注的。
高内聚：业务组件是系统中实现的最小业务单元，也就是说组件内只包含一个业务，同时组件内的步骤和功能对于组件来说都是缺一不可的。因此设计组件模型的时候，业务粒度的选择非常重要。
低耦合：业务组件具有明确的功能、输入和输出，它能够与其他组件写作来完成特定的业务目标。业务组件的输入和输出通过标准接口来实现，因此，一个组件不会依赖另一个组件的内部实现过程，只会以接口调用的方式和其他组件进行协作。
组合：指对于一系列紧密关联的业务活动，组合起来定义为一个业务组件。这种情况下，业务活动与业务组件是多对一关系。如“发现潜在供应商”活动、“维护供应商信息”活动和“评价供应商”活动可以定义为“管理供应商”组件。
……
在学习企业架构，特别是组件化的过程中，给我的一个很大的感受是学习组件的过程，同样需要我们具备抽象的能力，所不同的是组件包括的内容比对象更多，范围比对象更大，含义比对象更广。
一种企业架构的方法 – CBM
“CBM是Component Based Modeling的缩写，直译就是‘业务组件建模’”。
“组件化就是把企业的产品、销售、采购、生产、财务等业务功能转变为业务模块，即业务组件。CBM是通过企业功能组件化的方式对企业进行重新定义和组合的过程。”。
对于企业的业务架构来说，可能包括业务组件、流程、组件分布、内外包模型、组织架构、绩效考核、架构管理等方面的内容，这里面发现和定义业务组件是业务架构中最重要的一个方面，CBM提供了一个发现、设计、定义业务组件的方法，具体来说包括下面内容：
1） 一张总图
CBM提供了一个2维矩阵的组件总图，通过两个维度，能够让我们更有针对性地寻找和组织业务组件。
CBM总图中，纵向是只能层次，风味战略规划、管理控制、执行操作三个层次；横向是企业的业务能力，也就是说企业具有哪些业务线，比如下图就是《企业架构》中举的一个总图的例子：
通过这个矩阵，我们能清晰定义业务组件。
2） 一个组件定义模板
CBM提供了一个组件定义模板，这个模板我们可以看成是一个CheckList，帮助我们不遗漏、不重复定义每个组件的内容。一个业务组件定义模板的结构如下图所示：
3） 在组件内寻找二三级活动
在CBM中并没有提到是先有了组件再分析里面的活动还是先分析了活动再组合和封装成组件，这实际是自上而下和自下而上两种思路。在实际的业务中，我们往往是两种方法结合使用，通过设计和重构的不断迭代过程最终抽离出业务组件。
同时，需要注意的是，我们要承认变化的存在，在业务架构过程中，业务本身可能发生变化，CBM总图或者组件图、活动也不是一成不变的，因此我们要经常维护这个模型。
一个组件二、三级活动分解的例子如下：
4） 发现“热点”组件
前面已经提到了制定企业战略时除了选择要做什么，还要选择不做什么。企业战略不只是决定什么要做得最好，也要决定什么不必做得最好。通过CBM，我们能确定哪些是企业的核心竞争力，这部分组件是热点组件，需要我们格外的关注；其他非热点组件，可以通过购买，外包的方式。
举例来说，在我们的项目管理系统中，在整个项目管理系统里面，和XX相关的组件是我们的核心，属于热点组件，我们要尽力自己做，并树立起技术壁垒；其他譬如人力资源、财务等目前不是我们的热点，我们可以采取合作的方式，购买或者分包给其他厂商。如果我们将来认为这部分也是热点，我们可以在不对系统做大的修改情况下，自己提供相应组件替代目前的组件。
对于业务架构来说，业务流程的设计也是非常重要的一环，这部分书中只提了一些概念性的东西，这部分的学习还需要在接下来的工作中向同事学习。
一个继续学习的指引
“SOA应用系统：应用系统提供了一系列的服务，以支持企业的业务流程。”
“TOGAF是提供了一整套方法和工具的企业架构框架。”
虽然《企业架构》这本书讲的比较浅显，很多概念都是点到为止，但是至少打开了一扇门，同时也让我们知道了接下来要学习的方向。
目前部门在金根的推动下，使用TOGAF进行业务架构，坦率的说，这是一条充满了困难的路，我们将努力在接下来的工作中，针对性学习，在项目中学以致用。
原文链接