如何在问题与变化之间去平衡
一、企业架构的终极目标:从“散乱建设”走向“有序协同”
我们搞企业架构,不是为了画几张漂亮的图,而是要推动一场深层次的变革:构建新型的信息管理职能体系,实现真正的“江湖管控”——即:对信息化建设的全局掌控、有序引导和动态调优。最终目标是实现:“建得起来、连得起来、管得下去”,“充而不散、通而不堵” 的新时代信息化格局。“充”:能力持续增强,系统不断丰富;“不散”:方向统一,标准一致,不碎片化;“通”:数据贯通、流程协同、系统集成;“不堵”:响应敏捷,治理高效,不僵化。这正是企业迈向“IT2.0”或“数字化成熟期”的标志。
二、H 阶段:架构变更管理 —— 让架构“活”起来
在企业架构方法论中,H 阶段通常代表 “架构变更管理”(Architecture Change Management)。它不是可有可无的补充,而是整个架构生命周期的关键闭环机制。因为现实世界是动态的:业务战略会调整,市场环境会变化,项目执行会偏离,所以架构不能一成不变,必须具备适应性与进化能力。
而 H 阶段的任务就是: 系统化地管理所有可能引发架构调整的变化因素。
三、变更的两大来源:我们必须管住这两个“入口”
架构变更不会凭空发生,主要来自两个方向:
- 业务能力需求的变化(自上而下),企业战略调整 → 新的业务目标出现;组织重组 → 职责分工变化 → 能力结构需重构;新兴市场拓展 → 需要新增“国际化运营能力”等。这类变更是“顶层设计驱动”的,必须通过架构调整来响应,否则系统将脱离业务。
- 实施过程中的合规偏差(自下而上),某个项目在建设中发现原架构设计不适用;技术选型受限,不得不采用非标方案;实际业务流程与规划不一致,导致系统无法落地。这类变更是“实践反哺”的信号,说明架构本身可能存在缺陷或滞后,需要修正。
四、变更管理的目的:不是随便改,而是“有规则地进化”
很多人担心:“如果经常改架构,那还叫‘架构’吗?不就成‘草稿’了?”
关键在于: 变更必须通过一个正式、受控、透明的管理流程。我们不是“哪出问题改哪”,而是要:统一受理变更请求;评估影响范围(对其他系统、数据、平台);提出调整方案;由架构委员会决策是否纳入更新;更新后同步传达给所有相关方。
这样做的价值是:保障灵活性:架构能及时响应内外部变化;
保持一致性:所有变更都经过评审,避免碎片化;
积累组织智慧:每一次变更都是对架构的“迭代优化”。
五、好架构是“养”出来的,不是“画”出来的
“好的企业架构,也是通过变更不断‘养’出来的,是国家养出来的。”
这里的“国家”,可以理解为:企业的治理体系、组织能力和集体共识。
就像一棵树,初始设计是“种子”,日常治理是“浇水施肥”,变更是“修剪枝叶”,最终长成参天大树,所以架构不是一次性工程,而是持续演进的过程;架构团队不是“设计师”,更是“园丁”和“守护者”;变更管理机制,就是这棵“架构之树”的生长引擎。
六、总结:H 阶段的核心价值 —— 实现“稳”与“变”的动态平衡
维度 |
内容 |
变更来源 |
|
管理方式 |
建立正式的变更申请、评估、决策、发布流程 |
决策机构 |
架构委员会(跨部门权威组织) |
核心目标 |
既保障架构稳定性,又支持业务敏捷性 |
最终成效 |
架构从“静态蓝图”进化为“动态能力中枢” |
企业架构的真正价值,不在于它一开始有多完美,而在于它有没有一个健康的“新陈代谢机制”。只有建立起科学的变更管理体系,我们的信息化才能真正做到: 既能守住主航道,又能灵活应万变。这才是新时代企业数字化转型的长效机制。
一个真实案例:某特大型政策性银行的实践落地
“这是某一特大型政策性银行在架构评估与变更管理中的实际应用实例”,非常有价值,因为它不是理论模型,而是已经落到实处的运行机制。它向我们展示了:在一个复杂的大型组织中,如何通过流程化、制度化的方式,实现对企业架构的年度审视、动态调整与权威仲裁。
一、变更管理流程的关键触发点
该流程主要由两类事件触发:
1. 年度规划:业务能力需求发生调整,每到战略规划周期(如年度/三年滚动规划),
业务部门提出新的能力诉求;例如:要提升“普惠金融服务能力”、建设“绿色金融评价体系”等。这些新需求可能超出原有架构覆盖范围,就需要启动架构影响评估,判断是否需要调整顶层设计。
2. 治理过程:发现实施项目与架构出现偏差,在项目立项、设计或验收阶段,架构合规审查发现:使用了非标技术栈?未接入统一身份认证?数据模型不符合主数据规范?这类“偏差”不是简单批评了事,而是要进入正式的评估与决策流程,回答一个问题:是项目必须整改?还是架构本身需要更新?
二、变更管理的核心流程:五步闭环
根据该银行的实际运行机制,其变更管理流程可概括为五个关键步骤:
步骤 |
内容说明 |
1. 变更申请 |
由业务部门、项目组或架构团队发起变更请求(ARC, Architecture Change Request),说明背景、动因与建议方案。 |
2. 影响评估 |
架构团队组织评估:对应用、数据、技术、安全、集成等方面的连锁影响,识别风险与成本。 |
3. 方案评审 |
提交至架构委员会进行技术与战略层面的综合评审,多部门协同讨论可行性。 |
4. 仲裁决策 |
委员会做出最终裁定:批准、否决或退回修改;重大事项上报高层决策。 |
5. 更新发布 |
一旦通过,更新企业架构资产(如能力模型、数据标准、技术路线图),并通知所有相关方执行。 |
整个流程通过IT系统在线化管理,确保可追溯、可审计、可协同。
三、这个流程解决了什么问题?
问题 |
解决方式 |
架构僵化 |
允许合理变更,支持业务创新 |
各自为政 |
所有变更必须走统一流程,防止“暗改” |
责任不清 |
明确申请、评估、决策、执行角色 |
信息不通 |
架构更新后自动同步到规划、项目、预算等环节 |
治理失效 |
形成“发现问题 → 评估 → 决策 → 落地”的闭环 |
四、为什么说这是“真正落地”的标志?
很多企业也画了类似的流程图,但停留在PPT上。
而这家银行做到了:
有组织保障:设立专职架构管理办公室(EA Office);
有制度支撑:纳入IT治理章程和项目准入规则;
有系统工具:在架构管理平台中内置变更工单流程;
有决策权威:架构委员会由CIO牵头,多部门负责人组成;
有闭环机制:变更结果反哺下一年度规划与预算安排。
总结:好架构 = 好设计 + 好流程 + 好执行
层面 |
实践要点 |
职能建设 |
架构管理不只是设计,更要承担治理职责 |
流程设计 |
建立标准化的变更申请、评估、决策、发布流程 |
机制运行 |
年度规划与日常治理双通道触发变更 |
组织协同 |
架构委员会作为仲裁机构,保障公平与权威 |
价值体现 |
让架构既能“守正”、又能“出新”,持续服务于战略演进 |
我们就介绍完了八部一法,从接受创建、使用维护。可以说高层做接受,以我们业务驱动作为基本的一个导向,然后四步做创建,两类做使用,变更作为这样的一个脉络,一位一中心八部法,接受靠高层,这是你必须学好的一招。
任何企业都是先是政治后是企业。一般先从政治思维角度自上而下,先去塑造能力的愿景,自上而下,再去推动企业家的创建。然后再变成发育的文化再去进行治理。在这当中我们面对业务需求来讲,我们企业家就是一个引导的关系。引导关系。面对我们业务的信息化的建设实施来讲,我们信息部门是一个什么治理?跟他是一个治理管控关系