從零開始做架構圖
2021 年 8 月 31 日

什麼是架構？
“The software architecture of a system is the set
of structures needed to reason about the system.
These structures comprise software elements,
relations among them, and properties of both.”
- Len Bass, Paul Clements, Rick Kazman
Software Architecture in Practice
“The fundamental concepts or properties of a system in its environment
embodied in its elements, relationships, and in the principles of its design
and evolution.”
- ISO/IEC/IEEE 42010:2011
“Architecture should speak of its time and place but yearn for
timelessness.”
- Frank Gehry

Frank Gehry的建築架構風格

企業普遍面臨架構方面的問題
◼ 業務單位過度主導系統發展，技術單位不懂業務發展，你說我
做，導致高度客製化，變成怪獸系統
◼ 沒有目標發展藍圖，沒有明確架構方針，頭痛醫頭，腳痛醫腳，
系統疊床架屋，最終卡死業務發展
◼ 業務領域間互相獨立發展互不交集，系統發展缺乏宏觀面向的
企業架構概念，造成資訊系統與業務發展全部都變成穀倉效應
◼ 穀倉效應下的資訊系統發展間接造成相同的資訊功能重複建置，
造成成本堆疊
◼ 當業務發展往橫向交錯發展時，重疊的資訊系統不易整合，拖
住業務發展，更直接失去數位時代發展所需要的技術彈性
◼ 業務不懂技術，技術不懂業務，數位沖擊下的業務發展缺乏技
術知識，技術人員閉門造車不懂業務應用，變成封閉循環，失
去競爭力
◼ 資訊技術發展多頭馬車各自運作，缺乏統一的技術標準，缺乏
新技術研究能力，也缺乏策略性的引導集中發展關鍵競爭力

企業架構如都市規劃，依長遠目標訂立策略及執行計畫

架構包含了業務架構、資訊架構、與組織架構
目前架構現況 目標架構藍圖
時間線發展規劃
資訊專案執行團隊
階段1 階段2 階段3

TOGAF的企業架構發展方法論
與業務高層討論，取得高階業務發展模式與
方向，並探討目前企業面臨最大挑戰與問題
1
Architecture
Context
以企業架構方法分析業
務架構，查明起點，提
出業務領域架構圖
（Business Domain
Map）
2
Architecture
Context
Architecture
Delivery
分析對應的各層面架構，
產生對應的架構樣貌(As
Is Architecture)
3
依據可能發展的模式方
向，擘劃未來架構藍圖
(To be Architecture
Blueprint)
4
Transition
Planning
沙盤推演執行上的挑戰
與轉型的共生關係，提
出發展執行策略
(Transformation
Strategies)
5
提出執行路徑圖
(Transformation
Roadmap)，並開始執行
6
成立轉型計畫辦公室並追蹤
發展的方案進度，並透過企
業架構治理(Architecture
Governance) 以維持架構完
整性與發展目標的一致性
7
Architecture
Governance
ADM
Architecture Development Method

企業架構團隊由四種架構師所組成
Architecture Content Framework
具業務領域深度知識並熟悉
領域內的業務發展以及完整
端到端生態的架構師，例如:
• 銀行架構師
• 保險架構師
• 投資架構師
具傳統數據分析、大數據
分析、資料架構、數據應
用以及各項數據技術深度
知識的
Business Architect
Data Architect
具特定業務領域的知識，
熟悉該領域資訊系統架構，
並具有高端系統架構設計
的架構師，例如:
• 前端系統架構師
• 核心系統架構師
• 行動方案架構師
Application Architect
具特定高端資訊技術能力，
專注發展特定技術並應用
於企業架構的實施，例如:
• 整合技術架構師
• 平台技術架構師
• 雲端技術架構師
• 資安技術架構師
Technology Architect

從策略規劃到系統實作，各種架構圖的負責範圍
 Use Case/User Story Mapping
 業務架構圖 Domain Map
 資訊架構圖 - 業務架構的事件流
 現有資訊架構位置 - IaaS or PaaS
 架構風格 - 單體式、微服務、事件驅動
 4+1架構視圖 - 說明靜態結構及動態行為
 系統流程圖 - 從UI -> 流程 -> 服務 -> Entity/PO
 開發工具技術框架 – Technology Stack & Version
 DevOps流程圖 - 每個階段採用工具套件和流程
 基礎架構圖 - 網路拓譜圖及實體伺服器資訊
Enterprise Architecture (Chief)
Business Architecture
Application
Architecture
Data
Architecture
Technology Architecture











