重用性经常被视为软件开发的“圣杯”，每个人都想要，但是没有人真正得到。同样的，最大化重用也是一个非常棘手的挑战。很多企业采用“构建，然后它们就会到来”的方法，这实际上是一种计划外的重用。随着团队创建解决方案，组件和服务构成的详细目录也逐渐建立起来。我们期望新的解决方案能够考虑到详细目录，在开始创建一些新的东西之前可以看到现在已经有哪些了。

    实际上，这个平台不利于这种方法。因为所有的开发通常都是项目等级范围的，围绕粒度、功能分解和接口进行类似决策的机会很小。在这之上，企业架构并不是为了共享创建的，它是为了交付项目而建。如果一项服务需要修改，谁来做这件事情呢？如果是一个新的项目团队，他们如何保证不会影响到创建原始服务的最初解决方案呢？简而言之，与仅创建一项服务相比还有很多可以重用。

    有很多改进措施可以完成这些，像发布已识别的新服务并从外部项目寻求需求输入，但是这还不是最大化重用。如果最初项目分解不同于其他项目，一些领域潜在的应用可能永远也不会谈到。

    为了最大化重用，你必须有计划的进行。这也正是企业架构师和产业架构师能够维持生计所在。他们的工作就是比任何一个项目要想的更广泛。他们是唯一需要识别潜在重用区域并为项目团队实现目标提供框架的人。首选方法就是功能图。功能图（capability maps）根据业务功能表达事物，不仅为项目团队在定义其解决方案架构提供框架，也为重用领域识别提供了框架。

    为了为重用确定目标，功能域必须同业务目标和组织架构进行配对。这是非常重要的一个步骤，因为且仅因为有些东西可以重用并不意味着就应该重用。很显然，重用是一种高度的自由度，因为涉及到标准项目架构之外的团队。早先的步骤中，这种自由度可能会影响交付直至事情合理化。

    如果交付时间要严格符合战略业务目标，组织中适量的重用目标可能很好的定义了区域。如果降低运营成本更重要，识别出更多区域和确定新服务团队来获取尽可能最大化的成本节省就更有意义。无论目标是什么，都不可以在没有框架来进行这些决策的时候进行，这个框架就是功能图