很多企业都画过架构图。图上有ERP、CRM、数据中台、数据库、接口、服务器和云平台系统之间连着密密麻麻的线。但真正追问时往往没人能讲清这些系统分别支撑什么业务能力哪些功能正在重复建设一项战略调整会影响哪些流程和数据哪些系统应该保留、整合或者下线未来三年的建设顺序是什么问题在于企业画出了IT现状却没有真正建立企业架构。在正式展开之前我整理了一套《数据仓库建设解决方案》包含数据平台建设、数据治理和系统整合等实践内容。正在做数字化规划、数据架构或系统升级的读者可以结合本文一起参考。资料包需要自取https://s.fanruan.com/7igmg复制到浏览器一、企业架构不是一张图而是一套企业设计方法企业架构英文是Enterprise Architecture简称EA。很多人看到“架构”首先想到系统、数据库和服务器。实际上企业架构首先解决的是经营问题其次才是技术问题。它要回答的是企业为了实现战略目标需要具备哪些业务能力这些能力应由什么流程、组织、数据、应用和技术共同支撑例如一家制造企业准备从“销售设备”转向“设备全生命周期服务”。这不是增加一套售后系统就能完成的而是需要一系列联动业务上增加远程监控、预测性维护和服务续费能力流程上打通设备交付、运行监测、故障预警和工单处理数据上采集设备状态、维修记录、备件消耗和客户使用数据应用上连接MES、IoT平台、CRM、工单和财务系统技术上解决设备接入、实时传输、存储计算与权限控制。因此企业架构的本质是把战略逐层翻译成业务能力、业务流程、数据、应用和技术。一套完整的企业架构通常包含四个核心领域业务架构说明企业做什么依靠哪些能力、流程、组织和规则完成。数据架构说明企业需要哪些数据数据由谁负责如何定义、流动、共享和治理。应用架构说明哪些应用支撑业务流程各应用之间怎样分工、集成和协作。技术架构说明应用运行在什么技术底座上以及如何满足性能、安全、稳定性和扩展性要求。四类架构必须能够上下追溯战略决定能力能力依赖流程流程产生数据应用承载流程技术支撑应用。实际盘点时架构图上的数据流不一定等于真实的数据流。某些系统标注为“实时共享”落地后可能仍靠人工导出Excel某项指标声称来自ERP计算时却又拼接了财务和业务部门各自维护的文件。此时可以先用FineDataLink 5.0接入相关数据库、接口和文件把数据来源、同步方向与更新周期跑出来再对照架构图核验。这样识别出的不是“图上应该怎样流”而是数据当前究竟怎样流。二、企业架构和技术架构区别到底在哪里二者最大的区别是观察范围不同。企业架构站在企业整体视角技术架构站在技术实现视角。假设企业准备建设统一客户经营平台。企业架构关心的是为什么要建设客户经营平台它支撑哪些战略目标和业务能力CRM、电商、客服和会员系统怎样分工客户主数据由谁维护哪些旧系统需要整合或退出项目应分几个阶段实施技术架构则继续向下回答系统采用单体还是微服务架构数据库、缓存和消息队列怎样选型服务之间怎样通信如何实现高可用、容灾和弹性扩展身份认证、日志监控和接口安全如何设计所以技术架构是企业架构的一部分但企业架构不等于技术架构。现实中不少“企业架构项目”最后变成技术选型项目讨论云原生、微服务和数据湖却没有说明这些技术究竟支撑哪项业务变化。判断一项技术建设是否必要可以沿着链路向上追问这项技术支撑哪个应用应用承载哪个流程流程形成哪项业务能力能力又服务于什么战略目标如果无法回答技术方案可能只是局部优化还不能称为企业架构决策。三、4C模型是什么它和企业架构不是一回事不少人习惯写“4C模型”更通行的名称其实是C4模型。C4由四个层级组成。Context系统上下文说明目标系统处在什么环境中与哪些用户和外部系统发生关系。这一层不讨论数据库和代码主要回答系统为谁服务、解决什么问题、依赖哪些外部对象。Container容器这里的Container不只指Docker容器而是能够独立运行或部署的应用单元例如Web应用、移动端、后端服务、数据库和消息系统。这一层回答系统由哪些主要单元组成每个单元承担什么职责彼此怎样通信。Component组件继续拆解容器内部的模块。例如订单服务可以拆成价格计算、库存校验、支付处理和通知组件。Code代码深入到类、接口、函数或代码模块。由于这一层变化频繁通常只对核心、复杂或高风险模块绘制不必覆盖整个系统。C4的价值不在于把图画得更细而在于针对不同对象控制信息粒度。管理者看Context架构师看Container开发负责人看Component开发人员再深入Code。画数据平台的Container图时我们项目组会把FineDataLink 5.0作为数据集成单元放入架构上游连接业务数据库、API和文件下游连接数仓与分析平台。继续下钻到Component层才展开数据连接、转换任务、调度依赖和运行监控。这样同一套架构既能说明平台边界也能支撑后续任务设计。但要注意C4是一种软件架构表达方法不是完整的企业架构方法。它能够讲清系统内部结构却不会自动回答战略目标、业务能力、投资优先级和架构治理问题。四、TOGAF是什么重点不是模板而是ADMTOGAF是企业架构领域常见的方法框架其核心是ADM即架构开发方法。ADM形成了一套持续循环明确架构愿景与建设范围设计业务架构设计数据与应用架构设计技术架构识别实施方案和工作包制定迁移顺序与投资计划开展实施治理根据业务变化持续调整架构。很多企业应用TOGAF时容易把它理解成文档目录业务架构做一份PPT数据架构画几张主题域应用架构列一张系统清单技术架构再补一张部署图。真正重要的是建立三种状态之间的关系现状架构当前能力、流程、数据和系统存在哪些问题目标架构未来需要形成什么能力和结构迁移架构从现状走向目标中间需要经过哪些阶段。例如目标是建立统一经营数据平台但当前ERP、CRM和供应链系统不能一次性全部改造。迁移阶段往往先保留原系统通过FineDataLink 5.0建立同步链路将分散数据汇入统一数据层待指标口径、主数据和应用边界稳定后再逐步调整接口和替换旧任务。这里的数据链路不是最终架构本身而是现状向目标过渡时的一部分。没有迁移路线的目标架构只是一张愿景图没有实施治理的架构则容易被项目逐步架空。五、企业架构、技术架构、C4和TOGAF怎样放在一起这几个概念不是竞争关系而是分别解决不同层面的问题企业架构定义企业需要管理哪些业务与IT关系技术架构解决系统运行、集成、安全和性能问题TOGAF指导现状分析、目标设计、迁移与治理C4用分层视图表达软件系统的结构。可以把它们概括为企业架构定义“要管理什么”TOGAF说明“架构工作怎样推进”技术架构回答“技术底座怎样实现”C4负责“系统结构怎样表达”。以供应链协同建设为例企业架构先识别采购协同、交付跟踪和库存共享能力TOGAF用于分析现状、设计目标并制定迁移路径技术架构确定接口、消息、安全和部署规范C4再把供应链平台及内部结构画清楚。进入数据链路建设时采购、库存、订单和财务数据会按照目标架构重新确定流向。实际任务在FineDataLink 5.0中按全量初始化、增量同步、字段转换和调度依赖分别配置架构评审时再结合运行记录检查数据时效、上下游依赖和异常恢复情况。此时架构不只存在于图中也能从具体链路验证设计是否成立。六、企业架构真正落地需要抓住五个步骤第一步从高价值业务问题切入不要一开始就盘点所有系统。可以先选择订单交付周期过长、客户数据分散、库存无法协同等具体问题。场景越明确越容易判断需要哪些能力、数据和系统。第二步建立“战略—能力—流程”关系明确战略目标需要哪些业务能力每项能力通过哪些流程实现并识别能力短板。企业缺少的可能不是系统而是跨部门流程、统一规则或明确的数据责任。第三步建立“流程—数据—应用”关系继续识别每个流程产生什么数据、使用什么数据、由哪些应用承载。这一阶段重点识别三类问题同一能力被多个系统重复建设同一数据存在多个来源和口径流程已经跨部门系统边界仍按部门割裂。第四步设计现状、目标与迁移架构目标架构不能只描述最终状态还要说明哪些系统保留、哪些整合、哪些下线以及每个阶段交付什么业务价值。迁移顺序通常要同时考虑业务价值、技术依赖、实施风险和数据基础而不能只按照系统上线时间排列。第五步把架构治理嵌入项目流程新系统立项、接口调整、数据口径变化和旧系统下线都应检查是否符合目标架构。架构治理不是要求所有项目机械遵守旧图而是持续回答新需求能否复用已有能力是否正在重复建设系统数据责任和来源是否清楚项目是否偏离目标架构原定架构是否已经不适应业务变化架构既要约束项目也要接受项目实践的反向验证。结语企业架构最容易被误解成一张庞大的系统关系图。但它真正要做的是把企业战略翻译成业务能力把能力落实到流程、数据和应用再通过技术建设、迁移项目与持续治理完成实施。企业架构解决整体方向技术架构解决技术实现TOGAF提供推进方法C4负责分层表达。当这四者被放在正确的位置上架构才会从技术部门的图纸变成企业共同判断“为什么建设、建设什么、先做什么、如何持续演进”的决策工具。