關於公司架構管控的思考

假想背景：
現狀是，各子系統的新建及重大迭代都會形式化地走架構審批流程，但應用架構是否設計以及是否合理，信息技術部門不能掌握。而架構規劃部門的架構師人屈指可數，面對總人數達數百人的開發團隊所負責的幾十子系統、每月數十個迭代特性，沒法作到直接幫助開發團隊詳盡的進行架構設計。由此提出：架構審批流程不表明架構設計、架構規劃部門要增強架構管控。

要作好架構管控，須要可以回答幾個問題：架構管控的目的是什麼？架構管控的目標是什麼？架構管控須要管控什麼內容？如何進行管控？

1、目的

一個穩定發展、創新發展的企業，支援業務發展的信息系統的穩定與效率同等重要。架構管控的目的，要指導各團隊技術負責人設計出合理的系統，可以知足穩定與開發效率的要求，可以知足功能與非功能的需求，可以考慮到各級相關者的意見；而且還要有考察開發過程及運營過程的機制，以肯定最終交付的軟件系統複合架構設計及開展架構設計的持續改善工做。

2、制定目標

爲了達到這些咱們架構管控的目標又是什麼呢？發佈一份指導意見？發佈一份制度說明？發佈一份評分表？
我認爲這些應該歸屬於如何進行管控，而不是目標。
咱們須要梳理現狀，找出主要矛盾，量化主要矛盾，造成目標（SMART原則別忘記～～）

（一）、主要生產問題、客戶投訴及分類

從客戶反饋中能夠抓住主要矛盾。

（二）、信息技術方面的主要矛盾

1. 外購產品 vs 二次改造
   早期從外部採購的產品通常會使用比較老舊的開發框架，進行二次改造困難，常帶來較多故障，而且開發效率低下。
2. 系統解耦 vs 互相影響
   分佈式帶來較好的伸縮性等非功能特性的同時，也帶來了複雜度 —— 系統間相互影響較難控制，給設計和開發增大了難度。
3. 開發團隊對科技公共平臺的不熟悉 vs 強制使用
4. 業務數據模型混亂 vs 新需求

五、控制 vs 創新

（三）、造成架構管控目標

1. 控制新增外購系統的架構方案的合理性、梳理既存外購系統的架構、提高開發效率。
2. 下降分佈式系統的開發難度、提高分佈式系統的交付質量。
3. 下降科技公共平臺的使用難度。
4. 引導、規範新技術的引入。