最近剛完成了半導體龍頭AI數位轉型大解密的封面報導,一口氣整理了護國神山過去30年來,如何一步步,在2000年邁入全自動,2012年發展出整合平臺和大數據分析,到了2016年更進入了智慧製造第三階段,更獨家披露了他們持續聚焦的數位轉型5大領域、AI應用4大布局和IT基礎架構3大工作重心。

出刊後不久,有天早上,一位在光電產業擔任高階主管的大學同學,突然打電話來,想分享一下,他讀過這期封面後的感嘆。

「護國神山之所以能大力發展AI,前兩階段的打基礎非常重要,」他向我解釋,相較於邁入先進製程的晶圓廠,光電產業的工廠相對規模較小,機臺自動化程度也較差,甚至有些老舊產線設備,才剛脫離手動操作的階段。不少高科技公司,大多還在自動化發展和大數據蒐集和分析的階段。

但更令他敬佩的是,這家龍頭直接用AI來優化晶圓廠,而不是用AI來輔助晶圓廠的優化。我不解,這有何不同?前者是,廠務工程師「放心相信」AI告訴他的優化參數是對的,但後者,則是還要靠人複查後才執行,兩種作法帶來的效率截然不同。

「他們對IT這麼有信心,能放心的把數百億元的晶圓廠交給它。甚至可以喊出,我們用的就是跑在程式碼上的晶圓廠(The Fab runs on Code)。」他說。

老同學嘆了口氣接著說,我們光是將需求告訴IT,都不一定能清楚傳達,讓IT做出能解決產線、業務問題的功能,「怎麼知道AI給出的答案,就一定正確或更好?」製造研發與IT開發間複雜的協作、溝通挑戰,成了他對資訊系統成效的擔心。

我能體會他的擔心,若需求溝通都講不清楚了,開發成果如何符合業務部門、產線部門的預期,得花上好一番功夫來驗證才能放心,或者仍舊一邊使用系統,但又一邊提心吊膽,深怕哪天出現了從沒想過的例外而出包。「你敢將數百億的產線,壓在不如預期的系統嗎?」對他的反問,我沒有答案。

但,隔周的封面故事「微服務設計兩難怎麼解?」正好提供了一種讓領域專家與IT團隊協作的軟體方法論,對於促進雙方溝通品質,可以有所幫助。

微服務架構是近幾年最紅的應用程式架構,將傳統大型單體式應用(Monolithic),拆解、重構成鬆耦合的微服務架構,來發展雲端原生應用,是許多企業IT現代化的改造主流作法。

但微服務架構最大挑戰是「怎麼微?多大?多小?如何切割?」都沒有標準答案。

微服務顆粒度越小(程式功能切割得越細),越容易擴充,異動影響範圍越小,派送部署速度都能更快,反過來,若顆粒度越小,微服務數量就得越多,架構複雜性也越高,都會增加維運和管理的困難度。

回到業務角度來思考微服務的切割,問世超過十多年的Domain-Driven Design(領域驅動設計,簡稱DDD),提供了一套可以系統性拆解微服務的方法論,成了解決微服務設計難題的新方法。

這個封面,正是分享了國泰金控導入DDD的第一個實際專案,如何打造出創新保險商業模式背後的中臺架構(技術中臺與業務中臺)的經驗。

例如,國泰舉辦了DDD常見的事件風暴(Event Storming)工作坊,將領域專家、技術人員和需求單位人員聚集在一起,建立用來描述系統的一套共同語言,並將業務流程拆解,聚合成不同的領域,畫出一份有助於架構設計參考的界限上下文關連圖,可以提供一個對整體系統的全局觀,來協助系統設計和開發。

IT如何獲得企業和內部顧客(也就是員工)的信賴,讓需求單位有一種「你懂我」的感受是第一步,而DDD,倒是一種值得嘗試,用來促進雙方溝通的方法。

作者簡介

熱門新聞


Advertisement