作者供图

连接高层次战略决策与日常技术选择 介绍

在今天动态的且快速变化的环境中，组织依赖技术来实现战略目标、推动创新并为内部和外部利益相关者创造价值。架构原则作为基础指导方针，连接了高层战略与塑造信息技术解决方案的复杂设计决策之间的桥梁。通过建立清晰、易于沟通的指导原则，嵌入技术治理和决策过程，组织可以确保一致性、战略契合以及对技术格局的控制，同时保持创新所必需的敏捷性。

什么是架构原则呢？

架构原则是说明组织IT资产和能力应如何设计、实施和运营的指导性声明。它们通常由高级管理层批准，以确保与业务目标和组织战略保持一致。有效的原则既稳定又灵活，不会频繁更改。它们指导决策，以平衡技术趋势的变化、安全、合规性和成本等因素。

架构原则的关键好处

1. 战略一致: 将组织战略转化为可执行的IT指令，确保新的解决方案、项目和流程与组织目标保持一致。
2. 复杂性管理: 通过专注于基础规则，这样做减少了技术蔓延、冗余解决方案和重叠倡议所带来的复杂性。
3. 决策框架: 原则为IT架构师、工程师和领导者提供了一个一致的参考点，使选择平台、解决方案和架构更加清晰。
4. 沟通工具: 这提供了一种共同语言，帮助不同团队和利益相关者理解架构决策背后的逻辑。

架构原则的作用

• 规范性作用： 它们为解决方案设计设置规则，明确组织环境内哪些是可接受的，哪些是不可接受的。
• 指导性作用： 它们提供解决方案构建和维护的指导，将诸如安全、性能、成本节约等抽象目标转化为实用的最佳实践。
• 信息性作用： 它们记录并分享机构知识，使人们能广泛理解关键IT决策背后的原因。

结构和构成部分

每个架构原则都应包括这三个核心要素。

• 表述：对原则的简洁表述。
• 原因：简要解释该原则存在的原因及其如何对组织有好处。
• 实际效果：应用该原则后产生的实际结果和需要。

确保效果

要让架构原则真正有用，架构原则应该具有以下特点：

• 数量有限制：理想情况下不超过20条。
• 着眼未来：提供长期指导并允许灵活性。
• 管理层支持：领导层的支持确保了采纳和执行。
• 清晰易懂：简单明了，易于理解。
• 定期审查但很少更改：即使技术不断进步，也保持稳定。
• 用非技术语言编写：以便业务和非技术人员都能轻松理解。

当被有效实施时，架构原则能够确保技术环境的一致性，减少复杂性，并使解决方案与公司的整体目标相一致。它们不是僵硬的规则，而是作为指导标志，促进战略清晰和运营的灵活性。

如果你的组织没有一套清晰的业务和技术策略与目标，怎么办？ 那么，你仍然可以创建一套架构原则，重点关注所有组织共同面临的挑战，例如提高效率、降低成本、提升客户满意度、提高安全性、降低风险、标准化以及防止应用蔓延泛滥。

示例架构原则

以下是一些架构原则的例子，可以作为您组织的起点。调整这些原则以适应您的使命、监管环境和优先事项。这些原则足够通用，应该能在大多数情况下适用。

1. 尽早参与（左移）

说明：与业务伙伴紧密合作，了解他们的需求、痛点以及未来规划，确保在选择技术方案的过程中尽早让IT参与进来。

理由：早期参与能让IT引导团队走向能满足需求的现有解决方案，或确保新方案符合组织和安全标准。反之，延迟参与可能导致效率降低、解决方案过多、风险加大和支持不足。

影响：

• IT领导者、产品负责人和关系经理应主动建立信任，并与相关方保持持续沟通和合作。
• 应将架构和安全审查整合进项目初期（甚至更早），以避免出现偏差。

2. 利用我们已有的解决方法

说明：在引入新的技术之前，要尽可能利用好每一个机会，来重用现有的服务、系统及其集成。

理由如下：通过重复利用经过验证的解决方案，组织可以减少冗余工作，节省成本，减少风险并加速交付。

影响：

• 维护一个全面的IT应用程序、服务和资源的目录或组合，以确保所有可用的工具一目了然。
• 建立一个正式的审查流程，要求新项目在开始前先评估现有的解决方案。
• 促进各部门之间的合作和知识共享，以避免不必要的重复投资。

3. 选择尽量高的抽象层次

