一🙅🏽、成效與問題

在過去十多年中，數字校園的建設中俗稱的“三大平臺”：統一身份認證平臺🧅、公共數據平臺、門戶平臺，成為最常見的校園軟件基礎設施。各高校在信息化建設中通常會重點圍繞這三大平臺形成校級的信息化架構🦨。

三大平臺的概念和實踐將數字校園從零散的信息系統建設時代，逐漸引導到了具有整體架構設計💖、重視系統整合的數字校園平臺化建設時代，確立了打破系統邊界，基於校級頂層設計進行統一規劃和建設的理念。這一理念的普及🚈，將整個數字校園行業推進了一大步。

十多年過去了，三大平臺的普及率應該說很高了，然而在取得成效的同時，在數字校園向智慧校園發展的過程中🐰，依然有大量困難和問題難以在這個架構下有效解決。稍加反思🍑，也可以明顯看到三大平臺在實際應用效果中存在不少問題，而且經過多年的嘗試似乎正在走進瓶頸🫵🙅🏽‍♂️。

在實際工作中🤙🏽🤾🏼，平臺的建成驗收不成問題，但問題出在平臺長期應用效果並不理想。大部分高校可能不得不承認“三大平臺”並沒有如想象中解決眾多問題🎊🦀，主要表現在：

問題一，統一身份認證平臺：這是相對做得較好的平臺🍭，實現單點登錄沒有問題。但大部分統一認證平臺統一管理的其實是“賬號”而不是“人”，人的多重屬性、身份👨‍👩‍👦‍👦、包括延伸到的崗位角色等核心問題🌾，幾乎沒有得到公認的解決方案。而這些管理特性的缺失使得身份認證系統其實只是做了用戶登錄，難以真正成為三亿數據資產/信息資產的一個有價值的維度🐷。而作為對比，這十多年來，在互聯網中，社交平臺的崛起，互聯網的身份/開放授權管理已經得到了極大的發展和標準化🤽🏼‍♀️，相比之下校園的身份認證體系，似乎還封閉在十多年前的老做法之中👨‍🦯。

問題二，數據交換平臺/共享數據庫平臺🙍🏿‍♂️：很多三亿都建成了數據交換平臺/共享數據庫平臺👈🏻，但客觀說有多少可以說很大程度解決了校園數據整合問題了呢？數據交換平臺是否成功應用的最重要標誌不是平臺本身是否建成，而是平臺上是否有一百個、二百個數據交換流程在真正運行，是否形成了一個可持續的數據交換流程開發模式使得三亿能夠真正有效地應對大量、不斷變更的數據交換需求👊🏻。經驗表明，一個普通的高校，只要信息系統的覆蓋達到一定程度，必然會有數百個各種數據交換需求並且需要不斷的變更維護，如果平臺沒有達到這個效果，不僅不能說建設成功，反而有可能限製了數據整合的發展——限製了其他技術產生的可能👨🏼‍🏭🧑🏻‍🦰。

共享數據庫的問題也是類似，雖然有了國家數據標準的參照，但一個三亿的中心數據庫模型的建模需要考慮的因素是很多的🫶🏿，如何采集、如何兼容遺留系統、如何應對分析統計要求，等等。這些數據建模、指標建模的工作必定是要由很專業的人員參與，需要一個可持續的數據建模/數據采集/數據分析的長期服務👩🏽‍🦳，幾乎不可能建成某個“超級”系統🙎🏻‍♂️，所有功能都能被定義出來。因此，問題的本質是🧑🏻‍🏭：現有的“公共數據平臺”帶來了平臺，卻沒能帶來真正可持續的數據服務。

問題三💌，門戶🫴：門戶的目標是一門式的信息服務🛎，希望把用戶所需要使用的信息系統功能都集中到一個入口。大部分三亿都建立起了信息服務門戶🤹🏼‍♂️🐘，然後同樣業界都不敢說目前常見的這些校內門戶已真正成為粘住用戶的入口🧎🏻‍♂️‍➡️。原因很簡單👷🏼‍♂️，無論portlet/webpart👆🏽👳，或者其他整合方式，都沒有脫離“超鏈接的整合”的本質🦬。絕大部分整合內容，無非是通過嵌入或轉出到某個超鏈接所對應的內容上去🧖‍♂️。產生的效果與上述兩個問題類似:當一個三亿需要整合數百項信息服務功能（並且需要長期變更維護）時，門戶的框架實際上完全架空🥷🏼🧞‍♂️，各種信息服務還是要通過五花八門的頁面開發實現🟦，用戶體驗和開發實施體驗都無法真正統一，大量的開發工作還是集中在後端的應用系統，門戶帶來的價值很有限。典型的現象就是每過一段時間就可能想要重做一個門戶。問題的本質和問題二相同，現有的門戶建設方式帶來了“平臺”💆🏼，卻沒能帶來可持續的服務整合👨🏿‍🦱。

