StarCraft游戏初期，神族高级玩家一般喜欢在出了一两个狂热者就带上一个农民出发，利用优秀的微操作能力很可能推倒一些心理素质不太好的Player，尤其是对付虫族的小狗，如果操作得当，两个狂热者往往可以消灭掉6~8个小狗。然而这一战略如果用过了头，比如，在刺蛇海面前，再优秀的微操作马上变得可笑。在一次国内的比赛中，我曾经看到过这样一场悲壮的比赛。

有一句话说得很对：先做正确的事，然后正确地做事。如果把大型项目比喻为刺蛇海，那么我们无论如何都不能在这样庞大的攻势面前傻乎乎的用某一两个“设计模式”、“PoEAA”或者“Core J2EE Patterns”这样的微操作。原因很简单，在业务架构尚不清晰的情况下，盲目的用小规模的技术组件来套用是愚蠢的做法。我经常听到不成熟的程序员这么在说：晤，这里可以用状态模式，嗯，那里可以用解释器模式。问问他是否真正明白业务的需求，他一脸茫然。当目标从一开始就错误的时候，再优雅的设计得到的顶多是一堆优雅的垃圾。

那么，正确的事是什么？是正确评估分析你的业务。业务架构是技术架构的基础，业务语义是技术语义存在的前提。这个问题之所以没有被得到重视，是因为我们现在做的大多数系统都还比较简单，我以前做过的项目基本上用事务脚本便可以解决，通过数据库的增删改查从而完成特定功能；在此基础之上建立了一系列技术组件，比如OA, 工作流，CMS。在分析项目的时候，将功能需求往已有的技术组件上套，然后用不太先进的技术完成了一个又一个的项目。因此我说，项目成功的保证一定不是所采用的技术，而是对业务的理解程度。

我们比较不幸。客户越来越成熟，对信息系统所能带来的生产力期望值越来越高（政府项目除外）。大量的旧的系统如电力，金融等，开始被迁移到J2EE平台。J2EE平台技术的成熟并不等同于业务的成熟，当一个系统膨胀到刺蛇海的规模时，当功能需求书堆起来一米多厚、功能错落有致、交叉相连时、就是这样也不足以描述需求时，那么技术方面的某些小小的微操作、模式就像是刺蛇海面前可怜的狂热者，潇洒却凄凉；又如同印尼海啸面前“坚固”的漂亮的海边别墅，不堪一击。在对这样大的项目进行分析的时候，业务是最重要的。将业务分析清楚才是正确的事，而不是上来就往J2EE N层模式上套。放之四海皆准的方案，往往可行性、操作性成问题。只有当业务分析清楚了，业务功能之间的联系也分析清楚了，怎么做就变成了很简单的事情：无论你怎么做，代码写的多么难看，只要完成功能，你做的事情都决不是Dirty work.

然而，业务分析也太艰难：当你面对一个具有十几个子系统、几千种交易、数百种工作流、子系统功能之间纵横交错的时候，没有业务知识和技术知识的双重修炼，这件事情无异于mission impossible. 这方面，我想才是自己需要修炼的一个方向。Raimundo同志正在进行这方面的研究，希望能够有所建树。

稍微有点高兴的是，目前我们接触到的项目大部分并不庞大，大部分都能够进行归类，比如简单的业务逻辑普通的增删改查就能完成，复杂一些的加上工作流支持；大一些的公司有能力对这些操作进行积累，称之为“技术组件”，因此某些以构件为核心的解决方案（公司）抢到了许多订单。从一段时间趋势来看，这种方式也是目前最可行的一种方式。