假想背景：现状是，各子系统的新建及重大迭代都会形式化地走架构审批流程，但应用架构是否设计以及是否合理，信息技术部门不能掌握。而架构规划部门的架构师人屈指可数，面对总人数达数百人的开发团队所负责的几十子系统、每个月数十个迭代特性，无法做到直接帮助开发团队详尽的进行架构设计。由此提出：架构审批流程不代表架构设计、架构规划部门要加强架构管控。
要做好架构管控，需要能够回答几个问题：架构管控的目的是什么？架构管控的目标是什么？架构管控需要管控什么内容？如何进行管控？
一、目的
一个稳定发展、创新发展的企业，支援业务发展的信息系统的稳定与效率同等重要。架构管控的目的，要指导各团队技术负责人设计出合理的系统，能够满足稳定与开发效率的要求，能够满足功能与非功能的需求，能够考虑到各级相关者的意见；并且还要有考察开发过程及运营过程的机制，以确定最终交付的软件系统复合架构设计及开展架构设计的持续改善工作。
二、制定目标
为了达到这些我们架构管控的目标又是什么呢？发布一份指导意见？发布一份制度说明？发布一份评分表？我认为这些应该归属于如何进行管控，而不是目标。我们需要梳理现状，找出主要矛盾，量化主要矛盾，形成目标（SMART 原则别忘记～～）
（一）、主要生产问题、客户投诉及分类
从客户反馈中可以抓住主要矛盾。
（二）、信息技术方面的主要矛盾
外购产品 vs 二次改造早期从外部采购的产品一般会使用比较老旧的开发框架，进行二次改造困难，常带来较多故障，并且开发效率低下。
系统解耦 vs 互相影响分布式带来较好的伸缩性等非功能特性的同时，也带来了复杂度 —— 系统间相互影响较难控制，给设计和开发增大了难度。
开发团队对科技公共平台的不熟悉 vs 强制使用
业务数据模型混乱 vs 新需求
5、控制 vs 创新
（三）、形成架构管控目标
控制新增外购系统的架构方案的合理性、梳理既存外购系统的架构、提升开发效率。
降低分布式系统的开发难度、提升分布式系统的交付质量。
降低科技公共平台的使用难度。
引导、规范新技术的引入。