媒体融合之架构模型一

媒体融合首要解决的是技术架构的工作，在对原有的信息系统进行融合和集成改造的时候，需要先认真的进行架构的论证。经过近10年的发展，媒体融合的技术解决方案可谓是非常之多，但大部分是基于集成云计算、大数据等方面的能力的系统。

在云计算发展早期的时候，有一些媒体云之类的产品，但大部分基于PASS和IASS层为主，主要服务于媒体行业的解决方案。后来有大量的软件的厂商，如广电服务商，CMS系统服务商，视频服务商等加入之后，各自有重点的开发了一些媒体融合产品，但最终都没有能够非常好的解决融合的真正要求。各家的产品都是基于自己的长处来进行开发，比如视频供应商会重点以视频做出发点，纸媒会以报纸为出发点，新媒体以新媒体的方式作为出发点。而这样的系统，在实际出售和量产的时候，面临的是没有办法改造的问题。为了标准化服务输出，有一些厂商做成了云服务，以SASS的形式输出，甚至用APP生成工具生成APP，这样的东西看起来大家没有什么两样，而在实际的项目当中，各个地方有不同的发展特色，需要进行定制，此时这种标准的产品显得力不能及。

发展到后来就出现了，以集成商为主的定制性开发，但最终都面临一个问题，那就是集成商并不真正了解业务，做出来的东西没有达到应用厂商的需要，即使是做了非常详细的调研，也很难达到深入的理解服务对象的运营模式，最终没有办法达到深度的融合，导致的结果是做了一些集成的工作，把原有的系统打通，然后资金跟不上基本上就定型了。

还有一类除外，那就是有一定的技术自有化能力的厂商，可以利用自己的技术团队充分的理解业务和运营模式，在很好的支撑下做出适合自己运营模式的系统，然后在技术融合发展中取得最大的技术收益，但转而带来的就是技术对外输出，毕竟企业需要钱来养活技术人员，然而对外输出要管理良好，才能保障较为优质和长期的技术输出。

本文架构模式为单位内部解决融合的架构，可做参考。在信息处理过程当中我们需要解决的是信息系统的整合，那么目前要解决“策－采－编－审－发”这个流程主线，思路就比较多了，本文先写其中一种，以供大家参考。

上图可以说是一个标准的融合架构，目前我们实现的集成主要是集中在了中央稿库这一层，可以说CMS是所有的媒体生产最重要的系统之一，大部分情况下我们主要解决CMS的对接。

图中移动采编部分目前实际上受限于APP类的应用的技术条件，基本上没有办法完成比较重的操作，如视频的大量编辑、图文的大量编辑，这些实际上目前都不能很好的实现，大家只是作为一个所谓的创新点在讲解。

底层的融合资源共享部分，实际上在大部分应用场景下，并不是非常重要的点，也只是作为大数据的应用的一种模式而已。最上层的融合管理中心都差不多。

面对如此一个看起来非常巨大的系统架构，我们需要解决的问题在技术背后，就是如何让内容生产、运营能够接受这样一个架构，很多时候需要大量的思维模式的转变。