星期日 2004年10月17日
星期日 2004年10月17日 <IT Doesn't Matter> by Nicholas G. Carr May 2003, Harvard Business Review
http://www.nicholasgcarr.com/articles/matter.html
嗯，前几天打出来，刚才看完。觉得说得很不错。
从商业的角度来讲了下，IT的地位同过去的铁路,电力,蒸气机,电报,电话，这些东东 对工商业的冲击和作用程度，并没有本质的差别。虽然有号称是第N次工业革命 甚至是生活革命，但是现状是IT的逐步大众化和普及本身造成了它逐步丧失作为 专有技术的特点，于是先锋型的公司在初期能获得高额的利润，通过推广后期为 大众逐步接受之后就面临着利润额下滑的危险。
在此基础上的方法要么是鼓吹某些并不需要的功能，例如MS的OFFICE 2003和INTEL 的主频决定论，要么是转行做服务或者叫做效用(utilities)机构，所谓网格，web services，on demand,动成长,网络计算，SOAP都是这个意思。
最后作者给公司的IT主管CIO的建议比较有意思:不要过分担心没有采用新技术而跟 不上时代，相反得要比较注意不要过渡投资IT。Dell和Wall-Mart就是两个很好的 例子，在IT技术被充分试用和标准化之后再介入，利用本身强大的运营优势，以更低的成本获得更高的利润。(想起HP的卡莉怒斥Dell就会搅乱别人的市场，嘿嘿 ）这种占先机而获得高回报的机会在现在这样IT 日用品化的时代是越来越凤毛麟角了.
企业的核心竞争力不在于用没有最新的IT产品，而在于本身的不可复制的那些东西。 (比如运营水平，品牌，服务，等，个人观点，IT已经是想电力一样的必要的基础，但不是扭转局面的决定性因素了)
CIO们应该遵循的三个最重要的原则是:
1. 花更少得钱，办更多的事.
2. 跟随主流，但不要领导潮流.
3. 关注易受攻击的程度(稳定性，可扩展性，可用性，安全性),但不是可能的机会.
关于OpenStack vs M$ XP Stack的讨论(8)
下面说说这个系列的重头戏，Open Stack， 唉，好不容易到主题了。
Gary defined Open Stack主要是指支持并应用XML 及其附属标准的若干Open Source的软件，主要包括： OpenOffice.org: Writer, Calc, Impress, Math, Web, 特别的是针对MS InfoPath的Form Mapping策略，OOo有一个"OpenPath"项目，就 是XSLT Filter。用户自己编写一套XSLT转换程序，就可以把customer-defined XSD转换为OOo XML 文件格式。因为能够自己定义XSD的人，应该有能力写一个 XSLT吧，呵呵。当然这部分还欠缺一个GUI操作生成XSLT的功能，Alvota的 MapForce就有这样的功能。
数据源访问 OOo是采用了SDBC的结构，也同样可以访问JDBC/ODBC/ADO/和其他很多 种data source，并且StarOffice 附带了一个桌面数据库(Adabas D)，其实这个可 以随意去哪里下载一个MySQL/PostgreSQL来用，因为OOo已经内置了MySQL的 native驱动。
另外OOo的 incubator 刚开始一个新项目: Glow是专做 IM，email,calender, web folders & white board(WebDAV), P2P这些东西的，另外还有一个Chandler，是 用Python写的，也是做groupware client的.
Server那里，可以用Apache, Zope( Python写的content management及其他), OpenGroupware（刚opensource的，可以支持web,Mozilla,outlook,evolution, WebDAV,KOrganizer, Apple iCalc等。
另外还有Mozilla/Mailer/Composer.
感觉上这个OpenStack其实是可用的，而且成本比较低，完全跨平台，因为已经各 自在native的hardware-OS上实现并封装了base-library了。(OpenGroupware 是用 Object-C写的，基于Linux-like系统，这个不大方便，不过Server用Linux也很正 常了).
这个同GNOME or KDE的跨平台不同，那个本身就是一个Window manager，要装起来 还是比较麻烦的，而且很少有customer愿意在windows上来个GNOME/KDE风格的窗口 .
有了这么多东西，Open Stack基本上是可以满足Collaborative Computing 的需求 的，我以为。而且将来的extendible很好，open source,总之优势多多。现在似乎 还没听说有什么基于Open Stack做Solution的公司，我正在想如果Start-up这样一 个公司，恩，做Solution & Services，不知道情况会如何，呵呵。俺想去做CTO了 。:) .
大家讨论，拍砖，吐口水，鸡蛋，西红柿齐发吧。 我要好好休息一下了。 over.
关于OpenStack vs M$ XP Stack的讨论(7)
MS XP Stack
这个大家都很熟悉， MS Office XP/2003: Word, Excel, PowerPint, InfoPath, Access, Outlook, FrontPage, Visio, OneNote, Project. 数据源连接有ODBC,ADO， 随Windows还捆绑了IE, Outlook Express, Win-XP里面还有MSN Messenger/windows Messenger, 服务器有IIS, Exchange, SharePoint, BizTalk,等。
可以说MS的协同软件是最全的，功能最多的。
恩，说说缺点，当然是封闭啦，还有误导性的"Embrace, Extend, Extinguish" 策略，详细的看我上面的文章。
总之，MS 是众矢之的的说，呵呵。
关于OpenStack vs M$ XP Stack的讨论(6)
Adobe.
Adobe的情况和前面几个都不太一样，因为实际上它宣称的不是做Collaborative Computing的，大家都知道Adobe是做图像和视频处理，以及电子出版物的。但是 从大约是Acrobat 5开始，在Adobe的全线产品里，逐渐加入了对XML的支持，这是 表明Adobe做工作流处理的一个大动作。
因为起初在Acrobat里是可以做action的，用的大多是Jscript或者是PDF自己的 API，后来为了迎合企业需求，在Multimedia Page设置方面，InDesign 中利用 XML可以设计一些Layout，通过Adobe GoLive用不同的形式发布出去；在Form 处理 方面，PageMaker,FrameMaker,Acrobat等都提供了user-defined XML schema 与 control控件mapping的功能，以及PDF内部的商业逻辑。并且文档元数据用XML描述 ( Extendible metadata Protocol, XMP), 支持SVG,可以做数字签名等等。并且将 来的PDF还可以作为base64的块数据包在XML文档中，(Extendible data Package, XDP)。这样在Acrobat Reader中填了表格，可以直接通过HTTP POST/SOAP,将XML形 式的数据传到后端GoLive上，由它来调用XSL-T或者 XSL-FO将文档publish到不同 的媒介上去，并由于PDF本身meta是XML化的，就很方便FrameMaker/pageMaker 在 create PDF的时候加入必要内容，将来做内容管理。
总体来看，Adobe是在私有的PDF格式上嵌了user-defined XML schema的功能， 这些是同MS Office 做的类似的。但是Adobe有MS Office不具备的优点:
1. PDF是电子出版的事实标准，(Arobat reader is almost everywhere) 而且 这个领域没有强大的竞争对手，MS刚想加入。
2. PDF格式公开，只是如果要做授权的reader，需要交一定的费用(估计不低)， 呵呵。 ( X-Window上有个GPL 的reader, xpdf。是没有授权的，做地相当不错， gpdf就是基于它做的。但是如果要拿xpdf地source来做商业行为，就要买license 了，呵呵。)
3. 还有Adobe的商业形象没有MS那么糟糕，虽然在某些地区也比较糟糕，比如在 中国的反盗版措施，举报，突击检查等等。还是Maker太贵了，唉。
Adobe的缺点是，它只有电子出版和文档流管理的功能，确切地说是Forms管理这 块功能，其他的没有。这也许会导致它只能在协作计算领域偏安一隅，如果不同其 他产品做联合的话。不过也许正像广告里说的，"Their markets are specified, people trust specialists." (知道是谁的广告么？;) 呵呵。
关于OpenStack vs M$ XP Stack的讨论(5)
Oracle.
我其实还是挺佩服埃利森的，一大把年纪了，好像有60来岁了，还那么能折腾，有权利 欲望，征服，挑战，aggressive。也许是个挺不错的优点。
Oracle在去年年中发表要做协同软件，目标指的是Ms exchange server，说微软的东西 如何烂，如何不安全等等，还贵。 我看了下oracle collaborative suite的资料，大致是 感觉上把oracle db应用到了协同计算里。instant messgaer, file share, pda, email voicemail，估计它可能把能存到数据库里的东西都存进去了，它的suite提供了几种 方式访问数据，outlook(oracle没有再自己做个客户端，仍然沿用), web browser, mobile,pda,phone,fax等等。
第二个特点是把email, voicemail,和mobile, 固定电话，传真等给结合起来，据说还 依据的是个什么标准传输协议，关于voicemail的。举个例子，出差在酒店里，可以打 电话回去suite，用语音查project shared file里的新文件，如果发现新的，可以语音 指定发到某个fax上。然后用share desktop来协作修改文档。
可以说是一个充分利用传统通讯手段的协作软件，缺点是，没有充分利用XML，因为 Oracle没有好的client软件，也没有类似于share point这样的处理文档内容的server， 它的优势在于数据库的强大稳定，所以就充分利用了这一点。所以Oracle 协作suite里 电话回去suite，用语音查project shared file里的新文件，如果发现新的，可以语音 指定发到某个fax上。然后用share desktop来协作修改文档。
在处理文档时还只能简单的文档版本1-2-3 之类的多个拷贝，也智能用share 桌面这样 比较粗糙的办法来共同修改一个word文档， 缺乏办公套件客户端，是oracle collaborative suite的最大的软肋. 不过因为价格还比较便宜，另外也集成了一些传统通信功能，在某些企业里受欢迎。 用outlook，照样还得买MS Office压，还有病毒啥的，只是服务器安全点了。
关于OpenStack vs M$ XP Stack的讨论(4)
再说个老的吧，Corel WordPerfect.
老实说这个WordPerfect Office其实已经不应该算是collaborative computing的了，因为corel公司不提供任何的server方的东西，wordperfect差不多是legacy的东西。
WordPerfect Office包括三大块主要功能:WordPerfect字处理，Quattro Pro电子表格， Presentations幻灯片，再就是一个叫做XML Project designer的东西。这个我还 没太搞懂是干啥的，似乎是用来design 文档的 layout的，可以输出成css,等格式dtd, 但是感觉有点老，也不太好用。
wordperfect字处理里有个选项可以save as 成xml,我试了一下，输出的文件可以导入， 但是用ultraedit看到是binary的! 呵呵，后来看到Gary似乎是说 corel把xml还打了 个包，不知道为啥不想人别人知道。不过它也可以export to xml格式，但是这个就很 简单了，输出了一个raw xml,连namespace都没有，简单的outline，我试了个rtf打开 后export 成xml,掉了很多东西.
Gary对Corel WordPerfect有个评论，大意是说Bill gates为了遏制corel想要往XML 的Open Stack上发展的趋势，把他所持有的corel的share全数地卖给了一个很有可能会将wordPerfect部分剥离，出售，碾碎的投资公司，"恶意抛售股票",给Vector投资 公司，以将一个已经倒地的前竞争对手彻底提出场，我觉得可以把M$之前收购Corel的 股票看作是give it a hand, be ready to throw it away if necessary.
前阵在北美传出Gateway在少量低价电脑上捆绑wordperfect出售，不过我以为这基本 上是给M$ 甩脸色看，corel现在基本就是在老的用户基础上维持和decay,了.
关于OpenStack vs M$ XP Stack的讨论(3)
IBM
IBM的协同计算，基本上是基于Lotus Notes/Domino的，在办公软件部分，有几种选择： 用MS的 Office,用Lotus SmarSuite,用OpenOffice.org包装.
用MS OFFICE当然是最方便的，况且IBM做服务或者解决方案，本来也就不怕用别人的东西 但是多少总会有对自己的东西有打压。 如果用lotus smartsuite, 东西实在是太老点了，很久没有更新，现在还是millinum edition 9.8 (新千年版), 我看到它说的对XML的支持比较有意思，呵呵。 你想在smartsuite中用XML吗？好办，现在XSLT的转换程序满天飞，随便拿个external 的xslt processor，把xml转成comma-separated file也就是逗号分割的纯文本(csv)文件 然后就可以导进来了嘛，文字处理，表格，甚至Organizer结构图里的人员地址簿，都 可以用嘛，呵呵。老实的有点可爱。:)
我不清楚现在的Lotus Notes/Domino对XML的 支持有什么，因为没用过，只看过whitepaper,以前有一个老派的intelligent document 智能文档，实际上就是协同计算的preproitary版本，算是鼻祖了，因为lutus notes/domino 用的还是相当广泛的，比较稳定，而且颇可以和IBM的后端服务器配合，比如DB2 content management,Websphere, 占据了相当大的市场，但是XML化程度似乎不是很高。 然后就可以导进来了嘛，文字处理，表格，甚至Organizer结构图里的人员地址簿，都 可以用嘛，呵呵。老实的有点可爱。:)
而且它的软肋是桌面工具smartsuite比较差，很大程度上它是依赖与ms office的协作的， 这个与oracle类似，以后再说。 有消息说IBM北京部分有在做OpenOffie.org的包装，所以我怀疑他们提供的部分方案里也许 有OpenOffice.org的case，不过不清楚是在哪里做的，也许是CDL.
关于OpenStack vs M$ XP Stack的讨论(2)
关于协同计算的概念，Gary Edwards的观点和我的有点不大一致。他的主要着眼点是在 业务流程的重组(re engineering,不知道这样翻译是不是恰当)，以及如何提高企业的 运作效率。也许是跟他的背景有关系，Gary有20年左右的IT技术背景，做过很多银行和 地产的咨询的职位，擅长的就是分析业务流，优化，这些。恩，他的(mm,gf,lp?不确 定)是做房地产代理的，还是个华裔,好像有点八卦，不说了.
在Gary眼中，collaborative computing的重点是传输协议，也就是XML，而且计算的 各个部分都需要支持标准的而不是私有的公开协议，非preproitary的。那么实际需要 计算环境中的各部分软件都要最大程度的支持公开标准，XML等，实际情况是怎样的呢？
数据库这部分，似乎并没有包括在Gary的collaborative computnig的定义 中，也许是这部分实在是没有什么成熟的特定标准，XML在DB中的应用，现在似乎还尽是 XQL,Oracle号称他的9i2是 based on XML B的，核心元数据是XML描述，这个，可以在 Sep 03的Oracleworld上的材料上看到。应用服务器这部分，老实话俺不是很熟悉，不敢 瞎说，ebXML,SOAP,WSDL等等，
下面一个个挨个讲，重点在client和collabortaive computing的server，不含database, app server,
关于OpenStack vs M$ XP Stack的讨论(1)
这几个月又做了一些探讨、调查和研究，对OpenStack又有了新的认识，借这个地方作点笔记.:p
1. Mozilla 里面有个扩展的功能插件,Calendar 可以从http://www.mozilla.org/projects/calendar/得到，现在仅支持文件形式的Calendar共享，包括local,NFS,SMB,和HTTP之上的WebDAV等等.
2. WebDAV是个好东西，可以提供用户验证的网络文件共享，DAV本身的意思就是Distributed Authoring & Version control。所以从机制上来说，OpenOffice.org/StarSuite 与Mozilla 都已经支持了协同开发方式。
3. 基于OpenOffice.org/StarOffice/StarSuite的Collaborative Computing 方案，已经有厂商在做了，现成的例子包括SAP 和 一个叫做icoya的德国公司(www.icoya.com)。都是在德国，也许就是“近水楼台先得月”吧。SAP的方案是把StarOffice嵌入进Java程序里，利用OOo/SO提供的OfficeBean功能；icoya的方案是把OOo/SO同 Zope CMS结合起来，在Zope的基础上利用UNO的Python实现方式用XSLT对StarOffice的文件进行转换和管理，发布等功能。
4. 现在利用ODK和XSLT的结合的Collaborative Computing或者content/document management的B2B方案实例 icoya实现的方案已经满足了进行文档流转和控制的需求，只是它的实现是在server上与Zope结合起来的，并不是完全得利用OOo/SO的ODK来完成。当然这也许是经过技术选择的结果，因为UNO ODK从我个人角度来看也许是比较适合做desktop/client上的应用的，作为大密度触发的server会有难度。而Zope在这一点上已经经过了实践的考验，并且表现良好。所以应该说icoya的选择seemingly是明智的。:)