企业IT架构治理之道

一、什么是架构和治理

1.1 架构的起源

开篇还是要说说大家理解的架构,何为架构,架构跟我们的工作和生活有什么关系。

英文Architecture本源来自于拉丁语,最早起源于建筑领域,建筑是文明社会一个重要的标志,同时也是人类社会最早形成完善理论和经验的领域。人民在长期的生产生活中,乐于将经验进行总结,希望将具象的场景浓缩成简单的结构和逻辑,附加场景后便于理解和传播,因此架构是对所做工作总结的一个显性成果,后期形成了方法论,用以指导人们在新的生产劳动中不断使用和优化。

     建筑行业跟我们现在从事的科技行业,实际上并无太多交集,但将架构这种方法应用到IT领域,却不得不重点说一下。根据我的观察,虽然我们行业大部分从业人员都或多或少对架构有所了解,但不少人对架构的认知还存在一些误区。由于我们从事的IT行业中,软件占大多数,因此我们更多接触的是软件,软件的基本工作内容即编写代码,实现功能。对一个新手程序员来说,编写软件如同砌房子,给我块砖我就往上垒,垒到头垒到顶就完成工作,架构这件事貌似跟我没关系。但是随着时间的推移,程序员发现,有的时候垒完的墙,还要修修补补,有的时候还要重新垒,为啥会出现问题,大概率就是自己垒的墙跟周边的配合出现了问题,从而引入了架构的思想。对于一些架构师而言,虽然深耕自身领域多年,但又限于仅从技术层面考虑问题,对业务架构、数据架构、安全架构知之寥寥,只能局限在某某领域的架构工作。我们需要知道我们在做啥,别人在做啥,大家一起做的是啥。掌握架构或架构设计也就成为了架构师和Developer需要具备的能力。

     我们探求架构的起源,是为了解释清楚为什么会需要架构,以及现在的IT架构发展是怎样的。这里我们还得把互联网行业单独拿出来,跟传统企业做并行分析,其原因是互联网行业整体的发展历程,是一个相对特殊的存在,因此无论其企业架构,还是IT架构,都与传统的企业不同。传统企业IT经过多年的发展,形成了自身的体系,包括很多经典的企业架构体系和开发方法,全部来源于传统行业和企业,核心IT大多围绕ERP、财务、供应链系统构建。互联网企业大多是ToC场景的商业模式,随着国内人口红利爆发,C端业务高速发展,企业在发展过程中并无太多机会认真审视自身的架构,且传统的IT架构根本无法跟上互联网的业务发展速度,无法借鉴。互联网企业大都是云原生的,云计算、大数据、AI等对企业IT带来的变革,一定是传统企业没有预料到的。传统企业在拥抱新技术和新领域的过程中,意识到并开始改变,并且同步考虑新技术体系带来的管理问题。那么互联网企业有没有思考过自身的企业结构问题,有没有认识到IT架构中隐藏的风险和不合理的地方,并且通过什么方式来管理呢?

1.2 架构与治理

     先有架构,再有治理。治理来源于管理,很多场景中治理是管理的一部分工作,但由于其具备特殊的流程和方法,因此被提炼出来作为一项任务或者活动,治理实际是对管理工作的增强或改进,并且基于一定的目标且要实现确定的结果。也有一种说法是治理是流程、实践、规则和关系的组合。治理与管理的区别如下:

治理通常是由高层或执行管理层来发起,管理是由中层来执行。中层来发起治理是不合适的;

治理可以是阶段性的也可以是长期的,但通常会具备一定的周期,管理则是长期持续的;

治理的价值的是在效益、风险和投入资源之间,找到平衡点,并且保持这个平衡不会被打破,管理则是各自领域的管理活动;



9b4f478a49e94b1f5f26693ea01ba6a3.png



图1 治理价值三要素

     架构治理实际上就是在管理架构的同时,基于特定目标,投入资源对架构管理的过程和结果进行改进,并通过一定的活动保持治理的成果。由于我们所处的行业属于IT这个大行业,因此跟我们自身或者我们的客户相关的架构领域有很多,按TOGAF体系企业架构规划和管理,有业务架构,有应用架构,有技术架构,有安全架构,有组织架构等等,我们把上述这些架构中跟IT相关的部分都归结为IT架构,或者也可以专指应用架构、技术架构、数据架构、安全架构等,当然也有些其他领域的治理工作包括IT架构治理工作,如风险治理、成本治理、业务连续性治理等。

网上定义架构治理是行使经济、政治和行政权力来管理架构的开发和实施,IT架构治理介于企业架构治理和IT架构管理之间,是企业架构管理的一部分。IT体系本身包含丰富的治理内容,其中IT架构治理也是目前最主要的IT治理工作,其目的是保证IT战略与企业战略及业务战略对齐,并能够解决IT建设和运营中的架构问题。



f4f2d68e0041880377081aba4b39353d.png



图2 IT架构治理关系图

结合目前企业数字化最新实践成果,IT架构治理的意义可以总结为以下五个方面,确定了意义,自然也就确定了成果和收益,也就可以申请资源和预算来完成治理工作。

架构治理的意义:

1、  为企业的业务部门提供服务—经济;

2、  规避或者转移企业的风险—政治;

3、  完成上市公司审计要求—行政;

4、  提升客户体验—服务;

5、  不断优化成本—管理;

二、IT架构治理主要标准体系

在IT治理方面,有几个国际标准涵盖IT方面的治理体系和工作内容,一个是从内控COSO承接过来的偏重企业级IT管理和IT风险管理的COBIT体系,一个是偏重于IT服务和流程治理的ITIL体系,以及偏重于IT安全的ISO/IEC17799。同时由于目前企业IT和数字化能力中软件比例越来越大,因此CMMI也包括部分治理内容。COBIT体系除了组织、资产、流程外还引入了IT审计,ITIL体系中主要是侧重IT运营流程的治理,在这些标准中,IT架构治理都是IT治理的核心工作之一。

2.1 COBIT,信息系统和技术控制目标