在选择或设计解决方案，或者确定在哪里部署时，我们应该尽量选择更高的抽象层次。例如，优先选用软件即服务（SaaS）解决方案，而不是自写软件，优先使用供应商托管的环境，而不是本地安装或部署。

推荐的选择顺序:

应用:

• 现有的平台（M365等）
• SaaS
• 商业软件，
• 定制的软件（最不理想的选择）

托管方式：

• 供应商托管
• PaaS（平台即服务）
• Container
• Virtual Machine
• 物理服务器 （最不理想的选择）

部署地点:

• 公有云（基础设施即服务，IaaS）
• 本地安装（不太推荐的选择）

理由：抽象将大部分维护和支持的负担以及风险转移到供应商/提供商身上，从而减轻了内部团队的工作负担。通过优先考虑“作为服务”模型和外部托管，遵循层级结构，组织可以借助供应商的专业知识，快速扩展资源规模，并减少长期运营成本。

影响:

• 关于适当抽象层次的决策不应只是由个别工程团队做出，而应该包括架构和治理委员会，以确保组织目标和标准得以实现。
• 所选择的抽象层次不仅要满足功能需求（业务要求），还要满足非功能需求（如安全、性能、合规）。
• 任何例外情况都应被记录并解释清楚，特别是在更严格的控制或独特的技术要求使得较高层次的抽象难以实现时。

4. 软件优先性

在可能的情况下，我们应该优先选择软件解决方案而非专用硬件解决方案。

原因：基于软件的解决方案通常能提供更大的灵活性、更易于维护和管理，同时降低对物理数据中心的需求，具备更强的可扩展性。

影响

• 关于专用硬件的请求必须包括为什么虚拟化或容器化方法不够用的原因。
• 有效的情况可能包括以下几种：需要严格性能要求或隔离需求的专用解决方案，这些是单独使用软件无法实现的，如某些特殊应用场景。
• 有效的情况可能包括以下几种：需要严格性能要求或隔离需求的专用解决方案，这些是单独使用软件无法实现的，例如某些特殊应用场景。

5. 网页浏览器是客户端。

一般来说：在实际可行的情况下，应用程序应尽可能通过符合标准的网页浏览器来运行，无需安装任何额外插件。

理由如下：浏览器的方式可以确保广泛的兼容性、统一的版本控制，还有更简单的部署过程。

意思:

• 软件选择或审查过程必须确保所有功能都可以通过标准网络浏览器正常访问。
• 记录需要特殊集成或插件的专业软件的例外。

6. 提供自助服务功能

在可能的情况下，设计平台和流程让用户能够在没有IT帮助的情况下完成日常任务。

理由如下：自助解决方案加快交付速度，减轻IT团队的工作负担，并提高用户的使用满意度。

这意味着：

• 实现直观的门户或仪表板，用于资源调配、系统配置和报告。
• 提供有关自助服务流程和工具的培训以及清晰的文档。
• 使用基于角色的访问控制来维护安全性和合规性，并授予相应的自主权。

7. 买在建之前

建议：尽可能使用商用现成软件（COTS）或软件即服务（SaaS），而不是定制开发的软件。

理由：商业解决方案通常能更快实现价值，减少维护成本并提供供应商提供的支持，从而减少总拥有成本（TCO）。

影响

• 在开始自定义开发之前，彻底评估现有的市场解决方案。
• 确保合同明确关键要求，如安全、合规性和供应商责任。
• 将内部开发资源集中于能提供独特竞争或战略优势的项目上。

8.: 设计保障安全与数据隐私

说明：将安全和隐私方面的考虑贯穿设计和实施的每个阶段，从概念设计到最终退役。

原因：尽早采用安全最佳实践可以减少风险，保护重要数据，并避免后期昂贵的修复。

意思是:

• 定期进行安全评估，包括威胁建模和渗透测试。
• 实施基于角色的访问控制、数据加密（传输中和存储时）以及详细的日志记录和审计。
• 与合规和法律团队合作，确保符合相应的数据保护法规（例如HIPAA）。

9. 数据质量和管理

把数据当成战略性资产，使用标准流程来进行数据的收集、存储、共享以及生命周期管理。

理由如下：高质量且管理良好的数据是准确的报告、明智的决策和可持续运营的基石。

影响：

• 定义数据治理角色，以管理数据质量、所有权和访问权限政策。
• 实施涵盖版本控制、保留和归档要求的治理框架。
• 使用一致的元数据标准来促进互操作性并避免形成信息孤岛。

