目前就在做所謂的"中台",
大致上就像你說的一樣.只不過我覺得這種責任分屬....
這些各自為政的系統,原本都是各組自己有一套商業邏輯,
他們有很多table和排程去維持系統運作
但是當要把它們拆出來變成"中台"時,
(1)
我要先根據業務單位的需求文件(ex:user看到的前台畫面)
去推敲出我需要提供什麼樣的api給前台串接
(2)
然後跟此後台系統的同仁詢問,如果要做這些東西,
我需要哪些table,增刪查改大概要怎麼做
(同仁只會提供你一個大概,因為這些需求都是新的,
等於是我中台人員需要去了解各系統的業務和排程運作方式,
以及他們各個table是在幹嘛的.而且這東西根本不可能講清楚,
開發時我會看著這些table資料的變化,自己推測他們程式邏輯)
(3)
之後測試以及後續上線時,如果有問題(客人看到數字算錯,還是資料查不到)
都是我這邊優先來解決(因為給前台串接的api是我寫的)
當這類系統越做越多,會發現原組別的loading好像慢慢地都堆到中台身上
而且後續要修改也牽涉到一堆問題,
比如說商業邏輯要調整時,原組別的後台程式要修改,我這邊也要配合修改
還是說我這不是"中台",而只是another"後台"而已..?
※ 引述《aoshiken (三十六雨風飄搖)》之銘言：
: 之前在金融業工作過一段時間
: 我也是在金融業才聽過"中台"
: 分享一下中台的存在價值
: 首先 銀行系統後面很多各自為政的系統 像卡系統 貸款系統 存款系統...etc
: 大部分都只能活在內網 不可以接到外網 而且輸出格式五花八門...
: 中台的存在意義 就是在這些系統上面架一層統一的web service
: 讓app,網頁甚至是外部協作系統可以方便取得對應的資料
: 所以通常中台出來的資料都是統一的json格式
: 但是它們吃到的資料真的是五花八門 有json 有 xml 還有鬼txt之類的東西