COBIT作为国际公认的IT管理与控制框架,已在世界一百多个国家的重要组织与企业中运用,指导这些组织有效地利用信息资源,有效地管理与信息相关的风险。作为目前IT治理的核心模型,COBIT包含34个信息技术过程控制,并归集为四个控制域:IT规划和组织(Planning and Organization)、系统获得和实施(Acquisition and Implementation)、交付与支持(Delivery and Support)以及信息系统运行性能监控(Monitoring)。治理工作被列入评估、指导和监控 (EDM) 领域,向下监督管理领域,包括管理域中的计划、构建、运行和监控。

EDM01 确保治理框架的设置和维护

EDM02 确保实现效益

EDM03 确保风险优化

EDM04 确保资源优化

EDM05 确保利益相关方参与



5cc5185b4d4f11161b66029939d1f89a.png



图3 治理与管理的关系

COBIT已成为国际上公认的IT管理与控制标准。

2.2 ITIL,信息技术基础架构库

ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范,企业的IT部门和最终用户可以根据自己的能力和需求定义自己所要求的不同IT服务水平,参考ITIL来规划和制定其IT基础架构及服务管理,从而确保IT服务管理能为企业的业务运作提供更好的支持。对企业来说,实施ITIL的最大意义在于把IT与业务紧密地结合起来了,即IT架构与业务架构保持紧密的联系,从而让企业的IT投资回报最大化。

ITIL框架包含了一系列的文档和指南,涵盖了IT服务管理的各个方面。其中,最核心的部分被称为服务生命周期,包括服务战略、服务设计、服务过渡、服务运营和持续服务改进等五个阶段。每个阶段都具有特定的目标和最佳实践,以支持组织实现卓越的IT服务管理。除了服务生命周期,ITIL还包括其他重要的组成部分,如服务策略、流程和组织、技术和架构等。这些组成部分共同构成了ITIL框架的完整体系,为组织提供了全面而系统的IT服务管理指南,ITIL的治理部分主要在于确保所有的活动都符合价值链,IT架构应持续支撑价值链的存在。

无论是COBIT框架体系还是ITIL体系,都是基于传统IT架构体系,无论是从IT资产还是工作流角度,都从传统IT领域积累了大量经验实践和方法论。近年来,随着IT不断向弹性、集约共享、服务化的趋势发展,上述两个体系也吸收了云化基础设施、敏捷研发、云原生、技术中台、AI等能力,但看来距离国内外具备先进技术能力的大型互联网企业,还是有不少距离。

目前很多企业都开始使用云计算、大数据、DevOps等技术和体系,由于这些领域技术发展快,对技术要求相对高,并且相对传统的企业架构有变化,因此企业架构管理面临着诸多的变化和挑战,IT架构似乎一夜之间发生了很大的变化,企业需要开始应对架构以及治理的变化。

2.3 IT4IT参考架构

     为什么我们会在这篇文章中加入IT4IT,重点还是希望把企业的IT架构治理与IT价值链拉通到一起。IT4IT参考架构是The Open Group的一项标准,阐述了如何对IT业务进行全面管理,在整个IT价值链中实现无边界信息流。它为设计、采购和管理整个IT价值链活动的服务提供了规范性的指导。IT4IT参考架构是一个提高运营效率的蓝图,使公司能够以可预测的最小的成本来提供最大的价值。



400cff8647d80f92d795012f8d6b2378.png



图4 企业IT价值流与架构治理的关系

在企业围绕效率和敏捷构建价值链的同时,架构及相关的治理工作从来不会缺位。尤其是战略到组合,以及发现到纠正,都涉及架构的正确性和持续治理工作对架构工作的保障,因此IT架构治理,一直是企业持续创造价值的重要支撑部分,也是IT能力对业务价值的充分体现。

三、IT架构治理方法

参考了业界先进的IT治理框架,我们需要把相关体系应用到IT架构治理的具体场景。由于企业IT需要服务于企业战略,因此IT架构治理要与企业架构及治理活动保持一致。IT架构治理需要围绕企业自身IT系统和能力,治理体系需要根据企业IT相关的人机料法梳理清楚结构和相互的依赖关系,以及相关的干系组织和影响因素。IT架构应承上启下,既能对接战略输入,又能够指导项目和行动落地。



bf1d972dc44dbc93fea1594534a2b279.png

图5 IT机构治理与影响因素

我们通过结合现代企业架构理论,尤其是互联网等新兴行业IT技术发展给业界带来的新变化,对COBIT体系进行裁剪,并结合ITIL在服务管理的实践、IT4IT在价值链的探索,形成目前相对符合企业数字化场景的IT架构治理体系以及治理架构。



893e470cebb5fd1516cc36af58210802.png



图6 根据COBIT体系改进的IT架构治理组件图

其中,我们把原有的人员、技能与组织合并,与原有的其他组件总结为与IT架构相关的架构五治,即架构治理组织及人员、架构治理原则和标准、架构治理活动、架构治理文化和道德、架构治理工具。架构治理组件之间是不同的,可以分开独立执行,也要支持以整体协同的方式运作。同时,架构治理组件体系也不是一成不变的,会随着架构成熟度、技术成熟度、管理成熟度的提升,组件体系会不断优化。治理组件也可以排定优先级,对于互相之间有依赖关系的组件,考虑到复杂成熟度和影响面,优先开展治理实施。架构治理的最终成果是对组织有益,且支持共享,可以供其他组织或后续的工作使用。

1、架构治理的组织、人员

     架构治理的相关方,决定了架构治理的组织,也能够确定治理最终的价值。每家企业都有一个核心部门,他们掌握着组织的核心架构,他们要能支撑企业的业务发展,并能够申请到足够的预算建设和维护架构体系,让企业能够稳定运行,持续创造价值。IT架构治理属于架构组织的分支部分,多以虚拟组织为主。



756442808915a6b55663446d6d837222.png



图7  IT架构治理组织结构

IT架构管控团队职责:

Ø  明确架构原则及评审标准