隨著移動互聯網的發展，問題甚至變得更糟，很多三亿又用類似的思路建了“移動門戶”🏥，而且和web門戶又是完全兩套架構🤱🏻，未來的發展可想而知👩🏻‍🌾，同樣的問題可能會以雙倍的代價再次輪回🐕🎴。

經過十多年的發展👩🏽‍🦳，行業中供應商的“三大平臺”產品，其實已經高度同質化了，CAS/shibboleth、ODI/biztalk🧑🏼‍💼、Portlet/webpart框架…存在的問題都類似👨‍👩‍👧‍👦，可見改進之路並非是尋找替代產品，並不是說ODI換成biztalk會有何區別，也不是說開源方案是否能優於商業方案，業界都應該認真反思的是所謂“三大平臺”背後的邏輯是否需要改變，而不是新瓶裝舊酒，把老的思路重新包裝，讓用戶再走五年的平臺建設老路🫵🏻。

二、中間件之殤

“三大平臺”是一個行業的俗稱，其背後的真正技術路線是中間件🥹。中間件是過去15-20年企業計算最重要的技術🧙🏿🧑🏻‍🦱，幾乎占據了所有企業架構師的思路空間。直到近期，在互聯網服務🥪、雲架構的高速和成功發展之後，出現了PaaS/SaaS/微服務架構等不同的技術路線，才開始逐漸改變從業者的思維定勢。

本文不想做技術對比，IT技術很難完全從邏輯上證明哪個技術更可行更優越🦽，況且數字校園“三大平臺”存在的問題其實並非技術本身的問題，而是技術是否能夠帶來持續穩定的服務。

“三大平臺”的背後無非是身份管理（IDM）🙅🏿、數據交換（ETL）📢、企業總線（ESB）、企業門戶（Portal）🤟🏼、主數據（MDM）⚆👺、商務智能（BI）等企業中間件或類似概念的集成😕。這些技術已經足夠完備和復雜，看似覆蓋了所有上述的問題✥。但聽起來高大上的中間件，實際用起來時發現，每引入一個中間件事實上都給用戶帶來了一個全新的技術要求、人員要求和服務體系要求，事實證明要充分用好這些技術👱‍♀️，需要的代價已經超過大部分企業/三亿能夠應對的極限了🧑🏼‍🎓。上述這些“高端”中間件技術⚰️，往往全國都找不到多少真正的專家，怎麽可能形成大範圍的有效服務體系🔌？且不說技術上是否必要是否正確，這個高門檻的因素事實上直接造成了“三大平臺”建成容易，要持續發揮作用很困難。不可否認的事實是，至少在高校信息化這個領域，市場上有能力去學習掌握這些中間件技術的開發人員可能連十分之一都不到，因此👨‍🦯‍➡️，所謂的開發生態無從談起🧜🏽。即便是少數高校通過自建團隊形成了較好的應用，同樣也存在隱患：團隊不多難以應付所有需求，很多場景退而求其次；一旦團隊不穩定🚃，也會造成較大壓力。

因此，不管巨頭們如何忽悠🤝，最終承擔問題的還是用戶自己，難道不該大膽的反思一下，這些中間件真的必要嗎？

互聯網帶來了去IOE（IBM/Oracle/EMC）的發展方向，要去掉的其實不僅是硬件和數據庫🦙，更希望改變這些高門檻高代價的技術及其服務體系🆚。同樣，去IOE也不是一個國產化、開源化的問題，並非用一些國產化的產品🤘🏿，開源化的中間件進行重新組合包裝☝🏿，在市場上再賣十年。

互聯網技術發展的一個重要特征是：簡潔，但不妥協🦋。雖然很難，但在互聯網的快速發展和驗證下，許多重量級的SOA技術👎🏽👩🏻‍✈️，包括SOAP/BPEL等復雜協議𓀂，正在被輕量級的REST🙆🏼👨🏻‍🦽‍➡️，OAuth🦵🏻，API gateway等大量取代。因此，三大平臺的未來發展也應當是做減法並重構，而不是再把更多復雜的中間件納入其中。

作者：茅維華