这篇文章上次修改于 292 天前，可能其部分内容已经发生变化，如有疑问可询问作者。 #### 32技术之24：基于能力的规划 > 再阶段E和F中起到重要作用的是一种基于能力规划的原则、确定和规划企业转换的具体方法，这是一种聚焦业务成果的规划技术。它是业务驱动和业务导向的，它将各个业务线所需的力量结合起来，一道道企业期望的能力。它适用于大多数（甚至所有）的企业业务模型，尤其再需要具备快速响应的潜在能力（例如，应急准备单元),或相同的资源被投入到多种能力中的组织中有位有用。通常业务场景技术被用于发现和优化对这些能力的需要。  解读:它再E和F角度，让我们做发展规划的时候，是：面向能力交付，定好阶段划分。每一个阶段交付的能力叫一个过渡架构。我们在能力规划过程中，你要知道我们在做发展规划，和以前交付系统不一样，系统上，我们叫交付能力，靠能力的落地，能力的展现。那所以我们来看，在做规划的过程中，我们面向未来的能力，我们阶段性划分是一系列能力增量的达成。每一个能力，是我们这个阶段性达成某种能力的增量：要完成一些列项目的组合。所谓跨项目组合：因为每个能力既涉及到业务流程改造、还涉及到数据治理、还涉及到系统建设、还涉及到所依赖的平台建设 #### 32技术之25：迁移规划技术 > 阶段E和F中介绍了多种支持迁移规划的技术。下面各小节对这些技术进行了描述。 解读：迁移规划技术，主要是，面对迁移规划，我们需要做好四个参数的细化： #1. 时间进度规划 #2. 预算与投入规划 #3. 价值/目标规划 #4. 风险、保障规划 迁移规划技术，是在阶段性划分的条件下，每一个项目，都要细化的去做这个四个规划。迁移规划技术，在提交领域，又叫tcvr技术。t是time，c是预算，v是价值，r是风险。 ##### 32技术之25.1：实施因素评估和推论矩阵 > 创建实施因素评估和推论矩阵的技术在阶段E使用，用来记录影响架构实施和迁移计划的各种因素。矩阵应包括影响因素的列表、他们的描述和推论（结论），这些推论指出了制定计划是必须考虑的行动或约束。 示例矩阵：  解读：我们如何排号进度先后、衡量价值高低、识别预算多少、分析风险状况。 我们往往先有一个推论（我到底要实施什么，我有一个推论），通过推论去找进度先后、价值高低、预算多少、风险影响。 实施因素，就是我们要干的一系列实施行为，比如有什么样的流程建设、系统建设、数据项目、数据治理的项目、平台类的项目，都是实施因素。 推论：整个过程中实施因素会带来什么影响。推论后有利于我们对四个参数的细化。tcvr是得益于实施因素和推论矩阵的应用 ##### 32技术之25.2：整合差距、解决方案和依赖性 矩阵 > 创建整合差距、解决方案和依赖性矩阵的技术，使架构师能够将各架构领域差距分析结果中所识别的差距进行分组，评估可能的解决方案、以及一或多项差距件的依赖关系。 这个图表展现了一个例子。在创建工作包时，可将这种矩阵作为一种规划工具。识别出的依赖性关系将驱动阶段E和F中项目和迁移规划的创建。  解读:有了实施因素评估和推论矩阵的基础，我们就开始整合分析他们的依赖。整合差距、做好依赖分析。依赖意味着进度先后、价值高低、风险和投资者倾斜 ##### 32技术之25.3：架构定义增量表 > 创建架构定义增量表的技术，使架构师能够规划出一系列过渡架构，概要地描述出在特定时间点企业架构的各个状态。 应绘制类似如下表，列出各个项目，然后再各过渡架构中对其分配增量交付物。  解读：有了25.2，最后我们按照先后的规划，把我们每个过渡架构项目组合的计划情况做出来。把每一个过渡架构/某种能力所要完成的项目组合-----一般叫架构定义增量表，它回答了，某种增量过渡能力需要完成什么项目组合。 ##### 32技术之25.4：企业架构演进状态表 > 创建企业架构状态演进表的技术，使架构师能够使用技术参考模型（Technical Reference Model,TRM)来展示不同层面架构的建议的状态。 应当绘制类似下表，列出企业中用到的所有TRM中的付物，各过渡架构和建议的转换方式。应当描述所有SBBs的交付和它们对这些付物的影响。并且应对它们进行标识，以展示企业架构进展的过程。下面这个例子中，当已经达到目标能力时，将该SBB标记为“新增”或“保留”；当企业能力正过渡到新的解决方案时，将其标记为“过渡”；当能力被取代是，将其标记为“替换”。 示例：企业架构演进状态表  ##### 32技术之25.5：业务价值评估技术 > 这种评估业务价值的技术基于价值指标维度和风险指标维度来绘制一个矩阵。 如图，价值指标应当包括如与原则的符合、财务贡献、与战略的一致性，以及竞争地位这样一些标准。风险指标应当包括如规模和复杂性、技术、组织能力，和失败的影响这样一些标准。应对每一个标准分配单独的权重。 指标及其标准和权重应由高级管理人员制定并批准。在选定这些指标前，应寿险制定决策的标准，这一点非常重要。  解读：价值一定要分先后，分高低。预算一定要分出倾斜来、进度上分出先后来、风险性也要识别出影响来。这是一系列的。 ##### 32技术之26：实施和迁移计划 > 实施和迁移计划在阶段E和F被制定，它提供了实施过渡架构所描述解决方案的进度表。实施和迁移计划包括了时间、成本、资源、效益和实施的各里程碑。 实施和迁移计划的一般内容包括： 1. 实施和迁移战略 * 战略实施方向 * 实施排序方法 2. 与其他管理框架间的相互关系 * 使架构和业务规划相协调一致的方法 * 整合架构工作的方法 * 使架构和项目组合/项目管理 * 使架构和运营管理相协调一致的方法  解读；迁移规划技术，主要是四个参数的计划：时间、预算/投入、价值、风险。而最终的迁移计划作为一个结果，它应当充份展现从企业现状基线走向未来目标架构的一个提升问题，这样的话能更好的去推动我们的过渡架构及其能力的达成（叫做里程碑).每个内部要做的事情是工作包的组合，都是可行要完成的一些项目。 ##### 32技术之27：过渡架构（里程碑） > 阶段E定义了一个或多个过渡架构，并将其作为输出。过渡架构展示了企业的递增状态，反映了在基线架构和目标架构之间各过渡时间段。可使用过渡架构来对各个工作包和项目进行分组，组成一些可悲管理的项目组合和项目群组，以清晰说明每个阶段的业务价值。 以下使一个过渡架构中的典型内容： 1. 机会组合 * 整合的差距、解决方案和依赖性评估 * 对机会的描述 * 收益评估情况 * 能力和能力增量 2. 工作包组合 * 工作包的描述（名称、描述、目的、交付物） * 与机会的关系 3. 里程碑和过渡架构里程碑 * 过渡状态的定义 * 每个过渡状态的业务架构 * 每个过渡状态的数据架构 * 每个过渡状态的应用架构 * 每个过渡状态的技术架构 解读：里程碑在企业架构里面叫做过渡架构，里程碑也叫能力达成里程碑。过渡---使能力提升过程中设置中间点的一个问题。在我们努力过程当中，我们需要说清楚每个阶段到底有什么价值，要从对能力的达成性上去解读。每一个过渡架构意味着我们需要从业务上、应用上、数据上、技术上一个提升性的描述。这个过渡架构/能力，意味着我们在业务流程上有哪些流程建设、意味着我做了哪些数据的数据治理、意味着我做了哪些系统支撑/系统建设、意味着我们做了哪些平台的提升改造。里面都有它特有的内涵，要理解过渡架构/里程碑是以能力为导向的里程碑 ##### 32技术之28：实施治理模型 > 一旦定义了架构，就有必要规划如何在实施过程中对实现了架构的过渡架构进行治理。在已建立了架构职能的组织中，很有可能已经有了一个治理框架，但是具体的流程、组织、角色、职责和度量可能需要针对具体项目进行进一步的定义。 作为F阶段输出而产生的实施治理模型，确保了一个过渡到实施的项目也会平滑地过渡到适当地架构治理（对于阶段G而言）中去。 实施治理模型地典型内容包括： 1. 治理的流程 2. 治理的组织结构 3. 治理的角色和职责 4. 治理的检查点和成功/失败标砖 解读：治理，体现出我们如何把企业架构用起来的一个组织保障。它要求一个企业的信息部门必须做这四件事情：第一个，定政策：出红头文件；第二个，建组织，得有一个管理职能；第三个，明流程，明确流程，第四个，做考核。这些就是实施治理模型。基本上所有得治理模型都是这四个方位。我们信息部门要变成这样得一个部门。数据治理模型对于我们在G阶段实施治理得时候是一个组织保障。 ##### 32技术之29：架构契约 > 架构契约在阶段G：实施治理中被创建。架构契约是在开发团队和赞助者之间，就架构得交付物、质量和目标适用性达成得协议。  解读:当架构治理落地到每一个实施项目上，我们需要一个遵从性得章程，就是架构契约。每一个项目，立项的流程。每一个项目，在企业债务时代，业务需要一个遵从行的章程。它主要是我们的流程建设，不能违背整体能力发展的规划。不能违背业务架构；我们的系统软件开发不能违背业务架构；我们数据库的涉及及其数据的共享流转不能违背数据架构；我们技术路线的选取不能违背技术架构。一样的道理。治理架构契约，就是以契约的精神来推动我们企业架构对实施项目的一个管理问题。契约精神，蕴含着公平公正公开的思维。我们每一个项目事先要遵循：公平公正公开。不能事后出xx治理要求，事后出xx治理要求是违背契约精神的。契约精神都是事前大家公平公正沟通好的，有利于公开仲裁的。架构契约是治理职能面对实施项目之间的一个锲约化的模式。如每个项目立项，我们作为架构管控/架构管理人员，我们要拿出一份架构契约。告诉每个项目组，要遵从性贯彻什么。 比如：北京农商行企业的架构管理处，主要工作：项目立项--把这个项目整体的情况了解以下，给项目出一个架构契约，又名检查单。也会出台一个帮助项目组遵从的架构设计指南。总之就是检查大模式。  契约是一个增量补充，架构开发的时候，委托咨询公司做的架构，也叫架构合同，更多是一个架构开发。注意和架构契约区分，不要弄混了。架构契约是面向治理的。  ##### 32技术之30：变更请求 > 对架构变更的请求在阶段H：架构变更管理中被考虑。在架构的实施过程中，随着越来越多的事实被了解，初始的架构定义和需求有可能不再适合或不足以完成解决方案的实施。在这种情况下，实施项目偏离原有架构方法或请求扩展范围就变得很有必要。此外，外部因素===如市场因素、商业战略的变化和新技术的计划---也会创造扩展和完善架构的机会u。 在这种情况下，可提交变更请求以启动新一轮的架构工作周期。  解读：变更源于两个，一类是需求的变化；一类是治理的偏差。需求变了，能力需求不一样了，业务部门主动举手，对不起，我们新的能力需求和当时前两年做的能力规划不一样了。原来的面向能力规划，问题在于：企业架构当时做的总体架构设计，能力提升模式，还不如项目选的实施方案呢（有这种情况），我们已经变更，这里的变更有两种类型（两种输入).三种思路。两种类型：需求变化，重新打造一个全新的能力，增量变高。第三简单变更，纯IT，业务战略没有调整，能力没有追加，单纯是IT架构的调整，我们把纯IT架构的调整，叫做简单变更。如应用架构，原来是总线型，通过结构解耦，变成微服务模式。这是尊重能力主线的思维。 ##### 32技术之31：合规评估 > 一旦定义了架构，就有必要在实施的整个过程中对架构进行治理，以确保最初的架构愿景能被适当地实现，并且确保实施中所有地经验教训都能被反馈到架构流程中去。在阶段G中对实施项目进行定期的、一致性的审查，就提供了这样一种机制，确保了设计和实施的进行能符合战略和架构目的。  解读:合规评估既是行为，又是时代。我们的行为就是要确保企业架构有效反映到实施项目当中，有人去检查，是一个检查行为。时代表示，我们到了通过让实施项目遵从整体架构去打造新型能力建设的信息化时期了，这是一个时代。合规评估是一个时代问题，这个时候它会充份发挥原定治理契约的作用，把检查单有效的用起来，治理契约能规避合规评估的主观性，回到客观评估上来。合规评估是非常重要的，我们的目的就是推动信息化进入到合规评估时代，这是一个艰难的过程。我们积累了一套合规评估资产，什么方位，比如说需求分析材料、立项可研报告、系统架构材料、用户手册等一系列---怎么检查出跟企业架构的一致性。这是非常复杂的一件事情。其目的，让架构管理部门真的能够把各个项目通过合规评估往前去带，引领大家发挥追求整体架构的作用。 ##### 32技术之32：需求影响评估 > 在ADM的整个过程中，有关于架构的新信息在不断被收集。随着这些信息的收集，新的事实会显露出来，证明架构已有方面的不合理。一份需求影响评估表评估了现有架构的需求和规格，识别出了应该做出的变更以及这些变更的相关影响。需求影响评估的结果记录了对变更的评估以及对架构的建议。 需求影响评估的建议内容如下： 1. 对特定需求的引用 2. 需求的利益相关者的优先级 3. 需要被回顾的各个阶段 4. 确定需求优先级的阶段 5. 阶段调查的结果和修正的优先级 6. 对需求管理的建议 7. 引用存储库的号码，这些内容通常作为对变更请求的回应而被创建。 解读:需求影响评估是指在调研过程中，我们去各部门去收集了一些关于能力建设的一些想法。这时候，这些想法和业务架构有关、还是和数据架构有关、还是和应用架构有关、还是和技术架构有关？比如现在功能很多，系统很慢，应当通过平台建设提高系统性能，多引入云计算等---这是跟技术架构有关。这些就是需求影响评估，衡量这些架构的关注点，有利于我们再去做架构设计。所以需求影响评估，是识别我们业务需求跟我们架构关注点的关联性：业务/应用/数据/技术等。
没有评论