Ø  制定架构设计流程,明确架构设计标准和指引

Ø  制定架构设计方案和实施计划,组织架构经理、技术专家等人员进行评审

Ø  建立架构分析质控流程和架构分析质控清单,编制架构整体方案

Ø  建立架构分析变更管理流程,架构分析成果纳入企业级架构资产库进行管理

IT架构治理组织职责:

1)  制定架构治理组织的章程,协作机制等。

IT架构的治理基于共识管理而非绩效管理,通过卓越团队模式,发挥架构治理组织中各级专家和相关方的积极作用,形成治理工作的决策机制,通过共识形成结论,推进架构持续改进。

2)制定委员会运作原则。 

会议:通过定期会议,重大事项临时会议等方式,会议中通过互动引导会议方式

授权:以有意义的方式实施授权,注重实质而非形式

上报:定义并运用了上报程序,如架构治理中的争议部分

     3)IT绩效中与架构相关的部分,在绩效考核中加入IT架构部分内容,包括架构设计、架构管理、架构治理。

Ø  新员工转正考核

Ø  技术体系晋升通道

Ø  技术影响力建设

4)协助IT架构管控团队迭代IT架构成熟度模型。

5)确定架构治理指标,如健康度,完整度,偏离度。

6)架构治理专项活动的评估。

2、架构治理的原则和标准

架构治理原则:

1)架构治理应结合业界技术路线和先进实践,符合企业发展规划和实际情况,如一致性原则、统一性原则、高内聚低耦合、SMART原则,应用领域如应用系统统一为SOA架构,技术平台的中台架构,微服务治理架构等。

2)IT与业务融合,以客户为中心,以创造价值为导向,不创造价值的(业务价值或IT价值)治理活动优先级降低,价值可衡量。

3)鼓励创新和变化,对新技术、新体系要勇于尝试,通过创新来改变原有落后、不合理的架构。

4)IT架构治理既要保持持续性也要保持稳定性,以免对企业IT环境造成波动。

5)IT架构标准化。

6)架构治理能够降低风险,保证安全合规。

7)关注架构的非功能性目标,如灵活性、稳定性和可扩展性等。

8)架构共享,架构迭代原则。

架构治理标准:

IT架构成熟度模型,是结合业界先进实践和标准制定的模型体系,治理组织需要根据企业实际情况对成熟度模型进行裁剪,并不断迭代架构成熟度模型。企业可以定期根据成熟度模型对标企业IT的建设和运行状况,对标可邀请一家或多家第三方机构,以及企业IT部门共同执行。



154a0890fb1c160b6e907f24336d2d96.png



图8 架构成熟度评分示例

架构成熟度定级能够指导企业IT架构确定治理目标和治理成果,是成熟的标准体系,应用广泛。

领域

子领域

1级

2级

3级

4级

5级

云平台 架构

基础资源服务化

各类基础资源未进行服务化,以传统计算、存储、网络等资源形式

部分传统基础资源以标准服务化方式提供

IaaS服务化程度较高,覆盖大部分应用系统要求,具备相关规范和标准

各平台所有基础资源均已服务化,统一以IaaS能力作为应用部署;

跨平台进行基础资源IaaS服务化统一编排,综合考虑应用特点进行IaaS服务适配;

自动化供给

基于传统上线部署流程,手动进行资源供给和部署

部分资源实现快速标准化供给

通过云管理平台和服务目录实现基础资源的快速标准化供给

将基础资源及组件分别形成服务目录

跨云跨平台的统一编排,通过流水线形式进行基础资源的自动化部署和配置

弹性伸缩

传统技术架构,基础资原不具备自动化弹性扩容能力

手动进行资源扩容、部署、上线

利用云平台实现基本的资源弹性伸缩能力

大部分基础资源物具备自动化弹性伸缩能力

支特不同模式和策略的自动化弹性伸缩配置,与监控系统高度集成

高可用

基础服务没有高可用设计

云平台采用高可用架构部署,自身可用性有保证

云平台可提供高可用功能

云平台架构自身基于高可靠性设计

具备跨混合多云的高可用部署能力

表1 IT架构成熟度模型示例

3、架构治理的活动—流程、监控、审计、专项工作

流程相关:流程描述了一组为实现某种目标而安排有序的实务和活动,并生成了一组支持实现整体IT相关目标的输出内容。流程改进不拘泥形式,核心是在合理合规的前提下,高效快捷。

Ø  IT架构治理需要对IT架构相关的活动,以及多项活动形成的流程和流程之间的交互进行管理和维护,包括IT架构的全生命周期,架构增删改弃,架构变更,架构迭代等

Ø  产研活动中,优化与IT架构相关的管理节点,规划、评审、复盘等

Ø  流程改进,如架构治理前置等

Ø  与其他治理活动的协同,如风险治理、成本治理、数据治理等

(注:由于数据治理是一个专业领域,其中数据架构治理是其核心部分,本篇文章未对数据架构治理特别说明,后续会在相关数据治理文章中体现)

监控相关:监控分成两个部分,一部分是对现有架构管理组织负责的架构运行情况进行监控,另外一部分是对架构治理工作进行跟踪和记录。监控通常由架构治理委员会常委会委员轮流执行并输出监控报告,PMO协助。

Ø  监控IT架构组织及其实践,产品和服务的绩效。这样做的目的是确保企业IT架构绩效符合政策和组织治理评估,指导和监控组织的所有活动。

Ø  评估IT组织架构,IT组织与其他方的关系的评估。当利益相关者的需求和外部环境发生变化时,需要定期评估组织。

Ø  监控架构专项治理活动的资源投入,活动过程,预期产出。

Ø  配合审计和内控部门,输出相应的结论和证明件。

Ø  监控工具平台的规划建设。

Ø  架构治理指标的统计分析。

    审计相关:根据上市公司内控需求和SOX法案的合规性管理描述,IT部门的主要职责和

