金融服务企业云迁移

在过去的五年或更长时以前，许多大型金融服务组织已将IT服务迁移到云。这种过渡有许多措施，例如：实现现有实施，采用SaaS的提升和转移，采用本机云功能，甚至完全重新构想服务以支持业务转型。

作为一名建筑师，我在这次旅程中为几个客户提供了支持。该博客总结了我学到的知识的一些想法。

好处

客户可以期望TCO节省下降，同时又减少了冗余能力和可用容量的增加。但是，管理的看法可能会因缓慢的迁移交付和维护混合基础架构以适应禁止使用公共云的位置的数据而扭曲。

可以说的是看到了许多其他好处：

• 快速交付业务需求的敏捷性
• 通过在AI等领域迅速开发云产品的创新
• 改进的安全性：跨设计，CI/CD和控制产品的标准化模式可以提高控制效率和有效性
• 通过计算的弹性，可以增加可行和负担得起的能力
• 通过冗余和SRE的改进实践的工作负载弹性

挑战

由于以下原因，福利实现可能比其他行业更难：

• 较高的监管负担
• 许多金融服务组织的大规模规模
• 更严格的内部审计要求更紧密的安全要求
• 与控制不足有关的更大声誉风险
• 企业中的技能差距

启用重点的关键领域

这些挑战需要在任何云迁移中直接解决。但是，对于金融服务企业而言，以我的经验，可以使用四个关键启用结构有效地处理它们：

• 云产品支持
• 建筑控制
• 集中设计模式
• 安全过程
• 这些主题中的每一个将在下面更详细地描述。

云产品支持

云产品团队应为用例团队推动启用启用，但业务必须确定优先级 – 没有象牙塔或软件供应商议程。如果企业想要Spark Ba​​tch ETL，则可以使该服务首先运行，而不是推动重构为其他ETL API。除非这样做有明显的好处，否则请避免使用CSP提供默认替代品的昂贵供应商产品。

从一开始，产品支持团队应培养一个社区，以告知最佳实践。特定于云的建筑社区会议非常适合传播发展，为查询和设计的同行评审提供了论坛。为个人服务的产品所有者分配可以通过透明度对专业知识来源进一步采用。特定产品的指定通信渠道还带来了有关设计和实施的协作。

建筑控制

集中式建筑审查提供了一个机会来传播知识并启用应用程序团队，同时实施最佳实践。增加价值的潜力是巨大的。信息良好的控制操作员可以洞悉最新产品开发，使用模式和弹性机制。通过这些控件对设计人工制品的标准化有益于所有利益相关者的理解。

设计模式

中央创建和设计模式的提供通过在用例级别节省辛劳来加速迁移。具有足够授权和正确的中小型企业的设计团队可以做一次并正确地做到这一点。这应该包括通过架构和安全控制进行设计，以保存多个应用程序团队必须这样做。当然需要有足够的设计模式：并非所有用例都可以得到相同的架构支持，并且一如既往的有效通信是机器的油。必须提供消费团队的手段，以了解隐性技术决策及其对个人用例的适用性。

安全过程

云上的安全是至关重要的，实施基础政策的机会应改善防御能力。但是，管理变更的过程也必须得到增强。不执行此操作可能会导致由于关键功能的块而引起的迁移应用程序的吞吐量约束。云产品，安全和应用程序团队之间的密切合作将通过相互了解产品安全功能和使用安全策略来产生不成比例的收益。建立的设计模式只能进行一次安全验证，此后删除对每个消费应用程序进行详细分析的需求。

前面的道路

每个迁移计划都是不同的，并且在集中控制和利用主动性和应用程序交付团队的用例知识之间将始终保持平衡。建立这种平衡以使既及时又合规的交付取决于受影响各方之间的有效沟通渠道。

大规模迁移的理由存在普遍的逆风。必须适应支持移民执行的程度和业务流程很大，并且可能导致延误，幻灭和妥协，从而削弱了福利。业务领导者正确地专注于功能改进，而不是为了技术创新而不是技术创新。对AI的未来收益，成本效率和更好的数据获利的看法可能会有所帮助，但是Jum明天只会走得太远。云迁移的努力和费用的规模及其战略影响需要详细的路线图，以显示如何以及何时提供福利。可以使用复杂的方法来证明在完成之前付款的计划，其中应包括在迁移积压中的快速胜利的识别和优先级，可以早期提供高ROI。

即使在一条快乐的道路上，程序也可以持续多年，最初的匆忙随后是一系列应用程序，只有在合适的产品可用时才能移动，可以满足数据依赖性或监管制度允许。首先跳到两只脚，快速移动并破坏事物，或者最高利益相关者没有远见卓识的承诺，都是灾难的食谱。另一方面，从云中解锁收益是金融服务企业保持竞争力所必需的。有效和受控的移民计划和交付提供了超越竞争的机会。