從「顧客旅程」著手分析目前業務架構
業務架構分析需要取得並
思考的資訊：
1. 哪些客戶?
2. 藉由何種通路?
3. 經過什麼服務和流程?
4. 取得什麼產品?
5. 產品怎麼生產?
6. 如何延續客戶?
7. 後勤怎麼支援?
分析一間公司的企業架構，從拆解這家公司的
商業模式與生態開始，透過客戶歷程的概念，
瞭解該業務的過程，逐步挖出完整企業樣貌。

藉由客戶端Top-down方式盤點出相關系統
整合
服務
通路
企業
後勤
產品
客戶取得商品
企業提供商品
必要時，亦可從企業端後勤支援以Button-up方式同時進行

 業務領域架構圖 Business Domain Map
電子錢包
代收付
企業營運系統
Enterprise
System
產品服務
Product
Service
通路
Channel
電支服務
核心服務
Core
Service
信用卡
綁定
跨境支付
存款綁定
APP
場景應用
集團商品 異業商品
叫車點餐
訊息服務
IM
Email
客戶管理
數位通路
POS
Web KIOSK
分行通路
ATM
3rd Party 通路
街口 Line Pay 其他電支
AML
Fraud Control 黑名單 徵授信
安全風控
帳戶異常交易偵測 終端設備安全偵測
個人帳戶 特約帳戶
個人票券
交易管理
帳戶交易 其它電支交易 外幣交易
票券服務
電子票券
SMS
數據分析
MIS分析報表 業務分析報表
後臺管理
帳戶維護
促銷活動 客戶服務 數據倉儲
BI儀錶板
AI/ML
合約條款
外幣換匯
跨境交易
儲值卡
AR/定位
整合應用
點數交易
終端設備維護
電子發票
廠商管理
商品/服務
票券
合約條款
訊息推播
票券歸戶
紅利點數
TMS資金管理
電子發票
會計總帳 資金水位監控
票券交易
交易清算 決策分析
• 從行動APP和Web
作為電支服務的前
端通路
• 增加票券服務，提
供實體ATM通路和
POS機串接，和其
他電支介接
• 開發場景應用，成
為生活消費入口
• 支援電支所需的客
戶管理和廠商管理，
及必要之交易功能
及資金管理核心服
務
• 伴隨票券服務，除
了異常交易偵測，
也須防詐欺防洗錢
等功能
• 配合場景應用，相
關數據分析也需一
併建置，以便支援
業務應用決策和跨
業合作
R1
R2
R3
R1
R2
R3
R1
R1 R1
R2
R1
R2
R1
R2
R1
R3
R1
R3
R2
R2

依照階段擬定產品建置時程和WBS

 資訊架構圖 - 業務架構的事件流
功能面需求
Event Storming

關鍵架構需求 (ASR, Architecturally significant requirements)
用以收集/分析利害關係人的非功能面需求
以Markdown文字方式記錄，並可入版控追蹤
ASR介紹, https://en.wikipedia.org/wiki/Architecturally_significant_requirements
ASR範例
XXX-ASR 1.1(WBS) 架構需求分析
⚫ 目的與範圍
⚫ 閱讀受眾
⚫ 業務背景
• 利害關係人
• 業務目標
⚫ 關鍵架構需求
• 技術約束
• 業務約束
• 質量屬性需求
• 重要情境
• 具影響力的功能需求
• 重要用戶或用戶角色
• Use Case或User Story
⚫ 附錄A：術語表
⚫ 附錄B：質量屬性分類
⚫ 分析記錄
執行期間質量屬性 開發期間質量屬性
性能、安全性、易用性、
持續可用性、可伸縮性、
互動性、可靠性、強固性
可理解性、可擴展性、
可重用性、可測試性、
可維護性、可移植性

 現有資訊架構位置 - 依非功能面考量
Where?
考量專案非功能需求，業務情境和可
能使用量，依解決方案限制與現有平
台情況決定使用何種平台和技術，並
非容器就比較好，虛擬機就比較差。
IaaS
A Overview of Enterprise IT Technology Architecture
Enterprise API Management
Enterprise Gateway
Web/Mobile Services Partners
Traffic
Outer API
BFF Service
Application
Server
Application
Service
PaaS
Managed Container System
MeshProxy
Inner API
Miniservice
Proxy
Inner API
Miniservice
Proxy
Inner API
Miniservice
Proxy
Inner API
Miniservice
Administration
Portal
Consumers
Channel
Inner API
Service
Inner API
Service
Application
Service
Inner API
Service
Platform API Management
Microgateway
IoTs ChatBot
Enterprise Service Bus
ODS TMS BaNCS CardLink IFX Accounting G/L
DB Pool
DB Pool
Here? Or here?
VM Container
Business Domain Map

 架構風格 - 依非功能需求決定服務顆粒度
