【分层策略】分层应用策略和IT组织设计：如何构建成功应用团队

最新推荐文章于 2022-05-24 17:59:33 发布

小雨青年

最新推荐文章于 2022-05-24 17:59:33 发布

阅读量2.4k

点赞数 1

分类专栏：领域驱动设计DDD 文章标签：分层策略 DDD

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.csdn.net/diandianxiyu_geek/article/details/103423708

版权

领域驱动设计DDD 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Gartner的Pace-Layered Application Strategy使IT组织可以根据业务需求构建一些用于快速更改的系统，而其他一些则用于稳定性。我们将探讨CIO如何组织其应用程序团队，以利用步调分层的概念。

关键挑战

各地的IT组织都迫切需要在选定的业务领域中更快地交付系统。
组织应用程序团队进行速度分层提供了一种方法，可以在需要它的区域提供速度，同时在最重要的区域保持稳定性。
尽管没有“一种方式”来组织应用程序团队（或任何团队），但中心辐射模型最适合大多数按节奏划分的应用程序团队。
交付创新系统的人员（最注重速度和变化的系统）可能位于IT部门内部或外部。如果他们住在外面，新兴的首席数字官（CDO）将越来越扮演提供创新系统的角色。

介绍

组织设计的黄金法则是围绕要优化的内容进行组织。对于Gartner的“分层式应用程序策略”，应用程序团队正在尝试优化以交付具有不同变化率的系统，以便IT组织可以缓慢而稳健地交付某些系统，而快速而灵活地交付其他系统。这项研究的重点是Gartner认为应该将步伐分层的应用程序团队组织起来。

组织起搏层意味着以不同的速度交付

放下手，当今IT部门面临的最大问题之一是速度问题。 IT必须更快地满足业务需求。但是在所有系统中交付速度并不是普遍必需或不希望的。 CIO需要了解需要快速交付和变更的系统与不需要快速交付和变更的系统之间的区别，并且他们需要围绕每个系统进行组织。输入Gartner Pace-Layered Application Strategy，该策略将根据应用程序更改的速度对应用程序进行分类。

在“如何使用速度分层来开发现代应用程序策略”中，我们定义了速度分层：

记录系统-支持核心事务处理并管理组织的关键主数据的已建立的打包应用程序或旧式本地系统。变更率很低，因为这些流程已经建立并且对于大多数组织来说都是通用的，并且经常要遵守法规要求。记录系统的生命周期最长，为10年或更长时间。
差异化系统-支持独特公司流程或行业特定功能的应用程序。它们的生命周期中等（一到三年），但是需要经常进行重新配置以适应不断变化的业务实践或客户要求。
创新系统-临时构建的新应用程序，用于解决新的业务需求或机遇。这些通常是使用部门或外部资源以及消费者级技术的短生命周期项目（零至12个月）。

为应用程序团队构建层级应用程序策略意味着要组织快速交付某些事情，而缓慢地交付其他事情，而随之而来的是治理，需求流程，文化和开发方法方面的所有差异。有关各层之间的主要差异，请参见图1。

属性	记录系统	差异化系统	创新系统
变革的步伐	缓慢，不频繁和增量。每六至十二个月更换一次。	中度且更频繁。可配置性是关键。每三到六个月更换一次。	快速，非常频繁且特别。 “一次性”定制。每周更改，有时每天更改。
生命周期	10年以上	1到3年	0到12个月
计划范围	7年以上	1到2年	最多6个月
治理模式	正式的和全局的	反应灵敏且以业务为主导	灵活而特别
利益相关者/所有权	高级企业主管的参与; 业务与IT战略之间的一致性。低端用户的参与，并从业务到IT正式交接。	高业务主管的参与度，但受业务范围的驱动。最终用户的参与度适中，业务参与热点，而IT填补了空白。	适度的业务执行人员参与，并得到一些赞助商的支持；战术上的。最终用户的高度参与，通常是通过业务用户甚至是规避IT来实现的。
资金	资本支出（资本支出），以及相应的运营支出（运营支出）。公司或部门资金。年度预算。	资本支出和运营支出的混合。公司IT预算或部门支出预算。全权委托。	主要是运营支出。部门支出预算。创新基金。
架构	大型的模块化设计以正式的前期蓝图阶段为主导。	面向服务的体系结构（SOA）和基于云的服务，包括服务使用者和生产者。通过组装新的和现有的打包及自定义应用程序来增加复合应用程序的使用	轻巧而新兴的服务于消费者。移动和云为主。
应用程序生命周期管理（ALM）方法	瀑布接近（有时间限制）为70％。交互式和增量开发（IID）达到30％。	瀑布接近（有时间限制）为40％。互动率和IID为50％。敏捷和精益方法论占10％	瀑布接近（有时间限制）为10％。 IID为30％。 60％的敏捷和精益方法论。