活动应该包括:①深入了解公司的内控项目和财务汇报流程,②确定与内控活动或财务汇报流程相对应的IT系统;③分析和辨别这些IT系统带来的风险,并对此进行监控以保证控制措施的长期效力;④将控制措施文档化和IT化,并进行测试;⑤及时对IT控制进行必要的升级和变更,以配合公司内控或财务汇报流程的变化;⑥全程参与公司SOX法案合规管理项目。

IT架构治理工作需要与IT内审工作建立联动的工作关系,无论是配合内审要求进行的

IT架构调整,还是架构治理工作带来的IT架构变化及所涉及的风险需及时同步到内审部门,合规和降低风险始终是架构治理工作的基础目标。

专项工作:IT架构治理虽然被认为是一个长期持续的工作,但通常都会通过一些重点工作作为发起点,同时专项工作也是IT架构治理的主要活动和主要产出物。专项工作由架构治理委员会指定人员组织实施,并形成专项治理工作报告,报架构治理委员会审议。

Ø  架构设计能力提升专项

Ø  架构质量提升专项

Ø  敏捷研发场景中架构治理专项

Ø  集成架构治理专项

Ø  IT供应商架构能力提升专项

4、架构治理的文化、道德和行为

文化建设:在任何治理工作中,进行文化建设,都是能够起到事半功倍的效果。让工程师们从认知的角度理解架构,实时关注架构,主动优化架构,是架构治理的重要工作内容。管理手段并不都是最优方法,企业的架构管理组织需要完成架构治理文化建设,积极利用文化手段。

Ø  架构质量文化,架构师和研发人员是架构质量的第一责任人,质量问题是所有人的问题

Ø  架构领域的协作文化,打造卓越的架构技术团队

Ø  架构师文化,架构师殿堂、人人都是架构师、架构师委员会

Ø  架构宣传阵地,架构大讲堂,架构公众号,技术说,技术宣传片,架构技术社区,架构圈子

Ø  通过专有流量支持技术文章的传播,提升架构师在业界的影响力

道德和行为:架构师的道德和行为,会对软硬件的设计产生重要的影响,尤其我们设计的软硬件,越来越多的对组织和个人生活产生影响。架构治理工作同样不能忽视对架构师的道德和行为进行引导,必要时需加以约束,并在实际工作中予以考量。

架构师通常是由开发人员成长而来,因此容易将注意力放在产品功能上,常常忽视系统的架构以及周边的关系。需要能够从全局视角,从更高的层级审视全局。

许多架构师都希望证明自己的价值,展示技术才华,并以此提升自己的技术地位和影响力。其实架构师更多承担着管理技术架构的职责,是架构的最终责任人,需要脚踏实地要深入了解系统里各个细节,对架构管理要如履薄冰,谨言慎行。

部分架构师希望自己设计的软硬件产品能够一蹴而就,但事实上架构师需要做的是打造好系统或者产品的基础,使其容易修改和扩展,倾听用户的反馈,不断地在改进中提升能力。

也有些架构师有解决难题的欲望,一遇到问题,就立马陷入解决问题的活动中。而更可取的做法是审视问题本身,看是否可以改变问题,或是干脆绕开问题,很多时候技术上的难题通过业务上的优化是可以避免的。

5、架构治理的工具

IT架构治理涉及两类工具,一类是我们需要治理的工具,如基础设施、技术平台、应用、各类IT服务等平台或系统的架构,另外一类是帮助我们实现治理的工具,如项目管理工具、监控工具、存储工具等。

需要治理的工具示例:

基础设施指在企业中应用IT软硬件技术,支撑整个应用系统和网络运行的基础组件和技术。主要包括机房、服务器、存储设备、网络设备、云计算、虚拟化、分布式计算框架和算法等。这些基础设施为软件的开发、部署和运维提供强大的支持和保障。

技术平台指在基础设施之上,为应用构建提供通用技术能力的组件平台,提供包括数据库、中间件、AI、大数据、微服务等,以及通用技术服务如低代码、RPA、OCR、IOT等。

IT服务指在信息技术领域通过服务化的方式为其用户提供基础设施、软件开发、硬件管理、运行维护等全方位的服务。

IT架构治理不限于上述系统和平台,也不限于与之相关的作业流程,架构治理是长期持续的,但又要兼顾系统的稳定。

支持治理的工具:

项目管理:帮助IT架构治理工作项目能够按照预定的成本、进度、质量顺利完成,而对人员、进度、成本、风险等进行分析和管理的软件。

任务看板:在架构治理计划的启动阶段,将在不同治理活动获得的所有指导意见排列在设计“看板”上,尽可能地解决“看板”上所有要素之间的冲突,并得出最终结论。最终设计将是基于设计“看板”上所有要素的具体决策。通过遵循这些步骤,企业将获得针对其IT架构治理需求的实施成果。

知识管理:通过内网平台协调内部架构规划、架构设计知识分享,能够通过架构存储库获取各类IT架构信息。

监控平台:为全面了解IT架构治理的效果,需要对涉及治理的各级架构系统或平台进行监测,包括工作任务的执行跟踪,系统的事件和日志,指标,平行数据,舆情,业务反馈等。监控平台的建设以数据和事实事件为基础,逐渐形成统计分析体系,结合领域模型和专家经验,形成符合企业实际IT场景的辅助决策能力,并影响企业IT架构管理工作。

架构存储库:为了高效地开发设计IT架构,需要建立一个科学的框架构存储库框架来包含和组织所有的组件,以支持组织各架构域之间的协同,最终实现架构模型的统一维护和模型间依赖关系的统一管理。



7627393932dbab98554e949b5aaf17b5.png



图9 IT架构存储库

全面、系统的建立架构存储库,能够完善IT架构治理机制,更有效的发挥体架构的作用,实现IT架构资产的集中管理,增加架构建模的标准化与规范化程度,持续推进IT架构持续优化和完善。

四、京东IT架构治理实践

近年来,随着国内人口红利慢慢消退,互联网行业的增速也开始下降,原有支持互联网

