六角形架構更適合數字化銀行的核心繫統 -FINTECHNA

結構模組化
結構模組化意味著要圍繞業務能力而不是技術設計應用程式，並由專門從事業務領域而不是技術能力的團隊來設計。該原則對於其他行業的專業人員而言似乎是基礎，但在大多數金融機構中卻沒有實現，在大多數基於技術解決方案的組織中，並且業務領域的邏輯分佈在各個層中，例如，一些工作團隊在其中工作在大型機環境中，其他團隊開發BPM解決方案中的流程，其他團隊設計和公開API，等等。
近年來，這種趨勢更加突出。人們並不是不斷開發其核心繫統，而是在其之上新增了技術層，試圖提供新的數字和多通道功能，並且由於其成本和所涉及的風險而始終擔心接觸核心應用程式。實際上，銀行歷史在系統性金融機構中並不缺少業務連續性故障，這是由其核心繫統維護中的錯誤引起的。
由於這種趨勢，維護成本增加了，事件的解決效率和應用程式的發展也受到了影響，因為在以前只有一個團隊負責識別和解決問題的地方，現在有幾個團隊需要協調找出問題的根本原因。
當對業務邏輯的任何修改都需要多個團隊的干預和協調時，這種系統演化策略已經限制了在採用Agile或DevOps實踐以尋求更好的敏捷性方面的巨大努力。
 

運維模組化
應用程式在執行時必須在它們之間具有最小的依賴關係，以確保其服務的可用性和效能。
如果我們考慮在核心銀行系統中處理典型的金融交易，比方說在ATM中使用簽帳金融卡進行現金處理，則很容易發現在一次執行交易執行時，系統的不同元件之間存在數百種互動作用。
例如，如果像大多數一級金融機構那樣，我們考慮在Cobol中實現的核心繫統，則元件之間的這些互動的實現通常將作為整體系統中的COBOL呼叫來實現。當嘗試將此業務功能轉換為雲解決方案時，其中每個元件都將是微服務，如果所應用的設計模式與設計傳統核心系統中使用的設計模式相同，則這些COBOL呼叫將是轉換為例如API Rest，
在這種情況下，很明顯，必須徹底改變應用程式的設計方式，這些方式是一種傳統單體系統，其內部有數百個執行時互動的地方，現在我們連幾個都無法負擔運維維護。
運維模組化不僅對提供良好的效能特徵很重要，而且對於其對成本，維護敏捷性和應用程式演進的影響也很重要。
在敏捷模型下開發的現代應用程式中，很容易找到每日或每週的部署頻率。當我們檢視核心銀行環境中的部署頻率時，我們會發現有些應用程式具有每月甚至每個季度的部署視窗。這些限制的基本原理是由於需要控制部署中的風險。
傳統核心銀行系統中應用程式的高度操作耦合意味著對業務而言不重要的輔助元件修改會影響關鍵應用程式，因此必須將其視為關鍵要素；對於這種低業務價值的應用程式，它們需要廣泛的測試階段和複雜的影響分析。良好的運維模組化消除了關鍵元件和輔助元件之間的執行時依賴，從而顯著減少了系統維護和升級的成本和時間。
 

開發模組化
具有開發模組性的元件在軟體級別上具有最小的依賴性，因此可以部署更改而不會影響其餘元件。大多數核心銀行系統在它們的應用程式之間具有高度的耦合。修改和重新部署某些元素後，它們會將程式和元件從其他應用程式中拖出，從而進行了廣泛的影響分析和迴歸測試，與缺少運維模組性時發生的情況相同。
相同的問題已經在雲的新開發中重現，通常與缺少API版本控制政策有關，但最重要的是，與透過檔案使用介面有關，從而重現了源自傳統系統的設計模式。開發的依賴性是這些傳統核心系統缺乏敏捷性和維護成本高的最重要原因之一。
缺乏開發模組化的一個原因是技術層中的應用程式結構，這些結構由不同團隊，具有不同儲存庫的管理，並且必須協調其部署。
實現核心系統的高可維護性應該是新系統開發中的優先目標，因為維護是金融機構任何開發部門中最重要的成本專案。
核心銀行系統應用程式的生命週期比構建它們的技術要長得多
核心銀行系統支援銀行的關鍵銀行業務流程和產品，例如個人帳戶，卡，貸款等。
這些系統的生命週期為數十年，因為這些產品的業務邏輯不經常更改。由於與客戶互動模型的更改或法規遵從性要求的更改，導致核心周圍發生了重大變化，但是產品的加工過程並沒有發生重大變化。

這些系統的壽命將比其所構建的技術的壽命長得多。
雲平臺的發展是快速而持續的。當今的解決方案，標準和模式將在幾年之內完全被淘汰。這將有必要隨著可用技術的變化來開發應用程式，但是鑑於核心系統支援銀行的關鍵流程，因此任何嘗試更新其開發所基於的技術平臺的嘗試都將面臨巨大的阻力。除非透過正確的設計並透過將業務邏輯的元素與技術平臺本身隔離開來，否則將導致風險。如果不能實現這一點，將給系統帶來嚴重的技術過時風險，並且將迫使金融機構在技術被克服之後很長一段時間內以高昂的成本來支援技術。
 

使用六角形體系結構開發模組化應用程式並具有較長的生命週期
六角形的體系結構幫助我們開發了具有良好上市時間所需的模組化特性的應用程式，並在核心應用程式中實現了預期的使用壽命，從而避免了基於它們的技術的過時。
六角形體系結構是一種眾所周知的體系結構模式，它透過使用介面卡從外部隔離我們的應用程式的資料和業務邏輯，從而生成與技術環境和其他應用程式鬆散耦合的應用程式。介面卡提供功能和技術隔離：

• 功能性：核心域業務邏輯將不依賴於外部資料結構或域語言，而是所有輸入資訊都將轉換為我們域或應用程式的語言。這樣，與其他應用程式的介面資料結構中的更改只會影響整合邏輯，而不會影響應用程式的業務邏輯。
• 技術。業務邏輯不得連結到技術平臺。公開/使用API​​，釋出/訂閱事件或保留資料，無論使用什麼技術服務，都應使用相同的邏輯（相同的程式碼）實現：Kafka，Oracle，mySQL，MongoDB……這可以確保平臺的技術發展將不受它們對應用程式邏輯的影響所限制。

• Rest API的呼叫是透過介面卡進行的，以便將來將Rest API更改為另一個標準時，實現應用程式邏輯的元件不會受到影響。
• 信用管理應用程式在其客戶端應用程式的邏輯結構或資料元素中合併，但將其轉換為自己的內部語言。這樣，如果將來替換或轉換客戶應用程式，我們可以避免對貸款應用程式的業務邏輯造成影響