大多数应用程序团队仅通过默认所有系统的最慢方法（即记录系统方法）来避免以可变速度交付的问题。如前所述，这种策略不能长期有效，因为随着越来越多的数字业务机会，与记录方法系统相比，业务需要更快的速度。数字营销活动，众包竞赛和许多移动应用程序都是创新系统的示例，如果采用记录系统的方法，创新系统将遭受损失。

分析

本文档的某些部分基于历史信息；但是，最重要的最佳做法仍与领导力的发展阶段有关。

轮辐模型最适合按步调应用策略组织的应用团队

这里的中心问题是：“鉴于各层之间文化，开发方法，技能和方向的深刻差异，应用程序团队应如何组织以交付记录系统，差异化系统和创新系统？”

正如我们在“应用程序组织设计：概述”中指出的那样，很少有“一种方法”来组织应用程序团队。当理解和评估时，只有一组权衡可以计划和/或防范。但是，有一些驱动程序会迫使组织以一种或另一种模式（筒仓，系统集成商或工厂）进行设置。围绕速度层概念进行组织就是其中之一，因为速度层在各层之间具有根本不同的治理流程（请参阅“用于治理和变更管理的分层应用程序策略”），并且速度层专注于业务流程，而不是任何特定的商业组织模型。

CIO需要一种组织方式，以保持各层之间的一致性，同时留出足够的距离，以使创新系统，差异化系统和记录文化系统独立发展。 Gartner认为，实现这种微妙平衡的最佳选择是轮辐式组织模型。

通常，在中心辐射型模型中，有一个中央资源团队专注于在所有业务组之间共享（或应该共享）的通用应用程序。通过使用速度层，我们会将其扩展到具有通用治理，计划和管理功能的应用程序。围绕“ Pace-Layered Application Strategy”组织的应用程序团队从该中央团队或中心提供记录系统。这类似于Gartner的“运行”，“增长”，“转换”模型（其中差异化系统大致等同于“增长”，而创新系统则等同于“转化”）。

记录系统是创新系统和差异化系统所汲取的枢纽

这种结构的中心支持记录系统。该小组支持以相对可预测的变化速度使业务流程自动化的应用程序。这并不意味着没有资金分配给这些应用程序或它们对业务不是至关重要的（例如，工资单是由记录系统自动化的，并且肯定是关键的业务流程）。这确实意味着变更通常针对成本优化或效率，这有助于制定可预测的长期财务计划。

该组可以由任何主要组织类型（筒仓，集成商和工厂）组成，并且可以完全是内部，外部或两者的组合。该中心围绕应用程序交付过程的成本优化进行组织。集线器并不意味着从辐条到集线器的报告线，而是一个可以从中抽出辐条的公共平台（请参见图2）。

在这里插入图片描述

集线器还负责在各层之间提供连接组织。鉴于各层之间的治理存在深层差异，我们建议每个步伐层分别报告，并且没有层报告到另一层。有一些问题，我们在下面概述。本质上，无论一个创新系统小组是向CIO还是向企业中的其他部门报告，关键的事情是面向客户的差异化应用程序应位于一个团队中，并且该组不能在应用程序之间共享。

Gartner在“我们所知道的瀑布的尽头”中警告要在同一团队中使用不同的流程，尤其是因为敏捷和瀑布式（或迭代式）方法之间的主要文化差异。这些应用程序通常还需要专门的业务技能集，而这些技能可能无法在各个业务组之间共享。

分离模型各层有四个关键问题：

首先，大多数组织将无法放弃其当前的应用程序组合，并且许多应用程序跨越各个层次，尤其是在记录系统和差异化系统之间。这使得很难确定哪些应用程序适合哪个组织。实际上，可能需要重构现有的应用程序，以便某些部分可以成为记录系统，而另一些可以成为差异化系统。
其次，很多时候，各层之间将需要大量集成，因此，连接组织和设计合理的阈值的重要性。例如，开发人员需要知道在体系结构遵从性方面的限制。
第三，大小很重要。如果整个应用程序组很小，则不可能以中心辐射状模型进行组织。
最后，应用程序将根据其支持的业务流程的移动而在堆栈中移动。这就需要一套功能更强大的体系结构标准和文档，这些标准和文档在各层之间是一致的。这意味着，如已指出的更改，将需要在中心和分支之间传递应用程序交付和支持。

创新系统和差异化系统需要与他们服务的业务组更加紧密联系