Spectrum of Options for Microservices Architecture
Greater development agility, increased deployment flexibility, more precise scalability
Data Store Data Stores
Monolith Macroservices Miniservices Microservices
Monolith
Runtime
Monolith
Runtime Runtime
Data Store Data Store
Service Service
Service Service
Runtime Runtime
Data Store
Greater data integrity, lower architectural complexity
Service Service
Service
RT
Service
RT
Service
RT
Service
RT
微服務忌妒：除非單體式或Miniservices無法滿足非功能需求，避免不熟悉
Microservices架構導致額外的架構設計、程式開發和監控維運管理的複雜度。

 架構風格 - 單體式、微服務、事件驅動
Application Architecture Style
VM
VM
VM
VM
VM
VM
VM
VM
VM
Monolithic/Three-Tier Applications
Published API
Edge Gateway
Microservice A Microservice B Microservice C Microservice D
Microservices
API Service
API Service
Event-Driven Architecture

架構決策紀錄 (ADR, Architecture Decision Record)
避免架構決策，未經討論接受高層指示
• 盲目地接受
• 盲目地改變
任何決策分成
• 可逆決策 - 雙向門
修改成本低，如：API規格、命名規則
• 不可逆決策 - 單向門
修改成本高或無法改變，如：開發框架、選商
以Markdown文字方式記錄，並可入版控追蹤
ADR介紹, https://github.com/joelparkerhenderson/architecture-decision-record/
ADR範例
XXX-ADR 1.1(WBS) 架構決策主題
⚫ 概述
• 問題描述
• 解決方案
• 目前現狀
⚫ 細節說明
• 假設
• 限制約束
• 立場
• 各自論點
• 影響範圍
⚫ 相關資訊
• 相關決策
• 相關要求
• 相關軟體工件
• 相關原理
⚫ 會議記錄

 4+1架構視圖 - 說明靜態結構及動態行為
Architectural Blueprints - The “4+1” View Model of Software Architecture
by Philippe Kruchten(1995/11) IEEE Software 12 (6), pp. 42-50.

 4+1架構視圖 - 說明靜態結構及動態行為
4+1 View Model of Software Architecture 視需要從大輪廓到細部設計
C4 Model: Context, Containers, Components, and Code
Diagramming software architecture using C4 model and C4-PlantUML

建議使用PlantUML，文字檔可入版控追蹤架構變更
@startuml
database "MySQL" as datastore {
[entity]
}
interface "REST API" as RA
interface "DAO API" as DA
interface "Batch API" as BA
[Angular] ..> RA : use
RA - [Service]
[Service] ..> DA : use
DA - [Spring Data JPA]
[Spring Data JPA] - BA
[Spring Data JPA] ..> [entity] : JDBC
[Batch Service] ..> BA : use
[Cron Job] ..> [Batch Service] : trigger
@enduml

 系統流程圖 - 從UI -> 流程 -> 服務 -> Entity/PO

 開發工具技術框架 – Technology Stack & Version
Tier Client Client Client
Presentatio
n
Business Persistence Integration Data Source Analysis Security
Layer Mobile Web Desktop Reporting
Application
HTML5,
CSS3,
JavaScript
Java SE 8 Java SE 8
Framework
Angular 8 Spring Boot
REST API
Spring Boot
Spring
Security
JPA Apache
Camel
Infrastructure
Software
Nginx Tomcat 9 Tomcat 9 AWS
DynamoDB
Container AWS EKS AWS EKS AWS EKS
Operation System
AWS Linux
OS
AWS Linux
OS
AWS Linux
OS
AWS Linux
OS
Virtualization
AWS EC2 AWS EC2 AWS EC2 AWS EC2
Hardware x86 x86 x86 x86
Storage HD HD HD HD, SSD
Network HTTPS HTTPS HTTPS SFTP TLS 1.2

 DevOps流程圖 - 每個階段採用工具或套件
DevOps Pipeline
Library &
Container
Source
Control
Dev Security
PPM
Auto
Build/Deploy
Quality
CI Runner
未來將使用
目前已使用

 DevOps流程圖 - 每個階段開發部署流程

 基礎架構圖 - 網路拓譜圖及實體伺服器資訊
10.0.0.2
10.0.1.0 10.0.2.0
10.0.2.100
10.0.1.10
10.0.0.254
10.0.1.1 10.0.2.1
10.0.5.0
10.0.1.30
10.0.1.50
10.0.2.10
10.0.2.30
10.0.2.50
10.0.2.200

感謝聆聽
Q&A