在拜读一位大侠的 另一个层次的耦合度 by 邓芝，之后，我好好思考一下我们的问题，如何解构耦合的问题。当然我觉得这种思考可能是居于CTO级别的思考，而不是基于市场级别的思考，或许这个思考更多偏向于IT领域，而不是AV领域。

本文只是对于耦合问题的理解，从我们实际的角度谈谈对于这个问题的现状。关于耦合的技术理解请大家参考另一位大侠的文章，《模块的耦合度》就讲到非常好。

第一、技术与业务的耦合，在我们这种类型的公司中，技术与业务的耦合是一个必然的现象。比如说在网络环境下视音频文件的资源管理是一个技术，内容协同作业也是一个大技术，而我们对于视音频的产品以及各个模块中很多都会用到这个两个基础的技术，网络制作有资源管理，媒资有资源管理，新闻有协同制作，新媒体有协同制作，等等，在这种情况下，技术和业务是包容的，所有现实中出现什么结果，资源管理各是各的，协同平台各是各的，最后就是什么，就是技术架构和业务架构联动，开发人员水平同等化，技术架构变得虚弱，技术架构没有发展，遗留问题边缘化（在这个架构解决不了的问题永远解决不了），业务产品的升级对于技术架构的升级越来越难，技术架构没有持续发展；这是一种耦合没有处理好的结果；

第二、产品与产品的横向耦合，产品和产品之间主要是接口耦合、数据耦合和业务模型哦耦合，解决耦合关系难度相当大。这个问题我觉得我们做的稍微好一点，但是也只是停留在自己产品内容内部，但是往往我们这个类型的产品在跨公司之间的业务耦合比较多，所以显然我们需要寻求一个更加标准的耦合，来满足大部分用户需求问题，特别是需要面向全球客户的时候。之前对于行业能互联互通的需求的混乱，大部分主要由于国内企业对于耦合的标准的不统一，导致需求的混乱，然后被客户牵着鼻子走，其实统一标准也不是很复杂的事情，只是双方统一一个数据耦合的规范问题；

所以，对于解决以上两类耦合度问题的方法是：技术产品化、架构平台化、耦合协议化与规约化、产品体系化。

我根据我们情况展开解释一下：

技术产品化， 技术产品化，主要是针对技术技术的产品化，比如上面谈的资源管理问题，其实针对大数据媒体媒体文件，在采集、编辑、存储领域来说，可以实现资源管理层的产品化，当重点考虑资源管理的产品化这个技术产品化的时候，我们可能会重点关注这个资源管理技术的发展问题，其实AVID interplay是一个比较成功的产品。同时还要一个比较成熟的就是检索搜索引擎的产品化，在资源管理的同时我们更多用到检索功能，其实在IT领域检索搜索的产品化是比较快的，甚至于类似TRS这种商业化的产品，所以针对媒体内容的搜索产品是一个可以考虑的方向。当然这里的搜索不是指狭义产品中检索功能。

架构平台化：架构的平台化，其实我觉得这是一个高层次的技术产品化的思路，我觉得重点是在“业务基础软件平台”这一层，业务基础平台通过自己的支撑环境，将开发和运行管理软件系统所需要的底层技术进行了彻底的封装，然后上层通过一种建模的方式去开发上层的应用系统，简化了上层的开发。类似的产品包括TRS内容协作平台，微软的Sharepoint，Google的Site,甚至于博客领域的WordPress，应该都是可以理解成一个平台架构，对于应用可以采用插件、模板等等模式进行定制开发。所以我认为在我们的领域对于媒体资源管理，新闻内容协作，媒资内容管理，新媒体内容管理等在可以考虑架构平台化的技术路线。

对于耦合的协议化与规范化，我认为最重要的是将协议和规范作为产品来出来，并且作为战略合作的内容来出来，而不是作为客户化定制来出来，协议和规范需要商业化运作。对于协议规范本身没什么可以讨论的了。

产品体系化：其实产品体系化是两个维度的内容，一个就是在同一平台上的体系化的问题；能够为了实现共同协同工作的体系问题，还有就是不同平台上工具的体系话问题，需要实现类似功能的同一产品不同解决方案下集成；这里解决的耦合就是产品体系纵向耦合和横向耦合问题，我认为建议一个产品专业化的前提下，来考虑体系化问题。就是说保证专业模块的前提下来考虑体系整体问题。

我们经常习惯于业务搞技术架构，却很少给自己的技术搞个架构，把我们的技术平台化，产品化，看看那些成功的互联网、软件公司，无一不会通过这种方式来化解上面的困境。看到技术，永远是点，点多了必然会乱；只有把点组织为有机体（产品、平台、架构、体系），才会健康。

当然现在的层次已经又高于我前面所说了的，Amazon开始玩更高的境界了。

以上权当学习。