高速增长的体系也发生了变化。尤其像京东、阿里这样的大型企业,不得不开始思考在没有市场红利的情况下,企业该如何挖掘新的市场机遇,庞大的企业该如何健康可持续发展,遇到变化该如何变革。互联网企业也在向传统行业学习,提升企业管理和治理能力,通过工具平台也初步形成了自身的IT架构治理和管控能力。

4.1 IT架构治理实践:技术业务一体化实践

京东在发展过程中,遇到了两大难题,一是如何通过技术能力迭代来支撑多业态海量业务高速增长,二是如何避免重复造轮子带来的资源和人力浪费。通过具备预见性的规划和脚踏实地的实践,京东在一定程度上解决了上述问题。

1、基础设施领域

在基础设施领域,京东采用了边发展,边治理的方式。京东为了支持其业务拓展,支撑海量业务形态,很早便采用了敏稳结合的技术架构体系,尤其是在云计算、云原生领域,积累了丰富的技术实践。

     京东经历了传统的稳态架构时期,那个阶段的应用系统大多是单体型架构,并且是烟囱式独立发展,系统之间的数据无法打通。后来随着业务的发展,通过物理服务器已无法快速支撑业务,并且成本居高不下,单体式应用也产生了诸多弊端,诸多因素催生了对云化基础设施的需求,于是出现了虚拟化和云化服务能力,用以支撑系统扩展。再后来随着移动互联网爆发,多个场景服务指数级的增长,资源需求也水涨船高,技术底座再次出现了问题。京东采用了基于云原生的容器技术,同时通过微服务的方式完成应用架构的重构。平台快速进行资源发放和回收,同时通过智能调度削峰填谷,提升资源利用率,降低维护成本。微服务统一技术体系实现了组件之间统一标准,统一框架,开发和集成效率大大提升,沟通成本持续下降;DevOps帮助研发团队实现大规模敏捷研发,快速应对市场变化和业务需求。



4fad69fc3c2de6d1be33f7878d9bd0b7.png



图10 京东基础设施架构

2、应用技术领域

应用架构层面,京东采用了业务技术一体化架构,将业务能力抽离出来,形成业务能力中心,帮助业务方、产研侧通过复制和参照以及复用方式,快速构建业务能力,极大提升了业务响应速度,保持业务敏捷能力,同时降低了成本。

业务技术一体化平台的定位:

Ø  帮助企业高效构建业务共享服务中心或应用技术平台,降低架构管理复杂度。

Ø  助力企业核心架构的持续优化、持续沉淀可复用、可扩展的业务架构能力和技术架构能力,加速企业创新,消除数据孤岛,帮助企业实现数字化跨越式的发展。

Ø  引入架构开发管理机制,所有架构开发在主平台上扩展,始终保持架构体系透明,架构能力最优。

通过DDD领域驱动的思想梳理、识别各垂直业务的需求,在一体化平台上沉淀业务矩阵与共享服务能力,并将能力以扩展点的方式进行外放,最终形成企业业务资产,通过不断累积业务资产进行复用创造价值。同时业务架构和技术架构体系遵从平台沉淀的架构,并根据自身要求向平台提出改进需求,平台根据需求及最佳实践完成相应能力升级。

通过一套平台解决架构开发、架构管理、架构沉淀的问题,让企业IT架构与时俱进。



c90f3451fd75b6c3094408e7049b9272.png



图11 业务技术一体化架构示例

4.2 IT架构委员会

京东非常重视技术为供应链领域带来的提质增效,因此对构成技术体系重要环节的IT架构管理和治理,也作为重点工作。京东成立了架构管理组织,其目的在于切实有效的提升技术能力,优化技术架构,保持系统稳定。

IT架构委员会宗旨:在技术创新,影响力打造,稳定性建设,战略落地支撑(降本、创新、稳定)促进组织协同与项目落地,助力业务发展。建立IT技术架构规范和流程,统一认知;发现潜在风险,解决技术债务,提升技术能力;不断提升技术能力,促进技术对业务的向好演进。

IT架构治理工作:

稳定性建设领域:横向拉通各个产品线、职能部门推动产品和基础设施稳定性建设。

1)  故障复盘:所有重大故障,或典型性故障,架委会需进行深度复盘。以此规避因产线内部过于熟悉,而对产品/服务的风险隐患剖析不足的问题。

2)  架构评审:为提升产品和服务稳定性,对重要服务的技术架构进行评审,挖掘其中

设计缺陷、功能不足及风险隐患项,平衡稳定性及成本。

3)  稳定性项目推进:基于各类故障事件的自查回溯,识别各个产品部门的问题进行优

化改进,通过架委会整体推进落地执行。

降本增效领域:横向拉通各个产线、职能部门推动降本提效工作。

1)  成本治理:对产品线各类环境进行盘点,控制成本增长。

2)  流程改进:提升产研运之间工作流程效率,降低非必要的控制节点,提升沟通和协作效率。

技术创新领域:支持公司的创新和技术发展活动,鼓励技术团队提出新的创意和解决方案。委员会提供资源、指导和支持,促进技术创新并推动公司技术竞争力打造。

1) 重点专项:评估项目推进过程中的技术风险点,解决项目落地过程中的技术问题。

2) 可行性论证:如需要在技术上给予突破、创新的技术,可经架委会整体论证,给予专业性建议。

技术影响力领域:参与公司内外的技术沟通和推广活动,包括参加行业会议、发布技术博客、组织技术讲座等。帮助公司树立技术领导地位,增强品牌形象和声誉。

1)  技术分享:定期开展技术探讨和分享活动,提升京东技术影响力;

2)  链接各类技术峰会:通过峰会扩大京东技术影响力,锻炼技术同学综合沉淀和发声能力。同时链接外部前沿技术思想与外部客户,助力京东业务发展。

五、总结

     IT架构治理并非一蹴而就,需要公司高层的重视,中层各部门的配合,执行层面的亲力亲为。IT架构对架构师来说是一个神圣的名词,代表了我们架构师群体对自身事业的敬畏,对客户的尊重,对技术的向往,是我们的修养,是我们的品格,也是我们追求的目标。希望本文能够帮助我们技术群体解决一些萦绕在我们心头的困惑,打开一扇窗,让光照进心里,指引我们前行。

     感谢对本文给予帮助的同事和朋友。

