技術選擇決定了一家企業IT技術的發展方向，如果押錯平台，可能會多走不少冤枉路，這企業IT向來的課題，對歐洲快時尚電商Zalando而言，更是一個十分棘手的難題。
Zalando所有業務都是靠技術平台來實現，為了支援電商、支付、廣告和物流等多元營運模式，Zalando擁有一個1,200人規模的開發團隊，採取敏捷開發模式，分成了250個開發團隊，各自負責不同的產業市場和應用需求。
每個團隊都會面臨各式各樣的技術選擇，但每個團隊的任務差異很大，從資料，開發到維運任務都有，尤其，在Zalando上雲之後，不只開發團隊，連基礎架構團隊要支援的工具和語言也越來越多，如果沒有一套做法，放任各開發團隊自行挑技術，最後，各自用的技術越來越多元，不只維護代價越大，互通的複雜性也越高。
如何統一250個團隊的技術方向，Zalando的解法就是靠技術雷達（Tech Radar）。Zaoando要求各團隊都要參考這一份共用的技術清單，作為新專案挑選出最佳技術的參考，而不需要每一次發起專案都從頭進行技術評估，工程師可以參考這份清單來選擇合適的技術。因為每個團隊都是用同一份技術清單來挑選，因此，就能夠確保不同專案用的技術，都在雷達圖的範圍，來實現技術方向的聚焦。
Zalando不是自己憑空想像出這個技術雷圖，而是參考了業界知名的IT技術顧問公司Thoughtworks的技術雷達圖。在技術雷達圖上，列出不同類型技術的推薦採用程度，用不同的環來代表不同推薦程度，越靠近核心環，代表這項技術的推薦程度越高。Zalando根據自己的需求，聚焦軟體開發相關技術，分為四大類型的技術：資料儲存，資料處理（後來在2017年時擴大範圍更名為資料管理類）、基礎架構和開發語言。
而在推薦採用程度上，Zalando也同樣分為四個推薦等級，形成四個環，每一環代表了不同的推薦等級。這四級包括：Adopt（推薦採用）、Trial（推薦試用）、Assess（評估階段）、Hold（保留不推）。
技術雷達圖涵蓋四大類技術，分四等級推薦採用
凡是適合大規模採用的技術，就會列入推薦採用的程度，這是已經在Zalando自家正式環境上使用一段時間，風險低而且可以廣泛運用的技術。例如資料儲存類的S3和Cassandra，資料處理類的Kafka和Airflow，基礎架構類的K8s和SageMaker，或是開發語言類的Go、GraphQL等。
而推薦適用程度則是指已經在內部有成功專案的技術，而且至少用於真實問題而非模擬情境的處理。Zalando希望透過至少一次的認真使用來確定效果和技術侷限，不過這類試用性技術，仍有風險。因此透過成功專案，也能培養出實際用過的工程師來提供諮詢。還有一類是列入評估階段的技術，這是指一羣有明顯潛在價值，且值得投資的技術。Zalando會對這些技術進行研究和雛形開發來瞭解其影響，但是，這些技術太新，仍視為有高度風險有待評估的技術。最後一類則是Hold等級，就是不推薦但會繼續提供維護的技術。這是指不值得投資或還沒看到價值的技術，可能是更新興的技術，也可能是過於老舊的技術。Zalando同意將這些技術用於現有專案，但是不推薦用於新專案。
初期靠志願者維運帶來3大問題
2015年一開始，先靠人工繪製，在Zalando內部的全體工程師社羣中，挑選志願工程師來負責維護，整理大家的共識和經驗，手動畫出這張圖，後來才改用程式自動繪製出圖表。
不過，這份技術雷達圖用了2年，2017年時，發現有3個大問題。最大的問題是，技術升環或降環缺乏一套標準做法。例如，開發語言和儲存技術的評估方式不一致，造成了技術團隊選擇上的混淆，他們還得知道不同類型技術各自評估方式才能判斷，反而更麻煩。第二個問題是技術雷達圖的評估過程，缺乏一套正式流程，雖然高層要求團隊參考，但專案負責人還是可以採用自己熟悉的技術，這就無法達到原本預期要統一技術方向的效果。最後一個問題是，因為早期的技術雷達圖過度依賴志願工程師來維護，只靠這一羣人的熱情，無法反映全公司各部門的情況和需求，技術決策更無法支援全公司性的戰略。
在2017年，技術雷達圖沒有發揮作用，但Zalando的開發團隊越來越多，內外系統已經超過了4千套，技術多元化帶來的複雜性，依舊很高。
盤點4千套AP重新設計技術雷達圖
Zalando決定重新徹底盤點4千套AP所用的技術，瞭解目前使用了哪些開發語言，工程師們習慣哪幾種技術，願意提供哪些技術支援，來支援其他專案。另外，也參考了VM生命週期管理流程和CI/CD系統、可觀測性指標的需求，重新建立對於技術雷達圖的設計。
第一項修正就是調整了四級推薦的定義，Adopt等級更重視採用廣泛度，而且是高層有意願長期投資的技術才會列入這個推薦等級。另外，還會運用技術自動分析在所有產品中的試驗計畫的資料，更完整的找出已經試驗中且值得列入Trial階段的技術。在評估階段的技術上，也採取更主動性的技術評估做法，技術雷達圖維護人員會參考技術趨勢，以及採取一些非正式環境的評估機制來擴充。
最後一項Hold等級的技術，則更明確要求，不只是新專案不能用，也不鼓勵用於推廣性服務上，要逐漸縮小這類技術的應用廣度。最後會把把評估過但沒有列入四級推薦中的技術和推薦資料，都保存在「零級」類型，作為日後的參考。另外，Zalando也建立更清楚的推薦領域，透過技術領域的分類，來進行評估或推薦，包括了後端、行動、Web、Data技術、ML技術或基礎架構，並將Queues技術從基礎架構分類中，轉移到資料處理類並統一命名為資料管理類，至此，就形成了現在的四大分類資料儲存、資料管理、基礎架構和開發語言。
指派首席工程師專人維護，更提交高層會議討論
在技術雷達圖的維護上也有重大改變，不再由志願工程師負責。當時Zalando正在進行工程師職務的調整和重新設計，新增加了一個首席工程師的職務，在各部門資深工程師中，挑選出優秀者專門負責技術研究而不擔任管理職，並且成立了首席工程師社羣。Zalando改由這個首席工程師社羣接手技術雷達圖的維運工作，而所有工程師仍舊可以提出建議，最後由首席工程師社羣和指定首席工程師來決定。
每次進行技術推薦等級的調整時，首席工程師們先討論出一份調升調降版本，還要送到高層會議中討論，一方面確保技術符合公司長期發展，也讓高層將技術發展納入企業長期戰略中。
Zalando也根據技術雷達圖，訂出一些採用範本和指南，提供常見問題説明和使用案例，甚至是不同替代技術間的比較等。
另外也鼓勵內部工程師，分享自己的使用案例，集中到這項技術的採用範本Wiki網頁上，不只如此，還直接蒐集在公有雲上的正式環境這些技術的使用紀錄，程式碼儲存庫中的紀錄，基礎架構團隊定期使用數據，都整合到每一項技術的採用範本上。這個技術雷達圖，最後成了一項Zalando所用技術最重要的一份完整技術採用指南。