10. 互操作性和基于标准的集成（使不同系统可以顺利交互和整合）

说明：使用行业标准和可靠的API来确保数据在不同平台和应用之间顺畅交换。

原因：大型组织通常依靠多个系统。确保它们能够无缝协作，避免数据孤岛，简化流程，并提高整体效率。

影响：

• 利用现代集成模式（例如 REST API 和 FHIR）来连接系统。
• 构建易于集成或替换的模块化组件。
• 保持对数据交换格式和集成点的详细记录。

11. 建议采用标准的技术栈和框架体系

说明：在整个IT部门，必要时还可以跨部门，采用标准化技术栈、平台和框架，以简化流程并提高支持效率。

理由：标准化简化了集成过程，减少了所需技能的多样性，并集中了支持工作。

这就意味着:

• 维护一份经批准的技术栈和框架清单。
• 定期审查标准，确保它们紧跟行业趋势。
• 避免没有正当理由的一次性解决方案偏离已批准的标准。

12. 使用现代的身份验证和集中式身份管理

说明：所有新的 web 应用程序，包括软件即服务（SaaS）产品，必须与组织的 Entra ID（原名 Azure AD）身份管理系统进行集成。这确保了单点登录（SSO）、多因素认证（MFA）和条件访问策略的实施。传统的 Active Directory（AD）/LDAP 身份验证仅用于遗留系统。

理由：通过在现代身份管理平台上集中认证，组织可以从简化用户访问、一致地应用安全策略以及自动离职中获益。支持现代协议（如 SAML、OAuth、OpenID Connect）不仅简化了用户的体验，还通过在整个企业范围内启用多因素认证和条件访问，显著降低了安全风险。

影响:

• 技术要求：所有新的解决方案必须支持现代身份验证标准（如SAML、OAuth或OpenID Connect），以便与Entra ID集成。
• 安全治理：安全和企业架构团队必须在批准新应用之前验证其是否符合单点登录（SSO）、多重身份验证（MFA）和条件访问策略的规定。
• 遗留考量：仅在无法实现现代集成时，才可接受遗留的AD/LDAP身份验证方法，且此类例外必须记录并经过审批。
• 用户生命周期管理：通过集中身份管理自动处理用户权限的授予和撤销，使员工入职和离职流程更加高效和一致。
• 风险缓解：集中式身份管理可减少潜在攻击面，确保更强的访问控制，并支持合规性努力。

13. 从一开始就制定数据备份和灾难恢复计划

说明：所有新的解决方案必须在设计、预算和实施初期就包含一个全面的数据保护以及灾难恢复（DR）方案。

理由：未能提前规划备份、数据保护和灾难恢复（DR），会使组织面临重大的运营和财务风险，尤其是在系统变得至关重要时，尤其是随着时间推移。适当的灾难恢复规划不仅能保护数据的完整性和可用性，还可以确保符合法律和监管要求。尽早考虑这些需求可以避免后期出现可能大幅增加成本的问题；比如，存储解决方案和大型数据集常常需要额外的数据预测和灾难恢复解决方案，这可能会使存储成本翻倍。

影响

• 设计与预算：备份和灾难恢复（DR）规划必须在初始架构设计和项目预算中考虑进去。这包括实施强大DR能力所需的硬件、软件和运营成本。
• 治理与审批：任何新的系统请求应包括由架构或治理委员会审查和批准的这些解决方案的备份和DR计划。缺乏书面计划的这些解决方案不应进入生产阶段。
• 测试与验证：定期测试和验证备份程序、恢复能力和DR故障转移计划，以确保所有关键数据和系统能够在可接受的恢复时间目标（RTO）和恢复点目标（RPO）范围内恢复。
• 合规与审计：维护备份和DR过程的文档以满足监管和审计要求。这有助于证明组织在合规检查中的韧性和准备情况。
• 例外管理：如果某个特定系统被认为不够关键，不需要采取高级灾难恢复措施，则业务案例必须解释为何接受最少或零备份的合理性，并详细说明潜在风险暴露。

14. 可伸缩性和性能。

说明：为应对高需求场景制定计划，并在基础设施以及应用程序中确保考虑可扩展性。

原因：系统会因为各种原因经历使用量的激增。低估系统容量可能会干扰关键操作或影响扩展。

影响:

• 在云或混合环境中实施弹性或按需扩展机制。
• 实时监控系统以发现潜在瓶颈并计划容量更新。
• 平衡专用环境的成本与灵活的云突发成本，以应对高需求负载，如数据分析或高性能计算。