创新系统和差异化系统的治理与记录系统的治理显着不同，后者更多地侧重于灵活性和速度，而较少侧重于可预测性和可控制性（见图3）。

	记录系统	创新系统	差异化系统
应用程序组合管理	评估成本，风险和业务适合性	评估是否仍然分化	评估是否准备好产品化
项目和项目组合管理	优先考虑业务需求和ROI	优先考虑业务战略需求	优先考虑机会
人员配备，技能和采购	专注于可靠，经济高效的交付	专注于业务知识和速度	专注于实验设计
财务分析与预算	专注于可靠，经济高效的交付	随着项目的进展按预算进行迭代	风险资本式融资回合
体系管理	确保数据和流程的完整性	利用记录系统和新流程	尝试新技术和新结构
软件流程	主要是瀑布（有时间限制）	主要是增量和迭代	大多敏捷
运营与支持	严格控制的变更管理	每个系统的流程简化	团队控制“杀戮开关”
供应商管理	大型稳定的巨型供应商	同类最佳，BPMS和复合应用程序	无论如何
商业参与	正式流程	日常参与	做许多工作

通常，差异化系统应在IT组织内部进行报告，因为许多差异化系统实际上是较大记录系统的一部分。整个工作需要各层之间的高度完整性。

创新系统并非总是如此，在某些情况下，创新辐条系统可以而且应该位于IT组织外部。当IT组织没有深入的业务知识或复杂的需求管理时，尤其如此。

如果IT组织对以下两个或多个问题的回答为“否”，则创新交付系统可能会正式或非正式地驻留在IT组织外部：

IT能否以创新的步伐交付系统？例如，应用程序团队是否设置为在不到六周的时间内一致且重复地交付系统？
当出现新想法时，IT组织与企业的距离是否足够近以能够出现？例如，IT开发人员是否定期参加正在讨论新概念和想法的会议？
影响企业业务模型的技术破坏深度是否如此之大，以至于业务模型本身受到威胁？换句话说，它的收入来源或任务是否由于数字化而受到迫在眉睫的威胁，例如报纸或旅行社的收入？
如果IT对以上两个或多个回答“否”，则创新交付系统的大部分机会将嵌入业务部门，而不是中央IT组织。

在中心和分支之间建立明确的阈值

无论创新系统在哪里报告，都必须在与保持后台运行相关的控制和风险管理实践以及与前台相关的机会主义，以收入或任务为中心的文化之间保持距离。这意味着在轮毂和辐条之间建立阈值，以了解哪些是必需的，哪些不是必需的。建立的最重要的阈值是数据完整性和过程完整性。

关于这些阈值，有几个方面需要注意。首先，应用程序团队需要能够依靠成熟的体系结构来阐明阈值。在这种情况下，“成熟”是指一种架构，该架构反映了有关需要在整个业务（枢纽）中共享和共享的元素以及需要区分的元素（辐条）的一致且被接受的观点。

要牢记的一个好的经验法则是，标准化本身并不会带来普遍利益，差异也不是。旨在标准化商品流程，这是差异化不会给企业带来任何回报的业务领域。这是通过使用集线器作为通用标准平台的记录系统方法来完成的。在这种情况下，数据和流程完整性的阈值非常高。

同样，在差异创造价值的领域，例如在差异化系统和创新系统中，要允许差异化的流程和系统。在区分系统中，通常仍需要过程和数据完整性来确保整个系统的一致性。但是，负责整体差异化系统的团队在组织上是分开的，他们使用不同的方法，时间表和治理来实现其业务目标。

创新系统连接到其他层的阈值通常在数据中，而不是过程中。例如，针对数字营销活动的创新系统可以使用不同的流程，非企业供应商，敏捷方法或新的融资模型，但是创新的最终系统几乎应该始终能够从主客户数据中获取信息。换句话说，为了保持创新系统的变化率，您可以容忍从一个业务部门到下一个业务部门的重复解决方案，但不能重复数据。

了解业务需要标准化以及需要差异化的地方是了解创新系统，差异化系统和记录系统之间需要多少完整性的第一步。

组织差异化系统来交付产品而不是项目

对于大多数组织而言，衡量，管理和交付的容器是一个项目。项目交付新功能，或逐步修改功能，或两者兼而有之。如前所述，在许多组织中，企业内部对项目驱动的资金的不满程度日益提高。

