實用的解決方案架構交付成果 - Chiu
解決方案架構師在日常實踐中通常做的更多實際示例和可交付成果:
讓我們概述一下覆蓋範圍,
- 每個解決方案都應該從業務問題陳述/目標開始。沒有業務價值,無論您的解決方案多麼強大,它對業務都沒有價值
- 這將是架構願景(有些人將其稱為 IT 願景。但是,根據我的解釋,IT 願景通常是針對企業級別的更高階別的)。它將突出假設和約束,以及高階當前和目標概念架構
- 緊隨高階非功能性需求以捕獲對業務特別是金融業也可能有用的技術需求(例如效能、安全性)
- 最後,這將是解決方案選項和成本估算,這將對業務案例有用並尋求業務批准
業務問題陳述/業務目標
這些業務問題陳述/目標應該來自業務利益相關者,具體取決於您的組織結構,它可能來自 BA(業務分析師)/ PO(產品負責人)。
但是,上述業務相關的方向/內容需要在進行任何技術/架構設計之前得到業務代表的同意、審查和簽字。否則,您可能無法獲得業務支援,或者在更糟糕的情況下,您為業務設計了錯誤的解決方案。
下面列出了每個元件的詳細資訊及其常見的表示形式:
問題陳述——陳述企業的痛點/擔憂。這通常由定義問題或需要解決的新需求宣告的業務使用者編寫/確認
輸出PPT:利益相關者、部門/團隊、業務能力或價值流受到影響的列表,以及優先順序
業務願景——同意架構的高水平預期業務成果和可量化的好處(例如節省成本、增加收入)
輸出PPT:文字描述,帶有圖形/圖表作為補充
業務能力影響——說明新解決方案影響業務能力的領域(例如,運營可能因新系統而改變)
輸出PPT:能力模型或價值鏈圖
變革驅動因素和機遇——確定目標架構實現業務願景的變革驅動因素和機遇。
輸出PPT:實現目標架構的潛在機會列表和影響對目標架構做出的決策的驅動程式
業務目標——說明解決業務問題陳述的原則/目標是什麼
輸出PPT:與每個問題陳述相關聯的業務目標列表,以及技術目標列表,例如現有系統的遷移、退役
IT / 架構願景
在收集了這些業務願景、目標和要求之後,架構師可以開始在高層設計架構,其中包含設計原則、假設、約束和風險。然後架構師將確定它在當前狀態下的樣子(例如現有系統和整合),併為目標狀態起草初始概念架構。
架構假設— 說明在選擇目標狀態下的建議選項時所做的架構假設(例如特徵假設、覆蓋率)
輸出PPT:架構假設和相關領域列表
約束和風險——說明技術限制和相應的風險(例如,特定產品與可能無法實現業務願景的現有系統的可整合性)
輸出PPT:限制和風險列表,如果可能,還包括緩解措施
通常的做法是將假設、約束和風險分組到一個具有不同類別的列表中,但實際上它們也可以單獨捕獲。
當前狀態架構——以視覺化檢視說明當前狀態架構,這將有助於架構師瞭解相關現有系統、資料庫、介面和整合的當前 IT 環境
輸出PPT:架構圖
目標狀態架構——在視覺化檢視中概述目標狀態架構,包括受影響的應用程式、高階資料需求、基礎架構以及將利用/整合的技術元件
輸出PPT:帶有表格/列表的架構圖以補充細節
非功能性需求
一旦您有了目標架構設計,您就應該開始收集非功能性需求 (NFR),這將更好地概述您的解決方案選項和不同方面的成本計算。
可用性——執行時間、可用性要求(例如高可用性 (HA))、是否有批處理視窗、計劃停機時間等。
效能——響應時間和可接受的資料延遲,可能是使用者介面、處理時間等。
Volumes — 預計入站和出站的平均資料量
使用者互動- 使用者數量、併發使用者數量和使用者的位置/辦公室
業務連續性— 高階別災難恢復 (DR) 計劃以及 DR 站點上可接受的事務和使用者數量
安全性——身份驗證和授權要求、資料安全要求(例如靜態資料、傳輸中的資料)、審計控制和資料機密性
操作和監控——操作和監控要求(例如與現有的應用程式監控工具整合)
網路 -網路要求,例如 LAN、WAN 和雲網路要求(例如 VNet、子網)、VPN / ExpressRoute,以及負載均衡器
使用者介面要求——使用者將使用裝置以及裝置的解析度
架構需求——整合需求和環境需求(Dev、QA、UAT、Prod)或 CI/CD 需求
輸出PPT:Excel 中包含類別的非功能性需求列表
解決方案選項和成本估算
透過概念架構設計和非功能性需求,您應該對解決方案的外觀有一個清晰的概念,並瞭解哪些是可行和合適的解決方案選項。
提議的解決方案選項——通用方法將是購買(從供應商處購買現成的產品)vs. 構建(構建自己的解決方案)vs. 混合。考慮到不同的考慮因素和標準(例如許可模式、產品功能能否滿足業務需求、定製解決方案是否過於昂貴),您應該能夠為成本計算和後續步驟列出 3-4 個選項
輸出PPT:不同選項的解決方案圖以及用於比較選項的表格
Costing Estimate —高水平的成本估算,向企業表明該解決方案的成本以及實施多長時間
輸出PPT:帶有成本類別、單位成本、數量、總金額、成本型別(一次性/經常性)的 Excel 成本核算模板,以及高階實施時間表
下一步?
上圖是解決方案架構 101 - 高階流程
回顧上一個故事中的流程,一旦您掌握了所有資訊/設計,團隊應該進入解決方案交付和實施階段。但是,大多陣列織都會有以下過程,
- 業務案例批准,以確保業務收益與所需成本
- 解決方案設計委員會/設計權威,確保解決方案不重複且適合實現願景,同時符合企業 IT 政策
- 安全審查委員會確保 NFR 和安全要求得到明確說明和驗證
所有這些過程都是為了確保設計方案的可行性。不正確的解決方案/設計可能會對組織的金錢投資、時間和精力產生重大影響,有時也會對團隊士氣產生重大影響。
下圖總結了解決方案架構師在其角色和職責中涵蓋的所有關鍵可交付成果,
請記住,每個組織都可能有不同的設計權威/解決方案架構委員會/委員會,這可能需要不同的可交付成果。這個故事只是旨在根據我的經驗列出那些常見/關鍵的可交付成果。希望你喜歡它!
相關文章
- 微軟解決方案架構 (轉)微軟架構
- 揭秘政企安全加速解決方案的架構與應用場景實踐架構
- 阿里雲解決方案架構師,講述分散式架構雲平臺解決方案阿里架構分散式
- BEA推出應用安全基礎架構解決方案(轉)架構
- 微軟解決方案架構(模組八) (轉)微軟架構
- 微軟解決方案架構(模組十) (轉)微軟架構
- 微軟解決方案架構(模組一) (轉)微軟架構
- 微軟解決方案架構(模組四) (轉)微軟架構
- 解決方案架構師的小錦囊 - 架構圖的 5 種型別架構型別
- 使用GPT-4o實現軟體架構解決方案GPT架構
- 企業架構師、解決方案架構師和技術架構師的異同 - Briqi架構
- Spring Cloud 微服務架構解決方案SpringCloud微服務架構
- 微軟解決方案構架(模組七)(1) (轉)微軟
- 微軟解決方案架構(模組七)(2) (轉)微軟架構
- 微軟解決方案架構(模組九)(1) (轉)微軟架構
- 微軟解決方案架構(模組九)(2) (轉)微軟架構
- 微軟解決方案架構(模組二)(1) (轉)微軟架構
- 微軟解決方案架構(模組二)(2) (轉)微軟架構
- 微軟解決方案架構(模組二)(3) (轉)微軟架構
- 微軟解決方案架構(模組五)(1) (轉)微軟架構
- 微軟解決方案架構(模組五)(2) (轉)微軟架構
- 微軟解決方案架構(模組五)(3) (轉)微軟架構
- 微軟解決方案架構(模組六)(1) (轉)微軟架構
- 微軟解決方案架構(模組六)(2) (轉)微軟架構
- F5應用交付容器解決方案如何?看這場巔峰對決
- 交付架構師工作指引架構
- Spring Cloud 微服務架構下的 WebSocket 解決方案SpringCloud微服務架構Web
- 六邊形架構:管理複雜性的解決方案架構
- SOA架構的域控制器測試解決方案架構
- 大資料架構和模式(三)——理解大資料解決方案的架構層大資料架構模式
- 軟體架構師或解決方案架構師必讀的五本書 - javarevisited架構Java
- 架構師必備的那些分散式事務解決方案!!架構分散式
- 講述分散式架構雲平臺解決方案分散式架構
- 微服務架構及分散式事務解決方案微服務架構分散式
- 醫院整合平臺 IT 基礎架構解決方案架構
- IT基礎架構整體解決方案供應商架構
- 前端插拔式 SPA 應用架構實現方案前端應用架構
- SAP開源的持續整合-持續交付的解決方案