15. 以业务为核心的設計

确保技术决策与行动不断与公司的总体目标相一致。

理由如下：技术投资应直接或间接地支持组织的战略目标，无论是提升患者的体验、优化研究流程，还是促进科学发现。

影响：

• 将用户反馈融入解决方案设计，并让利益相关者参与其中。
• 根据方案给组织带来的实际好处（如节省成本、降低风险、增加收入等）来评估提案。
• 鼓励采取敏捷和迭代的方法快速测试和采纳新想法。

16. 促进持续改进和负责任的创新

声明如下：鼓励持续学习、实验和反馈循环的方法，以进化技术和实践，同时还要平衡风险并与组织的总体目标保持一致。

理由：持续改进的文化氛围结合风险管理，使组织保持灵活并具有竞争力，免受未控制威胁的侵害。有效利用新技术需要实验和有组织的管理。

影响:

• 留出时间和预算用于研究、试点项目和概念验证，探索新兴技术和实践方法。
• 制定并应用明确的标准来评估新想法，基于投资回报率（ROI）、战略契合度、安全性和合规性。
• 在组织内分享成功和失败的经验，以加速学习和改进过程。
• 尽早让架构、安全和相关治理委员会参与，以识别风险、规划缓解措施，并确保与战略目标保持一致。
• 定期根据创新项目的教训，完善架构原则和标准。

17. 资本技术收购过程中的尽职调查工作

声明：涉及重大资本或运营成本的技术收购必须遵循尽职调查程序，以确认所选解决方案满足组织的功能和非功能需求，并确保其以有竞争力的价格获得。

理由：考虑到有限的财务和运营资源，确保任何可能的解决方案都能满足业务需求和预算限制这一点至关重要。适当的尽职调查有助于保护这些资源，并减少低效或不兼容方案的风险。

影响:

• 需求定义：在适当的情况下，定义并记录该解决方案必须满足的功能（业务）和非功能（IT/架构）需求。让业务和IT相关方共同参与，以确保对需求和限制的全面理解。
• 招标流程：如果有必要，根据范围或成本进行招标，向多个候选供应商发出招标书。该招标书应包括明确的需求和指示，要求供应商说明其解决方案如何满足这些需求，以及详细的报价。
• 评估与文档记录：记录招标书的评估和选择过程，包括任何评分矩阵和正式评审标准，以及最终决策的理由。
• 验收测试：如果可行，在采购订单（PO）发出之前，执行验收测试，以验证解决方案的能力是否符合记录中的需求。
• 独家供应商例外：仅在确实不存在其他竞争性解决方案的情况下保留“独家供应商”的理由。
• 治理审批：所有新技术采购必须由相关治理委员会或委员会（如架构审查委员会、IT委员会）审查并批准。这不仅确保与组织的IT架构和安全标准相一致，还促进了透明度，并为领导者提供了提问或挑战提案的机会。

17. 实用性优于纯粹性

说明：这些原则更像是指导方针，而不是死板的规则；如果合理且有充分的理由，例外情况也是可以被接受的。

理由如下：实际的限制条件和战略优先事项可能需要偏离理想架构的选择，特别是在关键截止日期迫近或有独特业务需求的情况下。“理想”一词在此处具有特定含义。

这意味着：

• 正式的例外处理流程应在获得最终批准之前评估对安全、性能、合规以及成本的影响。
• 记录例外情况有助于保持透明度并为未来的决策提供参考。

结尾

通过遵循一整套明确定义的架构原则，组织可以做出一致、战略性且面向未来的技术决策。强调早期与利益相关者的互动，重用已验证的解决方案，优先选择适当的抽象级别，确保安全和隐私，并确保互操作性，这些措施有助于简化流程并提高组织的灵活性。

架构原则并不是僵化的规则；它们是成功的框架，有助于构建一个战略清晰、运营高效的技术生态系统。随着新的挑战和机遇不断出现，定期回顾并调整这些原则，确保它们始终是所有技术决策的重要参考点。

实施计划如下：

• 建立架构审查委员会，定期开会评审新项目提案，跟踪例外情况，并确认与原则的一致性。
• 创建中央存储库（如 SharePoint 站点或维基），存放并更新所有原则的最新版本、相关指南和更新。
• 提供持续的沟通和培训，确保对原则的广泛理解和采用。

通过这些步骤，您可以将架构原则嵌入到组织的运营流程中，从而实现战略一致，降低风险，并促进可持续的创新驱动增长。