技术选择决定了一家企业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所用技术最重要的一份完整技术采用指南。