创建一体化业务和技术战略

代码库中产品类型的表示方式会对添加新产品或在出现新产品时调整类别变得多么容易产生重大影响。寻找其他系统中对产品线信息的假设。产品代码可能在其他地方被硬编码，某些系统可能只假设某些类型的产品。寻找整个堆栈中的更改，从您提供不同的客户体验和网站导航的 UI，到域模型中的新条目，以及数据库中可能存在的新表结构。

业务流程可能不适合正在考虑的未来产品。可能需要对共享服务后端系统进行更改，例如支付和开票系统、分销和仓库管理系统以及业务报告。

在产品之间共享能力使您能够专注于新产品的增值差异化因素。整合共享能力可以提高上市速度。但是，要注意强制共享能力的情况，因为在产品产品之间流程不同的情况下，这可能会导致能力中不必要的复杂性和债务。

不增加产品差异化的能力可以安全地分配给打包软件，无论是安装的还是 SaaS。开发此类能力的清单可以推动考虑当前的供应商产品。产品线的变化可以帮助澄清哪些能力对产品差异化很重要。重新检查提供合适产品的供应商，这既是由于时间的推移，也是由于重新评估差异化因素。

确定可以在市场之间多样化、复制、统一或协调的功能。多样化和复制的功能可以存在于每个市场，您希望通过全球平台提供统一的功能。

如果您需要由于监管、合规性甚至性能原因在新市场托管您的基础设施，则需要使部署在您的系统中可重复。这减少了跨区域的不一致性，从而导致故障发生时的高排查时间。对于组织来说，建立单独的团队来定制和运营每个区域太常见了，这会导致配置漂移/代码雪花和手动维护。维护需要同样重视 - 成本、人员工作量和结果（事物得到修补、一致、旧版本被淘汰、各种规模的修复快速全面地推出）。地理位置扩展的运营成本变得近乎线性，改进和修复不会快速或一致地分发。

为了符合规定，在新市场启用新的数据中心可能需要很长时间。如果流程不可重复，并且启用需要一段时间，您可以考虑迁移到云。基于云的基础设施将更容易遵守新市场的​​数据主权要求，但您可能需要考虑将数据库分区以符合规定。

查找任何通过将受监管的信息传递到国外而使您不合规的第三方系统。这可能包括检查 OLA 和 SLA。

查找默认情况下支持此功能的 UI 框架。将国际化改造到 UI 中可能是一个繁琐的过程。内容长度可能会因语言而异。查找可以容纳更长或更短文本元素的动态 UI 元素。如果 UI 框架已经为翻译文件配置，一个不错的实验是将所有翻译更改为“XXX”之类的短语，以及更改为非常长的内容以查看页面如何响应。

查找隔离更改的良好分解代码库。

您是否需要在开发流程中添加时间以允许代理机构翻译您的文件？这种额外的等待时间会影响您的小型反馈循环。或者，您是否需要将翻译流程引入设计流程？

难以更改的前端代码将使提供新的客户体验具有挑战性。查找硬编码的导航元素、难以更改的前端代码以及缺乏前端测试。

未经测试的代码，尤其是未经测试的 JavaScript，将使更改体验变得有风险。仅通过缓慢（且不稳定）的端到端测试进行测试的前端将增加开发新体验所需的时间。

在合并新的 UI 体验时，例如将您的网站扩展到原生移动应用程序，请考虑您的数字平台如何在提供各种前端交互的灵活性的同时适应和集成核心业务功能。如果您已经拥有微服务或微前端网站，则需要进行哪些架构调整，例如 BFF（面向前端的后端）移动适配器。

即使被收购的企业继续独立运营，也假设一些业务能力需要集成（例如财务），但可能并非所有能力都需要集成。业务能力图是在深入到 API 之前，在业务层面上说明交叉点的快速第一步。API 策略是一种通过构建 API 生态系统来解锁现有业务能力的方法，以实现规模化创新。它有助于缩短上市时间，通过创建一个易于操作、集成和使用的 API 生态系统。API 与专注于系统集成的传统方法不同。通过专注于通过定义明确的 API 集成企业，您将提高未来创新的能力。

对 API 策略的调查在独立运行的情况下与在本例中一样适用，但是您可以利用一些其他杠杆。例如，您可以共享事件流或利用共享存储。

当您希望与被收购的企业密切合作时，您将需要考虑跨领域模型进行整合。如果您专注于在领域模型中获得这种一致性，则系统的数据匹配和集成将变得更容易配置。

