MDA不需要设计的原因是什么？

接连几个项目下来，都是跟政务相关的，这一趟下来，感觉收获颇多。

我接触的第一个政务类项目，是CRJ系统（金税系统也有接触，但是不是很深），在这个项目中，小J和他的团队们，开创了一个大型项目全部使用MDA工具进行系统实现的一个先河。这个项目，目前应该是成功了，在成功的背后，J也进行了总结，我个人，对他的总结，还是有些不同的看法的，这种看法，在这次政务项目之行后，得到了充分的验证。愿意就这个问题，跟他探讨。

这个项目成功，小J兄弟总计了很多条，有三条最为重要的是：1 采用了迭代的开发方式，2 采用了MDA工具； 3 客户的大粒度的参与。 1和3都没有什么好说的：迭代的开发方式，是我在该项目初期，给项目组做咨询时，给他们引入的第一项思维方式的转变；在项目的初期，CRJ的客户就派了业务专家和协调人，入住到泰安基地，一直工作到项目上线前。其实，第2 点，从大体上说，也是对的，不过，如果说是因为采用了MDA工具，就可以省略分析和设计的工作，我感觉还是不妥。

要知道，CRJ系统，产生的背景是：国家选了5个省做试点，山东、广东、江苏各是一个，为了保证各个省以后的统一管理，国家局还制定了一套标准。这个标准，对crj系统的指导意义，是非常大的，不管是业务架构，还是技术架构，或是安全架构，在这个标准中，都有明确的规定。我研究了其中的核心领域模型，最后推导出来的数据模型，居然跟标准中规定的数据模型非常类似。一方面，这说明，我们对系统的核心领域把握得很准了，另一方面，我们可以想像得出，国家局在制定标准时，花了多少精力。

因此，我可以很负责任的说，CRJ项目之所以成功的关键原因，是国家局对系统架构的统筹和规划。（这里面，包括了系统需求，包括了系统架构），而MDA工具的应用，是在这个统筹规划的基础上，起了推波助澜的作用。

这个感受越来越深,从上海到广州，这几个项目，都缺乏这种国家级别的规范，在做领域职能分层时，我找不太出策略层或决策层的内容，客户在建设的过程中，虽然有心想做统一规划，无奈目前业务的复杂度，不是区区一个信息中心能够解决的（关于这方面的思考，见后续的blog《理想向左，现实向右》）。因此，业务架构不稳定，技术架构上无法统一，项目风险急剧增大。

希望，听到对CRJ项目更理性的评估，有些本质，躲在了现象之后的之后。