在“特立独行研究：从项目到产品的转变将推动应用程序组织的重大变化”中，我们提出了一个不同的比喻，即应用程序成为支持全部或部分业务流程的产品。在基于项目的组织中，工作是按时间片分配的，称为任务。可以根据个人的可用性将其分配给多个应用程序。该项目是中心组织原则，而不是应用程序。在基于产品的组织中，创建了个人团队以长期支持产品或产品组。当然，人们来来往往，但有两点要记住：团队的任务通常很长（超过18个月），并且通常是全职的。团队成员可以处理多个任务或功能，但是它们在团队中，而不是多个项目和多个经理。这有助于对应用程序团队内的业务流程进行更深入，更一致的理解。

由于步调组织中的重点是支持业务流程的应用程序或产品，并且差异化系统和创新系统需要更灵活的治理实践，因此它们适合这种产品视图，在该视图中，计划和交付侧重于将在产品的下一个版本中（或尽快）将产品的次要关键业务功能纳入产品。

本质上，这里的需求治理是在业务流程级别上。每年，都会为该过程制定预算。通常，与此预算相关联的还有一组主要业务功能，可以映射到版本中。如果在一年中的任何时候出现了对差异化或创新至关重要的新功能，则可以将该功能放入适当的版本中，而无需等待一组项目完成。记录系统不需要这种更精细的需求管理。这对于差异化系统和创新系统至关重要。而且，由于这些变化发生得相当迅速，因此大多数差异化系统或创新系统将使用敏捷或紧密迭代的方法来交付。

在您的各层中建立良好的需求治理，以实现组织一致性

在“应用程序组织的四个支柱”中，它讨论了运行良好的应用程序组织的四个要素，第一个关键支柱是需求和关系管理。任何组织结构要想成功，必须首先考虑这个支柱。应用程序组织结构应与业务运作方式相匹配。如果整个企业有灵活的需求并且只有一个预算池，那么系统集成商结构将是最佳的选择。如果每个企业都有自己的预算，那么就很合适。步调层的组织通常专注于流程孤岛（也就是说，每个业务流程都有一个或一组应用程序对它们进行端到端的自动化和优化），而很多企业却没有。

试图以不同于业务合作伙伴的方式构造自己的组织的组织通常会遇到失败，除非他们采用非常结构化的方式来管理需求和关系管理。换句话说，他们需要在其运营模型中明确解决需求和关系管理方面的差异。由于业务组可能会使用驻留在多层中的应用程序，因此可能需要从管理结构中拉出需求治理和关系管理以实现此解决方案，并在业务组及其应用程序对应方之间提供单一联系。例如，用于应用程序交付的其他集中式操作模型将具有明确的，分散的需求管理器，与业务部门或部门保持紧密联系，以反映部门的更自主的操作方式。在许多方面，这就像我们在“应用程序组织设计：内部系统集成商”中描述的那样。
此外，组织需要在其治理实践中具有基本的成熟度，才能使任何组织结构正常工作。在“应用程序组织的ITScore概述”中，Gartner列出了必须考虑的八个学科类别。学科不会在有节奏的组织模型中发生变化，但是为满足这些学科而执行的特定活动将会改变。实际上，一个成熟的应用程序组织具有一组定义明确的过程，可以根据需要从中进行选择。

如前所述，治理实践将根据所支持的层而有所不同。基本成熟度（第3级或接近3级）对于使进度层正常工作至关重要，因为治理将使这些相对独立的团队聚在一起。对于迁移到步调分层的组织模型而言，这并不是特别特定。如果治理不好，那么在任何模型中都无法很好地管理。

共享组织方面的内容以在层之间创建连接

与我们一样，许多人会注意到该模型已经过尝试过。在某些情况下，它工作得很好。在其他情况下，没有那么多。在“分层应用程序策略”结构中进行管理的能力基于对业务流程和支持它们的应用程序的理解。因此，通用且结构化的业务流程和应用程序架构至关重要，尤其是在短期内，在这种情况下，组织通常会将混合在一起的应用程序和流程混合在一起，但意义不大。在整个业务中，这种通用视图对于避免过去尝试中出现的混乱状态至关重要。有关层之间的连接组织的更多信息，请参见“用于步速应用策略的连接技术”。

结论

IT组织迫切需要解决其流程和运营模型中的速度问题。具有节奏的应用程序团队是迈向更高速度的一步，因为它使IT组织能够围绕不同业务流程所需的不同变更率进行组织。创新团队的系统可能不一定位于IT组织内。但是，即使不这样做，也需要成熟的需求治理和强大的体系结构才能使不同的移动部件作为一个整体凝聚在一起。尽管没有一种组织应用程序团队的方法，但是轮辐模型可能是追求进度层的应用程序团队的最佳选择，其中记录系统提供了枢纽，创新系统和差异化系统是该枢纽画出最低程度的一致性，同时保持足够的自由度以快速移动。