跨两个产品的统一客户体验将提高客户满意度并改善保留率。它还将使两家企业共同为您的客户提供的价值放大，因为客户不会面临跨两个脱节的系统工作的负担。

来自企业架构即战略的操作模型象限，对于希望统一其公司集团的能力，或在处理无机增长整合时相关的组织来说是相关的。

成功的收购会投入资源和人员来整合业务。作为技术领导者，您可能需要提供帮助，以帮助整合工作了解系统将如何整合。可能需要整合运行时环境，可能需要将数据迁移到新系统中，或出于合规性原因进行归档。对系统的安全审查可能会突出显示系统迁移之前需要在系统内进行的安全修复。为了改善跨产品的开发人员体验，系统本身可能需要整合，因为库和框架在整个技术栈中统一。

简化和整合系统的运营方面可以降低运营成本，并减少跨多个不同系统进行管理所需的时间。您可能需要更改运行系统的方式，这可能包括更改日志信息、频率或更改日志的严重级别。

它是否反映了领域？在多个级别考虑这一点：在类或文件内，一直到组件边界。它们如何相互交互？（考虑领域建模）。评估代码的维度是：大小、复杂性、耦合、内聚。

测试覆盖率易于衡量，但并不总是能很好地反映测试质量 - 其他需要关注的事项包括测试数量；不稳定性；执行时间；测试的一致性/结构；命名；以及与代码的耦合

在预生产或生产中发现的缺陷，其修复成本和对增值工作流程的干扰呈指数级增长

寻找长时间的反馈循环，例如长时间的构建时间，验证跨职能需求是否得到维护

存在哪些文档，它们是否是最新的，它们是否相关/组织良好/易于查找，每个仓库是否都有关于代码目的以及如何测试和运行它的清晰文档。

合理的默认值、约定优于配置、安全的护栏和良好的入职文档可以提高新团队成员的生产力速度。

认知税会造成质量问题，从而显著降低交付速度。

团队经常忙于构建许多对业务价值不重要的东西。交付流程中的浪费示例包括认知负荷/上下文切换、在正确的时间找到正确信息的能力、开发体验中的摩擦以及缓慢的质量反馈循环。寻找开发生态系统，这些生态系统是碎片化的，需要导航到多个地方和系统才能完成工作。衡量工作流程各个阶段之间工作队列的大小是量化瓶颈的好方法。查看流程指标以及循环时间和交付时间。

衡量将一行代码更改投入生产所需的时间。对于小更改来说，长时间的延迟会阻止频繁更新，从而导致更大、风险更高的更新，并降低对业务机会的响应能力。

组件缺陷率热图可以显示最需要优先改进的区域。

如果计划在风险部分进行未来的功能开发，那么正确修复该区域可能更有效。通常需要进行架构更改来解决这些区域的根本原因。

寻找您达到容量的时期，并注意随着时间的推移出现的模式。如果您在增长后预计的负载下即将达到容量，那么您需要现在开始解决系统性能问题。

查找呼叫中心数据中的模式。将此数据中的任何模式与产品缺陷列表上的热图匹配。

查找经常一起更改的组件，这意味着它们紧密耦合。更改的热点表明高流失率。

随着向云的迁移，一些财务主管和技术主管都失去了他们曾经对在数据中心购买和运行的基础设施的财务可见性。基础设施购买中心已从采购办公室转移到工程师的键盘上，信用卡存储在云供应商帐户的档案中。通常，财务部门只有在月底收到账单后才能看到云支出。在启动新基础设施的工程师和预算控制者之间存在脱节。

将围绕云支出的财务决策民主化，让负责实例化云组件的工程师参与进来，需要在适当的财务控制和警报到位的情况下进行。影响组织在云上运营的文化对于帮助优化云成本至关重要，将治理和协作作为一种纪律。对基础设施进行标记并在运营仪表板上显示支出，以及正常运行时间和使用指标以及警报，将提供财务控制和治理之间的适当平衡。

停用或淘汰不再使用的系统是减少云账单的最快方法。仔细查看账单上显示的所有内容，以确保您仍然从中获得价值。

数据治理是指对组织数据资产的整体管理、控制和保护。它涵盖了确保数据在其整个生命周期中的质量、完整性、可用性和安全性流程、策略和标准。数据治理旨在建立一个框架，管理数据在整个组织中的收集、存储、使用和共享方式。

