我们能通过市民卡将很多不相关的应用产生联系，并形成一套用于民便于民利于民的规则，这才是通用。—题记
好吧，纠结了好久，还是写下去吧，用上一篇的话来说，再不写点就不会写了。其实呢，老实交代吧，股票亏了，没心情。找点事情做暂时忘掉吧。
上篇说到了通用，对于“通用”的解释，我觉得用业务云来解释比较好。浙江电信曾经做过业务云的项目，可以对外提供各式各样的在线服务。特点就是统一接口、统一平台、统一服务。统一接口接入基础服务提供商，统一服务平台，统一服务输出。因此也引申出了佛山的卡云项目。
佛山卡云的宗旨就是通过一个开放的平台接入服务提供者和服务消费者。服务提供者包括两类：基础服务提供者（制卡、配送等）、通用服务提供者（提供卡的日常服务，比如刷卡消费），服务消费者主体也有两类，一类是底层消费者（持卡用户），一类是服务需求者（政府、企业等）。可见如下图示：
这样看可能看的不够清晰，但是也不能说的太清晰，要不像我这样的P民，给人告个泄漏商业机密也没办法，谁叫我爸不是李刚呢。
基础服务提供者的服务对象是服务需求者，通用服务提供者的服务对象是底层消费者。
这样的架构有什么好处呢，卡云卡云，理论上提供无限卡业务提供商和消费者的统一服务平台。这样的架构不是一个纯粹的业务系统，而是一个卡类的生态系统，我们提供这样一个卡生命周期的生态环境，保障卡的全生命周期正常运转却不对其中任何的环节加以干扰。多么崇高的目标和理想。但是不能不说从它立论开始就已经树立了无数个躺在路上的敌人。
其一，利益纠葛。服务商之间存在利益纠葛；无法打破原有制卡企业已经和服务企业之间的灰色协议。
其二，数据安全。所有往来交易数据均在平台的监控中，提供者和消费者都不希望这些数据被泄漏。
其三，政策限制。发改委已经发布小额支付钱包不能超过1000元RMB的规定，从而加强了卡面对金融部分功能的重用性。
其四，搅乱卡片市场格局。批量生产，盲目扩大，管理方法延迟出台，最终结果是倒是市场的混乱。卡云平台在需求的推动下可以在短时间内产生大量不同类型的卡片，同时至今没有针对企业发卡的规范条例，可能会出现利用卡片做非法集资等法律风险。
其五，底层消费者不买单。卡片集成是社会发展的趋势，也是政府大力推动的政策，但是卡云平台只有在卡的多样性格局下才回发展壮大，这是与政府立调是相悖的，并且，底层消费者很显然对一人多卡很反感。
所以，卡云平台在立论的是存在很多风险的。但是其理论和基础架构还是比较有参考价值的，因为它就是基于通用性的架构。以下是经过我改良后的逻辑架构：
随便画画，将就点看。后端的基础服务是很多的，没有全部画上去，就是这个意思。
在架构上，我们必须保证后端的服务提供体系通过一致的服务接口接入。但是我们这里的云服务可能和前面卡云的概念上有点不同，这里立论的基础是在统一机构发布的卡范围内的业务服务，而不是不同机构发行的卡。因为不同机构发行的卡，如果也需要兼容可能需要的支撑更加大。那么对于我们不得不进行兼容的卡，我们如何进行处理呢？只能合作发卡了。
那么回到我们前文提到的“医院院长的难题”的问题，我们的系统如何进行支撑？
首先，医院发布一个积分的活动，并指定一个积分消费主体，消费主体进行积分消费设计。消费者在医院进行消费就会在该消费者的积分账户进行记录，并记录下积分类型。当积分达到消费主体的最低消费积分线，系统就会通过各短信、邮件等服务渠道通知消费者到指定地方进行积分消费。消费者到消费地点进行消费时，系统会通过预设规则进行比对积分消费条件进行智能积分消费。
当然，上面的逻辑图是简化了不少，还有很多子系统进行底层业务支撑，比如监控子系统、BI子系统等。
好了，这章没有通过业务来解释“通用”，这是比较出乎我的意料的，老实说吧，写之前我确实不知道自己会写成那样，不过还是勉强到达目的了，同时也简单介绍了一下我理想中的市民卡系统是个什么样子的，至于对“市民卡的未来在哪里”这个主体，好像有点偏了，那下回就有针对点吧，我觉得这篇文章应该从业务、技术、政策三个方面去说。这章的技术性不强，就把一、二权当业务吧。
总结一下，业务方面还是第一章提到的，市民卡的未来之路要走下去，必须走一卡多用、一卡通用的路，因为在政策上面存在支撑，政府也愿意这样去做。但是我们做实施的，必须脚踏实地，积极的扩展卡的多用和通用，只有这样，通过长期的努力建立市民卡的城市脉络，占领各委办局的资源，这才是发展之道。好吧，把自己最真实的想法透露出来了。
不是这样的吗？想拿到政府资源，也只有通过这样的合作了。
转载请注明：迷路的老鼠 » 市民卡的未来在哪里（二）
