服务化，是最近几年比较火的一个概念，同时，也是一个大家普遍认可的概念。但到底什么场景，什么样的功能需要做成服务化，服务化又能否解决我们的问题呢？这些可能都是我们需要考虑的点，否则，我们就只是为了服务化而服务化。
为什么谈到服务化，因为最近在公司里大家就一个场景是否要做服务化争吵了整整一个礼拜，还没有明确的定论。
背景：公司打算重新规划一套商品资料管理的系统，我们姑且称之为商品中心。而因为以前也有一套系统在管理商品资料，也已经和供应链端各系统打通并能够正常使用。
过程：在需求方案阶段，负责商品中心的同事要求供应链端产品经理提供下每个系统用到商品资料的场景，以及每个场景下怎么用。我很好奇为什么要提供这些具体的应用场景，在了解后发现，商品中心的规划是提供商品资料的查询服务，每个系统在应用时调用这个服务。举个例子，仓库收货时系统要校验产品编码是否正确，ok，先调用商品中心。采购系统下订单时，调用商品中心查询服务，来校验产品编码。
发展：产品编码，产品重量，产品申报信息，产品成本价等资料在供应链相关系统中像蜘蛛网一般紧密交织，且不说系统改造难度和风险有多大，我们先来看看服务化到底解决了什么问题。
服务化主要为了减少重复开发和维护的工作量及随之带来的风险，同时，服务化能够让系统模块解藕，减少关联风险。但产品基础资料本就在商品中心管理，由商品中心分发给各系统使用是一种比较简便的方法。可能存在的问题则在于同步数据丢失，同步延迟等问题，但这些问题有其他方法解决吗？答案是肯定的。
而服务化并非解决这个问题最合理的办法，商品资料作为基础数据，我们只要保证在同一个系统维护和管理，并且能够及时分发给各系统，足矣，没有必要非得搭上服务化这班车。
结论：这个事情在几次讨论后还无结果，这种状况也只能找领导决策，而最终决策竟是以服务化的思路执行。真不知如何就滥用了服务化，总之，这种设计思路我不会同意，也不会执行。
再说个很有意思的例子，我们的卖家管理平台可以支持卖家申请入库单，查询实际入库数量，入库费用等。而实际入库数据在仓储系统有，而费用则在计费系统中。在方案讨论时，卖家端的产品经理提出来，我们不会存储卖家的入库单，如果卖家需要查询，仓储提供数据查询接口来支持，并声称这样才是服务化的设计。
且不说仓储系统只是操作系统不会把性能浪费到这里，卖家端如此设计在无法满足卖家一次查询入库数量，入库费用等。在这个例子中，服务化又解决了我们哪些问题，减少了开发工作量，或许只是减少了某个系统的工作量。降低了系统的耦合性？本来这几个系统就没有强耦合。
作为产品经理，我们的所有决策都只有一个衡量标准，是否解决问题，再进一步，是否最高效地解决问题，而非引入一些华而不实的概念性东西。