公司里面的很多部门都在广泛的采用元数据管理，也采用了公司内部开发的元数据管理工具，有些部门的实施效果一直非常好，而有些部门的效果则差强人意。这个问题，其实和软件系统开发完成进入维护阶段后成本居高不下的性质是一样的。
究其本质，是因为国内很多的公司对流程的重视程度多浮于表面，较少的深入去掌握实质部分。在具体讨论元数据和API管理的问题之前，先来说说笔者在很多部门见到过的几类现状，一、大部分业绩比较差的公司/部门的考核通常是这样的，公司有新的项目开发，负责项目管理的项目经理问部门经理要了一批开发人员，临时招聘了一些人员，其他组抽掉了一些人员，结果轰轰烈烈的项目就开始了，经过一年半载的开发，系统终于开发完成了，差不多也交付给客户了，但此时业务量很少或者压根就还没正式的开展业务，基本上没有什么太多的问题。于是在年底的考核中，项目经理顺利的升迁了，项目被顺利的转交给另外一拨人进行维护，又过了一年半载，客户正式开展各种业务了，问题也开始了，系统的各种不稳定性，低性能，用户体验差，系统各种硬编码无法扩展，接盘的维护项目组各种抱怨，被客户和部门领导的各种批评。更有甚者，当年主要的项目经理得了公司奖项，次年，客户正式把公司炒了鱿鱼。而真正的考核不应该是这样的，而是应该真正的业绩驱动的考核。二、有些项目是这样管理的，各类人员都配备了，需求、概设、详设每个阶段都包含了，项目计划也都指定了，甚至也都严格跟踪了，可问题就是整个部门的效益仍然不高，仔细去观察，你会发现每个阶段的产出物质量没有专人进行检查，各类人员只检查各项要素是否齐全了，至于内容是否足够清晰、正确，通常是没有人关心的。到了编码的阶段，还在讨论某个需求是否合理，某个状态应该有几种取值。
言归正传，说说元数据和API管理的问题。很多部门通常在并不理解元数据和API管理模式的情况下盲目的采用，认为A部门效率很高，并且采用了各种管理工具和技术，自己部门采用肯定也能达到效果，然后照抄相关的流程和工具，结果通常成了东施效颦。事实上最大的问题并不在于元数据或者API管理采用什么方式或者什么工具，而在于对于元数据或者API管理本身的重视程度，真正的元数据和API管理是一个典型树木生长的例子，在设计和开发的早期，对于作为个体的开发人员来说，效率通常是看起来不升反而有降的，因为开发人员需要仔细的查看现有的系统中有哪些现成的标准字段、数据字典、数据类型、系统参数、错误号等，同时在决定新增或者修改现有的API时，必须仔细的思考其合理性。由于这些元数据和API需要经过申请和审核才能被证实纳入系统的元数据和API体系，所以，在早期，看起来这是一件降低效率的事。而正式早期的这些慎重的审核和分析，才使得系统在具有成百上千个API、数据字典等之后仍然能够保持内部的一致性和清晰性。所以，就如同树木在早期会花费大量的时间在地下扎根一样，正是因为这早期在地下的伸张，才使得日后不仅能够茂盛的生长，而且能够抵御狂风暴雨的侵袭。而这，是无法立竿见影的。
而很多职能部门和业务部门，通常是希望换了一个管理工具、引入了一个新的流程，系统就会神奇的好转、效率就会神奇的提升一样，殊不知真正的问题在于管理本身过于重于形式、轻于实质。就如人月神话所言，没有银弹。在软件行业，真正称职的软件开发管理人员还是太少了。