写于：2010年02月07日 博客园
今天花了一个上午去书店看了一本关于企业架构方面的书籍：《企业精简架构》（3星），这本书适合于架构师和CIO阅读，主要论述如何精简企业架构，道理简单，做起来很难。全书分为两部分：第一部分，作者通过一些直观的问题展示复杂性带来的问题，接着从数学的角度进行分析；第二部分，讨论解决复杂性问题的过程－简单迭代分割（SIP），下面把书中的一些主要内容给大家分享一下。
企业架构
企业架构的目标是通过IT投资获取最大的商业价值，它是一种高层次的企业视野，聚焦与组织的IT架构和业务架构之间。IT系统如果不能满足商业需求，那将是大大的浪费，而业务过程没有相应的IT支持，效率很难提高。《 Enterprise Architecture As Strategy》一书的作者们说过，真正能够有效利用企业架构的企业还不到5％，而企业架构又是如此重要，所以更有必要重视企业架构。
大多数企业架构师多多少少都有些方法论的经验，但是能够在这个领域有很开阔视野的架构师却为数不多，所以作者在书中介绍了一下目前最流行的Zachman、TOGAF和FEA，他觉得这些方法论更确切地说是框架，甚至连框架都不算，并没有很好的指导什么是好架构、什么是坏架构，又该如何做架构。他认为好的架构应该是简单的架构，也就是精简架构，在第二部分也提出了一个简单迭代分割（SIP）方法。
复杂性：C=PD
书中通过一些如硬币正反面、骰子等直观的示例，通过数学模型讲解一下复杂性的原理：
C=PD（c－复杂性；P－每隔决定点的支路数；D－决定点的数目）
骰子有6个面，一个骰子可以出6中不同组合，2个是36种，3个是216（63）种，12个是2176782336种，所以系统支持功能越多，每个功能之路数越多，系统就越复杂，可能成指数级的增长，所以需求人员不要以为只是增加了20％的功能量，但系统复杂度可能已经是指数级的增长了。书中还提到了增加桶的概念，其实就是分区的概念，把凌乱的对象按照逻辑划分为不同分区，减少复杂性，如12个骰子放在两个桶中，复杂度为2X66＝93000，与612=2176782336复杂度相比不是一个数量级的。
业务过程的复杂度与决定点的数目和那些决定点引出的路径的数目有关。软件系统的复杂度与变量的数目和那些变量的状态数有关。无论是业务过程还是软件系统，它们的复杂度都可以通过骰子系统来建模。在这个模型中，骰子的数目、每个骰子的面数，还有这些骰子是如果分割到几个篮子里的。
自治的子集：ABC
ABC是企业构架的基本单位，它是一个自治业务能力，是一个业务单元，这些单元之间都是自治的，并且以一种定义好的方式互相作用。
- A（Autonomous）：自治，不依赖于其他ABC的功能也能正常工作
- B（Business）：业务，有定义好的业务目的
- C（Capability）：能力，有能力创建出外部世界可见的效果
ABC模型简化的整个业务模型：
- 模型因为简化而收益，源于分割过程的结果
- 模型在处理问题时只关注ABC做什么，而不是怎么做
分区的五条法则
简化复杂性的三种主要方法：分区（分割）、迭代（执行子分区）和简化（移走子分区、做减法）。
- 必须是正确的分区：分割出自治的子集ABC
- 分区的定义必须是恰当的：功能必须分配到基于协作的等价关系的ABC
- 合适的子分区数量（3－8个）
- 每隔子分区中的元素必须在集的数量和重要程度上大致相当
- 子分区间的相互影响必须最小化且明确定义，ABC应该有伙伴关系
简单迭代分割（SIP）
我们已经知道ABC是企业构架的基本单位，那么我们如何找到这些ABC呢？SIP是一个找到这样的过程。
- 评估
- 准备
- 分割：从企业高层视角开始分割
- 简化：业务功能是否需要？是否可以采取组合方式？非核心功能是否可以外包？
- 区分优先级：价值图分析
- 迭代：可以采用 FEAF 等方法
互操作性
书中说到互操作性的一些方法：
- 使用过程、方法调用
- 使用共享数据库
- 使用共享数据访问层
- 使用SOA的交互操作
- 软件城堡模型
软件城堡模型
系统A没有任何部分封装成Web服务，而是让外部的一个叫做Guard的实体实现Web服务，Guard代表外界与系统A进行互操作。外界与Guard使用SOA进行操作。
我用ppt画了一个示意图：A、B是两个ABC自治子集
技术划分：
- 规则1：自治
- 规则2：清晰的边界
- 规则3：功能分割
- 规则4：依赖定义
- 规则5：异步
- 规则6：数据分割
- 规则7：无交叉事务
- 规则8：单点安全
- 规则9：内部信任
- 规则10：保持简单
这些规则有点类似SOA的规则，说起来简单，做起来可难了！