讀懂需求是IT被信賴的第一步

最近剛完成了半導體龍頭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，倒是一種值得嘗試，用來促進雙方溝通的方法。