未来工程：数据、软件和人工智能的共同点

识别跨学科共性不仅增强招聘策略，还支持灵活的IT架构。

我注意到IT部门中存在过度专业化的趋势。然而，多年来我学到的一个重要教训是这种孤立专业化的负面影响。

虽然这主要是一个组织问题，但对供应商专业平台产品的盲目追求也导致了我们企业架构中功能的显著重叠。

如果您的业务是提供专业IT解决方案平台，当然可以从高度专业化中受益。

对于所有其他企业，我认为这需要进行纠正。

从孤岛到更好的协作的转变

传统的软件应用工程、数据工程和人工智能/机器学习（AI/ML）今天形成了大型孤岛。

虽然不同的IT任务被认为是大致独立的，目标也各不相同，但实际上，业务需要应用程序与AI/ML模型之间无缝的数据交换和集成。

我们需要从孤立的任务转向集成系统。

各个领域的工程师实际上依赖于许多共享的实践，这需要一个共同的语言和方法论。数据管道现在必须支持实时模型推断；应用软件必须动态处理数据流；而AI/ML模型必须无缝地融入实时应用程序中。

这些跨领域的互动应该重新定义各个领域工程师的孤立角色，使我们清楚地认识到必须超越传统学科的界限进行思考。

在我为医疗行业工作时，我观察到了过度专业化的同样问题。医生也往往单一关注特定的器官或系统（例如，心脏病专家、神经科医生）。这种过度专业化虽然推动了某些疾病的治疗，但往往导致一种片面的做法，可能忽视患者的整体健康。这使得获得良好、全面的建议变得非常困难。

然而，近年来医疗行业确实发生了重大转变：从孤岛思维转向更为集成的整体方法。这一趋势强调跨学科的协作，结合不同专业的知识以改善患者的结果。

我们迫切需要在IT工程中进行同样的重新思考。

共同原则：跨学科的桥梁

回顾过去，有几个关键原则显得尤为重要，无论你是数据工程师、软件开发人员还是AI/ML从业者。

显而易见的共同点包括编程能力、算法思维和问题解决能力，以及对数据结构的恰当处理。这些原则为所有工程师提供了共同的基础。

让我们来看一些更多的共同原则。

模块化与可重用性

模块化多年来一直是软件架构的基石。

在数据工程中，这一原则同样至关重要。一个设计良好的数据管道必须是模块化的，以支持可重用的数据转换和易于调整的组件。在应用开发中，我们学会了以（微）服务的形式思考，从而为一个连贯的整体系统做出贡献，但在构建数据管道方面，我们仍然缺乏同样的能力。相反，我常常听到一个错误的说法，即数据工程不是软件工程。

查看谷歌的论文“机器学习系统中的隐藏技术债务”清楚地表明，模型本身只是整个AI/ML服务中一个很小的部分。大部分服务需要软件和数据工程的专业知识，以便将其正确集成到企业架构中。例如，特征工程实际上是针对AI/ML模型的数据工程，并且与传统的数据仓库ETL处理有许多共同点。

当这三种学科都追求模块化架构时，整合不同系统和跨孤岛重用组件就变得更加容易。

版本控制与生命周期管理

在软件开发中，版本控制对于管理变更至关重要，这一原则同样适用于数据和AI/ML模型。数据版本控制确保团队能够跟踪变更、维护血统并保证可重现性。AI/ML模型的实验跟踪和生命周期管理可以防止更新干扰流程或在生产中引入意外行为。

在各个领域采取严格的版本控制方法确保系统的清晰同步，尤其是在我们的动态环境中，数据、代码和模型不断演变。这一需求在“*Ops”学科的兴起中得到了体现，如DevOps、MLOps和DataOps，它们都旨在促进高质量软件产品的快速交付。

然而，这些重叠的学科导致了不必要的项目管理和工作流程开销。我们维持着三种独立的、过于专业化的版本，实际上这些流程在本质上是相似的。一个能够打破这些孤岛的统一方法将显著降低复杂性并提高效率。

实时处理与响应能力

随着对低延迟处理需求的增加，传统的批处理系统已不再足够。如今的用户期望即时的信息供应。这种向近实时响应能力的转变要求新的集成水平。

