8-挑战：保持编码人员的创造力

　　在我们转向MDD，期望简化设计表达、改善沟通、生成部分解决方案的时候，我们还需要认识到这会对团队产生影响。有些团队成员可能喜欢在较低的抽象层次工作；他们也许会在场景建模时觉得拘束，反而在努力实现解决方案的时候感到自如。这些担心并非都是合理的，但还是要听出“弦外之音”。我们需要保证每个团队成员都能发挥最大的作用。

　　即使在处理模型的时候，我们也需要底层实现的相关专业知识。应该使用什么框架？这些框架如何整合？下面以模式为例进行说明。构建模式实现的关键输入是参考解决方案，也就是样例，它用来决定模式实现应该做什么以及怎么做。如果我们要构建自己的模式实现，那谁来构建样例？谁来判定该样例是不是解决问题的最佳方式？既然期望能简化建模体验，那又由谁来给出规则、假设和约束呢？又该怎样把它们编辑到人人都要用的工具中呢？这些问题都强调，有很多地方都需要专业知识、创造性、以及解决问题的技巧。MDD策划、启动时有一点非常重要，那就是与团队成员沟通这些挑战，并确保每个成员都能以有建设性、有效率的方式为项目效力。反思一下过去的项目，真正创新的工作花费了多少时间？而机械、乏味、重复的任务又占用了多少时间？

　　9-挑战：没有可利用的内容

　　和其它相对比较新的方法一样，在最佳实践被充分理解和基础设施就位之前，产出的内容都很有限。现在MDD在软件行业越来越成熟，有了越来越多的推进力，可以看到，高质量的MDD内容和资产也越来越多。让这些内容从一开始就可用，对采用MDD来说是至关重要的。

　　面对有挑战性的业务问题，仅有工具和基础设施还不足以交付解决这些问题的软件。最终解决问题的往往都不是工具，而是使用工具的人。如果希望大家使用工具，那么最初就有工具的话，情况就会有很大不同。你是否曾经面对过一块白板、一张纸或IDE工作空间？如果你一开始就有参考或模板，或者有内容指导、组织你的方法，岂不是更容易一些？

　　这里讨论的MDD内容不仅仅是设计模式或UML项目模板。我们所说的内容是指行业或方案的参考架构（比如呼叫中心参考架构或银行参考架构）、作为可执行模型的行业标准集（比如保险业的ACORD或电信行业的SID）或实现存根的模板大全。这类资产的一个成功案例就是WebSphere Business Services Fabric（WBSF）的行业内容包（ICPs）。WBSF框架由运行时和相关工具组成。ICPs为特定行业（领域）提供了可定制的内容，从而成为框架的有益补充。这些内容包括不同抽象层次（比如业务、设计和实现）上的模型和模板，它们遵循行业标准，由组织加以裁剪和采用。

　　这些资产的核心价值在于提供了更多的业务价值，而且更接近组织的战略。换句话说，业务能看到它们会影响损益底线。如果我们比较可复用设计模式的价值和行业框架的价值，毫无疑问，行业框架能创造更高的价值。但行业架构的适用性是很有限的。譬如说，如果是保险业的行业架构，那就无法在电信行业中使用。与此相反，设计模式的应用与行业无关，但设计模式提供的价值却有限，而且离损益底线更远。跟基于资产的开发（ABD）社区所认可的一样，让内容可定制（技术术语是“可变点”）有助于扩大其适用性。

　　要注意的是，此类内容并不局限在高层次的抽象上（比如业务模型）。由于运营资产都是可执行的，所以它们会影响损益底线。例如安全领域的资产，能复用、改变的细粒度访问控制策略。可以确定的是，这些会对损益底线有所影响，人们也能从这里建立到高层次业务安全策略的联系。

　　10-误解：MDD仅用于开发

　　构建软件解决方案的时候，使用模型来指定架构、关联的服务和组件具有很大的价值，从解决方案的其它方面来说也是如此。但这仅仅是MDD给组织带来的一部分价值。要想利用模型并从中获益，就没必要把使用范围限定得这么窄。

　　我们之前曾将业务驱动开发（BDD）作为MDD的特例进行了讨论。那种情况下的焦点是业务建模——业务里的过程是什么？它们如何工作？如何对它们进行优化？如果在这部分没有做好，那就会遭遇“无用的信息输入和输出（Garbage In，Garbage Out）”。

　　此外，我们还能利用模型来支持规范一致性。模型能提供易于理解的表示，详细说明结果方案如何支持规范要求。比如说，要表明组织是如何对细分客户群、业务范围（LOB）或渠道持续应用某规则的，就能用模型来实现这一规范需求。只提供代码到文档的一致性并不足以成为一个最佳的方案。

　　如果要增强已有解决方案的功能，又怎么样呢？如果需求‘A’变化了，这对系统又会有什么影响呢？你如何确定IT布局中的哪些部分应该进行验证和修改呢？如果不能跟踪从需求到实现的过程，这个问题就很难回答，回答的代价也很高。

　　在企业里利用MDD的例子还包括对企业架构和运作建模的支持，但也不局限于此。虽然目标千差万别，但我们仍期望能够沟通、利用抽象、保证治理、支持一致性、提高生产率。

　　总结

　　MDD带来了很多好处，它能促进沟通、改进业务编排、提升质量、提高生产率。如果你以前关注过MDD，那现在应该换个眼光来看待MDD。如果你从没关注过MDD，那现在可是关注的好时机，因为工具支持已经很成熟了。

　　MDD在工具集里有点儿与众不同——就像你不会只使用一种语言，或是某种语言的单个库，为了达到目的，你需要选择合适的MDD方法和角度。如果想在项目中利用MDD，为了找到适合你的方式，你需要认真考虑下面的问题：

　　* 处于怎样的情境？

　　* 对建模工具有什么需求？

　　* 对建模语言有哪些需求？

　　* 需要哪几个抽象的层次？

　　* 如何简化并自动化构建好的方案？

　　* 需要哪些类型的图？需要多少个图？

　　* 和谁进行沟通？他们要了解些什么？

　　* 如何确定MDD方法和工具能被整个团队采用？

　　* 如何发挥整个团队的优势，并让每个人都参与进来？

　　* 问题空间里是否有现成的可用内容？

　　* 如何利用MDD来支持业务？如何利用MDD支持IT？如何利用MDD提供业务和IT编排？

　　* 有哪些可用内容？这些内容如何针对你的情况进行定制？