功能之谜实际上有两个部分。第一个是你的功能模型。一旦你理解了自己的功能模型，就可以创建一个贯穿整个公司的适应功能模型的功能映射。

　　功能模型是功能的一种分类。根据我的经验，通常至少存在三种层次的分解，最后一种层次粒度最细。这并不意味着最后一种层次代表了个体功能，相反，它意味着那种层次的功能是决策所需的粒度中最好的层次。

　　为了在这里进行讨论，所谓功能在这里指的是业务运营所需一或多个功能。你也许在其他来源会发现功能被定义为一个整体概念，使用“功能”作为粒度最细的项目；然而，我感觉对于一项应用专门术语来说，功能显得太大了。

　　制定功能模型可能是件棘手的事情。无论如何分类，事物都会存在多种组织方式，因此你如何选择分类将会依赖于你的组织方法。要设法找出与你公司关键功能决策相匹配的方法。

　　这些功能应该是对你的业务领导有意义的，起码是处在你功能模型的高层。如果你的企业架构团队跟大部分团队一样，也是从IT部门发展起来的，那就一定要确保把你的业务利益攸关者加入到讨论当中来。功能模型是你业务的体现，所以它需要对业务领域的人有意义，而不仅仅是对IT。

　　功能映射，顾名思义，就是把你功能模型中的功能映射到你的技术组合里面的应用、系统以及组件中。这就是在技术和业务之间进行协调一致之处。最简单的道理，应用提供功能。这就是功能映射极其有用之处。

　　首先如果你的映射表明你有超过一个应用提供了相同的功能，那么也许这就是一个合并的机会。让多个应用提供同一种功能也许存在着很冠冕堂皇的理由，如果这种理由存在的话，那也应当记录在案并始终如一地贯彻执行。

　　比如说，你的组织也许有一个多样化的运营模型，在不同的经营机构间其客户群互不重叠。如果是这种情况，有多个应用来提供客户管理功能也许一点问题都没有，只要这些应用适应经营机构即可。但是如果在同一个经营机构内存在多个应用来提供同一种功能的话，可能就要仔细地好好看看了。

　　除了在组合中找出冗余性之外，功能映射还能向你展示应用是如何在功能模型中分布的。正如前面我们提到过那样，你很有可能将至少拥有三个层面的功能分类。一个应用提供一个以上的功能并不罕见。最好是这些功能也能够在一个更高的概念层面上被归类为一个类别。如果不能的话，你就有可能存在应用与公司考虑其业务功能的方向背道而驰的风险。

　　为什么会发生失调有很多原因，但重要的是你有办法对解决方案与既定的业务功能相适应的程度究竟有多接近进行量化，并能够就此是否除妖处理做出决定。功能模型可以用一种最佳的组织和提供相似的业务功能的方式来表示。

　　这不单单是内部业务和IT相适应的一个有用的工具，对于第三方收购来说亦然，不管它是一次简单的技术购买或兼并或收购都是如此。如果第三方存在一个与你不同的功能模型，或者如果把它映射到你的功能模型能发现一些横跨你的功能模型域的系统的话，它可以帮助识别出你的组织有可能需要进行处理的调整决定。