对于数据工程师而言，实时处理意味着重新思考传统的ETL管道，转向更具事件驱动的架构，实时推送数据。软件工程师必须设计能够处理实时数据流的系统，通常集成AI/ML推理，以提供个性化或上下文感知的响应。对于AI/ML工程师而言，关键在于构建具有最小延迟的模型。

不幸的是，我们仍然离统一批处理和流处理相去甚远。

抽象的力量使跨职能系统成为可能

避免功能重叠的最强大工具之一是抽象。

每个领域都发展出了自己的抽象 – 例如，在应用开发中的用户体验原则，如模型-视图-控制器（MVC）或前端后端（BFF），在数据工程中的ETL管道编排，以及机器学习中的神经网络层。

通过基于通用抽象构建系统，我们创造了一种可以跨学科理解的语言。

考虑一下像数据即产品这样的抽象如何作为共享语言。对于数据工程师来说，数据即产品是由应用程序创建的明确定义的数据集，用于公开和传输给消费者。对于AI/ML从业者来说，它是为模型训练准备的特征集。对于软件工程师来说，它就像一个API端点，为应用功能提供可靠的数据输入。通过创建和消费数据作为产品，各个团队使用相同的语言，这促进了更好的理解。

操作系统（OS）传统上是提供这种基本抽象的基础设施，使其能够为所有特定应用程序同样有效地工作。在我们作为单一学科中的专业工具创建新的基本抽象之前，我们应该仔细考虑是否更好地由基础设施组件覆盖——例如，作为操作系统扩展。

接纳反馈循环

随着学科之间的界限变得模糊，反馈循环的需求变得至关重要。

数据、软件和 AI/ML 系统不再是静态的；它们在不断演变，受用户反馈和分析洞察的驱动。这进一步缩小了开发与生产之间的差距，使系统能够随着时间的推移学习和适应。专注于这种反馈循环的学科通常被称为 observability。

在数据工程中，observability 可能意味着监控数据流，以便进行持续的协作，从而提高准确性和可靠性。对于软件工程师来说，它可以是收集实时应用程序使用情况和用户反馈，以改进功能和用户体验。在 ML 中，反馈循环对于根据新的数据分布重新训练模型至关重要，以确保预测保持相关性和准确性。

精心设计的反馈循环确保所有系统持续优化。这些循环还促进跨职能学习，来自一个领域的洞察直接反馈到另一个领域的改进中，形成一个良性循环，实现增强和适应。

精简您的招聘

日益增加的专业化反映了应对现代系统日益复杂性的必要演变。

虽然专业领域可以带来显著的好处，但它们高度重叠的部分导致了协调和整合的挑战。那些成功协调这些交叉领域的组织——通过依赖健全的架构原则、协作文化和统一策略——将获得竞争优势。

您不需要为企业架构的每一个方面都招聘过于专业化的工程师。仅仅依靠少数具备足够经验的企业架构师来监督跨学科方面是无法成功的。强大的抽象并不是通过生活和思考在孤岛中产生的。必须鼓励工程师跳出框架思考，并理解在企业级别上进化架构的好处。

所有工程师都需要遵循健全的企业架构原则，而不仅仅是架构师。因此，请确保您的IT工程师中拥有广泛的架构知识基础。

不要寻找一个了解所有最新工具的高度专业化的DevOps工程师，而是寻找一个对软件工程有深入了解并懂得如何快速将软件投入生产同时保持最高质量的IT工程师。

朝着统一的工程思维

随着我们工程未来，显然我们的成功依赖于在必要时弥合分离的学科。数据工程师、软件开发人员和AI/ML从业者必须采用统一的工程思维，接受共享的原则和实践，以创建满足业务交叉需求的系统。

我坚信工程的未来是一段协作的旅程。通过在一个共享的框架内工作——模块化、版本控制、近实时响应和抽象——我们为集成系统奠定基础。目标不是消除领域之间的区别，而是利用它们独特的优势，超越任何一个学科的局限。

成功将属于那些能够跨越边界、采用跨职能原则并全面思考他们构建的系统的人。通过利用这些共同的线索进行工程，我们不仅提高了每个领域的效率，还促进了更大的交叉创新和敏捷性。未来是互联的，构建未来的路径始于接受IT工程中的共同原则。