软件生命周期结束 (EOL) 软件版本不再受软件供应商支持。这意味着供应商将不再为该软件提供安全更新、错误修复或新功能。因此，使用 EOL 软件会给企业带来许多风险，包括安全漏洞、性能问题、合规性问题和数据丢失。EOL 版本为当前市场扫描提供了机会，可以迁移到更新的技术，这些技术可以支持下一阶段的增长。

通过制定中断时的备用计划，公司可以减少中断对其运营的影响。利用技术提高对供应链的可见性。通过实时了解货物和材料的位置，公司可以更快地识别和应对中断。

定义数据架构以满足分析用例。根据数据工程、软件工程和持续交付的最佳实践设计和执行数据平台。您希望能够轻松地扩展不同的数据源和用户，从而实现分析用例，从而获得更丰富的见解。

如果数据是一堆不连贯的事实，那么轻松访问数据可能对组织没有用。构建经过精心策划的视图和受治理的数据集，其中包含来自各种来源的数据，用于分析、机器学习、服务、应用程序等。

一位优秀的领导者应该拥有清晰的愿景和目标，并有效地传达这些愿景和目标，以激励他人。情商至关重要，行动要正直和道德。果断、授权、适应性、协作和团队建设是培养积极工作环境的必要特质。问责制、韧性和注重成果也是有效领导力的标志。此外，优秀的领导者优先考虑指导和发展，以确保团队成员的成长，从而为组织的长期成功做出贡献。寻找那些提倡多元化和公平文化的领导者，以促进包容性。

看看鼓励知识共享行为的激励措施、认可或晋升。

寻找易于访问、导航和回馈的系统。

查看保留数据和离职面谈，看看是否存在重复模式

缩短系统访问请求的周转时间，以便员工可以回到增值任务中

衡量工作流阶段之间工作队列（库存）的大小是量化瓶颈的好方法。支持许多沟通渠道会增加成本，而许多渠道会增加混乱，因为人们不确定使用哪些渠道。交接点通常会产生摩擦

一些系统需要差异，因为存在特定于国家的法规和文化差异。但是，许多系统是在本地开发的，而其行为与世界其他地区基本相同。本地业务部门通常无法等待功能在全球范围内优先考虑，但这会导致许多类似的系统，这些系统难以维持。

聊天评论可以作为员工对系统和流程满意度的指标。情绪分析工具通常用于客户评论，它们也可以用于评估内部系统。

收到过高数量支持票证的系统应该进行审查，以进行增强或更换

如果员工用自己的脚投票支持外部系统，那么我们应该审查内部系统是否值得。

陈旧、疲惫的系统不仅会降低员工对您组织的情绪，还会损害生产力。就像您希望专注于引人入胜的客户体验一样，将您的员工视为内部产品的客户，并为他们提供实现目标所需的现代工具。重要的是，要像对待面向客户的产品一样对待这些系统。这意味着将您的内部用户视为这些系统的客户，并应用您对产品所做的相同产品思维方法、客户研究和客户服务。

Thoughtworks 的 Looking Glass 报告和 Technology Radar 是两份出版物，可以帮助技术领导者了解当前和新兴技术，以及 Gartner 和 Forrester 等分析师报告。但是，要谨慎使用新技术。不应该为了技术而选择新技术和闪亮的技术。应该为客户或员工创造明确的价值。一些组织采用创新代币。创新代币的概念非常简单：您获得三个创新代币。每次您进行创新（即做一些与标准不同的操作）时，您就会花费一个代币。一旦您花费了所有代币，您就无法再进行创新了。

确保使用可靠的数据源和历史数据，重点关注与业务目标一致的相关指标。细分市场并考虑外部因素，例如经济状况和技术进步。与行业基准和竞争对手进行比较分析，征求行业专家的意见，并验证假设。持续监控趋势，可视化数据，并采用前瞻性方法来预测未来发展并相应地调整业务策略。

考虑这些更广泛的问题可以让您快速适应快速发展的情况。例如，我们最近为一家旅游行业的客户完成了技术战略。我们利用旅行洞察数据和我们自己的客户研究来探索旅行模式在 Covid-19 诱发的封锁后是如何变化的。在人们在不确定的时期重返旅行时，取消和重新预订的便利性已成为一个重要因素。因此，技术战略侧重于提高取消、通知和后台集成的能力。我们还确定了机器学习可以帮助预测取消可能性的一些良好示例，因此我们在技术战略中加入了机器学习和数据工程的引入，以帮助客户重返旅行并减轻客户支持团队的负担。闪亮的技术解决实际问题，而不是为了使用闪亮的技术而使用。