商业中的不可知论含义：平台、供应商、技术
B2B软件推销中频繁出现“平台无关”、“厂商无关”、“技术无关”等字眼，并将其视为一项功能特性，而对其背后的解释通常被忽略。
在商业领域，“平台无关性”指的是产品、服务或策略在结构上不依赖于特定的平台、供应商或技术。这并非一种哲学立场，而是一种实践策略。如果无需重构应用程序即可更换云服务提供商，则该应用程序是云平台无关的。如果咨询公司推荐的工具不涉及经销商激励，则该公司是供应商无关的。这个词经常出现在招聘启事、供应商合同、架构文档和投资报告中。了解“平台无关性”在商业应用中的具体含义，有助于您更清晰地评估所有这些内容。
在商业领域，“不可知论者”是什么意思？
这个词源于希腊哲学。Agnostos意为“不可知的”，托马斯·赫胥黎在1869年借用了它，用来描述一种刻意保持中立的立场：不对无法验证的主张做出承诺。20世纪90年代，科技行业将同样的逻辑应用于基础设施领域。一个不依赖于特定平台或供应商的系统，就被称为对它们持中立态度——无论平台或供应商是谁，它都能正常运行。
想象一下万能电源适配器。它兼容欧洲、美国和英国的插座，没有任何偏好。它的设计初衷就是如此。这正是所有不偏不倚的商业概念所指向的原则，只不过它应用于软件选择和供应商合同，而非电气标准。
实际上：不存在结构性依赖。一家目前在 AWS 上运行的公司，如果其架构在设计之初就具备足够的灵活性，那么它可以迁移到 Azure 而无需重建核心系统。咨询公司如果没有与供应商签订任何协议，则会根据实际情况提出建议。两者都不存在被锁定的情况。
商业中的不可知论类型
这个词在商业领域的不同角落都有出现，含义也各不相同。以下是其主要几种类型。
平台无关
如果软件无论在何种操作系统或浏览器下运行都相同，那么它就是平台无关的。Google Docs 就是如此：无论是在 Windows 的 Chrome 浏览器、macOS 的 Safari 浏览器还是 Linux 的 Firefox 浏览器打开，都能获得相同的体验。无需针对不同环境开发单独的版本。
对企业而言，其重要性在于：用户使用的设备各不相同。用户不应该需要特定的笔记本电脑型号或手机品牌才能使用CRM系统。平台无关的工具解决了这个问题。
与供应商无关
厂商无关性是一种商业特性，而非技术特性。厂商无关的架构可以在 AWS、Google Cloud 或 Azure 上运行，并且无需在更换服务提供商时进行重建。没有经销商合作关系的 IT 咨询公司在提出建议时也秉持厂商无关的原则。
问题在于供应商锁定，而且通常只有在你试图离开时才会显现出来。数据采用专有格式，导出需要付费的迁移项目。你签署的合同并未包含数据可移植权。这些问题并非突然出现，而是双方关系出现问题之前一系列决策累积的结果。
技术无关的方法
这里的问题在于，系统是否会限制在其基础上进行开发的开发者选择语言、数据库或框架。一个与技术无关的 API 则不会。它接受来自 Python、Java、JavaScript、Go 等任何调用者的请求，并以相同的方式处理它们。依赖项的选择权完全掌握在客户端手中。
Kubernetes 将此作为容器编排的默认预期。该平台可以运行各种工作负载，而无需考虑编程语言、框架或云提供商。团队选择他们的技术栈，Kubernetes 负责运行。
其他类型的商业不可知论
这一概念的应用范围远远超出软件开发领域：
| 类型 | 它的含义 | 例子 |
|---|---|---|
| 与云平台无关 | 可在任何云服务提供商上运行 | 应用程序已部署到 AWS、Azure 或 GCP，无需任何更改 |
| 与设备无关 | 可在任何设备上使用 | 可在手机、平板电脑和桌面电脑上运行的 Web 应用程序 |
| 数据无关性 | 处理任何数据格式或来源 | 可接收 CSV、JSON、SQL 或 API 数据源的分析平台 |
| 与行业无关 | 业务遍及多个行业 | 投资于医疗保健、物流和金融科技领域的私募股权公司 |
| 与业务流程无关 | 软件逻辑不局限于单一工作流程 | 无需自定义代码即可适应不同发票格式的ERP系统 |
| 支付方式无关 | 接受多种支付方式或货币 | 可处理银行卡、加密货币和银行转账的商户平台 |
平台无关性 vs. 厂商无关性
人们经常互换使用这两个词，但它们描述的是不同的事物。以下是它们之间的实际区别：
| 方面 | 平台无关 | 与供应商无关 |
|---|---|---|
| 重点 | 运行环境（操作系统、设备、云端） | 供应商关系 |
| 主要关注点 | 互操作性 | 避免依赖单一供应商 |
| 例子 | 该应用可在 iOS、Android 和网页上运行。 | 基础设施运行在 AWS、Azure 和 GCP 上 |
| 常见于 | 软件开发、SaaS产品 | 采购、IT咨询、云架构 |
| 避免了关键风险 | 兼容性锁定 | 商业锁定 |
一个系统可以同时具备这两种特性。云原生且与供应商无关的应用可以在任何基础设施上运行，而无需与任何特定供应商签订合同。这些概念相辅相成。大多数成熟的技术架构都力求同时实现这两种特性。
为什么企业会采取中立态度
商业战略中的不可知论并非为了中立而中立，而是为了获得优势。企业出于实际原因追求不可知论：
- 避免厂商锁定：当您的系统不依赖于单一供应商时，切换供应商就变成了一个工程项目，而不是一场灾难。而那些被单一供应商锁定的公司，往往需要花费 15% 到 20% 的 IT 预算才能完成迁移。
- 价格压力：如果两家供应商都能提供相同的功能，他们就会竞标合同。而锁定效应会削弱这种竞争优势。与单一供应商绑定的企业普遍反映，其尾部支出比市场价高出 5% 甚至更多。
- 面向未来：技术发展速度远超大多数厂商的路线图。采用与技术无关的架构，您可以随时替换更优秀的工具，而无需等待厂商开发出竞争对手早已具备的功能。
- 可扩展性：模块化、API驱动的系统可以通过替换组件来扩展。而单体式的单供应商系统则需要升级整个技术栈才能扩展，这成本更高。
- 监管灵活性：合规要求因司法管辖区而异。与司法管辖区无关的软件无需修改核心系统即可适应这些要求。
- 更快的并购：与平台无关的系统在收购后集成速度更快。两家使用 API 优先、厂商中立软件的公司，在集成项目上花费的时间远少于两家系统硬编码到不同专有技术栈的公司。
不可知论相对于单一供应商方法的优势
这种权衡取舍是真实存在的。与供应商无关的方法需要更多的前期架构设计工作。而单一供应商的生态系统则更容易搭建。问题在于，在未来3-5年的时间跨度内，你的优化目标是什么。
| 标准 | 不可知论方法 | 单一供应商模式 |
|---|---|---|
| 灵活性 | 高——根据需要更换组件 | 低——与某一家供应商的路线图有关 |
| 初始复杂性 | 更高——更多集成设计工作 | 较低——单一生态系统，较少的决策 |
| 长期成本 | 价格更低——保持竞争力价格 | 续约时杠杆作用降低，导致更高水平的续约成本增加。 |
| 创新速度 | 更快——立即采用最佳工具 | 速度较慢——等待供应商交付功能 |
| 风险集中 | 分布在各个供应商 | 专注于一段关系 |
| 转换成本 | 如果设计时考虑到便携性，则价格较低。 | 高——数据迁移、重新训练、停机时间 |
| 最适合 | 满足不同需求的规模化公司 | 早期团队需要快速简化流程 |
两种选择都不是万能的。对于正在构建最小可行产品（MVP）的初创公司来说，快速推进至关重要，因此单一的集成平台是合理的选择。而对于致力于多年基础设施建设的企业来说，从一开始就需要构建兼容多种平台的架构，而不是在被供应商锁定后才进行补救。
真实世界中的无关商业案例
那些有意采用这种运营方式的公司规模都不小：
- Netflix同时运行在 AWS 和自有基础设施上。任何单一云平台的故障都不会导致服务中断。这种云平台无关性不仅体现在架构图中，也体现在生产环境中。
- Salesforce从设计上就具有平台无关性：无论客户的技术堆栈如何，CRM 都可以通过 API 连接到任何 ERP、数据仓库或营销自动化工具。
- Kubernetes可处理与技术无关的容器编排。工作负载可在任何云端或本地环境中运行，支持任何编程语言，并可通过任何 CI/CD 流水线运行。
- 对于追求基础架构灵活性的团队而言， PostgreSQL是一个与数据库无关的选择。基于 PostgreSQL 构建的应用程序可以部署在任何地方，而无需依赖 Oracle 或 SQL Server。
- 支付编排平台会将交易路由到多个收单机构（例如 Worldpay、Adyen 和 Stripe），并选择交易通过率最高、单笔交易费用最低的机构。这在支付领域体现了供应商中立性。
- 标榜自己不偏袒任何行业的投资银行，在医疗保健、物流、金融科技和消费品等行业的并购交易中提供咨询服务，且不带有任何偏好行业。
如何构建一种不偏不倚的商业策略
构建与供应商无关的架构需要时间，尤其是在那些多年来积累了供应商依赖关系却未积极管理的组织中。具体步骤如下：
- 审核您当前的依赖项。梳理技术栈中的每个工具、平台、供应商和集成。找出单点故障——那个一旦退出就会造成灾难性后果的供应商。
- 优先选择 API 优先的软件。选择提供清晰、文档齐全的 API 的工具。如果数据被锁定在专有格式中且没有导出途径，那就已经无法挽回了。
- 构建抽象层。中间件、iPaaS 平台和编排工具位于核心系统和特定供应商之间。这样，更换供应商就意味着更换连接器，而不是重建系统。
- 签署合同前务必协商退出条款。数据可携权和退出条款在合同签署前比签署后更容易获得。对于任何多年期协议，都应坚持要求加入这些条款。
- 为你的架构编写文档。没有文档的系统会因为晦涩难懂而造成依赖关系。只有最初的开发者才知道它是如何运作的，这意味着只有他才能修改它。
- 每年进行供应商评估。价格会下降，更优的替代方案也会涌现。三年前合适的供应商，如今可能不再适用。定期评估能让你保持价格谈判优势。
将不可知论思维应用于支付领域
支付是“支付方式无关性”商业理念产生最直接财务影响的领域之一。“支付方式无关性”的架构接受多种支付方式、货币和渠道的交易：银行卡、银行转账、数字钱包、加密货币等等，所有这些都可以接受，而无需将商家绑定到单一的支付处理商或卡组织。
支付锁定问题具有其特殊性。单一支付处理商意味着单一的审批率、单一的收费结构和单一的故障点。如果该处理商更改条款或出现故障，则没有备用方案。支付编排层通过将每笔交易路由到当时能够提供最佳结果的收单机构来解决这个问题。
加密货币将支付方式的灵活性提升到了一个全新的高度。接受比特币、以太坊、USDT 和其他数字货币的商家可以一举绕过银行卡网络、银行营业时间和地域限制。拒付是银行卡商家的一项主要成本支出，但加密货币交易不存在这个问题。对于希望真正实现支付方式无关性的商家而言， Plisio支持 20 多种加密货币，且不锁定任何单一货币或网络。
不可知论对你的商业策略意味着什么
所有这些不拘泥于特定含义的业务场景的共同点在于选择性。您可以更换供应商、更新技术栈或拓展新市场，而无需重做已完成的工作。这种灵活性是有代价的——当供应商发现您无法更换并相应调整条款时，或者当您收购一家公司后意识到整合需要 18 个月而不是 3 个月时，就会出现这种情况。
这一切前期都需要投入成本。构建兼容性意味着早期需要做出更多架构决策、进行更多集成工作，并且随着系统演进，还需要持续维护兼容性。但那些跳过这一步的公司并不能避免成本——他们只是在后期、在更糟糕的条件下、在更缺乏时间的情况下付出代价。
