地址/Add:北京市朝阳区南新园西路8号邮件/Mail：传真fax：010-小微金融彭蕾：传统企业转型 互联网应心怀敬畏|支付宝|彭蕾|互联网大会_互联网_新浪科技_新浪网
小微金融彭蕾：传统企业转型 互联网应心怀敬畏
英才杂志社社长宋立新与小微金融服务集团CEO彭蕾
小微金融服务集团CEO彭蕾
英才杂志社社长宋立新
　　新浪科技讯 8月27日中午消息，2014年中国互联网大会于26日至28日在京举办。在会上，英才杂志社社长宋立新与小微金融服务集团CEO彭蕾进行主题为“产业跨界?创新发展”的对话。彭蕾在会上表示，移动支付要成为真正的趋势仍需三至五年。谈到实体经济与虚拟经济的争议，她认为很多传统企业在转型方面做了很多创新的尝试，新兴网络经济应该要对他们怀有敬畏之心。
　　以下是彭蕾对话实录：
　　主持人：接下来是对话环节，主题为产业跨界•创新发展。两位女士分别是彭蕾女士，另外一位是很睿智的媒体领袖宋立新女士，两位女性的对话主题为速写彭蕾：突破想象，未来已来。
　　宋立新：各位嘉宾上午好！很高兴在这儿相聚于此，我今天第一次来互联网大会，第一个反应是我和彭蕾都穿的太多了，因为门口的那些姑娘展现的都是夏天的火热。我希望我们今天讨论的话题能够带给你们这样的一个火热。
　　其实今天的话题年初在媒体上争议很多，都是说移动生活是不是真的已经来了？我记得今年春天在上海讨论，彭蕾说如果这杯咖啡让我来付，一定可以刷支付宝，因为我是不带钱包的。我相信可能在杭州，移动支付比北京更明显，彭蕾今天您来带钱包了吗？
　　彭蕾：今天真没带钱包，刚才立新说的话题，其实我三四年前就尝试了。有一个下午，我不带钱包，成功地买了一张CD、一条围巾，还 给我的小孩买了一件衣服。怎么做到的呢？其实很多人并不知道支付宝可以在线下买东西，我就问他，你有没有支付宝？他说有，我说我就把这个钱直接给你好了。 我发现我现在不带钱包的习惯越来越强了。
　　宋立新：现场不带钱包的举一下手――所有举手的都是年轻的，无论年龄多少，但是我们走在生活的前列。其实今年上半年关于移动生活 的讨论，什么是移动生活的标准也蛮多的。我自己理解，生活的自由有两个纬度，一个是财务的自由，一个是时间的自由。可能金钱和时间是我们现在最大的两个要 素。但是，从争议上来看，大家对整个支付宝所带来的随心、随地、随时、随身、随感这种感受，我觉得现场还有一部分人感受不深。所以，我想先请彭蕾谈一下， 你觉得你所做的，会为我们的移动生活带来什么样的改变？
　　彭蕾：回答立新这个问题前，先讲两句跟这个问题无关的话。我其实真的特别少参加这样的活动，这个不是说特别清高，或者是觉得怎么 样，不是的。我觉得我真的是不太善于讲这种特别大的话题，特别是对一个未来的构想，然后包括对于过去所做的事情，它的意义的一个提炼，这个事情我觉得我是 特别发怵的，我特别不擅长讲这个。
　　我比较喜欢的是什么呢？刚才这个问题，其实我更喜欢的是回到当下我们需要的是什么？我在支付宝，我们支付宝今年10周年，我们一直讲，我最希望 看到的是说，支付宝他可以帮大家去解决掉生活当中一些特别小的，但是又特别不方便的需求。然后，让大家觉得我原来可以这么方便，还可以这么爽。我觉得这个 就是我们存在的最大的一个价值。就像2003年淘宝起步的时候，很多人在网上买东西很担心，我说我们就想了一个简单到有点愚蠢的一个想法：就是担保。我中 间给你过渡一下，卖家也放心，买家也放心。
　　其实今天在移动互联网时代，我们同样面临这个问题，你究竟给谁创造了什么价值？这个价值你先不要急于揣测它会为未来带来多么翻天覆地的变化，想 要把过去的一切都颠覆，然后开创一个新时代，打开一个新格局，那个都太早了。你回答一下，大家平常消费的时候掏钱包，然后拿出银行卡，或者拿现金，然后回 到所有的细节，然后再去体会，你用手机可以帮他做什么。我觉得我们今天是在面对移动互联网时代，特别是移动支付时代，一切一切回归到细节和当下的一些最小 的价值链上。
　　宋立新：手机到底能帮我们做什么？我们今天通过彭蕾的介绍，我们回到比较接地气的议题，我们看看支付宝这两年做什么？我们可以看到O2O这么一个时髦的概念是不是真的能落地？上半年其实用手机能干什么，你们已经和很多实体的商家合作了，达到预期的效果了吗？
　　彭蕾：其实我们上半年做了很多的尝试，大家也看到未来商圈，未来公交，未来医院，未来学校，我们做了一系列的未来系列的尝试。为 什么以“未来”作为主题呢？它当下还没有成为我们生活的全部。但是，由于我们看到移动互联网来了之后，它存在这样的可能性：就是用手机让生活更方便，让大 家的价值感觉更好。所以，我们在这个领域里面。比如说未来医院，你想在医院里排队，纠结吧，痛苦吧，你这儿挂号了，排队缴费，拿药的排队缴费，化验的排队 缴费，我们希望未来在手机上面可以不用去排队，你挂号，你的就诊，所有的费用都可以很轻松的。人家在那儿排队的时候，你在边上就可以搞定了。
　　未来商圈也是一样的。你去到那儿逛街，有些时候女孩儿大包小包买了东西，还要想怎么拎回来，你还要唱卡拉OK，或者吃饭，我拎着包特别不高兴。 怎么和网上的物流打通，让商家在店里面的库存降的更少？商家不用把货放在店里面，直接发到顾客家里。像这样一些小小的需求我们看到了，然后我们尝试用移动 的手段去尽量的帮他做实现。所以，我们现在都在做这样的尝试，很多尝试的结果也很有意思。
　　有些东西叫做你本来想去做这个，但是这个未必能达到你的期望，但是会带来一些新的价值。我们看到在移动生活、未来生活的概念下面，在杭州有一个 很有意思的小现象。在杭州的一些公园里面，边上很多人卖矿泉水，就是晨练的，跑步的，然后那些小贩儿用支付宝钱包收钱，因为出来跑步的人一般不会带钱包， 但是会带手机。所以这些需求，在很多的地方，在我们烛光照不到的地方就在实实在在的发生。包括还有很多早上卖油条、卖包子，很多人不愿意收钱，它就变成一 个二维码，说扫描就可以付，两块钱，拿了东西就走。所以，看到有很多这种变化在这个大潮下面一点点的在生长，我觉得这个其实是未来生活最有生命力的一个开 始。
　　宋立新：其实我刚才这个问题更多是一种提问，因为我的支付宝更多的功能是给儿子支付帐单，可能我太老了。但是，我真的在北京还没 有用支付宝付帐单的经历。厂商也给我抱怨，这个很好，但是他们除了甩掉尾货之外，并没有吸引来他们想要的客户，这一点也希望今天你能够给我一些答案，为什 么O2O说的很热，向往也很多，但实际上真正落地的这种感受还没有。
　　彭蕾：一种趋势背后，其实它是一个习惯和一种基于人性的价值。首先说习惯，一个习惯的改变其实没有那么容易。今天我们说通信的习 惯，现在大家有各种各样的通信方式。但是，在漫长的人类的历史当中，从驿站，到后来写信，到后来打电话，到现在的即时通信，经历了很多时间点，慢慢演变起 来。但是，随着新技术的发展，我们看到这个时间就是在缩短。即使缩短，如果把这个移动支付放到历史的时间来看，我觉得它真的要形成一个习惯，其实还是需要 有一个相当的时间段。回到我到餐厅吃饭，商场买东西，每个人都可以想一下，你想的那一刻最需要完成的事情是什么？你会想到手机会付钱，还是想到现金在哪 儿？我觉得并不是唱衰，但是我觉得一定需要时间去改变和培养习惯。
　　然后第二个习惯背后是什么呢？其实是一个价值的概念，一个诉求的概念。而这个价值和诉求，我觉得现在很多时候我们做很多事情还是很急，体现在哪 儿呢？我们会用利益去把大家的需求调动起来，但是你从长期来看，你这个利益的刺激能够支撑大家，所以我觉得你可以用一些方法，但是更重要的是你究竟为他创 造什么样的价值，这个价值究竟有没有像我刚才讲的，我跑步的时候不会带钱包，但是我会带手机。这个价值背后其实是人的本能的，最本质的一种需求的响应。这 种能力其实决定了我们很多的创业者，从业者在这一轮的大潮当中能不能够胜出，而不是想先要去想一个特别大的东西，就想它能够改变一切，这个我觉得不太靠 谱。
　　宋立新：刚才彭蕾也说了改变是一种习惯，根本的是体验价值的扩大。当有足够的差异化的时候，很可能才会往这个价值趋同方向在走。 所以，我想让彭蕾预测一下，你觉得在上海，在北京，多久能够达到像杭州一样的移动支付的水平？然后可以写下来，如果下面的有赢了，可以在上发，赢了的 话，可以找支付宝要奖金，请彭蕾预测一下。
　　彭蕾：实际上我也不觉得杭州现在已经那么的普遍了，其实这个也还有很长的路要走。但是，我自己的感觉，移动生活，移动支付要形成一种趋势，我自己感觉至少还要三五年的时间。
　　宋立新：上海比北京要快？
　　彭蕾：应该是。
　　宋立新：作为一个北京人，我们已经落后在互联网的速度之后，虽然北京有这么多的互联网公司，但我觉得移动支付的习惯在北京还是比 较弱的。因为北京是一个政治、文化中心，所以他们对安全的需求可能比别的城市要高一点。所以，我想问一问，移动支付，包括移动生活给我们带来很多的自由， 但是自由背后一定是你自主选择然后要自主担当结果。所以，很多人会在这个选择上焦虑，你觉得自由和安全的冲突怎么解决？
　　彭蕾：这个问题让我想起几百年前的银行。其实在很久以前，大家都觉得把钱在自己家后院挖个坑埋在里面最安全，我把钱挖出来放到银 行，这怎么可能。但是，今天如果谁还有这么一个想法，我觉得匪夷所思。但是，站在时间最开始的时候，任何对安全的想法都是特别正常的，没有一个新生事物它 在一开始的时候就特别靠谱，真的它需要时间，也需要一代代人把这个东西建立起来。认知上的恐惧和你对这个事情的担心，在面对很多新的事情的时候，这是一件 特别自然的事。但是也没有必要说明这样想是多虑，我们行业有种种方法会告诉人家这个是安全的。同时更重要的是，你手里上要强大的技术，强大的安全的能力。 像我说的几百年前的银行，如果那个银行特别不靠谱，一会儿倒闭了，或者一会儿被强盗抢了。
　　所以，在发展的过程中，新事物的安全性是不断在提高的。这个只是一个时间和趋势的问题，它本身并不是真正的一个问题。
　　宋立新：其实关于支付宝在公共环境之下是不是安全的故事随着变化不断会有新的故事出来。我一进会场，支付宝提醒我有免费的 WIFI在用，我觉得谁在发这个，但是人总是本能的，谣言重复一百遍的时候，可能多少会有些理性。大家有多少人用支付宝的WIFI？我明显感觉比刚才使用 支付宝的人要少。所以，就是习惯，如何能让我们不断地充分感受到安全。因为你发展的越大的时候，围绕的谣言、故事就会越多。这一块我想可能不是对于需求发 现的不同，甚至也可能不是对趋势方向判断的不同，也可能所处的利益也不同，这也可能是一种利益之争。
　　谈到利益之争，我们就想起来和王健林的天价打赌，包括和董明珠的纷争，把价格越提越高了，从1亿，甚至到100亿。这个来讲，O2O这 一块，真的会颠覆实体经济吗？我想听听你对他们俩天价之争，你是怎么看的？关于O2O、关于互联网、关于他们与实体店之间的利益，包括谁是未来的趋势？是 不是真的能够由互联网来主导未来的变革？这个问题虽然很大，但也是这两年比较多的话题。想听听彭蕾的看法。
　　彭蕾：对，我觉得这几年关于实体经济和网络经济的话题其实在社会各界的推波助澜下面好像已经变成一个社会性的话题。我是1999 年的时候参加阿里巴巴()，上网的时间也比较早。我觉得作为互联网行业的这样一代人，我看到我们的同事，包括我们这些人其实在很长时间里面确实有那么一点感 觉，就是我们要代表新经济，我们要去改变，要创造很多过去没有发生的事情。但是，随着时间越久，以及真的当你了解到那么多的几百年的很多百年老店的发展沉 浮之后，我其实越来越对很多的传统行业心生敬畏，因为很多很伟大的企业其实他现在做的和在他最初做的已经发生很大的改变。并不能说他的行业就落后了，或者 他的产品就落后了，这个有可能落后。但是，最可怕的落后是你对新生事物的好奇以及对于新技术的拥抱，以及对于新兴人类的一种需求的灵感的捕捉，这才是真正 可怕的颠覆背后的最大的危机。
　　所以，我老觉得，其实所谓的老经济也好，新经济也好，如果新经济对于老行业它的本质，比如我们现在做金融，金融行业，我们是为金融提供服务，为 他们怎么创造价值。但是，金融有它自己的本质特点：风险、信用、数据，对一整套的体系，你如果不了解，就好像互联网可以颠覆，可以摧毁一切，我觉得那是很 可怕的。
　　同理，如果老的行业相信最好的都是在过去，都是在以前，现在很多东西都不靠谱，比如00后唱的什么歌，穿的什么衣服，这对我们才是最可怕的，不要固守你传统的一套。
　　我觉得其实最后看哪一个人，或者哪一家企业它能够在这个潮流当中把这两种特制完美的融合在一起，它能够发现这样的机会，并且能够帮他的组织，帮 他的公司实现这样的转型，能够吸收各个行业的营养，最后才能成为他自己。而不是他急于批一个新经济的皮，或者在老经济里面，假装看不到一切。我看到老经济 他们对新事物的领会、拥抱、理解，以及使用的能力不够。
　　宋立新：请彭蕾举例说明一下，因为彭蕾刚才说学会了互联网新经济思维的传统产业他们是最厉害的。你给我们举一举你心目当中觉得厉害的。
　　彭蕾：举个金融行业，我跟平安的马明哲董事长聊过天，今天平安在金融领域以及在互联网行业，以及对于创新的尝试上面让我非常佩 服。他们那种拥抱性是有挑战自己过去的勇气和能力。当然很多金融机构，其实现在在拥抱互联网和移动互联网上做了非常非常大胆的、非常有自信的这样的一种尝 试。这个让我非常佩服。
　　宋立新：我知道彭蕾的小孩儿已经上小学了，而且还会做饭给妈妈吃。可能刚会做几道菜的小孩儿，我们不希望他马上就会做满汉全席， 所以你想做满汉全席，可以找资历更老的店，和小孩儿所交换的这样一个价值，就是你要降低体验可能才能更好。但是，人都不是这样的，每个人都是我信赖你了， 使用你了，我都希望你能给我一个满汉全席的感受。所以，这个过程当中，可不可以介绍一下，让你在每天工作除了不希望成为老古董这样的焦虑以外，你对支付宝 的体验最焦虑的是什么？
　　彭蕾：对支付宝的体验最焦虑的还真没有，这个没有不是说我们什么事都已经做的那么好了。因为其实人到了一定年纪以后，发现很多时 候你焦虑不能改变这个事情的时候，你的焦虑就只能消耗你自己的能量，让你自己特别不开心。我觉得有那点精力去焦虑，我们还不如看看最近注册环节是不是有哪 些地方可以改善，最近客户量，哪些客户提什么问题多了，我们产品背后是不是出了什么问题。
　　我真的好像不太容易为这个事焦虑，我不知道这个作为一个CEO来讲，是不是不太负责任。我真的不太为业务上的事情焦虑，反而如果说真的要焦虑， 我觉得还是对我们这个团队，就是说能够跟得上这一拨，跟得上未来的客户，对于这个我可能有点焦虑。现在90后的同事都已经加入我们了，我最近在研究弹幕网 站，一种新的视频方式吗。看电影可以直接吐槽，我在研究这个东西。因为你只有知道现在这些人在干吗，包括我女儿经常听歌，她最近听《龙卷风》，我也觉得听 听没有什么焦虑了。现在的业务它今天好，今天不好，我们都了然于胸，但是对未来发生的变化，这个不确定性，反而是比较令人焦虑的。
　　宋立新：我刚才想到巴斯光年谈到的星系宇宙拥抱无限可能，可能这更适合互联网一个人的想象和你们的愿景，我也想请彭蕾，今天在座 的很多公司谈谈你的感受。刚才你谈到，除了拥有互联网思维的这种传统产业可能能够抓住未来。但是，现在有这么多互联网公司做各种各样的尝试，你认为谁更有 可能抓住现在移动生活的趋势？
　　彭蕾：你又问了一个我最不擅长回答的问题，我就回答一下主办方的问题，用我自己的方式。其实我也不会算命，我只是将阿里巴巴创业最早的一些感受跟在座的各位朋友分享一下。
　　我知道今天其实有很多创业者也在现场。我们自己在1999年也经历过这样的过程，是完全能够体会在那个时候所经历的一切。我自己最大的感受是在 创业过程，最早的时候你感受到的是快乐，还是压力，是天马行空无拘无束的小孩，可以尽情折腾的事业的喜悦，还是我今天一定要把这个事弄成一个什么？今天马 总不在，马总曾经讲他要让阿里巴巴成为世界上排名前十的互联网公司之一。我们作为当时坐在下面的人，我觉得好像这个事特别遥远。但是，什么事情特别确定 呢？我们最早是做电子商务的信息交易的平台，每天看到平台上的用户数特别多，当时都是我们自己给他们回邮件，跟他们交流，非个性化的人肉性的服务。就是让 人觉得还有这么好的网站，而且我发布信息，真的有买家或者卖家找我，然后就给我们感谢，我们觉得做这个事很实。具体这家公司未来市值怎么样，它会让你如何 富有，真的没有想过。
　　第二个就是不管在那个时候你多么的艰难，信心其实是不应该轻易被放弃的。我们在开玩笑，1999年有一段快断粮了，就是没有钱进来。我说哪怕互 联网，阿里巴巴搞不下去了，我们就这一伙人，我们开一个店也是用户体验最好的。这个事情做不了，可以用别的方式，或者在别的领域，一定会有人需要我们这群 人给他创造更好的价值和体验。所以，我讲不出更多的东西，我就觉得这个很重要。
　　宋立新：我觉得彭蕾其实刚才谈到了三个点：第一、如何抓住未来的移动生活？首先是做实事的公司，每天把给别人带来美好的价值的改 变，有成就感，这样的公司是可能的。第二、做好事的公司，就是你这个方向，符合共赢的原则，能够担当自己的因果选择。第三、做新事的公司，每天，今天和昨 天都会有一点点的不同，这样三个事：实事、好事和新事。这样的公司可能会发现未来的机会。其实我觉得传统产业本身来讲，他们也是因为互联网在美国的上市创 新高，电商，相当于一个五粮液，对整个传统产业的打击还是蛮大的。所以，最后问一个问题，彭蕾喜欢听罗大佑的一首歌叫《告别的年代》，很文艺的一首 歌，谈到了生活的质感。会不会互联网发展的这么快，我们生活的质感会越来越低？
　　彭蕾：生活的质感低不低，其实要问这个选择权是不是在你自己手上。如果你今天被剥夺了这样一个选择的自由，我觉得是非常悲哀的一 件事情。刚才讲说是满汉全席，其实只要你有钱，或者你能找到那个地儿，你可以吃。但是，你如果想吃那个柴火烧的农家菜，你也可以找到那样的地方。所以，我 一直觉得所谓的你丧失了什么，你拥有了什么，其实最主要要问的是你选择的自由在不在你手上。如果你周围大家都在过这样的生活，其实今天还有很多人刻意放弃 这些，就到山里边过农耕时代的生活，所以关键看你自己喜欢的是什么，不要随波逐流。不管移动互联网，或者是未来什么，新闻说有些人要移民到火星，有几个人 已经准备上去了。我觉得像这些，你不要被这些东西所推着走，不清楚自己想要的是什么，你就不会担心你会不会丧失生活的质感，你还是可以选择。
　　宋立新：这个回答就是的出现并没有让满汉全席绝种。最后用一句话总结一下你参加这届互联网大会的感受。
　　彭蕾：非常高兴有这个机会来参加，我的感觉跟刚才立新进来的时候有相同的，也有不同的。相同的就是觉得自己穿太多，第二个不同的 就是说其实我真的确实很久没有参加这样一个大会，进来能够感觉到这种活力、热情还有一种无限的可能，就是在整个的会场，就是感觉到这样一种氛围，这个氛围 让我觉得感觉特别好。
　　第二个想说的，无论什么时代，其实最重要的是自己安安静静的静下心来想明白你心里究竟想要的是什么，你希望把它做成什么样子，以及和现实之间的差距，然后不随波逐流，也不轻言放弃。
　　宋立新：谢谢，移动生活给我们带来无限的可能，彭蕾也谈到，最大的一个词是自由。可能对于一个有责任的人来讲，自由不是说我们不 去做什么，我想不做什么，我有钱了，可以不去劳动，这样的一种自由，是不做什么的权利，而是刚才彭蕾所谈到的，想做就做的实力。所以，我最后用彭蕾在来往 当中的一句话做结尾，在告别的年代，要么生，要么死，但是如果你不拼，你肯定是生不如死，谢谢各位！
文章关键词：
&&|&&&&|&&&&|&&
您可通过新浪首页顶部 “”， 查看所有收藏过的文章。
，推荐效果更好！
看过本文的人还看过您的位置： &
　　英文原文：
　　多年以来，采用模型驱动开发（MDD）的水平似乎仍没预期的那么好。阻碍、限制MDD使用的因素有很多，例如对实际的MDD成功案例缺乏认知、不确定如何在平常使用MDD、缺少预先投资的拨款模式、或是没有战略举措的重点。
　　如果你过去尝试过MDD，那你很可能遇到了一些挫折，导致你现在不再用它。也或许你正在尝试采用MDD，而又面临着一些挑战和阻碍。无论你遇到上述哪种情况，本文都对你有所帮助。我们会在本文中看一看与采用MDD相关的挑战和误解。
　　建模早已证明了它在改善沟通、促进业务编排、提升质量、提高生产率上的价值。它的使用范围很广，分析、设计和开发都会有所涉及。考虑到这一点，我们就来看看有关MDD的诸多误解和挑战，我们又该怎样利用现代方法和相关工具集解决这些问题。
　　1 - 挑战：方法不当且不可用
　　过去，MDD的一个关键抑制因素是人们实施活动的时候没有现成的MDD最佳实践。比如说，人们在阅读有关如何执行特定任务（诸如设计高可用的解决方案）的过程文档时，文档里并没有任何MDD的内容。为了得到MDD实践，人们不得不到论文或书本里去找，然后再应用到现有的非MDD文档上。
　　如今，MDD从业者在进行日常工作时，可用的MDD指南已经越来越多，而且那些信息嵌在他们每天使用的工具中。我们先看看开发过程，它包括利用MDD原则的&工具向导&最佳实践，这些&工具向导&隶属于整个方法和过程。
　　特定任务的指南（例如需求评审、设计用户接口或设计高可用的解决方案）现在都包含指向MDD内容的链接。比如推荐设计模式、提供设计中应用模式的指南、利用现成工具中的模式实现。
　　以前还有另一个阻碍因素，就是MDD与特定开发方法过度掺杂，人们无法提取MDD最佳实践，并将其应用到不同的场景中。一个典型的例子就是面向对象分析和设计（OOAD）中存在大量工具，你要么采用全部的OOAD内容，将其作为从MDD受益的一部分内容，要么就完全抛弃OOAD。MDD的最佳实践曾是OOAD框架的一部分，但人们并不知道如何在框架之外利用这些最佳实践。抽取出MDD的内容并将其应用到不同的场景中是不可能的。
　　这些因素再加上其他一些原因导致企业很难在它们的环境里采用最佳实践（包括MDD最佳实践）。公司已经有了合适的过程和方法，而给这些方法添加MDD方面的内容却很困难。
　　为了在组织和特定类型的项目中采用MDD，业界在裁剪特定开发过程方面已经做得越来越好。比如有的研讨会旨在指导团队完成定制的开发过程，这通常被称作&方法采用研讨会&。研讨会的目的是针对特定项目裁剪现有的方法内容，它通常会涉及以下人员：过程工程师（管理组织开发过程的人）、首席架构师、开发人员组长和项目经理。
　　支持定制后，方法工具浮出水面，比如Rational Method Composer和Eclipse Process Framework Composer，它们包含定制的最佳实践库。这些工具的思想是整理、打包最佳实践，用工具为组织裁剪并采用这些最佳实践。在工具中，你选择想要采用的某些方法元素，对它们进行修改、编辑，并将其组织成希望关注的过程。然后将该过程以可读格式（例如HTML）在组织内发布，供从业者在日常工作中遵循。
　　尽管使用上述工具和方法的可用指南有很多，但仍然要求用户找到、理解并遵照指南。跨越这一障碍的措施是，除了在工具里提供指南之外，还要将方案的全面自动化。举例来说，你能在使用基于Eclipse的产品时利用备忘单（Cheat Sheets）。备忘单提供完成任务的步骤指南，并能自动化工作流里的步骤。
　　下一节我们会讨论关于模式实现的机制。不管选用什么方法，要点都是获取越来越多的指南，并将其落实到工具中，从而更好地指导用户充分利用模型。
　　正如软件解决方案可能会过度工程化一样，创建指南也会发生同样的问题。克服这个挑战的最后一点是要务实、主动。计算出构建方案所需步骤的全部细节，无论从价值来说还是从时间来说都没有什么意义。那关键的步骤是什么呢？他们如何与团队的技术相结合？在文档化步骤上投入时间的意义何在？相对于自动化，在创建静态文档上又该投入多少呢？
　　过程，尤其是MDD，都不是放之四海而皆准的，这将在&4-误解&中讨论。
　　2 - 挑战：基础设施和工具不能从MDD获益
　　近几年，我们看到建模工具已不局限于对特定图形符号（比如UML）的支持了，经过发展，它已然能帮助从业者完成工作。这些工具不仅支持图形建模符号，也内置了MDD特性，这些特性有利于：
业务编排：业务编排是SOA等成功方法的关键方面。通过使用MDD模型、自动化、以及与之关联的&追踪&，你能记录决策的原因，跟踪满足业务需求的所有方式。另外，我们可以研究利用MDD的特定版本，比如业务驱动开发（BDD）。顾名思义，BDD关注的是业务建模。你可以在这种情况下进行建模，也可以在某些情况下模拟组成业务的流程。
高质量：由于实践内建在工具中，并进行了自动化处理，因此出错的几率非常小，甚至不会出错。
增强的一致性和治理：由于工具支持指南和最佳实践的自动化，所以提高了解决方案中元素的一致性。另外，工具也能确保构建的元素是固定的，并与需求和最佳实践保持一致。
提高的生产率：重复、耗时的工作现在都自动化了。从业者可以&复用&，把时间花在最紧要的事情上（比如业务逻辑）。依赖自动构建，用户群的复杂度和自动化要么可以在当前项目中实现，要么可以分散在多个项目中实现。
改善的沟通：使用模型、工具和自动化，从业者（例如架构师）能针对不同的受众创建不同的视图。
影响分析：MDD的可追踪性能让你分析出需求变更对解决方案造成的影响，反之亦然。
　　让我们以设计模式为例，来说明工具如何给MDD带来了活力。假设某本书中描述了设计模式，我们将其称为模式规范。该规范非常有用。它描述了模式的使用时机、模式的特征，以及使用模式的好处和意义。模式规范能帮助人们理解模式并做出恰当的选择。但模式规范并不能确保设计的高质量和生产率的提高。为了从中受益，你必须将这些模式&自动化&。我们将其称为模式实现，也就是模式规范在工具中的可复用编辑。使用模式实现，设计者可以将模式快速应用到他们的设计中，也能确保这些应用准确无误。
　　领域独立的工具不太可能内置领域所需的所有MDD工件。工具除了提供开箱即用的MDD工件外（比如一组设计模式实现），也允许你扩展现有的工件、创建自己的工件。现在的工具包含&扩展框架&，以及最佳实践、模板和API。Rational Software Architect之类的工具还允许你构建适用于领域的MDD工件（例如模式实现、规则、约束等）。
　　既然你能构建这些MDD工件，那么基于资产的开发（ABD）就能让你与他人共享工件、提升复用的实践和基础设施。换句话说，ABD最佳实践和基础设施的改进支撑了MDD的采用进程。诸如Rational Asset Manager的可复用资产库能让你管理可复用的软件工件，让开发社区共享和复用工件。试想一个为领域创建的模式实现，你现在可以把它提交到资产库中，该模式经过评审和认可，社区中的其他从业者就可以复用它了。作为这个生态系统的一部分，你可以监控资产被复用的时机和方式，收集反馈信息并确保整个团队在使用合适资产的正确版本。
　　我们重新回到务实和实用上来。在对用户和用户所在组织有意义的情况下，ABD及复用倡议才需要被采用。你需要识别出你的成熟度级别，并采用支持该级别的工具和过程。通过事先思考和计划，你可以随需确定、推广ABD计划，避免不必要的开销和成本。
　　3 - 误解：MDD==UML？
　　有一个误解是MDD意味着你必须使用统一建模语言（UML）&&现状如此，完全是因为来自对象管理组织（OMG）的UML规范进行了这样的描述。消除这一误解的方法有很多。
　　打消这种念头的第一种方法是用MDD的方法工作，这只需要你在执行任务时把模型作为关键的工件使用，并使用利用这些模型的自动化机制。在这种情况下，模型是用语言简化了的现实，而这些语言具有定义良好的语法和语义。因此，可以在MDD中使用的语言有很多，而不仅仅是UML。&
　　在大多数情况下，我们确实要为手头上的任务选择合适的工具。如果我们的MDD需要标准化、为人熟知、被广泛支持的语言，那UML就是一个不错的选择。UML也是可扩展的。严格来说，它能通过配置（提供定制的元素、属性和约束）进行定制。这能让UML对所作的工作来说变得具体，也能让语言更加易学易用。增强建模语言可用性或针对性的另一种方式是创建你自己的领域特定语言（DSL）。
　　要记住的是，我们受益于使用的语言和创建的模型。为了指导投资，我们要权衡以下问题：
是否能有效地设计和理解解空间？
能否轻松地和其他人沟通？
是否能基于已经创建好的模型生成方案的其他部分？
能否有效利用开发生命期之外的结果？
是否能从实现追溯到设计？甚至需求？
　　4 - 误解：MDD放之四海而皆准
　　根据前面的误解可以看出，MDD显然不是放之四海而皆准的解决方法，任何非预设的生产线工具集都可以用来构建产品。MDD就是用模型为特定情况增加价值，它适用于特定领域，跟你所开发的软件类型也是配套的。因此，我们能在自己的场景中看到很多使用MDD、有意义的方式。
　　其中一个例子是，我们可以和传统的面向对象分析和设计（OOAD）一起使用MDD。在审视OOAD和MDD的时候，往往会发现使用了很多模型，比如用例、分析、设计和实现。有很多现成的例子和文档演示了如何使用这些模型来完成方案。但这并不意味着你必须用上所有的模型。关键是我们要有效地利用抽象。抽象的层次取决于所处的场景、使用的语言、相关的约束、规则和假设，以及可能实施的自动化。
　　除了在模型数量（和相关的抽象层次）上务实之外，也要切合实际地选择模型中用于交流的图表。比如说，如果使用UML作为建模语言，就没必要使用所有可用的图表类型（类图、交互图&&）。语言中有一系列图表可供选择，一般用途的建模语言能为各种需求提供服务就可以了。在特定情形下，对于你试图完成的工作来说，只选择那些能为其增加价值、有助于沟通的图表才是有意义的。至于完整性，我们可以进行进一步的讨论，要注意的是，即使在一个图表中，你也不必使用所有可用的模型元素。
　　5-误解：图表就是模型
　　MDD中关键的一点是要认识到我们在创建模型&&正如前面所讨论的，模型是用语言简化现实，该语言要具有良好定义的语法和语义。我们在模型中可以发现大量模型元素和一组图表。每种图表都提供了模型元素之上的一个视图。每个模型元素属于零或多个图表。我们要关注模型元素&&它们是什么？有哪些关系？有什么属性？我们通常使用图表来帮助我们理清这些问题。此外，我们还将图表作为和其他人沟通的方式。但模型的关键信息存在于模型元素中&&因为这能让我们生成所需的视图、创建所需的图表，从模型生成其他元素。如果MDD只是图表，那工具能画出漂亮的图片就能满足我们的需求了。这并不是说图表（和支持图表的工具）不重要。创建模型和图表的工具需要进行调整，以适合目标受众。
　　结合有选择性地使用图表，我们还能利用视角让模型更加可用、更加利于沟通。视角是组织模型的一种方式，以便模型的某些方面可以提供额外的图表，使模型面向各种各样的受众。透视图通常只包含图表，而没有额外的语义元素。严格来说，在你更新语义元素时，透视图会自动保持同步。使用透视图可以让你与其他角色和小组有效沟通，从而为MDD增加价值。每个小组都想理解方案中的一部分内容，也就是与他们的需求相关的那部分。在不打乱模型、不构建独立模型、或是不在维护同一元素的多个版本上浪费时间的情况下，透视图可以支持这些需求。请记住，我的意思并不是让你支持所有不同的小组，并创建庞大的一组透视图。再次强调一下，关键是要务实，要创建有意义、能带来价值的图表与视角。
　　6 - 误解：代码就是模型，模型就是代码
　　以前对MDD的误解之一就是它只能应用于代码。MDD基本上被局限在一个较低的抽象层次，因此它的影响也很有限。很多人只用MDD工具&可视化&代码（也就是将代码图形化的逆向转换）。这样是有好处的，比如说，更好地理解大段代码，以及组件或类之间的关系。但撇开这些来说，代码可视化并不能获得先前讨论的那些MDD优势（比如业务编排、改善质量、提高生产率或影响分析），因为它所作的一切也就是让你以图形化的方式查看代码而已。这是基本、初级的图形使用方法，和预期的一样，它的投资低，收益也低。
　　再复杂一点儿，在代码可视化之后，让可视化结果和预期的设计保持一致。例如设计师或架构师想评审开发团队开发的代码，代码的可视化视图就能让他们对代码和设计进行比较，因为可视化结果和设计使用了相同的可视化技术（比如UML类）。不过，尽管可视化结果和设计用相同的语言表示，但两者之间仍然有很大差距，因为它们所处的抽象层次不同。MDD工具凭借可视化、可追踪性、分析和发现功能、重构支持能帮助设计师完成工作。一旦标注出设计和代码之间有分歧的地方，人工干预就必不可少了，设计师就要和开发团队进行沟通。这能提升价值，但仍然无法完全拥有MDD的优势。为了支持分析和沟通，需要增加时间和精力，而且每个项目都需要投入多次。
　　MDD应该适用于任何层次的抽象，并有助于不同层次之间的连通。你应该在较高层次的抽象上进行建模。以分析模型为例（像系统的用例模型），它是设计模型的输入。分析模型中的有些元素可以在设计中予以利用。比如说，功能域信息分类（包）和用例可以用来创建设计模型中交互图的基础模板，用例会在设计模型中实现。利用工具及其扩展性，你可以修改&分析到设计&的转换过程，接着让组织内的成员在质量和生产率上获益。
　　MDD适用于所有层次的抽象，而抽象的层次是无穷尽的。要为领域和组织选择有意义的抽象层次。例如，在SOA中，可以在开发方案时采用以下的抽象层次：
业务：该层次对业务策划师、业务分析师或产品所有者来说是有意义的。在这个层次上，模型元素是业务目标、关键性能指标、业务方针和功能域之类的内容。
分析：分析和设计通常要一起看，分析模型的元素有时会演进为设计元素。在SOA里，考虑分析是很重要的，因为分析是支持业务元素的技术模型元素的起点。
设计：SOA方案中，大多数在架构上重要的元素都是在这个层次建模的。设计时要用文档记录架构的关键元素，以及它们的实现方法。
实现：实现是&代码&层次的抽象。在该层中，你可以用MDD基于设计生成代码存根，并在需要的时候让代码和设计保持一致。
　　另一方面会出现这样的情况：人们热衷于模型和MDD，甚至仅仅为了建模而建模，却忘了把模型转换成可操作或可执行的内容。架构师可以和利益相关者、设计者和开发人员沟通，但你仍然不能完全受益于MDD。在你策划MDD的策略和方法时，要思考一下如何利用模型。譬如，部署方案最终用什么平台？如何提高代码质量和开发人员的生产率？是否能将模型转换成代码存根？
　　另外，模型所包含的有用设计信息要多于生成代码所需的信息，所以我们还要看看其它方式，来利用这些已捕获的重要而有价值的信息。这包括文档的生成、测试用例、部署脚本等，这样就能显著提高项目的整体生产率。众所周知，实际的代码编写只是整个项目的一部分工作而已。
　　没有什么银弹。所需的代码并非都能自动生成（除非你的领域非常小）。最后，你必须处理模型和代码，MDD则会指导你利用模型、保持代码与模型之间的同步。
　　不过双向工程怎么样呢？如何利用自动化保持不同抽象层次之间的模型同步呢？这也是一般方案中较为棘手的问题。例如，从较高层次的模型向较低层次的模型转换时，许多元素会展开&&一个元素会在较低层次上演化出多个元素。一旦创建了较高层次的模型，用户就可以更新、移除、添加较低层次上的模型元素。那又该如何映射回较高层次的模型去呢？若干组详细的元素又怎样转换/映射到少量的高层次元素呢？面临这样的挑战，就很有必要想清楚，追求的这种方法到底是不是开发方法的一部分。
　　由于修改极可能在代码级别发生，所以若没有保持模型和代码一致的方法，模型很快就只剩文档了。最近，Rational Software Architect之类的工具在&保持一致&方面有了很大的改进，提供了可视化代码、比较和合并的功能。请注意，用于协调这些变化的方法比工具化的能力更为重要，这和治理也是相关的。举例来说，架构师看到了代码和模型之间的差异，怎么办呢？去和开发人员讨论？让开发人员修改代码？还是架构师修改模型？正如你所看到的，这些都不是完全自动化的方法。
　　已经取得巨大成功的另一个方式是预先在工具化上投资（要么购买要么定制），通过约束、规则和假设减小问题空间。对问题空间所能做的限制越多，生成高比例解决方案、减少抽象层次、消除双向工程需求的可能性就越大。在这种情况下，今后的关注点只需放在工程上。
　　7-挑战：平台无关性面临挑战
　　虽然不确定平台无关性发生的时间或原因，但是在高层次上进行建模、然后生成解决方案的想法已经引起了广泛关注。或许平台无关性来自于MDA的平台无关模型，也或许来自其它地方。不管来源如何，都要认识到很难从很高层次的内容进行延展，也很难将一种表示定位到许多不同类型的实现上去。已经有一些解决方案能让用户利用模型生成全部的结果代码了。但在那些情况下，也正如前面小节中所讨论的，工具化对领域来说很有针对性，而且利用了一组约束、规则和假设才使转变成为可能。解决方案空间比较狭小，这样才为生成高层次的内容提供了可能性。随着解决方案空间的扩展，生成会变得越来越困难。
　　就连迁移到DSL上也会提出这样的问题：使用相同的模型作为输入，生成不同的底层实现有多容易。在利用DSL的时候，关键应该是具体的领域和当前的项目。正如从许多敏捷过程中（以及自己的经验）学到的，过度工程化、计算每种可能性都要付出代价。这同样适用于建模和使用的语言。针对具体领域并不一定就是什么坏事，事实上它反而是最佳利益。不过，创建一个领域特定的解决方案，再大范围地加以应用是不切实际的。
　　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编排？
有哪些可用内容？这些内容如何针对你的情况进行定制？
　　感谢Brian Byrne、Greg Hodgkinson和Alessandro Di Bari分享他们的洞见，提出了提高本文质量的宝贵建议。
InfoQ采访&&结合MDD和SOA：
用基于资产的开发实现战略复用：
使用Rational SDP构建SOA解决方案：
揭秘SOA中架构和服务的基本原则&&第一部分：利用架构和抽象层次创建更好的SOA：
EclipseCon 2008大会：模式领悟！基于模式的自动化技术实践：
模型驱动的开发和相关方法的探讨：在模型驱动的体系结构中应用领域特定建模：
Eclipse建模框架：
Eclipse流程框架：
利用SOA、BPM和EA进行战略业务和IT编排：
模式：使用IBM Rational Software Architect进行模型驱动开发：
　　英文原文：
　　[1] 我们并不关注资金模型或战略创新等组织方面的内容。相反，我们要解决的是在尝试采用MDD时可能面临的挑战，并提供能克服这些挑战的MDD最新进展。
　　[2] 在抽象的SOA层面上，这个列表绝不是官方的、全面的。它在这里只是说明抽象的例子，而非代码（实现）。
　　[3] 高级设计和详细设计这两个层次的抽象都很常见。这里只是一个例子，你的选择还是应该视约束和目标而定。
　　[4] Scott Schneider和Randy Lexvold在EclipseCon 2008大会上所作的演讲：模式领悟！基于模式的自动化技术实践。
　　译者简介： 张兵，有Web应用开发、XML技术、消息中间件和企业服务总线等方面的开发经验，对SOA领域比较熟悉，关注软件架构技术和有效的项目管理。
上一篇：下一篇：