之前忙于搬家移居，无暇顾及博客，今天终于得闲继续我的“政治课”了，希望之后至少能够补完TOGAF方面的内容。从前面文章可以看出，笔者并无太多能力和机会对TOGAF进行理论和实际的联系，仅可对标准的文本进行翻译和整理,间或掺杂点个人理解，望各位看官海涵，如能有所帮助则足以欣慰。
5. 构建块（Building Blocks）
架构构建块可以说是企业架构内容的核心，也是企业架构开发方法的最终产物。与此相比，架构交付物所面向的是企业架构开发过程，架构制品则可以看作是企业架构内容的表现形式和使用方式，而唯有构建块则是企业架构内容本身。企业架构的主要作用就是在企业中的各个领域内（业务、数据、应用和技术）寻找和定义可重用的资源模块，并将这些模块结合为一个有机的整体，从而使得各个干系人对于企业情况具有准确清晰的共识，并促进企业中的信息资源的共享和优化。这些企业各个领域中的可重用模块就是架构构建块，也是架构资源库中的各种架构制品所描述的本体。
5.1 构建块特性
在TOGAF中，构建块所共有的特性被定义如下：
- 构建块是为了达成整个组织的需要而定义的功能包。
- 构建块需要具有在TOGAF内容元模型中定义的类型，例如执行者（Actor）、业务服务（Business Service）、应用（Application）或数据实体（Data Entity）等。
- 需要为构建块定义一个边界，并且通常需要领域专家认可这一边界定义。
- 构建块通常会与其他相互依存的构建块进行互操作。
除了上述通用的特性之外，作为一个良好的构建块还需要具有如下特点：
- 构建块的制定需要考虑其实现和使用方面，并通过逐渐演进而达成针对各种技术和标准的最大化利用。
- 一个好的构建块可以由其他构建块组合而成。
- 一个好的构建块可以是其他构建块的一个组件。
- 在理想的情况下，一个构建块应是可重用和可替换的，并具备详尽的描述。
5.2 构建块分类
与软件技术中的接口和实现类之间的关系相类似，构建块的边界定义和规范说明与其具体实现方式之间也是松耦合的，也就是说可以通过多种实现方式来针对一个构建块进行实现，而不会影响到构建块的边界定义和规范说明。为了达成这种灵活性，在TOGAF中构建块被分为架构构建块和解决方案构建块两类，其中前者用于对构建块的需求进行描述，而后者则在实现的层面对能够实现构建块的解决方案进行描述。需要注意的是，由于构建块的独立存在是没有意义的，如果要发挥其作用往往需要其他构建块的配合，因而针对作为构建块“接口定义”的架构构建块应具有一定的稳定性，而更加倾向于实现的解决方案构建块则更加灵活和多样。
5.2.1 架构构建块（ABBs：Architecture Building Blocks）
架构构建块与架构连续体相关，并且通常作为架构开发方法的应用结果而被定义或选择。架构构建块应具备如下特性：
- 捕捉架构需求，例如业务、数据、应用和技术方面的需求。
- 用以指导解决方案架构块的开发。
架构构建块的内容至少应包括：
- 基本功能和属性说明：有关语义方面且明确的说明，包括安全能力和管理能力。
- 接口：提供的选择集合。
- 与其他构建块之间的互操作和关系。
- 所依赖的构建块，并附以针对所需功能和用户界面的描述。
- 业务和组织实体之间的映射和策略。
5.2.2 解决方案构建块（SBBs：SolutionBuilding Blocks）
解决方案与解决方案连续体相关，并通过采购或开发的方式而获得。解决方案构建块应具备如下特性：
- 对用于进行功能实现的产品和组件进行定义。
- 对实施进行了定义。
- 满足业务需求。
- 产品或厂商是明确的。
解决方案构建块的内容至少应包括：
- 具体的功能和属性。
- 接口：具体实现集合。
- 被所需功能的使用而需要的解决方案构建块以及所用接口的名称。
- 解决方案构建块与IT技术和运用策略之间的映射。
- 环境中所共享属性的说明，例如安全性、可管理性、本地化和可扩展性。
- 性能以及可配置能力。
- 设计驱动力和约束，包括物理架构。
- 解决方案构建块与架构构建块之间的关系。
5.3 构建块的使用原则
虽然构建块是针对企业中各项资源和能力的组合，但针对这些内容的组合方式在不同的组织中却各不相同，并且组织也应该按照各自的特点对各个构建块进行安置，从而使构建块能够得到最大化的利用，因为一个针对构建块的明智选择和使用将会使得企业改善其对遗留系统的整合、互操作性以及在新系统和软件的创建中灵活性。从某种意义上说，所谓架构就是一系列描述在架构模型之中的构建块，以及一份关于这些构建块是如何组合在一起来达成所有业务需求的说明，而这些架构中的构建块描述了用于解决特定业务问题的范围和方法。在具体架构的设计过程中，针对构建块的使用需要遵循如下几个通用原则：
- 一个架构应该仅包含与此架构需要解决的业务问题相关的构建块。
- 构建块与其他构建块之间存在着复杂的关系。一个构建块可以用来支持其他多个构建块，或作为用以支持某一个构建块的一部分。
- 构建块应与其类型相关的标准相符合，并遵循企业中的其他相关原则和标准。
通过上述原则，企业可以将构建块组合为用于解决业务问题的各个具体架构，而针对作为架构组成单位的构建块的确定也是非常重要的。针对构建块的识别过程包括寻找企业中进行相互交互的各个能力或资产，并在之后将他们组合在一起，在这个过程中我们需要对如下几点进行考虑：
- 从如下角度对企业中的能力或资产进行分类：
- 可重用的构建块，例如遗留项。
- 需要被开发的构建块，例如新的应用。
- 需要被采购的构建块，例如从市场中可购得的应用。
- 采用适当的整合水平将各个功能组合到构建块之中。例如，遗留下来的各个元素就可以被当作一个大型构建块来处理，而不用将其分解开来。
5.4 构建块与架构开发方法
由于详细的功能需求、约束以及现实产品的可得性并不是在一开始就可以被定义清楚的，并且这些方面对于构建块的内容和选择也有着非常大的影响，因而构建块的定义过程必将是一个迭代过程，并伴随着架构开发方法的进行而逐步演进。总的来说，这一过程可以概括为：在架构开发方法的进行过程中，首先是架构构建块被确定出来，用以达成各项业务目标和阶段目标；接下来，这些架构构建块将会通过后续的迭代过程而得以改善，并最终形成一系列可由开发或购买而得的解决方案构建块。由此可见，构建块的详细程度与架构开发所处的阶段有着非常紧密的联系，但我们还需要注意，一个构建块的详细程度还与其所组成的架构所面对的目标有着关联，例如在呈现企业的能力时，一张清晰简洁的图片将胜过上百页的详细描述。
架构开发方法的各个阶段对于构建块的定义和确定有着紧密的联系，特别是架构愿景、业务架构、信息系统架构和技术架构这几个阶段，而包含在这些企业架构开发方法阶段之中对构建块进行定义和演进的步骤总结如下：
架构开发方法阶段 | 构建块定义和演进步骤 |
架构愿景 | 选定候选构建块的高层次模型 |
业务架构 信息系统架构 技术架构 | 选定参考模型、视角和工具 |
开发基线架构描述
| |
开发目标架构描述
| |
进行差距分析
| |
定义各路线图组件 | |
通观整个架构景观来明确和解决相关影响 | |
进行正式的干系人审查 | |
确定最终架构 | |
创建架构定义文档 | |
机会和解决方案 | 将构建块的差距与用于弥合这些差距的工作包联系起来 |