相关推荐

AI 会写代码之后,交付为什么还没变快?

AI 写代码,只是这场变革的起点,而不是终点。真正决定一个组织能否吃到 AI 红利的,不是"能不能用 AI 写出代码",而是敢不敢用 AI 重新设计交付流程、重新划分角色分工、重新组织团队结构。研发视角能把工具和个人推到极致,却会在组织的边界前止步;只有站上组织视角,把AI × 工具一路推进到AI × 组织,那些被 AI 照出来的摩擦,才会真正被抹平。国际技术部 Multi AI Native 想做的,正是这件事——让 Agent 成为你可靠的数字战友,让每一次迭代交付都快一个量级;

京东科技开发者 246

OxygenData-Vibe搭建:用 AI Coding重新定义数据看板搭建

长期以来,数据看板开发主要有两种方式:一种是使用标准化 BI 工具,交付快、成本低,但图表样式、交互体验和功能扩展都受限于 BI 本身的能力;另一种是自研定制开发,能够充分满足复杂和个性化需求,但需要投入大量研发资源,交付周期也更长。比如一个通过 BI 只需要 1 天就能搭建出来的看板,如果采用自研方式,可能需要投入 30 PD 的研发人力。既然 BI 交付这么快,为什么不把所有看板需求都交给 BI?原因在于,业务某些场景需要的不只是把数据展示出来。

京东科技开发者 309

当我谈数据库高可用时我谈些什么

大家都经常听到说数据库的双1,那双1指的是什么呢?参数=1(最安全)≠1(更快但可能丢)每次提交都把 redo 刷盘0/2:攒着刷,崩溃丢最近 1 秒每次提交都把 binlog 刷盘0/N:攒着刷,崩溃丢最近若干条"双 1"(都设为 1)= 单机不丢已提交事务的前提。生产核心库必须双 1;代价是每次提交两次 fsync。小结:单机层用 WAL 提速、用 2PC 保证 redo/binlog 一致、用崩溃恢复裁决半成品事务、用双 1 兜底持久性。

京东科技开发者 271

ScoAI:面向供应链的运筹原生决策智能

ScoAI 关注的并非 AI 能否进入供应链,而是 AI 参与供应链决策之后,哪些内容适合通过数据学习,哪些关系必须显式计算,以及哪些结果需要依据执行记录进行验证。其基本分工是:供应链业务定义问题、资源与行动后果,运筹学表达目标、约束和协同关系,AI 提供可复用的估计与判断。真正用于改进后续决策的,不仅是模型生成的初始结果,还包括实际采取的行动及其产生的业务反馈。

京东科技开发者 367

拆解海博 AI-Native 落地保障:海博团队 AI 知识库能力建设

绕了一大圈,回头看,我们其实一直在解开头那三个结:AI 读不懂系统、影响面靠人脑记、测试预期没处查。做到这里,本质上是把"AI 用不好"这个问题,从"是不是该换个更强的模型"重新定义成了"怎么把上下文经营好"。顺着这个思路,我们攒下了这么几样东西:•。

京东科技开发者 518

从零构建一个生产级记忆型 AI Agent —— AgentScope 项目全景技术与学习指南

domain 层端口接口(domain)职责适配器实现(infra)对话流水账读写经验记忆检索/落库请求级幂等四态会话元数据 CRUD会话级 Skill 选择态Skill 元数据HITL 权限网关(domain 内含逻辑,见第四篇)StreamSink技术中立的流式下沉(client 层桥接)以幂等端口为例,头部注释明确写道:实现 domain 端口,持有实体不出 infra 边界,对外只暴露嵌套视图GateResult。

京东科技开发者 571

数据涅槃:Agentic 重塑搜推数据生产体系

当前大模型已经能够理解需求、生成代码和解释错误,但数据生产的难点并不只是“写出一段 SQL”。一个需求还要经过数据源确认、口径澄清、加工编排、资源规划、任务提交、调度运行、结果交付和故障处置。任何一步缺少都可能让“看起来正确”的任务变成生产事故。

京东科技开发者 337

81.8 秒的视频,我们改了 15 个版本:一次纯 Codex 驱动的 AI-native 视频实践

81.8 秒、15 个版本,这些数字真正想说明什么?视频制作正在从一组专业软件里的复杂操作,变成一场围绕目标、参考和反馈展开的持续对话。AI 已经可以接住从脚本到交付的大量工作。你可以把精力留给更重要的部分:理解观众、选择故事、判断好坏。过去停在 PPT 和脑海里的想法,现在有机会被快速做成一支能看、能改、也愿意转发的视频。如果明天就要介绍你手头的项目,你最想先把哪一步交给 AI?

京东科技开发者 433

Codex 驱动的移动端AI全栈开发:从 Relay 原型图到可交付链路

AI 编程工具降低了跨端开发门槛,但“让 AI 写页面”并不等于“完成移动端交付”。PC 运营端页面通常以功能闭环为中心,设计约束较弱,研发可以基于组件库快速搭建;移动端 C 端页面直接面对用户,Relay 原型图和 UI 设计稿不仅是视觉参考,更是交互、信息层级、状态反馈和业务信任感的综合契约。

京东科技开发者 566

Claude Code vs Codex 记忆体系深度对比

Claude Code —— 分层自动记忆系统四层分层架构(CLAUDE.md / Auto Memory / Session Memory / AutoDream)构成自优化闭环,系统主动捕获、分类、去冗并跨会话接力经验。走的是自动化优先路线——让机器替人记忆、替人整理,以少量可控性的不确定换取强大的经验积累能力。Codex —— 声明式契约系统两层扁平架构(AGENTS.md 静态声明层 + 会话上下文层),记忆完全由人显式订立、显式修改,系统只读契约、绝不擅自变更。走的是可控性优先。

