資訊專欄INFORMATION COLUMN
摘要：由此提出架構審批流程不代表架構設計架構規劃部門要加強架構管控。開發團隊對科技公共平臺的不熟悉強制使用業務數據模型混亂新需求控制創新三形成架構管控目標控制新增外購系統的架構方案的合理性梳理既存外購系統的架構提升開發效率。
假想背景：
現狀是，各子系統的新建及重大迭代都會形式化地走架構審批流程，但應用架構是否設計以及是否合理，信息技術部門不能掌握。而架構規劃部門的架構師人屈指可數，面對總人數達數百人的開發團隊所負責的幾十子系統、每個月數十個迭代特性，無法做到直接幫助開發團隊詳盡的進行架構設計。由此提出：架構審批流程不代表架構設計、架構規劃部門要加強架構管控。
要做好架構管控，需要能夠回答幾個問題：架構管控的目的是什么？架構管控的目標是什么？架構管控需要管控什么內容？如何進行管控？
一、目的一個穩定發展、創新發展的企業，支援業務發展的信息系統的穩定與效率同等重要。架構管控的目的，要指導各團隊技術負責人設計出合理的系統，能夠滿足穩定與開發效率的要求，能夠滿足功能與非功能的需求，能夠考慮到各級相關者的意見；并且還要有考察開發過程及運營過程的機制，以確定最終交付的軟件系統復合架構設計及開展架構設計的持續改善工作。
二、制定目標為了達到這些我們架構管控的目標又是什么呢？發布一份指導意見？發布一份制度說明？發布一份評分表？
我認為這些應該歸屬于如何進行管控，而不是目標。
我們需要梳理現狀，找出主要矛盾，量化主要矛盾，形成目標（SMART原則別忘記～～）
從客戶反饋中可以抓住主要矛盾。
（二）、信息技術方面的主要矛盾外購產品 vs 二次改造
早期從外部采購的產品一般會使用比較老舊的開發框架，進行二次改造困難，常帶來較多故障，并且開發效率低下。
系統解耦 vs 互相影響
分布式帶來較好的伸縮性等非功能特性的同時，也帶來了復雜度 —— 系統間相互影響較難控制，給設計和開發增大了難度。
開發團隊對科技公共平臺的不熟悉 vs 強制使用
業務數據模型混亂 vs 新需求
5、控制 vs 創新 （三）、形成架構管控目標控制新增外購系統的架構方案的合理性、梳理既存外購系統的架構、提升開發效率。
降低分布式系統的開發難度、提升分布式系統的交付質量。
降低科技公共平臺的使用難度。
引導、規范新技術的引入。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11968.html
摘要：每秒實時處理超過萬項監控指標，讓異常無所遁形。此外，對于復雜數據庫故障事后排查故障根源現場還原歷史事件追蹤也迫使我們建設一個覆蓋線上所有環境數據庫實例事件的監控系統，做到覆蓋阿里全球子公司所有機房。所有性能指標做到秒級連續不間斷監控。 摘要： 2017雙11再次創下了32.5萬筆/秒交易創建的紀錄，在這個數字后面，更是每秒多達幾千萬次的數據庫寫入，如何大規模進行自動化操作、保證數據庫的...
摘要：解決方案如圖所示，將軍令分塊，數據內容權限平臺審批流平臺審計日志平臺提供各種靈活可插拔的服務，支持在通用服務的基礎基礎上進行定制開發。 背景 在大數據時代，數據已經成為公司的核心競爭力。此前，我們介紹了美團酒旅起源數據治理平臺的建設與實踐，主要是通過各種數據分析挖掘手段，為公司發展決策和業務開展提供數據支持。 近期，業內數據安全事件頻發，給相關企業造成了無可挽回的損失，更為數據安全防護...
閱讀 3450·2019-08-30 10:54
閱讀 3147·2019-08-29 16:38
閱讀 2165·2019-08-26 14:06
閱讀 1511·2019-08-23 15:39
閱讀 3033·2019-08-23 15:37
閱讀 2882·2019-08-23 13:50
閱讀 3189·2019-08-22 17:14
閱讀 2374·2019-08-22 15:44
