摘要：由此提出架構(gòu)審批流程不代表架構(gòu)設計架構(gòu)規(guī)劃部門要加強架構(gòu)管控。開發(fā)團隊對科技公共平臺的不熟悉強制使用業(yè)務數(shù)據(jù)模型混亂新需求控制創(chuàng)新三形成架構(gòu)管控目標控制新增外購系統(tǒng)的架構(gòu)方案的合理性梳理既存外購系統(tǒng)的架構(gòu)提升開發(fā)效率。

假想背景：
現(xiàn)狀是，各子系統(tǒng)的新建及重大迭代都會形式化地走架構(gòu)審批流程，但應用架構(gòu)是否設計以及是否合理，信息技術(shù)部門不能掌握。而架構(gòu)規(guī)劃部門的架構(gòu)師人屈指可數(shù)，面對總?cè)藬?shù)達數(shù)百人的開發(fā)團隊所負責的幾十子系統(tǒng)、每個月數(shù)十個迭代特性，無法做到直接幫助開發(fā)團隊詳盡的進行架構(gòu)設計。由此提出：架構(gòu)審批流程不代表架構(gòu)設計、架構(gòu)規(guī)劃部門要加強架構(gòu)管控。

要做好架構(gòu)管控，需要能夠回答幾個問題：架構(gòu)管控的目的是什么？架構(gòu)管控的目標是什么？架構(gòu)管控需要管控什么內(nèi)容？如何進行管控？

一個穩(wěn)定發(fā)展、創(chuàng)新發(fā)展的企業(yè)，支援業(yè)務發(fā)展的信息系統(tǒng)的穩(wěn)定與效率同等重要。架構(gòu)管控的目的，要指導各團隊技術(shù)負責人設計出合理的系統(tǒng)，能夠滿足穩(wěn)定與開發(fā)效率的要求，能夠滿足功能與非功能的需求，能夠考慮到各級相關者的意見；并且還要有考察開發(fā)過程及運營過程的機制，以確定最終交付的軟件系統(tǒng)復合架構(gòu)設計及開展架構(gòu)設計的持續(xù)改善工作。

為了達到這些我們架構(gòu)管控的目標又是什么呢？發(fā)布一份指導意見？發(fā)布一份制度說明？發(fā)布一份評分表？
我認為這些應該歸屬于如何進行管控，而不是目標。
我們需要梳理現(xiàn)狀，找出主要矛盾，量化主要矛盾，形成目標（SMART原則別忘記～～）

從客戶反饋中可以抓住主要矛盾。

外購產(chǎn)品 vs 二次改造
早期從外部采購的產(chǎn)品一般會使用比較老舊的開發(fā)框架，進行二次改造困難，常帶來較多故障，并且開發(fā)效率低下。

系統(tǒng)解耦 vs 互相影響
分布式帶來較好的伸縮性等非功能特性的同時，也帶來了復雜度 —— 系統(tǒng)間相互影響較難控制，給設計和開發(fā)增大了難度。

開發(fā)團隊對科技公共平臺的不熟悉 vs 強制使用

業(yè)務數(shù)據(jù)模型混亂 vs 新需求

控制新增外購系統(tǒng)的架構(gòu)方案的合理性、梳理既存外購系統(tǒng)的架構(gòu)、提升開發(fā)效率。

降低分布式系統(tǒng)的開發(fā)難度、提升分布式系統(tǒng)的交付質(zhì)量。

降低科技公共平臺的使用難度。

引導、規(guī)范新技術(shù)的引入。