京东科技开发者 605

上游给空、下游拿到 -1,我把故障一直追到了 commons-beanutils 的构造函数

这篇手记是一份事后复盘,写在我们已经把修复推上线、把测试用例跑绿、把约束文档沉淀进团队库之后。非研发同事,可以直接从第八章开始看,前七章都是讲排障和代码分析。故障本身不复杂,修复也不复杂,但这次排查真正让我想写下来的,不是技术本身——而是从问题提报到解决全程AI的作用:问题定位:业务方反馈了一个异常单号说「下发失败」,一线运维同事直接在日志系统捞到相关的系统日志,用IDE打开下游代码库,把异常信息给到JoyCode——AI 直接指向了问题是serialType值非法,系统只接受0和1,而当前上游给的是-1。

京东科技开发者 703

SKill测评:谁才是真正的Skill之王?

巧合的是,阿里近期开源了一款名为 Skill-Up 的测评工具——它专门面向 Agent Skill 开发者,支持在 Claude Code、Codex、Qoder CLI 等真实 Agent Engine 环境中验证 Skill 的功能正确性,并可将失败用例转化为精准的修复指引,同时支持本地与 CI 环境的持续回归。2026年,Skill 的热度不减,已成为 AI 辅助编程领域的标配。在日常研发中,无论是沉淀个人经验,还是将团队的优秀范本标准化,将知识“蒸馏”为 Skill 已是大家的常规操作。

京东科技开发者 618

让AI真正参与工作!JoyDesk已上线京东云

JoyDesk提供覆盖AI资产管理、权限控制、安全策略、审批审计、运营监控等企业级治理能力,支持按组织、角色和项目进行精细化权限管理,并支持私有化部署,确保企业数据边界清晰、AI行为全程可追溯、安全策略灵活可配置,满足金融、政企等行业对数据安全和合规治理的要求,让AI真正成为企业可信赖的生产力。JoyDesk支持MCP协议、标准API、技能等多种开放接入方式,可快速连接企业现有业务系统,将业务能力封装为AI可调用的技能和专家,让AI能够理解业务流程、调用业务系统、完成业务任务,而无需改变企业原有IT架构。

京东科技开发者 652

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手【最终版】

这个项目展示了AI Agent 在垂直内容创作领域端到端自动化:从内容理解到播客输出,全流程 AI 驱动多模态融合:文字、图片、音频、视频统一处理专业级音频质量:音色设计 + 智能混音,输出广播级品质低门槛使用:可视化配置 + 自然语言交互,无需技术背景。

京东科技开发者 556

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手(高级篇)

这是一个 AI 驱动的播客创作助手,专注于从文字/视频/音频内容识别到播客制作的全流程。你可以用自然语言与它对话,也可以上传视频和音频,它会理解意图、调用相应的语音合成工具,把他们变成真实的播客音频。

京东科技开发者 720

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手(进阶篇)

这是一个AI 驱动的音频内容创作助手。你可以用自然语言与它对话,它会理解意图、调用相应的语音合成工具,把文字变成真实的播客音频,并保存在本地。关于项目的详细介绍见第一篇文章:第一个 AI Agent 项目:从零搭建 AI 音频创作助手(入门篇)这篇文章更多介绍进阶篇添加的功能。

京东科技开发者 545

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手(入门篇)

这个项目让我第一次把前端、后端、AI Agent 三块内容独立串联起来。技术选型上每一块都是当下主流的方案,实际跑通整条链路之后对"全栈"有了更具体的感受。框架版本要锁定:LangChain 这类快速迭代的框架,版本差异带来的问题远比你想象的多先跑通链路,再追求完美:新手阶段能把用户输入 → AI 处理 → 结果展示这条链跑通,比深入某个技术点更有价值多看官方文档:相比博客和教程,官方文档更新及时,特别是 LangGraph 这种新框架后续计划继续迭代,欢迎交流!

京东科技开发者 602

ICLR 2026 | 面向序列决策的贝叶斯集成方法

在这篇工作中,我们关注的是。

京东科技开发者 294

ICML 2026|NaviAgent:面向 Oxygen 智能体的可扩展工具编排

大型语言模型(LLM)越来越多地作为函数调用代理,调用外部工具来处理超出其静态知识范围的任务。然而,它们通常一次只调用一个工具,缺乏对任务结构的全局视图。由于工具之间往往相互依赖,这会导致错误累积和可扩展性差,尤其是在扩展到数百或数千个工具时。为了解决这些局限性,我们提出了NaviAgent,一种显式的双层架构,它通过基于图的工具关系建模将任务规划与工具执行解耦。在规划层,基于 LLM 的代理决定是直接响应、澄清意图,还是检索并执行一个独立于工具间复杂性的工具链。

京东科技开发者 383

实测 9 款 AI 架构图工具:从 Mermaid 美化到 GPT-Image2,一份选型清单

支持 5 类图(架构图、工作流图、时序图、数据流图、生命周期/状态机图),主题 4 种(Classic、Signal Flow、Blueprint、Editorial)+ 3 种色彩模式(Dark / Light / System Auto),输出格式含 HTML、PNG、SVG、WebM、Share Card PNG、JSON IR。它把提示词图库、图像生成案例、参考图编辑流程和命令行工具整合在一起,让 AI Agent 能直接调用 GPT Image 2 模型完成文生图、图生图、参考图编辑等任务。

京东科技开发者 895

别再守着 Claude Code 了——学会指挥它自主干活

回到开头那句:别再一句一句地喂它、然后守着屏幕。真正的用法是——把一件事想清楚、划好边界、给它一个能自我验证的目标,然后交出去。你会发现,省下来的时间不是一点半点。把重复的判断和执行还给机器,把真正需要你的判断留给自己。

京东科技开发者 584

CVPR 2026|Oxygen XR 团队在原生鱼眼高斯泼溅技术上带来新突破

