第1章 企业架构导论
1.1 什么是企业架构
开放组体系结构框架（The Open Group Architecture Framework, TOGAF）将“企业”定义为有着共同目标而集合的组织的聚集。例如，企业可能是政府部门、一个完整的公司、公司部门、单个处/科室或通过共同拥有权连接在一起的地理上疏远的组织链。
从结构的角度理解信息化，可以发现三个特点：第一，结构是超技术层面的，要建立完整的企业架构，必须从企业战略高度来思考信息化建设；第二，结构可以很好地把握组织动态发展的脉络，为组织成长奠定坚实的基础；第三，结构具有丰富的层次性，可以有效地体现组织的柔性。
1.3 企业架构理论
架构框架是一个或一套基础结构，用来开发大范围的不同架构。它描述一个用构建块的集合来设计企业目标状态的方法，并显示这些构建块如何搭配在一起。它应该包含一套工具并提供共同词汇，也应该包含所提议标准的清单以及符合标准的可以实现构建块的产品。构建块可以是架构元模型实体的目录清单、矩阵及图表、功能规格、应用模块、软件和硬件产品及其组合。企业架构框架并不是企业架构本身，但是它可以告诉我们如何组织和描述企业架构。
Zachman架构框架理论最具代表性的是通过6列5行共30个元素表示的矩阵表格，如表1-2所示，以最简便的形式刻画了构成所有内在关系的设计元素以及这些元素在设计中的功能和作用，它构成了一个完整的理论和模型。扎克曼将每部分都看成独立的变量，这是关系型数据库中的标准思维；数据必须与功能、网络位置独立区分，以保持思维的灵活性和清晰性。
Zachman架构框架主要还是解决系统建设问题，而不涉及业务和流程的设计。
第2章 业务架构
业务流程首先要描述清楚企业现有的流程，其次要反映企业改进后的目标流程（如果有改进的余地）。
如果一个流程/活动对企业的战略目标没有贡献，那么这个流程/活动就需要从业务中去除。
建立一个清晰的业务架构时，可以使用业务流程建模（Business Process Modeling, BPM）作为表述的工具。
2.1 信息化与业务架构
保证数据有效的共享和交换是企业架构的主要目的之一。
第3章 数据架构
3.1 数据架构概述
数据架构管理聚焦于三个层面：宏观层面——数据总体视图，关注各应用系统中数据分类、分布、归属等；微观层面——具体应用系统中数据结构，关注表空间、数据库设计等；治理层面——数据管理政策、原则、规范、标准等，为宏观和微观因素的变更提供指引。
3.2 数据分类
分类与预测是两种数据分析形式，它们可以用来抽取能够描述重要数据集合或预测未来数据趋势的模型。
分类方法（classification）用于预测数据对象的离散类别（categorical label）；预测方法（prediction）用于预测数据对象的连续取值。
1．决策树
决策树归纳是经典的分类算法。它采用自顶向下递归的各个击破方式构造决策树，树的每一个节点上使用信息增益度量选择测试属性。可以从生成的决策树中提取规则。
2．KNN法
KNN法（K-Nearest Neighbor）即K最近邻法
采用这种方法可以较好地避免样本的不平衡问题。
对于类域的交叉或重叠较多的待分样本集来说，KNN法较其他方法更为适合。
该方法的不足之处是计算量较大，因为对每一个待分类的文本都要计算它到全体已知样本的距离，才能求得它的K个最近邻点。目前常用的解决方法是事先对已知样本点进行剪辑，事先去除对分类作用不大的样本。
另外还有一种Reverse KNN法，能降低KNN算法的计算复杂度，提高分类的效率。该算法比较适用于样本容量比较大的类域的自动分类，而那些样本容量较小的类域采用这种算法比较容易产生误分。
3．SVM法
SVM法即支持向量机（Support Vector Machine）算法
具有相对优良的性能指标。
通过学习算法，SVM可以自动寻找出那些对分类有较好区分能力的支持向量，由此构造出的分类器可以使类与类的间隔最大化，因而有较好的适应能力和较高的分准率。该方法只需要由各类域的边界样本的类别来决定最后的分类结果。
SVM法的目的在于寻找一个超平面H（d），该超平面可以将训练集中的数据分开，且与类域边界的沿垂直于该超平面方向的距离最大，故SVM法亦被称为最大边缘（maximum margin）算法。
SVM法对小样本情况下的自动分类有着较好的分类结果。
VSM法相对其他分类方法而言，更适合于专业文献的分类。
Bayes法要求表达文本的主题词相互独立，这样的条件在实际文本中一般很难满足，因此该方法往往在效果上难以达到理论上的最大值。
3.5 数据模型
数据模型分为概念数据模型、逻辑数据模型和物理数据模型，如图3-11所示。
第4章 应用架构
4.1 应用架构概念引入
应用架构的目的是建立企业的业务架构和数据架构与具体的IT应用系统之间的关联，在IT架构中发挥核心的作用。
4.2 应用架构风格
下面分别介绍一些常用的架构风格。
4.2.1 管道和过滤器架构风格
4.2.2 分层架构风格
4.2.3 面向构件架构风格
面向构件架构风格可以描述为：系统=框架+构件+组建。框架是所有构件的支撑框架；每个构件实现系统的每个具体功能；组建，可以视为构件的插入顺序。不同构件的组成顺序不同，其实现的整体功能也就不同。
4.2.4 面向服务架构风格
不同于面向构件架构风格中构件之间的紧耦合，面向服务架构（SOA）风格是指将应用程序的不同功能单元（即服务），通过服务间定义良好的接口和契约联系起来。
4.5 SOA应用架构设计要点
4.5.2 SOA总体框架
在全国信息技术标准化技术委员会SOA标准工作组制定的《信息技术面向服务的体系结构（SOA）应用的总体技术要求》标准中，提出了SOA应用的概念模型、技术参考模型和基本技术要求，为基于SOA应用的分析、设计、开发、测试、部署、运行、维护的提供了基础。SOA应用架构设计需参照技术参考模型的规定，如图4-5所示。
4.5.6 SOA应用效果评估
Open Group服务集成成熟度模型（OSIMM）
OSIMM成熟度矩阵定义了成熟度维度和水平，如图4-12所示。
第5章 基础架构设计与优化
5.1 企业的可持续发展战略与工具
进入基础架构设计阶段后，按照表5-2所示9个阶段进行基础架构设计，这9个阶段是完成基础架构的主要活动，需要注意的是，在实践过程中可以根据企业的实际情况进行一定程度的调整。
5.2 平台选型
这个定律的核心思想是并行处理的扩展性由问题可并行的部分所决定。
CAP定律指出，对于一个分布式计算机系统来说，无法同时提供以下3项保证。
- 一致性（所有节点在同一时间看到相同的数据）。
- 可用性（保证每一个请求都会收到或者成功或者失败的响应）。
- 分区容忍性（任意消息丢失或者部分系统失效时系统仍可继续运行）。
如果以上3项都必须保证，那么就必须使用集中式架构设计。
5.3 网络技术与规划
线路测试是其他测试的基础，统计数据表明，50%以上的网络硬件故障与布线有关。
5.4 存储技术与规划
RTO指的是当灾难或紧急事件发生时，从业务中断到业务恢复所消耗的时间，RPO则指的是当灾难或紧急事件发生时，数据可以恢复到的时间点。这两个值是衡量一个企业业务连续性能力的重要指标。
5.6 运营技术与规划
目前在业内已经有一些很好的运维管理方法论，例如ITIL（IT Infrastructure Library）和COBIT（Control Object for Information and Related Technology）。
ITIL通过24条原则定义了一整套运维管理的最佳实践。
COBIT则根据商业目标、质量标准、财务控制和安全需求来综合进行资源调配和流程管理。COBIT管理实践的4个要素分别是计划与组织、获得与执行、交付与支持以及监测。
ITIL将运维工作分为两大类：服务支持与服务交付。服务支持指的是常规的、必需的工作，目的是让用户能够顺利的使用IT服务，包括Service Desk、事件处理与跟踪、问题处理与跟踪、变更管理、配置管理、发布管理。服务交付指的是运维部门应当具备的工作流程，包括服务级别的约定与管理、IT服务相关的财务管理、系统可用性的管理、系统容量规划与性能管理、系统容灾备份恢复方案及业务连续性管理。ITIL将这11类工作统称为服务流程。
配置管理和变更管理一样，都是企业引入ITIL过程中需要首先建立起的流程。
第7章 架构迁移
7.1 架构迁移策略
实践证明改善管理，理顺流程，使业务流程合理化是企业在信息化过程中避免产生“IT黑洞”和“MIS泥潭”的一个前提条件
信息化建设的目的不只是单纯地为了应用信息系统，而是要通过信息的建设引进先进理念来提升管理水平、实现管理创新，通过整合资源来优化资源管理、降低成本、实现经济效益，最终达到提升竞争力的目的。
任何变革的本质都是通过量变的不断积累达到质变的过程
7.2 项目立项管理
项目立项管理（Project Initialization Management, PIM）的目的是：采纳符合机构最大利益的立项建议，避免浪费机构的人力资源、资金、时间等。
立项管理是决策行为，其目标是“做正确的事情”（do right things）。而立项之后的研发项目管理项目的目标是“正确地做事情”（do things right）。只有“正确的决策”加上“正确地执行”才可能产生优秀的结果。
由于立项调查工作和可行性分析通常比较费时费力，往往被人忽视。而草率撰写的《立项建议书》会有比较多的主观臆断，这对项目是有危害的。产品构思通常不可能快速完成，切不可闭门造车。深入地进行立项调查与可行性分析不仅对产品构思有帮助，而且对立项审查也有帮助。
7.3 项目集管理
在组织的环境中，项目组合是一组相关的项目，追求采用同等的管理方式获取全局整体利益的改善，但是项目组合不负责对其中每一个单一项目的直接管理与控制。项目组合的管理工作往往在单一项目管理范围之外。
第8章 需求管理
8.4 需求管理实践
需求的双向跟踪（正向跟踪：需求文档中的每个需求都应能在后续的工作成果中找到对应点；逆向跟踪：设计文档、代码、测试用例等工作成果应能在需求文档中找到出处）。
