这篇文章上次修改于 339 天前，可能其部分内容已经发生变化，如有疑问可询问作者。 #### 32技术之4：业务原则、业务目标和业务驱动力（简单理解为业务驱动） > 一份关于业务原则、业务目标和业务驱动力的声明，通常先于架构活动在企业的其他地方被定义。 作为预备阶段的输出，它们将被重新生命，并作为阶段A：架构愿景的一部分被再次审查。阶段A的审查活动是为了确保当前的滚动一正确且清晰。 TOGAF9第三部分： * ADM指引和相关技术中包含了一个含有八项业务原则的集合的例子，可以作为一个有用的起点。 * TOGAF对于这一交付物的内容没有定义，因为其内容和结构可能会随不同组织发生相当大的变化。 必须是业务驱动/能力导向，抓业务目标，抓业务驱动力。这一点需要在：整个企业的IT治理机制当中明确下来。今后的信息化总的就是能力导向、业务驱动的道路 业务原则：能力导向，业务驱动。 业务目标：能力导向。 预备阶段：三个要素，一个位置。（其中要素中就有原则）。到各个部门访谈的时候：要谈原则，讲模式--讲信息化的建设模式和治理模式 #### 32技术之5：架构存储库（划分） > 架构存储库在企业中充当了与架构相关的所有项目的保存区域的作用。存储库使项目能够管理其交付物、定位可重用的资产，并向利益相关者和其他利益方发布输出物。 需要有一个明确的结构来存储，比如方法目录、标准目录、设计目录、案例目录、治理评估---这样建目录。这里规定了跟企业架构相关的一些目录类型 * 架构框架 存方法 * 标准信息库 存标准 * 架构景观 存设计 * 参考架构 存案例 * 治理日志 存偏差 #### 32技术之5：架构工具（选工具) > 作为**预备阶段**的一部分，架构师应选择并实施能支持架构活动的工具。 Togaf并不要求或推荐任何特定的工具。对于选额架构工具来开发各种所需的架构模型和视图，togaf提供了一套建议的评估i保准。  主要的工具有：viso，sparkea （商业),ares（商业),archi(开源,opengroup推荐的建模工具，软件模型定义用uml较多，架构模型用archi，语言是archimate) #### 32技术之7：架构工作请求书 > 这是一份由赞助组织发给架构组织的文档，由它出发架构开发周期的开始。它是在架构组织的协助下，作为预备阶段的一项输出而被创建的。 架构工作申请书也可作为被批准的架构变更请求的结果而被创建，或是根据来源于迁移规划的架构工作的参考条目而被创建。  架构工作请求：是企业中谁来发起企业架构项目的一个方式和方法，以及双高：高层发起，高层赞助。 高层发起：任何业务部门/信息部门，不能以部门的名义发起企业架构的立项。能力发展规划，必须是管理层的代表发起。业务部门/信息部门是配合协同高层。 高层赞助：能力建设所需要拉动企业各方面的投资（流程建设、系统建设、数据治理、迁移等工作），都需要赞助，比如筹钱：出钱出力，尤其是人财物保障方面。必须高层赞助。 试想一下信息部门30%是信息部门发起的，就成了IT架构，不是企业架构，缺少了业务架构等。这样的后果是油水分离，业务和IT没有融合。 高层发起就不一样，高层可以推动信息部门和业务部门。业务部门之间，主责部门、相关部门协同进行能力的规划、业务的梳理。高层可以做到推动，部门之间无法做推动，一个部门一个职能孤岛，不会互相推动。一个部门是一个职能孤岛（传统封建文明告诉我们:组织结构定分工,职能部门做孤岛） 所以必须高层发起、高层赞助。面向核心能力做好顶层设计。 业务侧，项目当中，写出来的某一种说法，就是架构请求，牵涉到立项问题。不是部门立项，是高层立项。立项之时，作为能力建设的赞助者，承受不了投入，就不要做。能力建设，需要一定时期，人财物的保证，否则企业架构变成了画图，企业架构工作申请书可以类比于立项，内容建议如下： 1. 赞助组织（高层） 2. 组织使命的声明 3. 业务目标（包括变化） 4. 业务的战略计划 5. 时间限制 6. 业务环境的变化 7. 组织的约束 8. 预算信息和财务约束 9. 外部约束和业务约束 10. 对现有的业务系统的描述 11. 对现有的架构/IT系统的描述 12. 对开发组织的描述 13. 对开发组织可用资源的描述 #### 32技术之8：架构工作说明书：类比于实施方案 > 架构工作说明书作为阶段A的一份交付物被创建，实际上它是架构组织和架构项目赞助者之间的一份契约。这份文档是对输入架构工作请求书后的相应。它应当描述一份全面的计划，说明对架构工作有什么样的要求，并建议对已识别出问题的解决方案，将如何通过架构流程来进行开发。 至少包含：四个调研：总概细剖内视外查；两个文档：调研报告、分析报告；四个架构：BDAT；一个规划；一个治理。 每个工作项目可以用PPICTO--P背景、P目标、I输入、C成本、T是时间多长、O输出。来描述每个工作项目，就变成了实施方案。 对于一个架构团队，首先要写出来架构实施方案。如果写不出来，那么架构团队自身的工作能力就是架构工作的风险。  大概包含如下事项： 1. 工作名称的说明 2. 对项目的请求和背景 3. 项目的描述和范围 4. 架构愿景的概要或总体介绍 5. 管理的方法 6. 范围变更的流程 7. 各类职责和交付物 8. 架构被接受的标准和流程 9. 项目的而计划和时间表 10. 来自企业连续系列的支持（重用性） 11. 签署的正式批准
没有评论