如果直接談「企業架構」，也許很多圈外人會把它擴大化，畢竟對於乙個企業的「頂層設計」而言，企業架構主要是組織架構、生產架構，行政架構等，而我們圈裡人談的「企業架構」其實主要指的是「企業資訊架構」。
\ 作為我國企業資訊架構風向標的「金」字頭專案，他們在2023年體現最明顯的不是雲計算、大資料、列儲存等技術的引入，關鍵在於切入點的轉變。
\ 我們知道，一般資訊系統建設都是從以業務需求收集和分析入手、從企業高層的戰略目標入手，cio需要解決的問題基本上是業務高層的談到的一系列「我們要」、「我們決定」、「我們希望」，但在2023年光憑這個切入點似乎不足以成為大型「金」字頭專案立項的基礎，因為這些指標它無法體現作為大型企業、超大型企業資訊系統如何滿足「社會關切」的問題。
\ 下面看乙個簡單的例子
\ 以往：
\ 1、 在人力基本不變的情況下，我們需要借助該系統實現每年多查獲100萬件食品安全事件，多受理5萬件相關案件。
\ 2、 系統公升級後，每年**訂票數量增加400萬、**訂票數量增加200萬。
\ 現在：
\ 1、 在人力基本不變的情況下，我們需要借助該系統將食品安全事件的受理時限從1天縮短為15分鐘，通過食品**鏈透明化每年食品安全事件發生率降低10%。
\ 不知你是否發現兩者最大的區別？\
其中，標準流程位於「zachman framework enterprise architecture」部分，但現在必須外延到「服務物件關切」部分，儘管傳統的「上下文」部分本應該包括這些內容，但在實際操作中往往會「走樣」成「我們要」的情況。架構其他規模、其他型別的企業資訊系統時這個思路同樣適用。
\ 進一步，可以將上述過程與領域設計分析結合，根據分析內容與業務的相對「距離」漸次展開：
\ \ 以上面的業務關切為例：
\**訂票平均處理時間降低到5分鐘/呼叫、五年內降低到2.5分鐘/呼叫
\ 先做外部領域的企業架構分析：
\ what：**訂票
\ why：原因比較明顯，誰願意花費幾十分鐘甚至幾個小時訂票？
\ how：降低訂票手續的繁瑣程度，減少等待時間、諮詢時間、選票時間
\ who：乘客、接線員
\ where：手機、固定**
\ when：全年服務時間
\ 最終需要圍繞「**訂票平均處理時間降低到5分鐘/呼叫、五年內降低到2.5分鐘/呼叫」這個既定的量化目標分析，為了滿足這些要求外部應該滿足什麼條件，相應的對企業內部資訊環境要求是什麼。
\ \ 以5分鐘完成**訂票的「關切內容」為例，如果通過分析必須將「等待時間」限制在0-1分鐘、「諮詢時間」限制在0-1.5分鐘，「選票時間」限制在0-4分鐘，相當於我們就必須對企業內部各相關應用、資料、網路的架構設計提出明確量化要求，同時對於各關聯系統的處理效率、資料oltp響應時間、網路往復時間提出明確要求，然後這些要求轉化為傳統的企業架構設計中「戰略」、「業務」設計要求時就更具目的性，這個過程就好像常說的「換位思考」。
\ 2023年由於專案立項申請方式的轉變，一些「金」字頭的企業資訊系統架構開始走「先換位思考，再設計企業資訊架構」的過程，這個過程的積極意義如下：\
不過，空談「換位思考」比較容易，但做到很難，實踐中較為現實的方式除了直接面向使用者進行調研外，考察服務物件的「對口系統」也是不錯的方式，以往我們常說團隊需要溝通，其實具有互聯關係的內、外部企業資訊架構之間又何嘗不是呢？
\
\架構設計小思
現在做系統越來越傾向於把系統與外界的互動設計的很薄，和封裝一層很薄的一層 為什麼呢？下面是我自己的原則 controller 只會跟 http 有關的東西進行處理 嚴禁把 res,req 對像以任何行式傳入 service。controller 會對 http 方法的請求引數，cookie,sess...
企業資訊化IT架構方法
一 頂層業務架構 上 打通上游 商 中 打通內部各業務部門 打通各業務部門和財務部門 中 打通各地區域 分支機構 下 打通倉儲物流 渠道分銷 服務商 外 打通電子商務 外 打通最終消費者 二 頂層業務建模方法 1 戰略分解法 三年規劃 今年戰略目標 明年戰略目標 今年戰略目標行動方案 2 組織流程法...
微服務架構設計實踐系列之三 軟體架構設計思想
微服務架構設計實踐 目 次 1 序言 2 微服務 3 軟體架構設計思想 4 微服務架構設計實踐 4.1 專案概述 4.2 架構準備階段 4.3 概念架構階段 4.4 細化架構階段 4.4.1 業務架構 4.4.2 資料架構 4.4.3 應用架構 4.4.4 技術架構 4.4.5 物理架構 4.4.6...