"Into The Future？"
在前面的章节中，本书讨论了许多现象和问题。除了Borland本身的发展故事之外，
也讨论了一些科技的现状和未来的发展。在Java和.NET平台的竞争以及许多科学技术
的发展下，Borland的未来到底会如何呢？Borland又要如何适应才能够持续在信息界
竞争、生存下去，进而茁壮成为更大的信息公司呢？在本章中我将提出一些个人的看
法。
除了软件公司的发展之外，我也观察到了一些信息技术的走向。这些信息的发展在未
来也都将牵动着开发人员的走向。除了在第10章中讨论的事项之外，我也认为更精致
化的程序开发能力、面向对象和Modeling的平民化、Web Service的发展以及.NET平
台的普及化都将在2003年开始对于开发人员产生愈来愈深的影响。其中，Web Service
和.NET是开发人员无法控制的信息发展潮流。开发人员唯有在了解了它们的趋势之后，
及早准备以适应未来的趋势。
而精致化的程序开发能力、面向对象和Modeling技术的平民化，则是属于比较贴近开
发人员的发展，也是开发人员能够掌握和进一步控制的因素，是软件人员必须了解未
来继续从事软件开发工作时必须克服和掌控的技术趋势。
到底这些因素的影响事项是什么呢？为什么它们对于软件人员在未来有很大的影响呢？
这些也是本章讨论的重点。
不都是整理和抽丝剥茧吗？
我在从事信息工作的生涯中使用过数种不同的程序语言、数据库、组件模型以及
Framework。面对许多新的技术不断地出现，开发人员似乎陷入了永远学不完新东西的
梦魇。不过，如果开发人员仔细回味许多技术的本质，却会发现这些技术其实只是把
我们已经了解的东西再以更细致化的方式加以运用，关键在于开发人员是否注意到了
这些本质和趋势而已。
例如，目前在C++中流行得火热的Template、Policy-Based template，在Java、Object
Pascal和C#中当红的接口程序设计，以及各种组件模型和Web Service中的服务接口
等，如果我们仔细地咀嚼，会发现许多的东西正是发挥程序员原本就拥有的整理和抽
丝剥茧精神，再加以发挥的东西。这怎么说呢？让我们以数个例子来说明读者就容易
了解了。
首先让我们想想为什么会出现数据库这类的产品？很简单，因为由于数据愈来愈多，
数据种类也愈来愈繁杂，因此造成了我们需要一种软件产品能够整理这些数据让它们
更容易的被我们处理和使用，因此才有了数据库的想法和产品。
在每一个程序员学习撰写程序代码时，也会发现随着撰写的程序代码愈来愈多，许多
的程序代码不断重复出现和被使用，因此很自然的程序员开始使用例程(routine)/子
程序(subroutine)或是过程(procedure)、函数(function)等机制帮助我们进行程序
代码整理和抽丝剥茧的工作。
这些数据和程序代码整理的工作几乎是每一个程序员的求生本能，只是有的程序员只
做基本的整理工作，而更聪明的开发人员则对于整理的工作有不同的看法，进而促使
了许多延伸软件技术的出现，也开始对软件开发产生了重大的影响。例如，对于原本
杂乱的程序代码以数据和程序代码分离的看法而逐渐产生了面向对象的技术，以分离
例程/子程序和数据类型为看法的应用则产生了类似C/C++中的template技术，而以函
数面对服务的看法，认为开发人员应该面向服务的开发模式则造成了接口程序设计
(Interface Programming)的应用热潮。虽然现在这些从程序代码延伸出的技术都独领
风骚，在软件开发界中产生了重大的影响和开发模式的改变，但是，如果我们追根究
底来观察，这些技术不都是从对程序代码和数据的分析、整理和抽丝剥茧之后，以更
精致的方式来处理和开发软件吗？
因此，本着相同的想法和精神，聪明的开发人员开始脱离单一程序语言的架构而进入
了开发出可重复使用的软件组件模型，让不同的程序语言都能够在统一的组件模型中
达成团队开发的功效。这个更聪明的整理和抽丝剥茧的想法造就了CORBA、COM/COM+
和EJB等组件模型的驱动力。
除了脱离程序语言之外思考的开发人员外，另外有一些开发人员则再次回头检视本身
和他人的程序代码，并且努力搜寻优良和成功程序代码的基因，因此发现了这些优良
和成功的程序代码似乎都有着类似的模式和架构，再经过进一步的分析之后终于产生
了Design Pattern，这成为目前最重要的软件开发模式和技巧之一。在这之后，这些
聪明的开发人员了解到如果能够成功运用Design Pattern，并且把程序设计转变成以
服务为目标的方式，将更能够简化、标准化和结合Design Pattern的运用，并且隐藏
复杂的实现技巧，这就进而产生了Service Interface Programming的观念和技巧。
由此可见，只要开发人员能够发挥细心整理和抽丝剥茧的能力，那么即使无法创造出
伟大的新软件工程或是软件技术，但是仍然能够帮助我们增加生产力和软件品质。因
此，对于开发人员来说重要的不是无止境地学习层出不穷的各种新技术，而是到底有
没有了解这些技术之后代表的观念、思想，以及学习最重要的对于软件开发整理和抽
丝剥茧的能力。在我的工作生涯中，一直认为技术终究是会被大多数的人学会的，但
是在辛辛苦苦地努力这么多年后，到底我们的思想、眼光和抽丝剥茧的能力是否有所
精进呢？如果没有，那么我们永远就像被蒙着眼睛，只能尾随着他人告诉的技术前进，
永远找不到自己的方向。
现在，再让我们以一个C++的例子来证明只要开发人员能够看透程序语言和技术背后
代表的真实意义，那么即使是在已经被众人熟知的技术中，仍然能够创造出新的技术
和含义。在Andrei Alexandrescu先生所著的"Modem C++Design"一书中，我们再次看
到了聪明的开发人员对于程序语言的了解和对于程序代码撰写整理以及抽丝剥茧的惊
人能力。Andrei的想法不算复杂，但是却巧妙地运用了对于C++ template深刻的了解
而创造出了自己的精彩之作。其实，全书呈现的思维之妙，让读者可以从一开始的小
范例就看出如何运用已经广为人知的技巧之后呈现出的不同风貌。
例如，Andrei想法是以Policy-Based想法为主，以各种不同的准则来提供服务函数，
那么通过C++ template的能力，让开发人员能够根据自己的需求来选择需要的Policy
和数据类型，结合于C++的template，可以捉供开发人员前所未有的自由度，并且开
启了以往函数库开发人员无法想象的挥洒空间。例如，下面的程序代码中提供了三个
不同的类别，这三个类别都可以建立指定类别T的对象实例(Object Instance)，但是，
这三个类别各自使用了不同的方式来建立T的对象实例。在这里提供了建立T类别的对
象实例的准则Create()方法，但是却允许开发人员自由地根据自己的需求选择要使用
那一种方式来建立对象实例。
由于上面的三个类别提供了相同的Policy(其实，从Service Programming的角度来看，
可以说它们都提供了相同的服务)，因此，开发人员可以再自行定义一个consumer类别，
并且结合C++的template功能，让这三个服务类别成为客制化数据类型，再通过template
的能力，自由地被开发人员选择使用。例如在下面的程序代码中，WidgetManager
类别通过template功能可以在编译时期动态决定使用那一个Policy类别作为父代类别，
而自动拥有建立T类别的对象实例的能力。
最后，我们可以再次使用template能力在编译时期由开发人员代入欲建立的T类别的
实体类别定义，通过template功能结合Policy服务和各种不同的数据类型。例如，下
面的程序代码即指定了使用OpNewCreator这个Policy服务类别，以传统的new操作数
来建立Widget类别的对象实例，并且定义成新的客制化类型MywidgetMgr：
typedef WidgetManager>MywidgetMgr;
在这个范例中，我们看到了Andrei真正了解了程序语言的机制，并且经过他的思考和
抽丝剥茧之后，开创出了以Policy为主的template class library。Andrei的这番思
考的确为C++语言开创了新的应用和视野，这正是发挥开发人员聪颖的整理和抽丝剥
茧能力的另外一个好典范。
不过，C++的template功能却只局限于C++程序语言本身，这是因为template是C++语
言本身的特性，只有C++编译器提供了强劲支持。所以，C++的template无法在程序语
言之外和其他的程序语言合作提供类似组件模型的能力，因为其他的程序语言并不了
解template，也不支持template，这也是为什么Microsoft会以COM来提供不同程序语
言之间的整合，EJB则更单纯地只限定使用Java的原因。
其实在上面讨论的C++ template中，仍然可以通过混合编译时期和执行时期的功能来
提供C++在组件模型和其他程序语言或是技术结合的能力，同时又能够使用C++本身强
劲的语言机制。例如，我们可以在外部使用XML作为组态文件，以指定我们想要使用
的Creator以及想要建立的对象。例如下面的XML内容即指明了和前面相同的Creator：
OpNewCreator，以及要建立的对象：Widget：
而C++可输出一个纯粹的服务接口，类似COM的接口以便和其他组件模型或是程序语言
整合：
最后，在CPPCreator的实体衍生类别中可以通过分析XML组态文件的内容来决定建立
何种的Manager：
上述的机制可以让C/C++语言提升至组件模型和其他的技术整合的层面，又能够仍然
使用本身强大的template、Policy-Based template或是template函数库。当然，这
里我并不是以讨论C/C++程序语言的技巧为主，不过，上面的程序代码仍然可以进一
步使用dynamic dispatch来改善，成为品质更好的程序代码。
其实，这些想法和实现机制仍然是在使用整理和抽丝剥茧程序代码的方式来解决问题，
只是以更细致的想法重新给予程序语言或是工具新的意义并且运用在日常的开发生活
之中，有时候只要脑筋稍为转个弯就能够看到新的应用。
现在，除了在程序语言层面运用各种整理和抽丝剥茧的技术来增进我们开发的速度和
品质之外，许多人已经开始运用相同的想法在建立企业应用系统了。例如，现在许多
人已经了解Design Pattern除了在程序语言方面有实质的帮助之外，在企业应用系统
的设计方面更有极大的应用价值。而且许多人已经开始整合这方面的Design Pattern，
例如Martin Fowler最新著的"Patterns Of Enterprise Application Architecture
"一书中便分析和整理了他观察和使用Design Pattern在设计和发展企业应用系统的
心得。在这本书中，Martin Fowler也清楚地说明了他只是发挥了整理和抽丝剥茧的
原则提供给开发企业应用系统的开发人员参考，许多的Design Pattern并不是他发明
的。可见，现在许多的开发人员只是更精炼地观察和整理多年的开发经验，以萃取出
更佳的Coding和开发的技巧以及开发惯例。
而Design Pattern运用在企业应用系统中的功用是能够帮助开发人员更了解整个系统
的架构，并且更容易掌握如何分门别类企业应用系统不同层次之间如何的切割和分发，
能够营造出体质更为健全的复杂企业应用系统。
目前，这股重新整理和抽丝剥茧的风气也已经蔓延到各种信息开发领域，从程序语言、
组件模型一直到大型应用系统的设计和开发。我认为，下一步将继续进入整个开发流
程的领域之中。当软件厂商提供了完整的开发流程工具之后，就开始会有人研究如何
在开发流程中再度应用Design Pattern等技术。
因此在未来，开发人员必须了解Patterns，并且在开发的过程中时时注意软件开发的
趋势和使用惯例，不断吸收更多的技巧，以更精致的思想和方式来开发软件，如此一
来才能够脱颖而出，在软件开发的生涯中出人头地。
Web Service Works
SOAP和Web Service从去年开始快速兴起，并开始占据信息整合应用的市场。虽然许
多人提出对于SOAP和Web Service执行效率和安全性的质疑，但是，SOAP和Web Service
的穿透力、整合力却无庸置疑是极具吸引力的。因此，目前Web Service的各种规格
除了蓬勃发展之外，Web Service的应用也的确开始出现在我们的四周。不过，Web
Service到底应用在哪些方面呢？SOAP和Web Service目前在信息业界使用的情形如何？
相信这些都是许多人关心的问题，也是许多人想要知道的答案。
最近，我被邀请到一家信息机构交流信息技术的心得。主持人告诉我他们现在拥有一
个分布区域极为广大的信息系统。每一个区域使用的硬件、操作系统、数据库和开发
工具都不同。而且，目前这些系统之间并没有专线连接在一起。现在他们想要整合这
些系统，而且希望能够在机构中心向不同的区域查询货物数据并且在机构中心整合查
询到的信息。
这位主持人询问我有没有什么方法可以完成这个信息架构。在详细地讨论之后，我了
解到机构中心从各个区域查询的信息都是属于小量数据的查询。由于在每一个不同的
区域都有自己的数据库，因此可以通过每一个区域的数据库服务器从大量的数据中撷
取查询数据，再把查询到的结果传回机构中心进行简单的整合工作。
对于这个信息架构，我想最简单的方法就是在每一个区域的服务器上实现一个CORBA
服务器，再由CORBA服务器对外提供查询接口。由于CORBA拥有跨平台、数据库和开发
语言中立的特点，因此非常适合使用来作为原有专属系统提供对外的标准服务接口。
有了CORBA服务器作为服务接口之后，我们可以继续把CORBA服务转换为标准的Web
Service，再由机构中心使用SOAP，即可轻易地使用标准机制穿透并且整合原本的异
质系统。
使用Web Service的原因是由于在这个应用中只会有少量的资料查询，因此Web Service
绝对可以胜任，而Web Service提供的穿透力和整合力是其他技术难以相比的。对于
安全的需求，可以使用HTTPS加上CORBA的安全服务即可提供一定的安全可靠性。
原本看起来困难的事情一下子就被Web Service和CORBA联手解决了。这正是一个非常
好的Web Service应用范例。
那么在2002年，Web Service在信息业界应用的情形到底是如何呢？到底有没有信息
系统在使用SOAP和Web Service技术呢？其实，我们从各种开发工具都支持Web Service
的应用来看，一定是有人已经在使用Web Service了，否则没有必要几乎所有的开发
工具都争先恐后地加入对于SOAP和Web Service的支持。
下图是2002年信息界对于使用Web Service的最后调查结果，从数字中我们可以看到，
没有使用Web Service的比率是43.2％，但是超过50％的调查显示Web Service已经
或多或少的被应用在信息系统之中了。而这些统计数据也代表了Web Service被实际
应用的证明。
另外一份对于Web Service应用的调查结果如下页所显示。我们可以看到在2003年中
Web Service将有更大的使用比率，可见Web Service的应用将会快速地提升。
如果我们把两份统计结果以趋势图同时呈现的话，会发现Web Service应用的成长比
率几乎不会输给一般的开发工具或是程序语言的成长比率。
在2003年Web Service除了将愈来愈普及之外，新的Web Service规格也将慢慢完善并
且开始被软件厂商实现。除此之外，也开始有信息厂商对Web Service的缺点加以改
善推出变形的解决方案。不过千变万变，不变的是在现在信息多元化的时代正显示了
我们的确需要Web Service代表的穿透力和整合力。
许多人当初说Web Service是不实际的技术，从目前的各种迹象和统计数字来看这些
人似乎是错了。Web Service的简单化不代表无用，其缓慢也不代表不可用。我们只
需要在适当的地方使用适当的技术，Web Service就是一个很好的例子。毕竟当初Don
Box在定义SOAP时最原始的想法本就是"简单(Simple)"，不是吗？
面向对象技术的平民化
"你们是用什么方法来开发系统的？"，"你们使用UML吗？你们在使用面向对象方式开
发应用系统时使用所有的UML图形吗？"，"你们遵循RUP来发展软件吗？"，这些问题
是我在和一些信息界的朋友聊天时经常询问的问题，因为我也非常想了解UML/RUP和
Modeling在业界使用的情形。
UML和Modeling的需求在三位OO大师多年的提倡并且成立Rational公司开始大卖Rose
后，照理说UML和Modeling在信息业界应该是被广泛地使用，不是吗？但是情形似乎
并不是如此。
在我知道的许多案例中，许多公司或是信息机构在购买了Rose之后，要么被供奉起来
成为一种先进/时髦的象征，不然就是被使用来作为画图的工具。即使是真地使用UML
和Modeling的公司也大都只是使用Rose画画Use Case、Class Diagram和Object
Diagram，再继续深入得几乎没有。为什么会如此呢？UML已经被证明是非常好的理论、
开发方式和沟通语言，Rose也推出了这么多年，为什么UML的普及率仍然非常低呢？为
什么许多购买了Rose的公司和机构也没有完全使用Rose的功能呢？这其中一定有一些
问题存在。但是，这是什么问题呢？
就我个人的经验来说，在许多的项目开发之中大概都只有使用到Use Case、Class
Diagram和Object Diagram，最多画画Sequence Diagram，接着就是结合组件模型、
开发工具和数据库开始进入开发的阶段，比较注重CBD的开发模型，鲜少使用到其他
的UML图形，因此可以说是偏向结合UML和Extreme Programming，以项目时程为最重
要的依归，并不强调完全遵照UML和RUP。因此，我也非常想要和其他的朋友交流，了
解其他人使用UML/RUP的情形，或者其他人是如何使用OO技术开发项目的。
我个人也是从事信息工作的一员。虽然没有什么显著的贡献，但是我对于UML和Rose
始终有一份怀疑。当然，这份怀疑并不是指UML和Rose没有用，相反，UML的确对于软
件工程有着卓越的贡献。不过我认为UML和Rose之中的许多东西过于繁琐，要实际应
用在项目发展之上，除非项目没有时程和资源的限制，就像Rumbaugh自己在GE时从事
的实验计划，拥有许多的资源和宽阔的时程，否则，怎么可能有时间和资源把所有的
UML图形都画出来呢？至少就我个人的项目生涯来说是从来都不可能的，因为在我个
人的信念中项目开发最重要的准则是"On-Time Delivery Of A Working And Decent
System"，不是UML，不是RUP，更不是任何其他时髦软件技术。
另外，我一直认为Rose实在算不上好的软件，每一次我使用Rose就有种回到Windows
3.1时代的感觉。此外，Rose在绘制UML图形上始终有一些小问题，从版本1开始到现
在都没有改善。因此我也曾经开玩笑地说，"Rose是全世界一流的OO分析师配合三流
的程序员开发出采的产品"。因此我个人对于UML/RUP一直有着一份怀疑，只是人微言
轻，不敢轻易表示对于UML/RUP的质疑。
不过，在Extreme Programming对于UML/RUP开发模式提出类似的质疑和逐渐分庭抗礼
之后，我也在Internet/Intranet上看到愈来愈多对于UML/RUP的批评以及许多人公开
讨论使用UML/RUP失败的原因和检讨。此后，我总算如释重负，因为这些都证明了不
单是我个人有疑问，许多人都有相同或是类似的问题。我认为这些批评和质疑对于
UML/RUP是一件好事，因为这可以让软件界再次审视UML/RUP不足之处，找出问题的所
在并且加以改善，才能够让UML/RUP持续地对软件界和软件工程做出贡献。正由于
Extreme Programming对于UML/RUP的挑战，反而可以让我们更清楚地了解什么方法才
是最适合的。我个人认为，对于小/中的系统或是项目而言，简易的UML和Extreme
Programming是比较适当的，而对于大型的企业应用系统(Enterprise Application
System)而言，UML和RUP被证明是有效的。
一直到2003年初听了TogetherSoft的首席科学家(Chief Scientist)Todd Olsen的演
讲后，才正式确定了我的想法没有错。连Todd Olsen都认为UML/RUP太过于学术化，
对于学术的研究没有问题，但是在实际的应用中则稍显繁杂。开发人员应该在开发工
具的辅助下进行适当的修整以找出最"适当"的方式来进行项目或是系统、工具的开发。
连Todd Olsen这种经验丰富、软件开发实力又惊人的大师级人物都这么说，我也就放
下心来了。看来属于实战型的开发人员，依照武侠书的讲法，应该掌握的是"最具杀
人威力的剑法，而不是华丽的招式"。当时我在聆听了Todd Olsen大胆的说法之后不
禁大呼过瘾，隐藏在心中多年的质疑终于一挥而去。
虽然过于拘泥于UML/RUP的开发模型不算是好的方式(或许这对于学术研究是正确的)，
但是也没有人完全否认UML/RUP对于软件开发的贡献。事实上UML是很重要的，因为它
可以让开发人员使用同一种语言沟通，也可以很有效地使用Use Case让企业人员和开
发人员沟通。但是为什么在Rational推广Rose这么多年来普及的成效仍然有限呢？我
个人认为有如下的原因：
■ 价格昂贵，难以普及
■ 只锁定金字塔顶端的开发人员
■ 过于强调完整的UML/RUP开发模式
■ 没有和开发工具整合在一起，以打入一般的开发人员群体
由于Rose采取高价的策略，因此虽然为Rational赚进了大把的钞票，但是也让UML/RUP
和Rose的普及率难以大幅地扩展。想想10年前的Client/Server技术也是在
PowerBuilder、Gupta等采取高价措施而难以快速普及，一直要到VB和Delphi等大众化
开发工具提供了Client/Server功能之后，才让Client/Server快速为大多数的软件人
员视Client/Server技术为理所当然的基本技巧。在PowerBuilder/Gupta错失了占据
Client/Server的庞大市场之后，再也无法成为Client/Server的领导厂商。
同样地，如果Rational一直为Rose采取高价，只锁定高阶开发人员市场的策略，那么
Rose很可能会在其他的竞争对手推出更好的UML产品之后快速流失市场，事实上这正
是Rational在2002年面临的困境，因为Rose不但遭受许多UML小厂商的竞争，更被其
最大的竞争对手TogetherSoft打得难以招架，要不是Rational还有3位OO大师的名号
在力撑，Rose早就被TogetherJ或是TogetherSoft的Control Center打得落花流水了。
从最近4年TogetherSoft可怕的成长速度可以看出来，Rational早已被TogetherSoft
逼得寝食难安了。
在Borland并购了TogetherSoft之后，Rational将面对更为艰难的状况。一旦Borland
成功地在其的开发工具中整合TogetherSoft的产品，那么将可能会像当初的Client/
Server技术一样，可通过提供更平易近人的UML工具而快速让UML为大多数的开发人员
接受而使用。再加上如果Borland以合理的价格提供UML和开发工具，那么将可以让UML
打入金字塔中/低阶的开发市场，快速鲸吞Rose的市场。到时Rose在UML/Modeling产
品本身不如TogetherSoft之下，再加上Borland开发工具的强力支援，Rational的大
势不妙。因此这是为什么当Borland宣布并购TogetherSoft之后受伤最深的公司就是
Rational，而Rational也立刻声明中断和Borland的合作的原因。最后在Rational眼
看后势欠佳，再加上IBM提出动人的并购条件之后便立刻接受了IBM的提议。
根据2002年的信息调查显示，大多数的开发人员已经视Modeling工具为相当重要的工
具。
而且目前使用Modeling工具的开发人员也相对地满意于Modeling工具提供的功能。因
此，如果Modeling工具能够再和开发工具紧密地结合，那么Modeling未来的发展将更
为快速。
目前在所有和开发相关的工具中，Modeling和设计工具已经占据了相当重要的地位。
根据2002年调查的结果显示，设计和Modeling工具已经分别占据了所有开发相关工具
的第2和第8名，而且还呈现持续上升的状态。
由此可见，开发人员已经愈来愈重视设计和Modeling工具。在Borland并购TogetherSoft
之后，我认为Borland会以较为合理的价格提供整合Modeling和开发工具的软件包，
快速把UML技术打入一般开发人员的市场，并且将会正式触发使用UML和Modeling功能
成为开发人员的核心基本技巧，就像数年前Client/Server技术对于开发人员一样。
因此，我们可以发现下面图形呈现的还是去年以前开发人员拥有的技术状况。开发人
员的核心技术只需要拥有程序语言、数据结构和Algorithm即可。
但是从2003年开始，一旦Borland或是IBM推出整合Modeling工具和开发工具的新一代
软件之后，面向对象、Modeling和Design Pattern等技术将被压缩到开发人员的核心
基本技术之中。这代表未来的开发人员必须熟知面向对象、Modeling和Design Pattern
等技术，再也无法逃避学习这些重要的软件技巧。
因此，我们可以说信息公司的合并不但影响这些软件公司之间的竞争，也会对开发人
员产生影响。在面向对象、Modeling和Design Pattern等技术成为开发人员的核心技
能之后，当然可以增加软件开发的速度和可靠度，这对于整个软件产业而言是正面的
结果。对于像Borland或是IBM等公司，由于让UML和Modeling技巧和产品成为一般开
发人员必须拥有的技巧和使用的产品之后，也可以通过更大量的市场来弥补产品价格
下滑的损失。一旦UML/Modeling技术大众化和产品平价化之后，软件公司反而可以拥
有更多的收入。
面向对象和Modeling平价化之后便会开始进入开发人员的生活之中，也会开始影响我
们开发软件的方式和流程。这两者会像从前的其他技术，例如Client/Server、数据
存取和Web等，慢慢成为几乎每一个开发人员必备的技术。然而不同的是，面向对象
和Modeling对于我们的思考模式却有更大的影响和改变，因此造成的影响也将远比从
前的技术更为深远。因为除了面向对象和Modeling的思想和开发流程之外，伴随着它
们而来的将是更多的软件工程和软件技术。
不过对于开发人员来说这实在是一条辛苦的不归路，学习的道路不但没有尽头，沿途
还充满了艰辛。软件开发工作真是个辛苦的行业，不是吗？不过反过来想，软件开发
生涯也将是充实、满载而归的路途，不是吗？
准备迎接.NET时代的来临
2002年是.NET初临的时代。虽然.NET的初鸣并没有给人太亮眼的表现，但是同七八年
前Java初次展现于舞台上时相比较，.NET的表现并不逊色，甚至比当年的Java表现得
更好。
在2003年，Microsoft更准备推出新版的.NET、.NET Server以及新的.NET开发工具，
而且大部份的调查也都指出.NET将开始在2003年起飞。面对Microsoft一连串强势的
动作，我们其实可以预见.NET也即将更为活跃和更有影响力。其实我也很想了解.NET
在2002年到底表现得如何？除了市场上许多的.NET书籍、文章之外，我也在业界和许
多朋友讨论以及询问2002年.NET在信息界使用的状况。我得到的结果都是在评估.NET
之中，实际使用.NET开发的产品还不多，但是ASP.NET被使用的情形则是令人惊讶的
快速。我已经发现许多的网站开始使用ASP.NET来开发，可见.NET和当初的Java一样，
是从Internet/Intranet开始入侵日常的信息应用。
最近一份.NET的调查报告终于把.NET在2002年使用的粗略状况呈现出来，显示出.NET
的确已经有了初步的成果，虽然也许没有达到Microsoft的期望，但是也有不错的成
绩。下图是ASP.NET在这份调查中的结果，读者可以看到，已经使用和准备使用ASP.
NET的比率已经超过50％，而且已经有18.9％的软件人员在使用ASP.NET开发Web应用
系统，这对于推出才1年的技术来说是非常惊人的，也可以说ASP.NET是非常成功的。
而下一份图形则显示出开发人员对于Microsoft .NET Server的使用情形。从数字结
果可以看到.NET Server的接受度也非常高，也有超过50％的接受度。可见在Microsoft
推出下一代的.NET操作系统之后市场反应也会非常的正面。
从上面的两个统计结果来看，.NET已经比我们想象的更快地进入实际的应用领域中。
在2003年看来准备在Microsoft Windows平台讨生活的开发人员的确是开始需要学习
.NET了，因为很可能从2004年开始我们便将看到Windows平台又将进入世代交替的现
象。
Borland的未来
Borland正站在十字路口上，面对未来的方向。数年前Borland错失了开发消费型软件
的契机，以致无法持续成长为更为强大的软件公司。看着Borland从2000年开始一连
串的发展以及在2002年完成的并购动作，我们可以看到Borland已经选择了另外一条
道路，那就是全力往企业市场前进。
企业市场一向是获利丰富的市场区块，这也是为什么Microsoft在称霸了客户端市场
之后急于切入的市场。不过企业市场也是更为危险的市场，因为在这个市场中的竞争
对手不但更大、更强壮，而且竞争的规模也远超过一般的软件市场。这也是为什么在
这个市场区块中的竞争公司几乎都是数一数二的公司，例如IBM、SUN、HP和Microsoft
等。Borland如何同这些资源丰富的厂商竞争，对于Borland的管理阶层将是非常严酷
的考验。
不过，这似乎是不得不走的路，因为Borland传统的开发工具市场虽然在持续成长，
但是传统开发工具的价格却不断下滑。例如当年Borland C/C++3.1的价格是一套799
美金，现在的C++Builder Professional的功能比当年的Borland C/C++3.1多了数倍
的功能，但是价格现在却只有399美金。这是许多信息产品相同的命运。Borland必须
想办法扩充其他的市场，否则，只能像许多的开发工具厂商一样等着成为历史。既然
数年前Borland错失了像Symantec成功地打入消费型市场的机会，因此，进入企业市
场似乎是Borland无可避免的道路。
问题是Borland如何在企业市场以小搏大、对抗世界一级的信息大厂呢？原本这样的
情势实在不怎么看好，没有想到在2000到2002年，世界历经了全球的不景气，许多信
息厂、甚至包括许多一级的信息大厂例如HP、Rational、IONA等都面临了前所未有的
严酷考验，不是元气大伤，就是被并购消失于历史之中。反而Borland通过公司有史
以来最聪明的并购，不但成功地取得了关键技术和产品，更重要的是，Borland在顿
时之间取得了一个绝佳的地位和制高点，拥有其他厂商所没有的完整产品线。这让
Borland进可攻，有机会成为一流的软件大厂，重回世界一级的软件信息公司。也可让
Borland退可守，成为小而美的独立软件公司，继续下一个10年的经营，甚至能够以
最好的价值和其他的软件公司合并成为更大的软件信息公司。这也是为什么最近一直
有传言称Microsoft、BEA、IBM和Oracle都在重新审视Borland的价值，并且重新评估
Borland这位突然之间实力大增的竞争对手。
当然世事有得便有失。Borland在极短的时间之内取得许多的公司、技术、产品和企
业文化，如何整合这些对于Borland来说也是一个挑战。在下一章中，我也会提出一
些Borland面临的问题的个人看法。不过从Borland的走向来看，不管如何，势必需要
面对和克服这些挑战和问题才能够持续在软件产业中竞争下去。我个人认为，Borland
必须赶快在下面的事项中取得领先的地位才能够拥有高度的竞争力，并且顺利地面对
其他的竞争对手。
提供全方位的开发工具
既然单靠开发工具已经无法在现在的软件竞争中取得一定的优势，那么Borland必须
发挥技术优势，并且整合所有的产品以便在Java和.NET平台提供全方位的开发工具。
目前，Borland已经形成了完整的软件应用供应链。我预见Borland除了会在不久的将
来提供整合性的开发工具产品之外，应该会持续在测试工具领域取得关键技术和产品，
以便形成更强劲的产品线。Borland最近推出的OptimizeIt ServerTrace便是向这个
方向努力的一个很好的例子。
为什么？因为在日后开发工具日趋整合之后，整体的测试工具便显得重要了，因为在
整合的开发工具中牵涉到的技术或是组件模型将会非常复杂，而传统的测试工具已经
无法处理这些复杂的应用。这是为什么目前在测试工具市场能够同时存在多种用途的
测试产品，而且由于测试工具市场快速地成长，因此，目前这个市场的利润相对的比
开发工具好得多，例如出品LoadRunner的Mercury公司便非常成功而且成长得非常迅
速。因此当大型软件公司开始注意到这类产品的重要性以及相对的价值之后，势必想
要进入这个市场。而Borland在拥有了分析/设计、Modeling、开发工具、基础测试工
具和组件模型以及分发平台之后，补强在测试领域的工具便很自然地成为下一步了。
一旦在测试市场拥有强劲的技术和产品，Borland的实力将更为强大，同时可通过全
面、整合性的技术和产品而保持合理的利润，以提供持续成长的推动力。
提升开发工具的价值
当开发工具的价格不断下滑之后，Borland面对核心产品市场的趋势应该如何处理呢？
这并不难解决。既然开发工具已经逐渐成为大众化的产品，高价的入门开发工具时代
已经不可能再回来，那么Borland可利用产品区隔来增加这类产品线的收入，而这正
是Borland在最近几年采用的策略。所谓开发工具产品区隔，是指在原有的产品线中
提供更为高阶的产品，以吸引金字塔顶端的软件人员。例如Delphi原本提供三个不同
的产品线：Personal、Professional和Enterprise。到了Delphi 6之后开始加入
Architect和Studio的版本，以便增加产品的附加价值，吸引资深的Delphi开发人员使
用这些高阶产品，JBuilder终究也一样会采用这种策略。否则，世界上将仅仅Microsoft
能够以不惜血本地大量抛售开发工具以便维护其Windows平台的利润，而任何软件公
司都需要一定的利润来持续经营的。
进入Run-Time市场
请读者现在想想，在软件产业中除了像Microsoft是靠大量的消费型软件大赚其钱之
外，其他最赚钱的软件公司是靠什么种类的软件在赚钱呢？答案便是靠所谓的Run-Time
软件赚钱。什么是Run-Time软件呢？让我指出几个例子读者马上就了解了。例如Oracle
最赚钱的产品Oracle数据库就是属于Run-Time软件，IBM和BEA的EJB服务器也是属于
Run-Time软件。Run-Time软件拥有大量使用、分发授权的特性，因此拥有相当良好的
获利水准，甚至能够和消费型软件并驾齐驱，一种以大量取胜，一种以价值取胜。
Run-Time软件一直是Borland想要拥有和进入的市场。从当初并购Visigenic和Entera
开始，Borland就有这种想法。只是当初Borland的产品尚不够齐全，管理阶层也没有
经验，因此一直不知如何进入这种市场。现在Borland产品线已经相当齐全，管理阶
层也有相当大的雄心，因此，这是为什么Borland一直坚持持续开发CORBA和EJB服务
器的原因。如果Borland能够在Run-Time软件市场成功，又能够通过InterBase数据库
进入嵌入式数据库市场，再通过整合开发工具大军横扫市场，那么，我可预见Borland
将可快速重返全世界前10大的软件公司，恢复昔日的光彩和雄风。
结论
2003年对于Borland是重要的一年，因为Borland在整合了许多的公司之后如何在2003
年推出新一代的产品，对于Borland的管理阶层以及R&D都是一项考验。此外，随着.
NET的脚步不断逼近，Borland也必须尽快推出.NET之下的产品。许多人对于Borland
如何在.NET下继续在开发工具市场竞争充满了期望、疑问和困惑。不过，随着Borland
取得了Modeling、分析、测试和分发技术/产品之后，Borland的确可以在.NET下推出
Microsoft无法提供的开发工具和解决方案。我个人也非常期待Borland能够尽早推出
.NET下完整的产品线。如此一来，Borland不单是以开发工具和Visual Studio.NET或
是其他.NET开发工具厂商竞争，还将提供更为全面的低、中、高产品线来竞争。这正
可突显Borland的不同。而且Borland将可再把竞争门槛往上提升，象征新一代Borland
的竞争力。Borland从80年代率先推出In-Memory开发工具，90年代推出可视化集成开
发环境开发工具，到了2000年之后，如果又能在.NET下率先推出新世代的整合性开发
工具，那么即代表Borland又将再次改写开发工具的意义，持续下一个10年的竞争领
先地位。Borland是否能像凤凰一样浴火重生、并且再次展翅飞翔呢？
其实，我认为2003年对于BEA和IBM来说也将是分出胜负的一年。如果BEA无法在2003
年增加WebLogic的竞争力，那么IBM的WebSphere将在开发工具和Modeling工具的助阵
下逐渐向WebLogic攻城略地，蚕食WebLogic的市场占有率。随着HP淡出EJB服务器市
场，SUN的iPlanet无法在市场上取得优势，看来IBM在Java阵营的影响力将会愈来愈
大。这对于SUN是一项警讯，因为现在SUN除了还控制Java语言、JDK和EJB的规范之外，
在Java开发工具、EJB服务器市场节节败退。现在，甚至在Web Service规范、Web开
发规范等方面也都沦陷于IBM/Microsoft和Apache，SUN在Java各方面的势力真是日渐
式微。
而目前看来处于真空的.NET市场也即将出现变化。一旦.NET势力兴起，必将冲击Java
的市场。那么对于许多Java厂商和EJB厂商会发生什么影响呢？.NET对于企业信息应
用会产生多大的影响力？.NET何时将对Java产生穿透力？这些影响和变化也都将从2003
年开始发酵。
