GDS Digital Service Manual 中文翻譯網站 (beta)
by HPX-GOV 英國政府數位服務研究小組 GDS Study Group
Home » 英國政府數位服務設計手冊 » CTO 指南 (Guidance for CTOs) » 技術架構 (Technology architecture)

技術架構 (Technology architecture)

架構不只是技術的設計和部署 – 要成功,你需要了解這些元素如何一起工作。

這些元素包括:

  • 高層次的商業願景和由使用者的需要引導而設計的流程和系統(因為業務需求會隨著時間而改變,所以在設計的解決方案時,需要最小化這種變化的影響)
  • 一個涵蓋公共和私有資料的資訊模型,以及諸如商業智能等更廣泛的資訊管理需求
  • 技術,核心功能的塑造,它們的結構和關係
  • 執行,包括指導方針、模式、藍圖、模型和社區的發展和應用,以確保跨多個大型計劃和専案執行和遵守的一致性。
  • 在整個専案的生命週期中,您將需要確保利害關係人在需要上保持一致(當利害關係人的需求與企業的成長衝突時(如降低成本)、系統設計(如網絡延遲(network latency) )和營運問題(如安全,隱私和稽核),你將需要解決以上的問題)

“架構”包括邏輯設計以及其具體的實作。邏輯架構是基於以使用者為中心的服務設計(user-centric service design)和清晰的使用者需求(user needs),並且應該總是優先於實體架構。在聚焦於產品選擇前,你至少需要了解需要哪些功能( what capabilities are required)

技術作業規範(technology code of practice)中提供了跨政府一致使用的技術指南。

我們的參考模型

我們的參考模型借鑒了現代的平台基礎的架構(platform-based architectures) 。我們應該利用網際網路組織的高擴展性開放平台模型,並借鑒其他國家的政府的實踐經驗,例如愛沙尼亞(Estonia)

圖中顯示了政府的架構參考模型

注:舉例僅僅用於說明目的。

我們的架構將需要擺脫緊耦合和專有模型,使用開放標準開放介面 而成為開放的、可互操作的架構,例如以XML和JSON為基礎的資料服務,以最大化提高政府的靈活性和增進的服務的交付速度。

我們應該努力做到:

  • 避免資料擁有權的重複 – 以預防同步、資料品質、安全性和隱私等問題
  • 限制開發工作的重複 – 防止跨多個専案在處理共通資料、使用者和流程時的持續重覆開發
  • 只要有可能(根據三的法則(rule of three)測試 “),我們將使用和再使用,使用開放標準的標準、可互相操作的組件、介面、資料格式和流程。

當用來優化使用者體驗時,重複是可以的(但是如果這資訊本身是重覆的,應該有明確的主從資料關係,例如,考量到性能而使資訊重覆)。

產品和服務

產品和服務是使用者參與了查找資訊或完成交易的事情。因此,它們應該被依最終使用者的需要而設計,而不是服務提供者的需求。它們可以是Mission IT(對內的)或數位公共服務(Digital Public Services)(對外的)。

產品是: 產品是不是:
以使用者特定的方式設計和開發,以符合:

  • 一組使用者需求,並且可以由這些需求被滿足的程度進行衡量
  • 政策的結果
詳細闡述了內部組織結構
在持續評估和改進下,進一步精煉服務的品質:“是不是滿足使用者的需要?” 特定的應用程式/產品之類狹義定義下的產物,即不是Microsoft Dynamics、Oracle e-business suite,或DropBox
使用者參與的單一接觸點,由使用者需求驅動 時間固定但為演化而設計,以滿足不斷變化的需求
服務經理(service manager) (使用者代表)的責任,不一定是所屬部門的責任:管理架構(reporting lines)應根據產品和使用者需求(與管理所帶來各方面的影響)設計
透過基於使用者需求和政策而定的清晰的產品路徑圖和時間表所引導

平台

平台提供了一套開放的介面、協議、資料格式和工具,使軟體開發人員能夠快速地提供產品和服務。

平台的例子是GOV.UK發佈平台、性能平台以及身份保證平台-他們不是“Windows Server”或“Linux Server”。

平台應盡可能地保持簡單,但必需以沒有擴大和向外擴展的障礙而設計。新的功能應該只在新的產品需求必要時被加入-平台由產品的需求出現,而不是由上而下的架構推動 。

了解更多關於政府平台

舊有系統

“舊有系統”代表既存的被設計來符合過去需求的IT系統和組件。通常,它們使用的技術已變成昂貴或難以維護或變更。

舊有應用程式的例子,像是span benefits systems、案件管理系統和客戶關係管理系統。隨著時間的推移,新平台的成功開發應該減少對舊有平台上的相依性。

為了減少對舊有平台的相依性:

  • 新的使用者服務,必須把握機會,以減少對舊有系統的相依性,並且新的大型計劃必需盡可能避免花費在與舊有系統整合的無價值支出
  • 這種系統的規模、維護成本以及業務重要性要不斷下降,也就是說,它們的存在是為了滿足當前的特定需求,但不應該是未來的投資的重點
  • 各部門要清查現有的系統狀況並且計劃遷移/減輕現有系統(依“不合時宜且不堪使用(old and broke)”、“不合時宜但堪用(old and works)”及“淘汰(defunct)”分類),以確保價值被釋放:
    • 應包含設計不佳的系統
    • 仍可使用的舊有系統應該被重新整理,以降低成本和風險,並且需要有開放的介面與新平台互動(interoperability)。
    • 舊有系統應該被更換或是定期檢視設計,以避免應用系統因為變得過於龐大複雜,讓人無法理解而無法維護,或維護費用過於昂貴而無法由其中穫益。
    • 系統和部門之間的互相操作(interoperability)必須使用開放標準,使用連接器(adapters)來整合現有的主機系統,程式,訊息和資料(例如,從本身不支持開放標準的大型主機到企業服務) – 應該避免在系統間的點對點定制整合(point-to-point bespoke integration),以降低成本以及內部相依性(inter-dependencies)

翻譯:Sharon Wang
校稿:
原始出處:https://www.gov.uk/service-manual/technology/architecture/

請留言

你的email信箱不會被發布出來. Required fields are marked *

*

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料