这篇文章上次修改于 306 天前，可能其部分内容已经发生变化，如有疑问可询问作者。 #### 32技术之12：业务转换的准备就绪评估 > **业务转换的准备就绪评估**这项技术在阶段A使用，用来评估并量化一个组织对接受变更准备就绪的情况。 推荐的活动包括： #1. 决定将会影响组织的准备就绪因素 #2. 使用成熟度模型来展现这些准备就绪因素 #3. 评估每个准备就绪因素的风险，并确定缓减风险的改善行动，将发现记录到能力评估的结果中，并在后续将风险缓减行动纳入到实施和迁移计划中去。  业务转换评估---是识别能力建设的可行性。我们在推动业务能力规划和建设，我们企业架构师面向能力的规划，必须对能力可行性做一下转换评估。企业有：生产能力、管理能力、服务能力、运营能力；这些能力，一个组织在面对能力规划的时候，它能承受的度不一样啊。就像拔高一样，有的人向上跳跃的时候，能跳出多高来，有的人只能跳一点。所以我们在目标架构所蕴含的能力增量应该是可行的。否则就存在一个风险，叫业务转换风险。 所有有两句话： #1. 立足转换找风险。 #2. 立足增量判可行。 这两个都是评估要做的。 比如一个企业要推动全球四大销售市场，销售部门的整合，以实现在客户共享，市场情报共享情况下，全球市场的精细化开放。这是一个能力建设，它可行吗。 #### 32技术之13：能力评估 > 专门把12项的能力评估提炼出来，在着手详细的架构定义之前，很有必要了解一下企业的基线baseline和目标能力水平。这些能力的评估将寿险在阶段A进行，并在阶段E进行更新。 面向能力的，能力提升的可行性。面向增量判可行。这就叫能力评估。企业的基础能力越强，面向能力提升的弹跳力就越强。就像普通的小孩，走路都不稳呢。你让他学会跳舞，可能吗？ 所以说能力评估，有两个维度的作用： #1. 哪些能力可行，适合做优化。 #2. 优化的能力，能优化多高。 能力评估是，宽度看多少，高度看增量。 宽度是我有多少能力适合做优化的，优化能优化多高多低。先是宽度找范围，然后看下这些能力单元增加多少，增量高低。 能力评估用在我们做业务架构的时候。或者用在我们做能力愿景考究的时候，重点是用在我们做能力愿景/架构愿景考究的时候： **架构愿景重点描述的是：高层的授权、部门的支持、下属的宣贯和能力愿景。** 嗨哟啊看下能力是否太多，太多的能力，也无法转化；还有能力提高的量是否可行，贪心不足蛇吞象。 * 企业的整体能力水平怎样的? * 企业希望在哪些方面增强或优化能力？ * 架构聚焦的哪些领域将支持企业所期望的能力建设 #### 32技术之14：风险管理 > 业务转换风险及缓减活动的识别寿险在阶段A被确定。风险管理在TOGAF9第三部分描述，它是一种在实施架构项目时用于缓减风险的技术。它包括一个由以下活动组成的风险管理过程  解读: 风险管理是企业架构总师，在我们企业架构整个这个能力规划过程中，应建立起来的风险管理环思维。 风险管理思维包括五步一环--五步：1识别、2度量、3量化、4权衡、5应对。一环：循环开展.总结为：1识2度3量4称5术6循环。 企业架构总师，带领别人，引领别人去突破的时候，要有风险意识。没有风险管理，要么是壮士（没死），要么是烈士（死了）。 通过风险管理，可以使自己运筹帷幄，决胜千里。风险为什么要循环的去做呢，古人说：安知千里外，不有雨兼风。你往前走一段时间，可能出现的情形，照样蕴含风险。 1识，把风险找出来；2度，把严重的风险挑出来；3量，把严重风险的影响识别出来，量化以下；4称，看下积极的和消极的，如果积极的大于消极的，不要管它，这是好事，风险要养，否则就要应对。5术，应对之策，如何应对这个风险。用学术来讲：叫风险识别，定性分析，定量分析，风险应对与规划，风险跟踪与监控。 #### 32技术之15：架构定义文件 > 架构定义文件是项目过程中创建的核心架构制品的可交付物容器，这份文档跨越了所有的架构领域（业务、数据、应用和技术），并检查了架构的所有相关状态（基线状态、各过渡状态和目标状态）。它首先再阶段B被创建，最初只包含与业务架构相关的制品，解下来在阶段C被更新加入信息系统架构的制品，接着在阶段D被加入技术架构的制品。  解读： 架构在我们梳理过程中，需要形成正式的交付物。架构定义从文档角度是必须要输出的。它将通过我们领导层这样的班子会议进行介绍，另外要向全系统有关业务部门、下属单位进行宣贯说明。 架构定义文件时非常重要的交付物，一般是：原则、架构、（后期）指南这三个要素。 原则：我们企业架构是传承什么原则做出来的，原则又称总体策略。 四个架构：从说法上：业务架构---业务梳理及其梳理成果，因为它推动了以能力为导向，业务驱动的工作成果，是相关业务口，在我们的积极协助下，梳理出来的成果---有现状的还原、面向目标的优化。 数据、应用、技术---是我们能力规划的塑造。 再往下是指南，指南是遵从性的规则和治理管控的应用：在某个条件下我们应该如何去做，用来作为信息化治理依据。我们需要说明到底我们通过怎样的治理方式，让大家用起来。 发展规划，不在这里体现，单独出。 这里就是企业架构，文件怎么写，原则、架构、指南。 #### 32技术之16：架构需求规格 > 架构需求规格提供了一套量化的声明，概要地说明了为了符合架构，实施项目必须做到什么样的程度。架构需求规格一版回城未 一份实施契约或更详细的架构定义契约的组要组成部分。 如上所述，架构需求规格是架构定义文件的伴随物，它对架构定义文件进行了补充，提供了定量的视图。 架构需求规格通常包括以下内容: 1. 可进行有效测量的测度（Success measures） 2. 架构需求 3. 业务服务契约 4. 应用服务契约 5. 实施知道原则 6. 实施规格 7. 实施标准 8. 可互操作性需求 9. 约束 10. 假定 解说： 我们如果针对一些平台化，或一些专题做总体设计，这种总体设写出来的是企业架构版的需求规格。这里不是面向某个业务能力了，是面向平台（不管那种类的平台），我们写出来就是企业架构版的需求规格。它有利于招标和推动总体建设之用。 比如某河北省某企业提出，我们要开阵投资一个6000万的一体化集成平台，实现数据集成、流程集成、身份集成、功能集成这样一个平台。我们来开展相应的总体设计，利用企业架构来帮助我们做出一套企业设计来，有利于我们的建设支持，能实现总体的目标明确、内涵明确 面向业务能力叫架构定义，面向某种平台做总体设计叫架构需求规格，叫企业架构版的架构需求 你要从业务、应用、数据等这种架构维度来描述和衡量。 同样是企业架构思维，面向能力规划出来的相对比较抽象；那么我们面向平台，设计出来的相对比较具体。如果对比而言，架构定义文件和架构需求规格哪一个更有利于遵从和实现：架构需求规格。这也告诉我们，企业架构可以面向能力做架构定义，也可以面向平台做总体设计。 #### 32技术之17：架构路线图 > 架构路线图列出了变迁的各个增量，并把他们放在一条时间轴上，展示了从基线架构面向目标架构的演进过程。架构路线图是过渡架构的而关键构建，并在ADM从阶段B到阶段F 的过程中，以增量的方式被开发。 以下是架构路线图中包含的典型内容：  解说： 架构路线图是棉线架构迁移描述出来的进而紧致的极端路线图。那么在这个过程当中，我们主要有一个主线，两个要素。 一个主线叫阶段划分，两个要素，一个要素叫做每个阶段的内部过渡架构，过渡架构是整个阶段要达成什么过渡架构，过渡架构呢，其实就是我们规划中要建设的能力。一个叫项目组合，能力当中有什么项目。这个业务架构或者这个能力实现：在业务上搞什么项目、在数据上搞什么项目、在应用系统建设上搞什么项目、在平台推进上搞什么平台项目---这就是项目组合，这些组合有利于我们能力的达成。整个路线图当中体现这个脉络：我不关注具体的时间，我关注阶段的划分：第一阶段、第二阶段、第三阶段。。。第五阶段，一般十三五，正好是5年，每年达成什么业务能力，能力当中有什么项目需要干，就是我们的路线图。 路线图中最重要的就是过渡架构：我知道，每一种能力，根据能力的布局，我应该怎么先后建设。 #### 32技术之18：业务场景  一、 对于识别和阐明隐含在新的业务功能中、满足关键业务驱动力的业务需求，以及隐含的架构需求 二、 业务场景是对业务问题的一种描述方式，使需求能够在整个问题的上下文中，在彼此的关系中被看待。 三、 如果缺乏对于背景的描述，解决问题带来的业务价值就会不清晰。业务场景就是一种帮助识别和理解企业业务需求的重要技术。 解读: 业务场景技术使用双流合一来描述交互： 业务流看逻辑、数据流看数据----双流合一，描述我们业务能力与其他上下左右环境要素是怎么业务逻辑上的交互以及数据上的交互。逻辑交互一般是箭头，数据交互一般是交互的对象，最能体现出双流合一来。业务场景就是双流合一定义业务交互。目标业务能力对象与相关业务对象的交互问题。业务流+数据流描述交互，既有箭头，又有内容。如果只有箭头叫业务流，加上数据呢，叫数据流描述：中间是目标能力对象，然后和相关要素制定的交互关系。 #### 32技术之19：差距分析 > 差距分析技术在ADM周期中被广泛的应用，用来验证正在被开发的架构。它通常是一个阶段的最后一个步骤。其基本的出发点是强调基线架构和目标架构之间的差异，即被故意忽略、意外遗漏或尚未定义的条目。 其步骤如下： 1. 绘制一个矩阵，将其所有基线架构的架构构建块（ABBs Architecture Building Blocks) ，放在垂直轴，所有目标架构的构建块（ABBs）放在水平轴。 2. 在基线架构轴的最后一行增加一行，标示未“新增的架构构建块”，在目标架构轴的最后一列增加一列，标示为“除去的架构构建块”。 3. 如果一个架构构建块同事存在于基线架构和目标脚骨中，在交叉单元格将其标记为“已包括” 4. 如果基线架构中构建块ABB在目标架构出现缺失，检查每一个缺失的ABB。如果缺失应该将其出去，在“除去的架构构建块”列合适的单元格中对齐进行相应记录。如果不该将其出去，这样就发现了目标架构中意外遗漏的ABB，在“除去的架构构建块”列合适的单元格中对其进行相应记录，这些被遗漏的架构构建块必须在架构设计的下一轮迭代中被回复并进行处理。 5. 当某个目标架构中的ABB没有出现在基线架构中时，在该构建块所在列和"新增的架构构建块"行的交叉单元格上将其作为差距进行标记，这种差距需要通过开发或外购该构建块的方式进行填补。 当完成上述步骤后，所有出现在“除去的”列或“新增的”行中的都是差距，这些差距要么解释为应该被除去，要么被标记出来，以便进行恢复或开发/采购其功能。  解读： 差距分析是识别我们工作包的一个过程。工作包和项目的区别：工作包通过可行性研究、解决方案优选后才能变为项目。在未来我们差距分析的结论上来讲：直接分析工作包，间接分析选方案。只有是我们的工作包，并且有方案的我们才能立项。差距分析，我们面对的是缺口，缺口体现为我们目标与现状之间的一个比较，往往呢，我们会绘制一个差距分析矩阵：把现状中有什么、目标中有什么，我们把要素描述为构建块，它是一种面向对象的思想，我们有哪些构建块，还缺少什么构建块，哪个构建块需要加强。找到一些“缺” 与“弱”的这两类要素。 如果说现状已有目标，认为已经满足，说明我们就用继承，没什么可做的。如果现状没有，目标中有，说明时缺，缺一个构建块。现状有，目标中认为需要升级得，这个叫弱。也是一种差距。还有一种叫重：现状中有相关多个，在目标中集约化统一了。 缺弱重，比如现状中我们我们是总部部门，下属各单位都有人力资源系统，到目标应用架构当中，发现总部集约统一化了，这是一个集约化改造，重的问题。缺/弱/重就是我们将来要干的事情：一个是全新建设，一个是升级改造，一个是集约化建设。 #### 32技术之20：架构视点 > 架构师在ADM周期从阶段A到阶段D的各个阶段中，使用视图和视点来开发每个架构领域（业务、数据、应用、技术）的架构。视图（VIew）是你看到的东西。而视点（ViewPoint）是你从哪儿看；即决定你看到什么有利位置或角度（一个视点也可以被认为是一种范式）。视点是通用的，可以存在视点库中供重用。视图对于它位置被创建的架构来说总是具体的。每个视图有描述它的相关联的视点，哪怕该视点是隐含的。 解读：架构视点，是在我们架构设计之前，它的一个共识化管理的问题。我们有很多干系人，当干系人提出很多关注点的时候，企业架构师是按照共识做架构设计，还是按照共识加分期做全集架构设计。 比如：财务部门和经济管理部门，两个部门掰扯的优点不一样，它俩似乎在某些通用能力，具体的业务场景上有些矛盾，怎么办？一般矛盾可以做成多套可选的架构；一般共识可以做成统一的架构。所以架构视点是---共识化的企业干系人关注。它告诉我最佳实践，比如财务部门、人力部门、营销部门、物价部门、设备部门，你看看大家没有冲突的有哪些，找出来，就是架构设计直接需要满足的所谓的需求空间，这种需求叫架构视点空间。 那为什么不都满足呢？那还是一个共识驱动问题，因为共识代表大家接受，不接受的不创建，先接受后创建。针对有冲突，该行关注点的不同业务口，他们的关注点有很多冲突怎么版？你需要用一套原则去引导，看能不能化解，如果化解不掉，仍然矛盾重重。那应该是你没什么架构可以做的，这事你要暂停。如果能化解，之后能形成共识空间，仍然可以努力。这就是架构视点的作用。 #### 32技术之21：架构视图 > 架构视图表现了整体架构，对系统中的一个或多个利益相关者来说具有意义。架构师再ADM周期从阶段A至阶段D的过程中，选择并建立了一套视图，以便可以通所有的利益相关者沟通架构，使其理解架构，并使他们能够验证系统将解决他们关注的问题。 ##### 在ADM中建立视图 架构师必须做出得关键决定之一，就是决定开发哪些特定的架构视图。 架构师有责任确保架构的完整性（适合使用），即能充份解决其所有利益相关者的关注问题；以及架构的一致性，即能将各个不同视图联系起来，圆满地协调不同利益相关者之间存在冲突的关注点，并展示在协调过程中所作出的权衡（例如在安全性和性能之间）。 解读：架构视图是指按照架构视点所完成的架构设计。 架构视图有三种形态： #1. 一维目录 #2. 二维矩阵 #3. 三维图形 比如应用模块，对业务能力要素的覆盖：一个是业务能力要素，一个是应用模块。那么必须使用二维的矩阵。就是架构视图。 三维就叫图形了 架构视图尤其注重的是，架构师在做的过程中，尤其注意哪些要做出架构视图来，基本点是：有冲突的不碰，没有冲突的去做。所以要能圆满的协调不同概念之间存在冲突的关键点，在协调过程中，做出的权衡必须有利于共识化的接受做出的图。这就是架构视图，有时候做出个目录，拉个列表，有时候做个关联矩阵，有时候绘制一个上中下左右，相关关联的一幅图 #### 32技术之22：架构构建块 > 架构构建块是架构的文档描述和模型，来自于按照架构连续系列进行分类的企业架构存储库。它们在ADM的过程中（主要在阶段A、B、C和D）被定义或选择。 ##### 架构构建块有类似于组件、构件的特性，其特点如下： * 他们捕获了架构需求：例如业务、数据、应用和技术需求。 * 他们指示并指导了解决方案构建块（Solution Building Blocks，SBBs)的开发。架构构建块规格的内容至少应包括以下内容： * 基本的功能和属性：明确的语义、包括安全性和可管理性 * 接口：被选择的集合，提供的接口（API、数据格式、协议、硬件接口、标准） * 可互操作性，以及和其他构建块之间的关系 * 所依赖的构建块，及其必需的功能和已命名的用户接口 * 与业务/组织实体和政策的映射关系 每个架构构建块应包括一份对于企业架构存储库中任一架构文档和模型的声明，以便在架构开发中可被重复使用。使用ADM建立构建块的规格是一个循序渐进和迭代的过程。 解读：构建块=一个视点+相关图形的封装统称。构建块有点类似面向对象的思想，在面向对象的模式的思想下，有利于把架构设计成果封装为一种设计资产。可以方便再架构过程中快速的集成和重用，也是提高设计效率、效果和质量的一种方式。 架构构建块---能够单独面向关注点，比如单点登录，门户聚合，怎么体现门户当中客户身份的聚合--画一张图，怎么体现功能聚合---画一张图，信息聚合---画一张图、应用聚合等，另外怎么体现基于商务数据仓库能实现全局数据资产共享。从某种层面讲，架构构建块能够很好的形成企业架构的资产库，有利于重用 #### 32技术之23：解决方案构建块 > 解决方案构建块SBBs与解决方案连续系列有关，他们是企业架构连续系列中被识别出的各个架构的实现，可以被外购或开发。 解决方案构建块首先出现在ADM的阶段E,在第一次考虑特定产品的构建块的时候。解决方案构建块定义了什么样的产品和构件将实现所需的功能，从而定义了实现方式。他们满足了业务需求，与具体的产品或供应商相关。 解决方案构建块，至少应包括以下内容： * 具体的功能和属性 * 接口：被实现的集合 * 被使用所必须的解决方案构建块及其所有所需的功能，所使用接口的名称。 * 从解决方案构建块到IT布局和运营策略的映射 * 共有属性规格，如安全性、可管理性、可定位性、可扩充性 * 性能、可配置性 * 设计的驱动和约束，包括物理架构 * 解决方案构建块和架构构建块之间的关系 解读：我们作为一个技术提供商，在产品规划的时候，我们也可以利用这个相应的思维来进行封装，把解决方案跟甲方的关注点封装---就叫做解决方案构建块。一般来说，是一个视点+相关方案==解决方案构建块。注意和架构构建块区分（一个方案+相关视图）。一个是实现相关的，一个是实现无关的。一般甲方会关注把自己的设计变成架构构建块，乙方把自己的设计变成解决方案构建块。架构构建块叫ABB，解决方案固件快叫SBB。乙方要多沉淀解决方案构建块，这样面对不同企业的企业架构，在进行产品解决方案选型的时候，能够更改好的识别自己的市场。 SBB也是以视点为导向，做好封装。甲方和乙方是基于视点来衡量解决方案是否可选的思维。这样的话，有利于我们去匹配：当我们行业内部，我们SBB和ABB都以视点作为通用的沉淀、封装。 当我们招标和比选选型的时候，就能很好的进行结构化的比选了。这是一个引领双方共同推进的事情。解决方案也可以作为资产，但是按照甲方视点进行封装
没有评论