联邦企业架构之联邦过渡架构及企业架构评估框架
邦过渡框架（FTF，Federal Transition Framework）是一份包含了所有跨机构的信息技术举措的目录，它为各个政府机构对于获知政府全局级别的信息技术策略目标以及各跨机构举措这些方面的信息充当了唯一的信息源。就这份目录的内容来说，联邦过渡框架包含如下两个方面的跨机构信息技术举措：
- 受OMB资助的各项举措，例如电子政务举措和业务线（LOB）举措等。
- 政府全局级别的举措，例如IPV6举措等。
FTF内容组织方式
所有这些举措都被罗列在联邦过渡框架之中。其中每一项举措都对应着一个部分（Section），并且针对每一项举措FTF都是采用一套标准的层次性方式来进行描述，而这套层次性的描述方式又与联邦企业架构参考模型相吻合，从而方便各个机构将这些跨机构信息技术举措整合到各自的架构中去。
通过在全联邦政府的角度将跨越各个机构的各项举措进行总结和发布，使得原来相互隔绝的各个政府机构可以从全局的视角审视整个联邦政府以及自己的信息技术和信息资源的状况，分享其他机构的最佳实践和信息资源，从而提升对于信息技术投资的效率并改善其效果。需要注意的是，FTF针对各项举措的描述采用了与联邦企业架构的参考模型相适合的方式，因而对于推行和使用了这些参考模型的各个政府机构来说，在各自的企业架构中整合这些全局性的举措是没有沟通和交流障碍的。总的来说，FTF目录的益处体现在如下几个方面：
- 增进各个政府机构对于跨机构举措的认知和参与。
- 增强各个机构的企业架构与联邦信息技术策略或其他形式的官方导则之间的一致性。
- 加强针对通用的跨机构业务流程、服务组件以及技术标准的共享和重用。
- 通过部门参与到跨机构实践团体中的方式来增强机构之间的合作。
除了针对各个跨机构举措进行归纳总结的FTF目录之外，作为一个框架，FTF还提供了一系列有关使用情景的描述，用以指导各个机构如何将这些跨机构举措融合到自身机构之中，并可以帮助各跨机构工作组开发与各条业务线相关的架构工作产品。在FTF中，这些使用场景的描述包含如下几个部分：
- 干系人（Stakeholders）：用于列举此应用情景所涉及到的各相关人员。
- 假设（Assumptions）：用于描述此使用情景得以进行的各个先决条件。
- 步骤（Steps）：用于达成情景结果以及创建和更新各项工作产物的各项步骤。
- 工作产物（Productions）：在各步骤执行过程中创建和更新的各种制品。
- 检验（Checks）：用于描述OMB在检验工作产物和情境结果中所采用的各项步骤。
- 结果（Outcomes）：用于描述使用情境达成后所带来的结果和影响。
FTF一共描述了七种使用情境，并根据其应用对象的不同分为两类：
- 针对各个机构的决策者，FTF制定了如下四种使用情境，用于指导各个机构如何将FTF中的跨机构举措整合到自身之中：
- 整合跨机构举措到机构的企业架构中。
- 针对机构的企业机构与跨机构举措的符合性进行自检。
- 将机构预算提交与跨机构举措进行对比校准。
- 将机构中正在进行的IT项目与跨机构举措进行对比校准。
- 针对负责FTF的开发和维护的跨机构举措工作组，FTF定义了如下三种使用情境，用于指导与各业务线相关的各个架构工作制品的开发和维护：
- 分析阶段：定义业务线的范围，这包括一个远景描述和参考架构。参考架构从相关业务功能、数据需求，以及服务和技术需求这些方面描述了举措的范围。
- 定义阶段：为业务线定义目标架构，同时识别出各种可能的实施方案并加以评估，并为实施方案定义业务用例。
- 操作阶段：开发和实施通用的解决方案，从而支持业务线的操作和最终结果的实现（例如节省开支，增进效率和效能）。
企业架构评估框架
企业架构评估框架（EAAF，Enterprise Architecture Assessment Framework）是联邦政府用来对企业架构的情况进行评估的一套框架。为了达到机构的性能改善，各部门机构需要在多个实践领域中通过相应的管理过程来实现，而企业架构项目就是这些实践领域中的重要一环，它阐明了机构战略目标、投资、业务解决方案和可测量的性能改善之间的关系。除此之外机构中还存在着其他实践领域，如战略规划、资金规划和投资控制、方案和项目管理，并且为了达到机构性能的改善，这些实践领域还须与企业架构项目紧密结合在一起。由此可见，单单对企业架构的情况进行评估是不够的，因而在EAAF中，OMB针对企业架构评估内容范围的定义除了企业架构本身情况外，还包括对于企业架构项目与其他实践领域在结合度方面的评估。企业架构评估框架定义了若干关键性能指标（KPI）来对企业架构的各方面情况进行评估，并且这些指标按照其内容特性被组织到三个分组之内。需要注意的是在每个指标的定义之外，EAAF还对每项指标的应用理由与是否为强制性衡量指标进行了描述（前者解释了为什么OMB认为该指标是值得评估的，而后者将指标与具体的法规或策略进行挂钩）。在EAAF（v3.0）中，这些指标及其分组定义如下：
|
指标分组 |
指标 |
注释 |
|
完成情况（Completion） |
目标企业架构和架构过渡计划 |
用于衡量目标企业架构在识别和解决现实与目标的差距、冗余和IT投资组合成本方面的效率和效能 |
|
架构优先排序 |
用于衡量部门的经过优先级化的片段架构（Segment Architecture）的开发情况 |
|
|
完成的范围 |
用于衡量已完成的片段架构所占的企业IT投资组合资金量的百分比 |
|
|
IPv6 |
用于衡量机构的企业架构将IPv6整合到机构的IT基础设施片段架构和IT投资组合的情况 |
|
|
使用情况（Use） |
性能改进集成 |
从流程和产出角度，对机构性能改善计划与企业过渡计划之间进行校准的有效性进行评估 |
|
CPIC集成 |
用于衡量机构的IT投资组合与企业过渡计划的契合情况 |
|
|
FEA参考模型与图表53内容 |
用于衡量关于主要的FEA参考模型映射以及用于规范说明机构IT投资的图表53内容的完整性和准确性 |
|
|
协作和重用 |
通过衡量共享和重用信息、基础设施、解决方案和服务组件的情况来评估企业架构的有效性 |
|
|
企业架构治理、项目管理、变更管理和部署 |
用于衡量机构对企业架构策略和流程的使用和实施的管理情况 |
|
|
结果情况（Results） |
任务性能 |
用于衡量机构采用企业架构对项目性能改善进行驱动的程度 |
|
成本节约和避免 |
用于衡量机构采用企业架构和信息技术来进行成本控制的程度 |
|
|
IT基础设施的投资组合质量 |
用于衡量机构借由IT基础设施片段架构和其关于IT技术设施业务线的承诺所做计划的结果的实现及交付的进度情况 |
|
|
测量企业架构项目价值 |
企业架构价值评测跟踪架构的开发和使用，并监督企业架构产品和服务的影响 |
上表中提到过的图表53是各部门机构用来向OMB汇报关于本机构所有IT投资的预算评估的报告用图表，并借以明确主要的投资项，而对于各部门来说完成此图表也是对于1996年《克林格.科恩法案》的遵循，从而符合该法案所要求的所有部门机构必须提供关于其IT投资的完备且准确的会计审核。OMB每年也会通过图表53来创建全联邦的IT投资组合，并将其作为总统预算的一部分而进行发布。除了图表53之外，OMB还制定了其他多种图表，例如总是和图表53相伴的用于发现主要投资项的图表300。
在针对企业架构的评估过程中，机构或OMB需要根据企业架构的真实情况并依照这些指标分别进行评分，评分范围在1-5之间（分值越高代表企业架构越好的表现，而且每个KPI分值的含义也在EAAF中得到了详尽的定义）。此外，OMB需要针对每个指标分组的指标进行平均分计算，并根据平均分数的高低将每个分组划分为绿、黄和红三个等级：
EAAF指标分组平均分等级标准
除了针对上述性能指标的定义之外，作为一套评估框架EAAF还对评估过程进行了定义。需要注意的是自v3.0以来，为了与其他实践领域相适应（CPIC等过程），原来的每年一次的评估过程被替代为分布于一年之内的多次且分立的评估，并且每次评估与一个指标分组相对应：
EAAF评估流程
如上图可见，EAAF将评估过程在一个财年中被分为前后衔接的四项：
- 在每个季度中间，各机构进行企业架构的各片段相关制品的汇报。
- 在第三、四和第一财季的中间各机构分别根据三个评估指标分组对企业项目进行自检，并将每个季度经过更新的片段架构相关制品与此自检结果一起提交给OMB。
- 在收到机构的自检报告以及经过更新的片段架构相关制品后，OMB将会对其进行审查和评估，并返回其意见。
- 在收集了所有指标组的自检结果和片段架构相关制品后，OMB将在第二个财季对关于机构的企业架构评估提供一份正式的回应。
云计算之路：用阿里云 vs Azure的对比测试揭开乌云的面纱
昨天重现问题时热泪盈眶，还有一个原因是因为只要能重现问题，我们就能对比测试。
当我们一次次怀疑虚拟机问题时，没有一次得到积极的回应，总是怀疑我们的应用环境——应用程序、缓存、Windows设置等。
而要我们证明虚拟机有问题，比阿里云证明虚拟机没有问题，难很多很多。
但是，今天早上我们终于进行了一次有说服力的证明！
对比的不是阿里云虚拟机与物理机，因为如果用物理机作比较，即使发现性能差异，也可以以“虚拟机比物理机性能差属正常现象”为借口。
我们用虚拟机来对比虚拟机——阿里云虚拟机 vs Azure虚拟机。
请看测试场景：
阿里云虚拟机配置：8核Intel E5645 2.40Ghz
Azure虚拟机：4核AMD Opteron 4171 HE 2.10Ghz
两个虚拟机用的是同样的ASP.NET程序，同样的Memcached/NoSQL服务器。
阿里云虚拟机访问的是阿里云RDS数据库，Azure虚拟机访问的是虚拟机上的数据库。（注：阿里云RDS上跑数据库比Azure虚拟机上跑数据库性能强很多）
压力测试工具用的是路过秋天的分布式压力测试工具（昨天就是通过它重现问题的，感谢路过秋天提供这个工具），对两个虚拟机用的是同样的测试压力：10万请求。
请看测试结果（红色曲线表示的是CPU占用率）：
1. 阿里云虚拟机的表现：
2. Azure虚拟机的表现
在“云计算之路-阿里云上”的系列文章中，我们一次次吐槽、抱怨，就是希望阿里云能从虚拟机层面找问题，或者明确告诉我们虚拟机的具体限制在哪里。
而一次一次的故障让我们处在崩溃的边缘，逼得我们不得不去找虚拟机问题的证据。
阿里云，我们不是故意要给你抹黑，是被你们逼的。
阿里云，用户不是故意要把问题往你们底层系统上赖，用户实在是因为在自己可以控制的范围内无法找到问题的真正原因。
（注：如果有朋友对这个测试结果有异议，欢迎拿出实测结果反驳我们。）