京东零售技术团队联合清华大学提出DirectFisheye-GS框架,创新性地将鱼眼相机模型原生嵌入3D高斯泼溅管线,通过跨视角联合优化策略直接处理鱼眼图像,避免了传统去畸变预处理导致的信息损失。该方案在多个公开数据集上达到SOTA性能,有效解决了单视角优化引起的几何畸变和视角不一致问题,同时保持与现有3DGS工具链的兼容性。技术已应用于电商3D重建和4D体积视频等场景,显著提升了沉浸式体验。相关论文被CVPR 2026接收,为宽视场场景重建提供了高效解决方案。

京东科技开发者 353

拆解海博 AI-Native 落地保障:Harness、双 Loop、知识库与技能自主迭代实践

海博研发RoadMap 的落地,彻底终结了 AI 编程“对话式玄学”的旧模式,真正落地了AI Native 研发工程化。它证明 AI 规模化赋能研发的核心,不在于堆砌大模型能力,而在于用工程思维重构 AI 的工作范式:用结构化流程替代随机对话,用固化规则约束模型行为,用持续沉淀实现能力复利,用分层架构支撑规模化落地。

京东科技开发者 633

让 AI 快速「读懂」你的代码仓:Joy-Code-Graph 云端图谱服务的三次进化

代码知识图谱不是要取代 AI 的智能,而是要补齐它对代码全局关系的认知盲区。当 AI 能一眼看清「谁调用了谁、改动会波及哪里」,它写出的代码才真正靠谱;当这份认知安全地留在自己手里、随时被 Joygen 调用、并且永久沉淀在代码仓里——AI 编程的体验,才算真正上了一个台阶。这,就是我们做 Joy-Code-Graph 云端服务的初衷。能力共享,数据自主;一次建图,长期受用。

京东科技开发者 751

【Coding生态】从代码托管到 AI 能力底座:与Coding一起共建 AI 研发生态

前两种框架能够很好地支撑对话式能力和预设流程式能力。它们适合基于提示词或预设工作流完成研发问答、知识查询、流程编排等任务。但在更复杂的研发场景中,仅仅“回答问题”还不够。当用户业务逻辑复杂时,一旦场景进入真实落地阶段,例如下载代码、修改文件、执行命令、安装依赖、运行测试、读取完整代码文件,或者与自有系统联动、将结果渲染到 Coding 页面、推送到京 ME,AI 应用需要的不只是知识能力,还需要真实的代码库操作能力和独立可执行环境。

京东科技开发者 768

GPT-5.6、ChatGPT Work 与 Codex 更新食用指南

三档模型当前都提供 1,050,000 tokens 上下文、922,000 tokens 最大输入和 128,000 tokens 最大输出,接受文本与图像输入、输出文本,并支持 web search、file search、Computer Use、MCP、Tool Search、Skills、Apply Patch 等工具。Work 可以读取你提供的文件,通过插件连接 Slack、Google Drive、SharePoint、邮箱、日历、CRM 或项目系统,调用获批工具,并在执行中展示进度。

京东科技开发者 860

把业务流程沉淀成高质量 Skill 的实践路径

使用Record & Replay创建的Skill,尽管创建流程简单,但它的本质实际是让 AI 去操作页面,这不但有可能影响我们对电脑的操作,还有可能无法稳定复现。创建Skill时,可以使用 Codex 的 Record & Replay 插件,把一次手工操作录下来,再让 AI 生成可复用流程。刚开始切换时,很容易遇到接口报错,可以让Codex排查原因进行优化,直到可以稳定执行;补充相应业务背景,说明这件事为什么要做,谁会用,输入从哪来,输出给谁看。电脑休眠、关机、软件没开时,本地任务可能无法执行。

京东科技开发者 835

政企前台AI-Agent的架构实践:打造可复用的 AI 服务平台-【灯塔计划】

不止是爆火的龙虾,还是各种Skills,MCP、Agent,脱离的具体的场景谈方案,最后只会是一场空。这一套可复用的 AI 服务平台,截止目前,通过前后端对接规范文档,多项能力已快速接入到各个场域的不同端平台,大幅降低研发成本, 并且各业务线新场景的接入从原来的 “开发驱动” 转为 “配置驱动”,接入周期从天维度缩短至小时级。

京东科技开发者 860

京东 Oxygen xLLM 大模型推理引擎正式捐赠开放原子开源基金会,共建国产 AI Infra 生态

下一阶段 AI 基础设施的核心命题,不是简单的算力堆叠,而是让工程本身变得智能——让调度系统能自主感知负载特征并动态优化,让推理引擎能根据模型结构和硬件特性自动生成最优执行方案,让整个 AI 工程链路具备自感知、自决策、自优化的能力。未来,Oxygen xLLM 的项目官网、社区沟通渠道及微信社区将陆续向开发者开放,诚邀芯片厂商、模型厂商、云厂商、企业用户及个人开发者共同参与,让国产大模型推理引擎在开放生态中加速成长。硬件层,原生支持 GPU / NPU / MLU 多类 AI 芯片,深度适配国产芯片。

京东科技开发者 1000

【京东云】全球首个!京东全栈开源JoyAI-VL-Interaction,让大模型从“一问一答”走向“边看边说”

开源一套系统,而不只是一个模型在实时视频流中,JoyAI-VL-Interaction每秒都会做一次判断,比如,继续观察、保持沉默,发现关键事件、主动回应,遇到复杂任务,交给后台Agent处理。一个好的AI 助手,不应该一直打扰用户,而应该知道什么时候该出现,什么时候该安静,以及什么时候自己解决,什么时候交由agent解决。深耕零售、物流、健康、工业等实体产业二十余年,京东拥有全球领先的物理世界运营网络,覆盖仓储、配送、门店、直播、客服、售后海量真实场景,每天都在发生人、货、场的实时互动。

京东科技开发者 1029
上一篇: 一种极简单的SpringBoot单元测试方法| 京东零售技术团队
下一篇: 【京东云新品发布月刊】2024年4月产品动态
京东云开发者
京东云开发者 企业官方账号 企业官方账号
博客等级 码龄8年 1万+粉丝 2139原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值