架构论战 打扫战场
4 views
Skip to first unread message
Qing
May 12, 2008, 1:43:16 AM5/12/08
to tt...@googlegroups.com
错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
差点忘了这封帖子不是谈领悟，是清理战场。
翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
innovate：
1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
3、这套混合架构是近些年逐步形成的，并非一个人原创；
4、目前已经有所实践，好几个了，但目前还不能公布；
5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
Interstage：
1、这不是架构，恐怕是一种实施方法论；
2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
4、以自己的经历，证明无法从技术层面解决问题；
5、再次强调"持续改善"，期望搞个持续改善的BI模型；
6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
哇哦，好累，花了一个小时的时间。
对于两者的争论，我无法去说什么，有的观点需要去证明，而不是在这里扯淡。能够讨论到这个份上，最好是能够继续深入。不可否认，两位都很牛，对错也不重要。我来对两位的东西也发表一些意见。
首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽然未必是优化）。
如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
interstage
May 12, 2008, 1:54:18 AM5/12/08
to ttnn BI 观点
你总结的＂6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；＂
这个不是interstage的观念，是innovate认为＂持续改善＂四个字总结的，把ＤＷ和ＢＩ分解彻底，把持续改善只能用在ＢＩ上，不能用在Ｄ
Ｗ上，呵呵，然后只认为ＤＷ的架构是纯技术的，＂持续改善＂的管理理论是纯业务，然后我认为数据仓库架构是属于应用性技术，必须考虑社会性科学的层面，
然后问他ＤＷ架构的组件和组件间定义规则和管理思路，回答不知道所云，一直在讲＂ＯＤＳ－ＥＤＷ－ＣＤＷ－ＤＭ＂的好处，所以更加怀疑他的研究．
On 5月12日, 下午1时43分, Qing <happys...@gmail.com> wrote:
> 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活-儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干-，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我-们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面-，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽-然未必是优化）。
>
> 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
这个不是interstage的观念，是innovate认为＂持续改善＂四个字总结的，把ＤＷ和ＢＩ分解彻底，把持续改善只能用在ＢＩ上，不能用在Ｄ
Ｗ上，呵呵，然后只认为ＤＷ的架构是纯技术的，＂持续改善＂的管理理论是纯业务，然后我认为数据仓库架构是属于应用性技术，必须考虑社会性科学的层面，
然后问他ＤＷ架构的组件和组件间定义规则和管理思路，回答不知道所云，一直在讲＂ＯＤＳ－ＥＤＷ－ＣＤＷ－ＤＭ＂的好处，所以更加怀疑他的研究．
On 5月12日, 下午1时43分, Qing <happys...@gmail.com> wrote:
> 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活-儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干-，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> 差点忘了这封帖子不是谈领悟，是清理战场。
>
> 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> innovate：
> 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> 4、目前已经有所实践，好几个了，但目前还不能公布；
> 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> Interstage：
> 1、这不是架构，恐怕是一种实施方法论；
> 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> 4、以自己的经历，证明无法从技术层面解决问题；
> 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> 哇哦，好累，花了一个小时的时间。
>
> 对于两者的争论，我无法去说什么，有的观点需要去证明，而不是在这里扯淡。能够讨论到这个份上，最好是能够继续深入。不可否认，两位都很牛，对错也不重要。我来-对两位的东西也发表一些意见。
> 差点忘了这封帖子不是谈领悟，是清理战场。
>
> 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> innovate：
> 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> 4、目前已经有所实践，好几个了，但目前还不能公布；
> 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> Interstage：
> 1、这不是架构，恐怕是一种实施方法论；
> 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> 4、以自己的经历，证明无法从技术层面解决问题；
> 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> 哇哦，好累，花了一个小时的时间。
>
>
> 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我-们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面-，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽-然未必是优化）。
>
> 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
interstage
May 12, 2008, 2:04:53 AM5/12/08
to ttnn BI 观点
Qing说＂关于＂持续改善＂究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚＂．这个＂Kaizen＂的管理理论起源于１９７０
年，在近１０年内国外企业开始大规模关注和引用，特别是＂第５项修炼＂的学习团队的建设和＂世界是平的＂的组织架构，就是对＂Kaizen＂管理学的开
展．所以建议大家在google上查查这个管理学理论，实践方法和这３０年在各企业的成功经验．如果大家有兴趣，我也可以专业讲讲这个理论，我也是０５
年接触理论，然后试着设计出和＂Kaizen＂理论一致的业务管理和业务系统并用于实践中，我目前从事的工作就是要设计出符合＂Kaizen＂理论的全
网业务运营模式并加以实施，也希望在空闲之余，想和ＴＴＮＮ的Bier一起设计出符合＂Kaizen＂理论的BI模型（我都不好意思说架构两字了），让
ＴＴＮＮ一起共享．如果Ｑing觉得可行，可以专门开了对＂Kaizen＂资料区，我会提供资料，给大家共享，谢谢！！
> 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活-儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干-，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我-们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面-，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽-然未必是优化）。
>
> 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
年，在近１０年内国外企业开始大规模关注和引用，特别是＂第５项修炼＂的学习团队的建设和＂世界是平的＂的组织架构，就是对＂Kaizen＂管理学的开
展．所以建议大家在google上查查这个管理学理论，实践方法和这３０年在各企业的成功经验．如果大家有兴趣，我也可以专业讲讲这个理论，我也是０５
年接触理论，然后试着设计出和＂Kaizen＂理论一致的业务管理和业务系统并用于实践中，我目前从事的工作就是要设计出符合＂Kaizen＂理论的全
网业务运营模式并加以实施，也希望在空闲之余，想和ＴＴＮＮ的Bier一起设计出符合＂Kaizen＂理论的BI模型（我都不好意思说架构两字了），让
ＴＴＮＮ一起共享．如果Ｑing觉得可行，可以专门开了对＂Kaizen＂资料区，我会提供资料，给大家共享，谢谢！！
> 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活-儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干-，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> 差点忘了这封帖子不是谈领悟，是清理战场。
>
> 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> innovate：
> 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> 4、目前已经有所实践，好几个了，但目前还不能公布；
> 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> Interstage：
> 1、这不是架构，恐怕是一种实施方法论；
> 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> 4、以自己的经历，证明无法从技术层面解决问题；
> 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> 哇哦，好累，花了一个小时的时间。
>
> 对于两者的争论，我无法去说什么，有的观点需要去证明，而不是在这里扯淡。能够讨论到这个份上，最好是能够继续深入。不可否认，两位都很牛，对错也不重要。我来-对两位的东西也发表一些意见。
> 差点忘了这封帖子不是谈领悟，是清理战场。
>
> 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> innovate：
> 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> 4、目前已经有所实践，好几个了，但目前还不能公布；
> 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> Interstage：
> 1、这不是架构，恐怕是一种实施方法论；
> 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> 4、以自己的经历，证明无法从技术层面解决问题；
> 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> 哇哦，好累，花了一个小时的时间。
>
>
> 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我-们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面-，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽-然未必是优化）。
>
> 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
Qing
May 12, 2008, 2:19:29 AM5/12/08
to tt...@googlegroups.com
好啊，你可以在下载区上传文件，有权限。
当然，其实理论的东西让人看起来总是很费劲，最好是能有一些结合实际的例子。
2008/5/12 interstage <buer...@gmail.com>:
。。。也希望在空闲之余，想和ＴＴＮＮ的Bier一起设计出符合＂Kaizen＂理论的BI模型（我都不好意思说架构两字了），让ＴＴＮＮ一起共享．如果Ｑing觉得可行，可以专门开了对＂Kaizen＂资料区，我会提供资料，给大家共享，谢谢！！
。。
innovate511
May 12, 2008, 2:53:32 AM5/12/08
to ttnn BI 观点
我在公司的架构规划中，提到过整体架构需要细分成数据架构、ETL架构、安全架构等几大方向，综合起来才叫数据仓库架构。而业界存在最大争议的就是数据
架构这块，所以经常单独列出来代表数据仓库的主体。
正如Qing所说，我对BI分析这块，首先认可BI持续改善的思路，而且BI和DW结合紧密，但并非紧耦合，必须DW架构跟着BI分析走，如果这样走，
那就完了，BI分析每天都有新的思路，几年后不知道会成什么样子，反过去看，还有数据架构么？BI分析的基础是数据，就算多维数据，它还是数据，越是接
近分析的数据，变化越频繁，变数越大，故前辈们总结出很多关于数据仓库的理论，并结合实践不断升华和加强。我专注于这块，故会以数据支撑这个角度去诠释
BI数据基础----DW的建设。
至于某些人的挑衅，我已经不再理会了，大家可以看到那么多帖子我没回，当然也没看，猜都能猜到在说些什么。当年Inmon和Kimball之战，意在数
据仓库架构，现在有人争论的是，数据仓库和管理理论，我可以没这么牛，这样关联不直接的命题，实难争论，明显是谈论牛头去和马嘴。
数据仓库数据架构的本意并非脱离BI分析独立思考，而是更好地适应BI变化多端的分析，BI分析是上层应用，和BI分析的直接接口是数据集市，因此数据
集市易变。那么数据仓库架构的最终目的是什么呢？那就是适应尽可能多的变化，我提到的案例里指出，目前顶级项目的多维数据仓库也不过支撑不超过10年，
因为在经历近10年的变化支撑后，最初的考虑已经不够支撑更多新变化，于是考虑到重组。
至于象某些人说的数据仓库不过如此，就是管理维和度量，但这是最初级阶段的认识。早在80年代Kimball刚在思考这些问题的时候就在做。现在的阶段
都是在思量如何应对变化：数据量过大、业务重组/企业收购、维变化/维定义变化/维组织层级变化、统计度量的定义多变、衍生维（退化维）的变化、汇总的
变化。于是当前无论哪种方案，在数据仓库肯定首要考虑的是适应长远变化，所以都在定义行业内比较通用的标准，而且在多维数据仓库加入辅助模型支撑尽量多
尽量大的变化。有了数据仓库的稳定，数据集市放可放开手脚迎合BI分析的多变应用和更多复杂应用。
还有我对QING的提法有异议，这根本不算什么华山论剑，我很遗憾之前做了些无谓的回帖。说的根本不是一回事，如果讨论数据仓库究竟哪种好，或者讨论模
型怎么建才能适应变化等等，那么这算是一种论剑。但是如果拿数据仓库技术和管理理论一起讨论，好像不符合争论的初衷，这种讨论就像有人争论数据库管理和
SOA谁对企业信息化贡献大一样，你说数据库管理和SOA一点关系都没呢，又有关系，但完全是解决不同的问题，何来争论之说？
> 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活-儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干-，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我-们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面-，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽-然未必是优化）。
>
> 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
架构这块，所以经常单独列出来代表数据仓库的主体。
正如Qing所说，我对BI分析这块，首先认可BI持续改善的思路，而且BI和DW结合紧密，但并非紧耦合，必须DW架构跟着BI分析走，如果这样走，
那就完了，BI分析每天都有新的思路，几年后不知道会成什么样子，反过去看，还有数据架构么？BI分析的基础是数据，就算多维数据，它还是数据，越是接
近分析的数据，变化越频繁，变数越大，故前辈们总结出很多关于数据仓库的理论，并结合实践不断升华和加强。我专注于这块，故会以数据支撑这个角度去诠释
BI数据基础----DW的建设。
至于某些人的挑衅，我已经不再理会了，大家可以看到那么多帖子我没回，当然也没看，猜都能猜到在说些什么。当年Inmon和Kimball之战，意在数
据仓库架构，现在有人争论的是，数据仓库和管理理论，我可以没这么牛，这样关联不直接的命题，实难争论，明显是谈论牛头去和马嘴。
数据仓库数据架构的本意并非脱离BI分析独立思考，而是更好地适应BI变化多端的分析，BI分析是上层应用，和BI分析的直接接口是数据集市，因此数据
集市易变。那么数据仓库架构的最终目的是什么呢？那就是适应尽可能多的变化，我提到的案例里指出，目前顶级项目的多维数据仓库也不过支撑不超过10年，
因为在经历近10年的变化支撑后，最初的考虑已经不够支撑更多新变化，于是考虑到重组。
至于象某些人说的数据仓库不过如此，就是管理维和度量，但这是最初级阶段的认识。早在80年代Kimball刚在思考这些问题的时候就在做。现在的阶段
都是在思量如何应对变化：数据量过大、业务重组/企业收购、维变化/维定义变化/维组织层级变化、统计度量的定义多变、衍生维（退化维）的变化、汇总的
变化。于是当前无论哪种方案，在数据仓库肯定首要考虑的是适应长远变化，所以都在定义行业内比较通用的标准，而且在多维数据仓库加入辅助模型支撑尽量多
尽量大的变化。有了数据仓库的稳定，数据集市放可放开手脚迎合BI分析的多变应用和更多复杂应用。
还有我对QING的提法有异议，这根本不算什么华山论剑，我很遗憾之前做了些无谓的回帖。说的根本不是一回事，如果讨论数据仓库究竟哪种好，或者讨论模
型怎么建才能适应变化等等，那么这算是一种论剑。但是如果拿数据仓库技术和管理理论一起讨论，好像不符合争论的初衷，这种讨论就像有人争论数据库管理和
SOA谁对企业信息化贡献大一样，你说数据库管理和SOA一点关系都没呢，又有关系，但完全是解决不同的问题，何来争论之说？
> 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活-儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干-，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> 差点忘了这封帖子不是谈领悟，是清理战场。
>
> 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> innovate：
> 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> 4、目前已经有所实践，好几个了，但目前还不能公布；
> 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> Interstage：
> 1、这不是架构，恐怕是一种实施方法论；
> 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> 4、以自己的经历，证明无法从技术层面解决问题；
> 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> 哇哦，好累，花了一个小时的时间。
>
> 对于两者的争论，我无法去说什么，有的观点需要去证明，而不是在这里扯淡。能够讨论到这个份上，最好是能够继续深入。不可否认，两位都很牛，对错也不重要。我来-对两位的东西也发表一些意见。
> 差点忘了这封帖子不是谈领悟，是清理战场。
>
> 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> innovate：
> 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> 4、目前已经有所实践，好几个了，但目前还不能公布；
> 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> Interstage：
> 1、这不是架构，恐怕是一种实施方法论；
> 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> 4、以自己的经历，证明无法从技术层面解决问题；
> 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> 哇哦，好累，花了一个小时的时间。
>
>
> 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我-们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面-，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽-然未必是优化）。
>
> 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
innovate511
May 12, 2008, 2:59:30 AM5/12/08
to ttnn BI 观点
如果有人打算把自己推销的东西建立在打压别人的东西之上（还不是解决同一个问题的东西），我觉得已经不是技术问题或者管理问题了。
数据仓库是否就那么简单，或者该怎么根据实际情况去思考和建设，并非拿一两个理论用来套即可，也不是你听说过，或者简单见识过就觉得不过如此。深入解决
更多更广泛的实际问题，那才是正道。
数据仓库是否就那么简单，或者该怎么根据实际情况去思考和建设，并非拿一两个理论用来套即可，也不是你听说过，或者简单见识过就觉得不过如此。深入解决
更多更广泛的实际问题，那才是正道。
interstage
May 12, 2008, 3:16:52 AM5/12/08
to ttnn BI 观点
呵呵，我推销什么东西了，我现在在推销产品吗，我已经告诉ＴＴＮＮ我现在工作的情况，就是搞全网业务运营管理．我用我的＂持续改善＂打压你的＂混合架构
＂了吗，我不是在努力展开你的＂混合架构＂，发现到目前为止，还不能叫架构，连组件间的接口定义和管理规则都没有描述清楚．我的＂持续改善＂ＢＩ模型，
我没叫架构，我把它称为模型，而且我很希望ＴＴＮＮ的人群策群力把它完善．你怎么会有这个心态，以为我在用我的持续改善模型打压你所谓的＂混合架构＂，
你的心情如此敏感，你的态度如此歇斯底里，这样的心态和态度能原创应用性架构吗，我很怀疑你和别人交流技术过程中是不是经常盛气凌人，或者诋毁漫骂，
哎．
＂了吗，我不是在努力展开你的＂混合架构＂，发现到目前为止，还不能叫架构，连组件间的接口定义和管理规则都没有描述清楚．我的＂持续改善＂ＢＩ模型，
我没叫架构，我把它称为模型，而且我很希望ＴＴＮＮ的人群策群力把它完善．你怎么会有这个心态，以为我在用我的持续改善模型打压你所谓的＂混合架构＂，
你的心情如此敏感，你的态度如此歇斯底里，这样的心态和态度能原创应用性架构吗，我很怀疑你和别人交流技术过程中是不是经常盛气凌人，或者诋毁漫骂，
哎．
interstage
May 12, 2008, 3:44:31 AM5/12/08
to ttnn BI 观点
＂我在公司的架构规划中，提到过整体架构需要细分成数据架构、ETL架构、安全架构等几大方向，综合起来才叫数据仓库架构＂从这句话，我终于理解了，可
能是我们都误解了，他提出的＂混合架构＂，是＂某公司的数据仓库混合架构＂，定语没加上去，我们以为他＂混合架构＂是挑战２大架构马上要成为第３方架
构，所以希望他展开，看来我们都误解了，表示道歉．
再次申明BI是1996年Gartner Group（其实就是Howard Dresber先生）最早提出，BI描述了一系列的概念和方法，通过数据
仓库,OLAP,数据挖掘等技术和支持系统来辅助商业决策的制定．所以BI分析应用的接口不仅仅直接来自数据集市(Kimball说可以在ODS上直接
出报表).这样把BI概念缩小到和DW彻底分解的做法,真的很值得商榷.
你不想和我交流,呵呵,没关系,至少我还是希望和你交流,让我和TTNN彻底来看看你的DW技术水平和技术修养究竟有多高,连我直接问你的＂混合架构＂
中4个基本描述问题都答非所问,你还能让我说你什么好.
On 5月12日, 下午2时53分, innovate511 <innovate...@gmail.com> wrote:
> 我在公司的架构规划中，提到过整体架构需要细分成数据架构、ETL架构、安全架构等几大方向，综合起来才叫数据仓库架构。而业界存在最大争议的就是数据
> 架构这块，所以经常单独列出来代表数据仓库的主体。
>
> 正如Qing所说，我对BI分析这块，首先认可BI持续改善的思路，而且BI和DW结合紧密，但并非紧耦合，必须DW架构跟着BI分析走，如果这样走，
> 那就完了，BI分析每天都有新的思路，几年后不知道会成什么样子，反过去看，还有数据架构么？BI分析的基础是数据，就算多维数据，它还是数据，越是接
> 近分析的数据，变化越频繁，变数越大，故前辈们总结出很多关于数据仓库的理论，并结合实践不断升华和加强。我专注于这块，故会以数据支撑这个角度去诠释
> BI数据基础----DW的建设。
>
> 至于某些人的挑衅，我已经不再理会了，大家可以看到那么多帖子我没回，当然也没看，猜都能猜到在说些什么。当年Inmon和Kimball之战，意在数
> 据仓库架构，现在有人争论的是，数据仓库和管理理论，我可以没这么牛，这样关联不直接的命题，实难争论，明显是谈论牛头去和马嘴。
>
> 数据仓库数据架构的本意并非脱离BI分析独立思考，而是更好地适应BI变化多端的分析，BI分析是上层应用，和BI分析的直接接口是数据集市，因此数据
> 集市易变。那么数据仓库架构的最终目的是什么呢？那就是适应尽可能多的变化，我提到的案例里指出，目前顶级项目的多维数据仓库也不过支撑不超过10年，
> 因为在经历近10年的变化支撑后，最初的考虑已经不够支撑更多新变化，于是考虑到重组。
>
> 至于象某些人说的数据仓库不过如此，就是管理维和度量，但这是最初级阶段的认识。早在80年代Kimball刚在思考这些问题的时候就在做。现在的阶段
> 都是在思量如何应对变化：数据量过大、业务重组/企业收购、维变化/维定义变化/维组织层级变化、统计度量的定义多变、衍生维（退化维）的变化、汇总的
> 变化。于是当前无论哪种方案，在数据仓库肯定首要考虑的是适应长远变化，所以都在定义行业内比较通用的标准，而且在多维数据仓库加入辅助模型支撑尽量多
> 尽量大的变化。有了数据仓库的稳定，数据集市放可放开手脚迎合BI分析的多变应用和更多复杂应用。
>
> 还有我对QING的提法有异议，这根本不算什么华山论剑，我很遗憾之前做了些无谓的回帖。说的根本不是一回事，如果讨论数据仓库究竟哪种好，或者讨论模
> 型怎么建才能适应变化等等，那么这算是一种论剑。但是如果拿数据仓库技术和管理理论一起讨论，好像不符合争论的初衷，这种讨论就像有人争论数据库管理和
> SOA谁对企业信息化贡献大一样，你说数据库管理和SOA一点关系都没呢，又有关系，但完全是解决不同的问题，何来争论之说？
>
> On 5月12日, 下午1时43分, Qing <happys...@gmail.com> wrote:
>
>
>
> > 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活--儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> > 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干--，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐-怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《-鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> > 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我--们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到-这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> > 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面--，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目-前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们-携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系-统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前-前进（虽-然未必是优化）。
>
> > 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
能是我们都误解了，他提出的＂混合架构＂，是＂某公司的数据仓库混合架构＂，定语没加上去，我们以为他＂混合架构＂是挑战２大架构马上要成为第３方架
构，所以希望他展开，看来我们都误解了，表示道歉．
再次申明BI是1996年Gartner Group（其实就是Howard Dresber先生）最早提出，BI描述了一系列的概念和方法，通过数据
仓库,OLAP,数据挖掘等技术和支持系统来辅助商业决策的制定．所以BI分析应用的接口不仅仅直接来自数据集市(Kimball说可以在ODS上直接
出报表).这样把BI概念缩小到和DW彻底分解的做法,真的很值得商榷.
你不想和我交流,呵呵,没关系,至少我还是希望和你交流,让我和TTNN彻底来看看你的DW技术水平和技术修养究竟有多高,连我直接问你的＂混合架构＂
中4个基本描述问题都答非所问,你还能让我说你什么好.
On 5月12日, 下午2时53分, innovate511 <innovate...@gmail.com> wrote:
> 我在公司的架构规划中，提到过整体架构需要细分成数据架构、ETL架构、安全架构等几大方向，综合起来才叫数据仓库架构。而业界存在最大争议的就是数据
> 架构这块，所以经常单独列出来代表数据仓库的主体。
>
> 正如Qing所说，我对BI分析这块，首先认可BI持续改善的思路，而且BI和DW结合紧密，但并非紧耦合，必须DW架构跟着BI分析走，如果这样走，
> 那就完了，BI分析每天都有新的思路，几年后不知道会成什么样子，反过去看，还有数据架构么？BI分析的基础是数据，就算多维数据，它还是数据，越是接
> 近分析的数据，变化越频繁，变数越大，故前辈们总结出很多关于数据仓库的理论，并结合实践不断升华和加强。我专注于这块，故会以数据支撑这个角度去诠释
> BI数据基础----DW的建设。
>
> 至于某些人的挑衅，我已经不再理会了，大家可以看到那么多帖子我没回，当然也没看，猜都能猜到在说些什么。当年Inmon和Kimball之战，意在数
> 据仓库架构，现在有人争论的是，数据仓库和管理理论，我可以没这么牛，这样关联不直接的命题，实难争论，明显是谈论牛头去和马嘴。
>
> 数据仓库数据架构的本意并非脱离BI分析独立思考，而是更好地适应BI变化多端的分析，BI分析是上层应用，和BI分析的直接接口是数据集市，因此数据
> 集市易变。那么数据仓库架构的最终目的是什么呢？那就是适应尽可能多的变化，我提到的案例里指出，目前顶级项目的多维数据仓库也不过支撑不超过10年，
> 因为在经历近10年的变化支撑后，最初的考虑已经不够支撑更多新变化，于是考虑到重组。
>
> 至于象某些人说的数据仓库不过如此，就是管理维和度量，但这是最初级阶段的认识。早在80年代Kimball刚在思考这些问题的时候就在做。现在的阶段
> 都是在思量如何应对变化：数据量过大、业务重组/企业收购、维变化/维定义变化/维组织层级变化、统计度量的定义多变、衍生维（退化维）的变化、汇总的
> 变化。于是当前无论哪种方案，在数据仓库肯定首要考虑的是适应长远变化，所以都在定义行业内比较通用的标准，而且在多维数据仓库加入辅助模型支撑尽量多
> 尽量大的变化。有了数据仓库的稳定，数据集市放可放开手脚迎合BI分析的多变应用和更多复杂应用。
>
> 还有我对QING的提法有异议，这根本不算什么华山论剑，我很遗憾之前做了些无谓的回帖。说的根本不是一回事，如果讨论数据仓库究竟哪种好，或者讨论模
> 型怎么建才能适应变化等等，那么这算是一种论剑。但是如果拿数据仓库技术和管理理论一起讨论，好像不符合争论的初衷，这种讨论就像有人争论数据库管理和
> SOA谁对企业信息化贡献大一样，你说数据库管理和SOA一点关系都没呢，又有关系，但完全是解决不同的问题，何来争论之说？
>
> On 5月12日, 下午1时43分, Qing <happys...@gmail.com> wrote:
>
>
>
>
> > 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干--，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐-怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《-鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> > 差点忘了这封帖子不是谈领悟，是清理战场。
>
> > 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> > innovate：
> > 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> > 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> > 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> > 4、目前已经有所实践，好几个了，但目前还不能公布；
> > 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> > Interstage：
> > 1、这不是架构，恐怕是一种实施方法论；
> > 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> > 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> > 4、以自己的经历，证明无法从技术层面解决问题；
> > 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> > 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> > 哇哦，好累，花了一个小时的时间。
>
> > 对于两者的争论，我无法去说什么，有的观点需要去证明，而不是在这里扯淡。能够讨论到这个份上，最好是能够继续深入。不可否认，两位都很牛，对错也不重要。我来--对两位的东西也发表一些意见。
> > 差点忘了这封帖子不是谈领悟，是清理战场。
>
> > 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> > innovate：
> > 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> > 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> > 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> > 4、目前已经有所实践，好几个了，但目前还不能公布；
> > 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> > Interstage：
> > 1、这不是架构，恐怕是一种实施方法论；
> > 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> > 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> > 4、以自己的经历，证明无法从技术层面解决问题；
> > 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> > 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> > 哇哦，好累，花了一个小时的时间。
>
>
> > 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我--们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到-这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> > 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面--，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目-前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们-携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系-统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前-前进（虽-然未必是优化）。
>
> > 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
raullew
May 12, 2008, 4:48:23 AM5/12/08
to ttnn BI 观点
要看在什么公司
在多数中国公司，简单即美，ODS+BI即可，DW、DM都不需要
因为大家都在探索业务，企业经营一季一个样，一年大变样
> 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活-儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干-，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我-们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面-，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽-然未必是优化）。
>
> 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
在多数中国公司，简单即美，ODS+BI即可，DW、DM都不需要
因为大家都在探索业务，企业经营一季一个样，一年大变样
> 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活-儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干-，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> 差点忘了这封帖子不是谈领悟，是清理战场。
>
> 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> innovate：
> 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> 4、目前已经有所实践，好几个了，但目前还不能公布；
> 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> Interstage：
> 1、这不是架构，恐怕是一种实施方法论；
> 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> 4、以自己的经历，证明无法从技术层面解决问题；
> 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> 哇哦，好累，花了一个小时的时间。
>
> 对于两者的争论，我无法去说什么，有的观点需要去证明，而不是在这里扯淡。能够讨论到这个份上，最好是能够继续深入。不可否认，两位都很牛，对错也不重要。我来-对两位的东西也发表一些意见。
> 差点忘了这封帖子不是谈领悟，是清理战场。
>
> 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> innovate：
> 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> 4、目前已经有所实践，好几个了，但目前还不能公布；
> 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> Interstage：
> 1、这不是架构，恐怕是一种实施方法论；
> 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> 4、以自己的经历，证明无法从技术层面解决问题；
> 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> 哇哦，好累，花了一个小时的时间。
>
>
> 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我-们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面-，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽-然未必是优化）。
>
> 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
interstage
May 12, 2008, 4:59:51 AM5/12/08
to ttnn BI 观点
嘘，小声点，你这样说会被牛人鄙视死的．不过我支持你的观念,在现在中国要搞原创性东西条件还不成熟,特别是搞和企业管理层面紧密相关的BI分析原创,
更谈不上基于BI分析的那些DW,DM架构的原创,能整个模型原创已经不错了.
On 5月12日, 下午4时48分, raullew <raul...@hotmail.com> wrote:
> 要看在什么公司
> 在多数中国公司，简单即美，ODS+BI即可，DW、DM都不需要
> 因为大家都在探索业务，企业经营一季一个样，一年大变样
>
> On 5月12日, 下午1时43分, Qing <happys...@gmail.com> wrote:
>
>
>
> > 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活--儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> > 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干--，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐-怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《-鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
更谈不上基于BI分析的那些DW,DM架构的原创,能整个模型原创已经不错了.
On 5月12日, 下午4时48分, raullew <raul...@hotmail.com> wrote:
> 要看在什么公司
> 在多数中国公司，简单即美，ODS+BI即可，DW、DM都不需要
> 因为大家都在探索业务，企业经营一季一个样，一年大变样
>
> On 5月12日, 下午1时43分, Qing <happys...@gmail.com> wrote:
>
>
>
>
> > 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干--，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐-怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《-鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> > 差点忘了这封帖子不是谈领悟，是清理战场。
>
> > 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> > innovate：
> > 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> > 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> > 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> > 4、目前已经有所实践，好几个了，但目前还不能公布；
> > 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> > Interstage：
> > 1、这不是架构，恐怕是一种实施方法论；
> > 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> > 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> > 4、以自己的经历，证明无法从技术层面解决问题；
> > 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> > 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> > 哇哦，好累，花了一个小时的时间。
>
> > 差点忘了这封帖子不是谈领悟，是清理战场。
>
> > 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> > innovate：
> > 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> > 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> > 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> > 4、目前已经有所实践，好几个了，但目前还不能公布；
> > 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> > Interstage：
> > 1、这不是架构，恐怕是一种实施方法论；
> > 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> > 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> > 4、以自己的经历，证明无法从技术层面解决问题；
> > 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> > 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> > 哇哦，好累，花了一个小时的时间。
>
yang kaymo
May 12, 2008, 5:15:24 AM5/12/08
to tt...@googlegroups.com
怎么感觉你们把BI搞成类似软件工程的东西了呀：
一个认为要瀑布方式，首先规划好
另外一个认为先原型，后反复迭代完善
我小脑袋想不明白了
KayMO Yang
interstage
May 12, 2008, 5:39:06 AM5/12/08
to ttnn BI 观点
呵呵,你这个判断有点意思,但不是我的本意.去年开始,起点是我经过几年BI项目实施后发现传统的软件工程不适合BI项目实施,因为需求太不固定了,而
且BI项目又和企业的管理思路紧密结合在一起,所以,我认为应该从企业管理思路的角度出发来考虑BI项目实施,BI项目实施中是不是要选择DW,或者选
择什么DW架构,我觉得不是BI项目实施成功与否的关键因素(可能是重点因素). 但牛人不是这样认为,他认为只要架构牛比,肯定能支持BI项目的成功
实施,如果BI项目不成功,不是牛比架构的问题,是BI本身的问题,并指出这个牛比架构是批判性的否定和结合CIF和MD 2大架构,即将成为第3个原
创性架构,这样TTNN的人(包括我)很兴奋,希望他展开这个架构,进行深化,然后他又马上说这个架构不是原创,是有国外很多成功案例,在国外
叫"Hub-and-Spoke"体系架构,他在这个"Hub-and-Spoke"体系架构加上了他自己的经验,把它叫成"混合架构",那我以DW架
构4个最基本元素(理论性拓扑图,组件间的接口定义和管理规则,组件内的模块定义和管理规则,以及行业模型在各组件的存在点和管理方式)来请教他,牛人
对架构这4个最基本问题的回答实在让人不敢恭维(甚至让我感觉他对如何定义架构的基本元素都不知道),使我坚信,他所说"混合架构" 只剩下所谓的实施
经验或者是"某些公司的数据仓库架构"的示例了.于是乎,风云突然变化,敏感的心态和歇斯底里的态度出现了.
目前的进展就是如此,当然有些节外生枝,我想联合TTNN的力量把我的起点意思(持续改善)结合我的经验和大家的知识搞一个模型,叫持续改善的BI模
型,然后牛人以为我在用我的这个BI模型来否定他所谓的"混合架构",然后也出现了一些误会.
On 5月12日, 下午5时15分, "yang kaymo" <kaymo.y...@gmail.com> wrote:
> 怎么感觉你们把BI搞成类似软件工程的东西了呀：
> 一个认为要瀑布方式，首先规划好
> 另外一个认为先原型，后反复迭代完善
>
> 我小脑袋想不明白了
>
>
> > 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干---，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，-恐-怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到-了《-鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的-领悟。
>
> > 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我---们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达-到-这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> > 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面---，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们-目-前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让-我们-携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明-年的系-统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的-原则往前-前进（虽-然未必是优化）。
>
> - 显示引用的文字 -
且BI项目又和企业的管理思路紧密结合在一起,所以,我认为应该从企业管理思路的角度出发来考虑BI项目实施,BI项目实施中是不是要选择DW,或者选
择什么DW架构,我觉得不是BI项目实施成功与否的关键因素(可能是重点因素). 但牛人不是这样认为,他认为只要架构牛比,肯定能支持BI项目的成功
实施,如果BI项目不成功,不是牛比架构的问题,是BI本身的问题,并指出这个牛比架构是批判性的否定和结合CIF和MD 2大架构,即将成为第3个原
创性架构,这样TTNN的人(包括我)很兴奋,希望他展开这个架构,进行深化,然后他又马上说这个架构不是原创,是有国外很多成功案例,在国外
叫"Hub-and-Spoke"体系架构,他在这个"Hub-and-Spoke"体系架构加上了他自己的经验,把它叫成"混合架构",那我以DW架
构4个最基本元素(理论性拓扑图,组件间的接口定义和管理规则,组件内的模块定义和管理规则,以及行业模型在各组件的存在点和管理方式)来请教他,牛人
对架构这4个最基本问题的回答实在让人不敢恭维(甚至让我感觉他对如何定义架构的基本元素都不知道),使我坚信,他所说"混合架构" 只剩下所谓的实施
经验或者是"某些公司的数据仓库架构"的示例了.于是乎,风云突然变化,敏感的心态和歇斯底里的态度出现了.
目前的进展就是如此,当然有些节外生枝,我想联合TTNN的力量把我的起点意思(持续改善)结合我的经验和大家的知识搞一个模型,叫持续改善的BI模
型,然后牛人以为我在用我的这个BI模型来否定他所谓的"混合架构",然后也出现了一些误会.
On 5月12日, 下午5时15分, "yang kaymo" <kaymo.y...@gmail.com> wrote:
> 怎么感觉你们把BI搞成类似软件工程的东西了呀：
> 一个认为要瀑布方式，首先规划好
> 另外一个认为先原型，后反复迭代完善
>
> 我小脑袋想不明白了
>
> On 5/12/08, interstage <buer0...@gmail.com> wrote:
>
>
>
>
>
>
>
> > 嘘，小声点，你这样说会被牛人鄙视死的．不过我支持你的观念,在现在中国要搞原创性东西条件还不成熟,特别是搞和企业管理层面紧密相关的BI分析原创,
> > 更谈不上基于BI分析的那些DW,DM架构的原创,能整个模型原创已经不错了.
>
> > On 5月12日, 下午4时48分, raullew <raul...@hotmail.com> wrote:
> > > 要看在什么公司
> > > 在多数中国公司，简单即美，ODS+BI即可，DW、DM都不需要
> > > 因为大家都在探索业务，企业经营一季一个样，一年大变样
>
> > > On 5月12日, 下午1时43分, Qing <happys...@gmail.com> wrote:
>
> > 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活---儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
>
>
>
>
>
>
> > 嘘，小声点，你这样说会被牛人鄙视死的．不过我支持你的观念,在现在中国要搞原创性东西条件还不成熟,特别是搞和企业管理层面紧密相关的BI分析原创,
> > 更谈不上基于BI分析的那些DW,DM架构的原创,能整个模型原创已经不错了.
>
> > On 5月12日, 下午4时48分, raullew <raul...@hotmail.com> wrote:
> > > 要看在什么公司
> > > 在多数中国公司，简单即美，ODS+BI即可，DW、DM都不需要
> > > 因为大家都在探索业务，企业经营一季一个样，一年大变样
>
> > > On 5月12日, 下午1时43分, Qing <happys...@gmail.com> wrote:
>
>
> > 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干---，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，-恐-怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到-了《-鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的-领悟。
>
> > > > 差点忘了这封帖子不是谈领悟，是清理战场。
>
> > > > 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> > > > innovate：
> > > > 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> > > > 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> > > > 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> > > > 4、目前已经有所实践，好几个了，但目前还不能公布；
> > > > 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> > > > Interstage：
> > > > 1、这不是架构，恐怕是一种实施方法论；
> > > > 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> > > > 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> > > > 4、以自己的经历，证明无法从技术层面解决问题；
> > > > 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> > > > 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> > > > 哇哦，好累，花了一个小时的时间。
>
> > 对于两者的争论，我无法去说什么，有的观点需要去证明，而不是在这里扯淡。能够讨论到这个份上，最好是能够继续深入。不可否认，两位都很牛，对错也不重要。我来---对两位的东西也发表一些意见。
> > > > 差点忘了这封帖子不是谈领悟，是清理战场。
>
> > > > 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> > > > innovate：
> > > > 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> > > > 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> > > > 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> > > > 4、目前已经有所实践，好几个了，但目前还不能公布；
> > > > 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> > > > Interstage：
> > > > 1、这不是架构，恐怕是一种实施方法论；
> > > > 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> > > > 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> > > > 4、以自己的经历，证明无法从技术层面解决问题；
> > > > 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> > > > 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> > > > 哇哦，好累，花了一个小时的时间。
>
>
> > 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我---们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达-到-这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> > 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面---，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们-目-前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让-我们-携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明-年的系-统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的-原则往前-前进（虽-然未必是优化）。
>
> > > > 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。- 隐藏被引用文字 -
>
> > > - 显示引用的文字 -
>
> --
> KayMO Yang- 隐藏被引用文字 -
> > > > 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。- 隐藏被引用文字 -
>
> > > - 显示引用的文字 -
>
> --
>
> - 显示引用的文字 -
raullew
May 12, 2008, 6:26:01 AM5/12/08
to ttnn BI 观点
究竟选什么架构，这跟公司业务特点、数据需求特点、人员配置、各自对数据部门的想法、个人发展方向都有关系，都会有影响
因地制宜
On 5月12日, 下午4时59分, interstage <buer0...@gmail.com> wrote:
> 嘘，小声点，你这样说会被牛人鄙视死的．不过我支持你的观念,在现在中国要搞原创性东西条件还不成熟,特别是搞和企业管理层面紧密相关的BI分析原创,
> 更谈不上基于BI分析的那些DW,DM架构的原创,能整个模型原创已经不错了.
>
> On 5月12日, 下午4时48分, raullew <raul...@hotmail.com> wrote:
>
>
>
> > 要看在什么公司
> > 在多数中国公司，简单即美，ODS+BI即可，DW、DM都不需要
> > 因为大家都在探索业务，企业经营一季一个样，一年大变样
>
> > On 5月12日, 下午1时43分, Qing <happys...@gmail.com> wrote:
>
> > > 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活---儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> > > 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干---，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，-恐-怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到-了《-鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的-领悟。
>
> - 显示引用的文字 -
因地制宜
On 5月12日, 下午4时59分, interstage <buer0...@gmail.com> wrote:
> 嘘，小声点，你这样说会被牛人鄙视死的．不过我支持你的观念,在现在中国要搞原创性东西条件还不成熟,特别是搞和企业管理层面紧密相关的BI分析原创,
> 更谈不上基于BI分析的那些DW,DM架构的原创,能整个模型原创已经不错了.
>
> On 5月12日, 下午4时48分, raullew <raul...@hotmail.com> wrote:
>
>
>
> > 要看在什么公司
> > 在多数中国公司，简单即美，ODS+BI即可，DW、DM都不需要
> > 因为大家都在探索业务，企业经营一季一个样，一年大变样
>
> > On 5月12日, 下午1时43分, Qing <happys...@gmail.com> wrote:
>
>
> > > 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干---，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，-恐-怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到-了《-鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的-领悟。
>
> > > 差点忘了这封帖子不是谈领悟，是清理战场。
>
> > > 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> > > innovate：
> > > 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> > > 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> > > 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> > > 4、目前已经有所实践，好几个了，但目前还不能公布；
> > > 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> > > Interstage：
> > > 1、这不是架构，恐怕是一种实施方法论；
> > > 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> > > 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> > > 4、以自己的经历，证明无法从技术层面解决问题；
> > > 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> > > 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> > > 哇哦，好累，花了一个小时的时间。
>
> > > 差点忘了这封帖子不是谈领悟，是清理战场。
>
> > > 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> > > innovate：
> > > 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> > > 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> > > 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> > > 4、目前已经有所实践，好几个了，但目前还不能公布；
> > > 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> > > Interstage：
> > > 1、这不是架构，恐怕是一种实施方法论；
> > > 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> > > 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> > > 4、以自己的经历，证明无法从技术层面解决问题；
> > > 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> > > 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> > > 哇哦，好累，花了一个小时的时间。
>
> > > 对于两者的争论，我无法去说什么，有的观点需要去证明，而不是在这里扯淡。能够讨论到这个份上，最好是能够继续深入。不可否认，两位都很牛，对错也不重要。我来---对两位的东西也发表一些意见。
>
> > > 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我---们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达-到-这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> > > 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面---，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们-目-前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让-我们-携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明-年的系-统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的-原则往前-前进（虽-然未必是优化）。
>
> > > 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我---们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达-到-这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
>
> > > 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。- 隐藏被引用文字 -
>
> > - 显示引用的文字 -- 隐藏被引用文字 -
> > > 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。- 隐藏被引用文字 -
>
>
> - 显示引用的文字 -
innovate511
May 12, 2008, 6:29:00 AM5/12/08
to ttnn BI 观点
嗯，我觉得很多公司其实ODS都没必要，直接业务系统+BI即可。直接在业务系统之上建MV, 很快就能开发很强大，ODS,DW,DM统统都没必要。
就像你说的，大家都在探索业务，别说一个季一个样，现在一个月一个样也很正常，还要数据基础干嘛。
就像你说的，大家都在探索业务，别说一个季一个样，现在一个月一个样也很正常，还要数据基础干嘛。
innovate511
May 12, 2008, 6:35:18 AM5/12/08
to ttnn BI 观点
并非规划好就是瀑布方式，我所谓的虚拟架构，是可以按照需求选择组件的，再有更大需求的时候才选择更多组件去集成。
他那玩意是在分析管理层面，在数据基础方面怎么建并没有说明，正如楼上一个举的例子，很多时候ODS+BI即可，其实再简化下业务系统直接BI也可，看
你什么需求，打算做成什么样子，打算做多大范围的系统。
而且有个理念是不够准确的，那就是BI完全包含了数据仓库。如果这样说的话，基于ODS的EDI应用也是BI？基于DW的计划、预算系统也是BI？数据
仓库发展到后面是多面的数据服务中心，其核心服务体是BI，但不完全是。
他那玩意是在分析管理层面，在数据基础方面怎么建并没有说明，正如楼上一个举的例子，很多时候ODS+BI即可，其实再简化下业务系统直接BI也可，看
你什么需求，打算做成什么样子，打算做多大范围的系统。
而且有个理念是不够准确的，那就是BI完全包含了数据仓库。如果这样说的话，基于ODS的EDI应用也是BI？基于DW的计划、预算系统也是BI？数据
仓库发展到后面是多面的数据服务中心，其核心服务体是BI，但不完全是。
innovate511
May 12, 2008, 6:51:34 AM5/12/08
to ttnn BI 观点
还有，这个要看什么需求说什么话，我曾经也为客户做过基于ERP做BI，因为他们当时的需求决定了不需要整合数据，也不需要历史数据和数据变化，那还建
ODS、DW干嘛呢，要知道建设DW系统要花多少钱，这些简单需求，几十万的成本没必要搞成几百万。
所以我一开始就说，我讨论的是企业有长期打算，想以循序渐进的方式最终建企业级数据中心的企业可以这样考虑。适合年纯利数亿及以上，有相当竞争优势，最
好在战略上有更高目标计划的企业。对于这样企业，打好数据基础才有紧迫性。
ODS、DW干嘛呢，要知道建设DW系统要花多少钱，这些简单需求，几十万的成本没必要搞成几百万。
所以我一开始就说，我讨论的是企业有长期打算，想以循序渐进的方式最终建企业级数据中心的企业可以这样考虑。适合年纯利数亿及以上，有相当竞争优势，最
好在战略上有更高目标计划的企业。对于这样企业，打好数据基础才有紧迫性。
innovate511
May 12, 2008, 6:56:38 AM5/12/08
to ttnn BI 观点
所以我描述了面向的客户群体，是战略上想有长远稳定的信息化建设规划，但前期投入谨慎的高速发展大中型企业，并非只考虑投资几十万做些报表那种对信息化
没规划、或者特大垄断企业和单位，一开始就有实力建设完整的数据架构。
没规划、或者特大垄断企业和单位，一开始就有实力建设完整的数据架构。
interstage
May 12, 2008, 8:32:03 AM5/12/08
to ttnn BI 观点
别再吹什么你的虚拟架构,呵呵,连基本的组件间如何定义接口,如何进行流程管理都不知道,谈什么按照需求选择组件,给你几个组件都怀疑你是否能把它们协
调在一起的.
我这个被你称为玩意的东西,至少数据基础方面建设上,尊重imnon和kimball的架构,按照实际情况有选择性的选择其中一个,不象某些人动不动什
么组件,混合架构,虚拟架构,松偶合,紧藕荷,这些词谁不会说,让他展开,连基本逻辑都不懂,太搞笑了.
现在我准备搞了一个DW架构,采用云计算,SOA计算,网格计算方式等来定义DW架构,DW架构中以"服务"方式取代以前所谓的"构件"或者"组件",
我已经和美国政府,日本政府,欧盟,中国都谈好了,他们把政府中最先进实验室的服务器贡献出来,kimball和inmon都表示愿意和我合作,放弃他
们的2个架构,在我的DW架构基础下,完全实现"服务"方式的DW架构,以后世界上只要有人想搞建什么DW或者BI项目,没问题,以"服务"方式加入我
在全球体系下的DW架构,为未来300年内的BI项目提供最大的DW架构支撑.这个计划已经得到联合国的支持,取名代号为"牛比行动", 估计在未来
20年能全部建成,3年后第一期工程实现. TTNN的朋友,等我的好消息吧,DWBI前景是美好的.
> > 我小脑袋想不明白了- 隐藏被引用文字 -
>
> - 显示引用的文字 -
调在一起的.
我这个被你称为玩意的东西,至少数据基础方面建设上,尊重imnon和kimball的架构,按照实际情况有选择性的选择其中一个,不象某些人动不动什
么组件,混合架构,虚拟架构,松偶合,紧藕荷,这些词谁不会说,让他展开,连基本逻辑都不懂,太搞笑了.
现在我准备搞了一个DW架构,采用云计算,SOA计算,网格计算方式等来定义DW架构,DW架构中以"服务"方式取代以前所谓的"构件"或者"组件",
我已经和美国政府,日本政府,欧盟,中国都谈好了,他们把政府中最先进实验室的服务器贡献出来,kimball和inmon都表示愿意和我合作,放弃他
们的2个架构,在我的DW架构基础下,完全实现"服务"方式的DW架构,以后世界上只要有人想搞建什么DW或者BI项目,没问题,以"服务"方式加入我
在全球体系下的DW架构,为未来300年内的BI项目提供最大的DW架构支撑.这个计划已经得到联合国的支持,取名代号为"牛比行动", 估计在未来
20年能全部建成,3年后第一期工程实现. TTNN的朋友,等我的好消息吧,DWBI前景是美好的.
>
> - 显示引用的文字 -
Solo Zhu
May 12, 2008, 10:34:16 AM5/12/08
to ttnn BI 观点
这里怎么这么热闹啊
其实我觉得再好的理论都是以实际实施为目标，我想大家都有实际项目的经验，是否适合企业有很多方面需要考虑：
1：成本。
2：人力资源。
3：开始应用时间。
4：客户操作方式。
我们说的构架什么的，其实需要考虑的有很多很多，首先我们需要服务器，需要数据库，需要license，需要对应的DBA，需要安排业务人员访谈，需要
考虑先进的管理方式，需要考虑用户，管理层的操作习惯，需要考虑未来的扩展，需要花时间测试，需要安排时间培训，需要花时间去熟悉，后期需要维护，更
新。其实这些本来和项目的构架技术没有绝对的关系，但是到了具体的客户，具体的管理，情况就不一样了。有些客户喜欢BO的那种每一个客户可以按照自己的
习惯去操作universe，也可以像MS那样简单实效。每个工具都有自己的特点，但是如果我们先有展现工具，那么考虑模型设计时，思路就是不一样
的。
DW的实施，不是求大求全，而是实际是应用效果，这就是成本回报的问题了，作为项目管理来讲，我们需要考虑的就是这些了。BI/DW的项目也是如此
的。
其实原来我们一起讨论的DW2.0的构架其实也是很好的，但是不一定适合每一个企业，现在有的用户还在用80年代的unix或者dos系统，其实也很方
便，他们不愿意换，因为都习惯了。
innovate511 的观点还是有一定的道理，毕竟有实现的平台。当然这需要一个不错的企业IT构架去支撑，kimball和inmon的理
论都有其道理，毕竟我们很多的观点都是来自于他们。可是我们可以发现，他们之间的理论有些是矛盾的。这就是矛盾可以同时存在。我们其实也可以用自己的想
法去建立一套理论体系，然后用自己的方式去慢慢完善。
其实我觉得再好的理论都是以实际实施为目标，我想大家都有实际项目的经验，是否适合企业有很多方面需要考虑：
1：成本。
2：人力资源。
3：开始应用时间。
4：客户操作方式。
我们说的构架什么的，其实需要考虑的有很多很多，首先我们需要服务器，需要数据库，需要license，需要对应的DBA，需要安排业务人员访谈，需要
考虑先进的管理方式，需要考虑用户，管理层的操作习惯，需要考虑未来的扩展，需要花时间测试，需要安排时间培训，需要花时间去熟悉，后期需要维护，更
新。其实这些本来和项目的构架技术没有绝对的关系，但是到了具体的客户，具体的管理，情况就不一样了。有些客户喜欢BO的那种每一个客户可以按照自己的
习惯去操作universe，也可以像MS那样简单实效。每个工具都有自己的特点，但是如果我们先有展现工具，那么考虑模型设计时，思路就是不一样
的。
DW的实施，不是求大求全，而是实际是应用效果，这就是成本回报的问题了，作为项目管理来讲，我们需要考虑的就是这些了。BI/DW的项目也是如此
的。
其实原来我们一起讨论的DW2.0的构架其实也是很好的，但是不一定适合每一个企业，现在有的用户还在用80年代的unix或者dos系统，其实也很方
便，他们不愿意换，因为都习惯了。
innovate511 的观点还是有一定的道理，毕竟有实现的平台。当然这需要一个不错的企业IT构架去支撑，kimball和inmon的理
论都有其道理，毕竟我们很多的观点都是来自于他们。可是我们可以发现，他们之间的理论有些是矛盾的。这就是矛盾可以同时存在。我们其实也可以用自己的想
法去建立一套理论体系，然后用自己的方式去慢慢完善。
raullew
May 12, 2008, 12:58:45 PM5/12/08
to ttnn BI 观点
我的观点需要展开一下
企业需要两种架构并存的局面
ODS+BI，这是一开始用以构建EDW的架构，解决各部门粗狂的数据察看的需要，通常是count（*）、sum（amount），这些数据需要快速
响应和（各种乱七八糟业务）全面响应，因此从ODS直接出、一步到位是上选
ODS（+DW）+MART+BI，这是5年后用以构建数据集市的架构，解决核心业务线精细化分析的需要，通常是极其复杂的逻辑变换，这些数据涉及的加
工太多，ODS无法支撑，而核心业务又比较固化可以接受较多的流水线，因此分层实施是上选
> > 因为大家都在探索业务，企业经营一季一个样，一年大变样- Hide quoted text -
>
> - Show quoted text -
企业需要两种架构并存的局面
ODS+BI，这是一开始用以构建EDW的架构，解决各部门粗狂的数据察看的需要，通常是count（*）、sum（amount），这些数据需要快速
响应和（各种乱七八糟业务）全面响应，因此从ODS直接出、一步到位是上选
ODS（+DW）+MART+BI，这是5年后用以构建数据集市的架构，解决核心业务线精细化分析的需要，通常是极其复杂的逻辑变换，这些数据涉及的加
工太多，ODS无法支撑，而核心业务又比较固化可以接受较多的流水线，因此分层实施是上选
>
> - Show quoted text -
life2008life
May 12, 2008, 8:45:53 PM5/12/08
to tt...@googlegroups.com
嘿嘿,还真别说;我还真觉得你这个"牛比行动"是大势所趋;下面可以展开一个新的话题
life2008life
2008-05-13
发件人：
interstage
发送时间：
2008-05-12 20:32:14
收件人： ttnn BI
观点
抄送：
主题： Re: 架构论战
打扫战场
interstage
May 12, 2008, 9:50:42 PM5/12/08
to ttnn BI 观点
按照"牛比混合架构"的说法,你这个提法肯定不对, 如果你上DWBI项目不用牛比"混合架构"的话,目前就是上了DWBI,哪怕大家都说好,也是短暂
的成功,3-5年后(可能10年后,也可以100年后)你的项目就不能叫成功了,因为没有牛比"混合架构"来支撑你的数据变化.如果你上DWBI项目用
了"牛比混合架构"的话,哪怕大家都说不好,也是短暂的失败,3-5年后(可能10年后,也可以100年后)你的项目才能叫成功,因为牛比"混合架
构"来支撑你的数据变化.
(前提条件:"牛比混合架构"吹的和实际一样,虚拟架构,组件真的清晰定义)
的成功,3-5年后(可能10年后,也可以100年后)你的项目就不能叫成功了,因为没有牛比"混合架构"来支撑你的数据变化.如果你上DWBI项目用
了"牛比混合架构"的话,哪怕大家都说不好,也是短暂的失败,3-5年后(可能10年后,也可以100年后)你的项目才能叫成功,因为牛比"混合架
构"来支撑你的数据变化.
(前提条件:"牛比混合架构"吹的和实际一样,虚拟架构,组件真的清晰定义)
interstage
May 12, 2008, 10:29:51 PM5/12/08
to ttnn BI 观点
呵呵,这就是牛比的逻辑,太神奇了.
> > 法去建立一套理论体系，然后用自己的方式去慢慢完善。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
>
> - 显示引用的文字 -
innovate511
May 12, 2008, 10:52:56 PM5/12/08
to ttnn BI 观点
raullew说的体现了虚拟方案的一个方面，因时、因需求建设，逐步展开，当条件成熟的时候，两个系统并存是虚拟架构必须的事情，接口不可能一下就对
接上，需要全面的数据质量验证，然后才是移植整合，以保证整体的质量，所有这些事情都是后台动作，不会影响前端需求。
要知道某些人的观点在国内根本还没成功案例，至少我做的东西是基于实实在在技术的，看得见的，已经有成功案例，而且我还在孜孜不倦地做，至少这点上，我
就能证明这玩意已经是成功的思路，能适合很多情况，而某些人的东西尚不清楚是否适合中国情况。要讥讽别人，先关好自己的事吧。
至于有的人因为太资深了，只相信自己那套，以及书本上的理论，容不下其他的经验和实践。容不下且不说，尽是些无技术含量的讥讽论调，不能说某些人不识
货，而是劣根性太强。
我的帖子全都被消极讥讽、没半点DW水平的言论淹没，兼职污染了群内的帖子。讨论什么就谈什么，尽是扯淡和无技术性的讥讽，这是技术讨论需要的么？无论
哪派之间的争战，都是围绕技术和实践讨论，而不是根据自己想象的，或者完全照搬理论来主观下定论。
我在这么多帖子中从没回到过没有技术含量的帖子，但某些人一直在发这种贴，还孜孜不倦，其他人也很少回复他的无聊贴，可见脸皮之厚。
接上，需要全面的数据质量验证，然后才是移植整合，以保证整体的质量，所有这些事情都是后台动作，不会影响前端需求。
要知道某些人的观点在国内根本还没成功案例，至少我做的东西是基于实实在在技术的，看得见的，已经有成功案例，而且我还在孜孜不倦地做，至少这点上，我
就能证明这玩意已经是成功的思路，能适合很多情况，而某些人的东西尚不清楚是否适合中国情况。要讥讽别人，先关好自己的事吧。
至于有的人因为太资深了，只相信自己那套，以及书本上的理论，容不下其他的经验和实践。容不下且不说，尽是些无技术含量的讥讽论调，不能说某些人不识
货，而是劣根性太强。
我的帖子全都被消极讥讽、没半点DW水平的言论淹没，兼职污染了群内的帖子。讨论什么就谈什么，尽是扯淡和无技术性的讥讽，这是技术讨论需要的么？无论
哪派之间的争战，都是围绕技术和实践讨论，而不是根据自己想象的，或者完全照搬理论来主观下定论。
我在这么多帖子中从没回到过没有技术含量的帖子，但某些人一直在发这种贴，还孜孜不倦，其他人也很少回复他的无聊贴，可见脸皮之厚。
interstage
May 13, 2008, 12:08:33 AM5/13/08
to ttnn BI 观点
就看你回我关于你"混合架构"4个架构建设最原始问题的贴,也没见你有多么高深技术含量和技术修养(至少这样的技术水平,我以前很多同事都不在你之
下),别继续再吹什么架构,就老老实实说自己的一些BI项目经验,在3个DWBI项目中即选择过CIF架构,又选择过MD架构,仅供大家参考.这样
TTNN不仅关注你的经验,更喜欢你的谦虚的人格. 人和人在技术上,业务上水平存在差异,很正常.取得一点小小的BI成绩都,就大吹特吹,吹的连2大
架构大师都看不上的人,而且问他点技术问题,要么答非所问,要么盛气凌人,要么空话虚话,这样的人除了被TTNN讥讽后,还能如何. 我真的快无语了,
难道我们中国从事BIDW技术人员最终都走向"忽悠"的方向,真的如我一直所说的,要么把别人弄傻,要么自己变傻吗.
> > 工太多，ODS无法支撑，而核心业务又比较固化可以接受较多的流水线，因此分层实施是上选- 隐藏被引用文字 -
>
> - 显示引用的文字 -
下),别继续再吹什么架构,就老老实实说自己的一些BI项目经验,在3个DWBI项目中即选择过CIF架构,又选择过MD架构,仅供大家参考.这样
TTNN不仅关注你的经验,更喜欢你的谦虚的人格. 人和人在技术上,业务上水平存在差异,很正常.取得一点小小的BI成绩都,就大吹特吹,吹的连2大
架构大师都看不上的人,而且问他点技术问题,要么答非所问,要么盛气凌人,要么空话虚话,这样的人除了被TTNN讥讽后,还能如何. 我真的快无语了,
难道我们中国从事BIDW技术人员最终都走向"忽悠"的方向,真的如我一直所说的,要么把别人弄傻,要么自己变傻吗.
>
> - 显示引用的文字 -
tosimple
May 13, 2008, 12:36:56 AM5/13/08
to ttnn BI 观点
大家不要偏离了讨论的主题，转移到人身攻击上去了。
从前面的帖子来看，两位争论的无非就是A说有一种架构很牛，B说你的架构未必牛。
但是A说的这种架构到底是个什么样子，各人有个人的理解。
本是希望A能详细讲解下这种架构，可是，他认为这个涉及到个人的核心竞争力而不愿详解。
当然，通过前面的讨论，不管结果如何，相信大家对仓库建设都有了更深一层的理解（不管这个理解是深是浅，甚至是正确还是错误）。
这才是讨论的真谛！
希望看到更多类似的讨论(尽管其中有些不和谐的声音）
> 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活-儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干-，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我-们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面-，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽-然未必是优化）。
>
> 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
从前面的帖子来看，两位争论的无非就是A说有一种架构很牛，B说你的架构未必牛。
但是A说的这种架构到底是个什么样子，各人有个人的理解。
本是希望A能详细讲解下这种架构，可是，他认为这个涉及到个人的核心竞争力而不愿详解。
当然，通过前面的讨论，不管结果如何，相信大家对仓库建设都有了更深一层的理解（不管这个理解是深是浅，甚至是正确还是错误）。
这才是讨论的真谛！
希望看到更多类似的讨论(尽管其中有些不和谐的声音）
> 错过了周五和周末的架构论战，这事儿发展地太快，有些跟不上，相信很多人跟我一样，都已经肚子被搞大了。于是，我做个好人，将这次争论的主要线索整理一下。这活-儿不好干，两位的思维都很发散，经常在主线索之外来点花絮，很容易就被引到另一条道。
>
> 总体来说，大家可以看到这次争论跟多年以前华山派的气宗和剑宗的拚斗很相似，气宗的说法，要点是在一个气字，气功一成，不论使拳脚，还是耍刀剑，都行。剑宗不干-，他们说重点是在剑字上，剑术已成，就算内功马马地，也能杀敌。两派一度斗的头破血流。不过我们现在更加文明，只动口不动手。从《笑傲江湖》这本书里面看，恐怕-还是亲剑宗疏气宗的，为什么如此？我想跟他的想法也有关系。内和外的矛盾，恐怕是每个人都会去考虑的。但金庸越写到后面，已经越来越轻视内而注重外，到了《鹿鼎-记》，基本就是为了目的不择手段了。而《笑傲江湖》是《鹿鼎记》之前的一本，差不多是一种内外矛盾的过渡。这是金庸的看法，我们每个人都会有不同的领悟。
>
> 差点忘了这封帖子不是谈领悟，是清理战场。
>
> 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> innovate：
> 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> 4、目前已经有所实践，好几个了，但目前还不能公布；
> 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> Interstage：
> 1、这不是架构，恐怕是一种实施方法论；
> 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> 4、以自己的经历，证明无法从技术层面解决问题；
> 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> 哇哦，好累，花了一个小时的时间。
>
> 对于两者的争论，我无法去说什么，有的观点需要去证明，而不是在这里扯淡。能够讨论到这个份上，最好是能够继续深入。不可否认，两位都很牛，对错也不重要。我来-对两位的东西也发表一些意见。
> 差点忘了这封帖子不是谈领悟，是清理战场。
>
> 翻开最近的几封帖子，整理双方如下的观点，如有不对，或者没有说道重点，请修正：
>
> innovate：
> 1、ODS-EDW-CDW-DM是一种低耦合的dw混合架构，各模块独立，以接口形式交互，有点SOA的感觉；
> 2、他们可以虚拟化的，可以一步步作实；虚拟化是很重要的；
> 3、这套混合架构是近些年逐步形成的，并非一个人原创；
> 4、目前已经有所实践，好几个了，但目前还不能公布；
> 5、并不否定"持续改善"，跟dw混合架构不矛盾，但他不是全部；
>
> Interstage：
> 1、这不是架构，恐怕是一种实施方法论；
> 2、质疑这到底是不是原创（怎么扯到Hub-and-Spoke上去了，没明白）；
> 3、建议将"混合架构"改成"实践性混合架构"，以求名副其实，建议细化；
> 4、以自己的经历，证明无法从技术层面解决问题；
> 5、再次强调"持续改善"，期望搞个持续改善的BI模型；
> 6、合理的持续改善BI应该是合理的数据仓库架构+企业信息化基础不断完善+不断进行战略、策略调整+持续改善的BI分析策略四部分；
>
> 哇哦，好累，花了一个小时的时间。
>
>
> 首先是innovate的架构，早先提出这个四层结构的时候，称之为架构我认为有些不妥，或者说还没有说完整。任何事物存在都有理由，架构的存在是为了什么？我-们好像总是在谈dw、ods，但为什么需要他们。我们需要一个能够让数据更快、更方便、更准确、更安全访问的地方，这个地方就是数据仓库，dw架构就是要达到这-个目的。如何达到？我认为仅仅说四层的低耦合混合架构还没有说完全。因此，继续探讨。
>
> 而对于interstage的持续改善，这个概念也已经提出很久，在他刚进入ttnn的时候就提出。但很不好意思，我还不能完全领会这个概念，但也许在其他方面-，我是赞同这个概念的。比如在魔星的故事里面，将这个系统描述成为一个自我演进的玩意儿，算是持续改善吗？由于一直以来这个概念从没有没深化，他究竟跟我们目前-的管理理念有什么根本的不同？这点似乎并没有说清楚。至少，从名词上，大家确实容易将这个名词理解成为一种口号。比如一位领导在主席台上大手一挥，"让我们携手-不断前进"，人家这听起来也是持续改善。所以，我想不同之点应该在于如何实现持续改善，而如果落到一个IT系统上，应该可以这么说，今年的系统跟明年的系统就是-不一样了。而落到管理上，就是今年的管理跟明年的管理不一样了。这种不一样不是推到重来，或者那位领导一拍脑袋定下来，而是根据一个基本不变的原则往前前进（虽-然未必是优化）。
>
> 如果这个说法没错，下一步可以深入探讨一些如何实现持续改善的手段上。
Qing
May 13, 2008, 1:44:02 AM5/13/08
to tt...@googlegroups.com
有个朋友一直喜欢在msn上跟我讨论，不大愿意在ttnn发帖子。他喜欢探讨一些比较形而上的问题，这种问题有时候说说确实挺有意思的，比如这次，他关于这次争论谈了自己的想法后，转到另一个话题——什么是架构？
他不愿意在这里谈，我觉得可能的原因是低调，或者是懒得写上一段，但肯定不去想。（嘿嘿，你肯定能够看得到）既然如此，我来整理一些他的想法。
对这次争论，他认为innovate的一直没有搞明白面对的问题，对于interstage的持续改善，他认为这在中国是难以执行的，因为不好汇报，不好出成绩。恐怕正是因此而开始探讨"什么是架构"的问题。通常，这种问题没有答案，也许权威的说法能够让人不假思索地接受，但我们这里没有权威，所以都可以互相挑战的。
其实，关于这个话题，在两年前的五月，就曾经有一个这样一个话题，架构之谈。
那是跟非bi界的一位架构高手babituo探讨架构的问题，所以谈的比较玄乎。最后得出的结论是，我们对这个概念的认识还是存在差异，谈不下去。昨天在msn上的探讨也差不多如此，对于"架构"这个术语，也许就是每个人心中有个想法，就像大家对什么是BI的理解一样。也许没有必要去纠正大家对这个概念的理解，虽然如果有一个统一的说法，他是什么不是什么，能够有利于交流。但除非是存在一个几乎是公认的说法才行，目前，没有。
昨天这位朋友认为架构是一种虚的，是人们对问题的根本认识的本能反应。这句话说的让人很晕，我不理解他说的这个架构。举了例子，mvc、soa是架构。这让人容易理解一点，有例子当然好理解，但例子并不能给出一个定义，因为一个实例里面总是包含了虚的东西和实的东西。比如soa，可以说本后有一种思想，存在一种服务接口，以及对服务接口的查找机制。这是虚的，而实的，就是这套机制的实现，也就是具体的接口标准，如何查找的实现。soa这个术语包含了这两层意思。我更倾向于架构是一种实的的东西，他是一种对机制（虚的）的实现。那位朋友不认同，不过没关系，不需要统一思想。
我之所以宁愿认为架构是实的，有理由。我们身处的是it界，架构这个词也是多在it里面谈论得多（也许这是从建筑业里面借鉴过来的吧，但保险在网上搜这个词都是it界的条目居多）。it是一种手段，思想很重要，价值很高，但既然在it里面说事，就是实实在在地从一种认识转换成为一种可以运作的支撑手段。比如你可以用本体论的思想来认识这个世界，但落到it，就可以是一种oo的语言。语言比思想实在。
对于innovate提出的混合架构。想支撑10年的变化，采用低耦合的分层方法，这是理所当然的。不论是dw的架构还是其他事务系统的架构，都希望如此。关键是如何。这还是在谈架构的目的和原则，下一步，如果能够将架构背后的机制，以及如何实现都谈一些。
为什么在这次讨论中，innovate觉得interstage咄咄逼人呢，因为你是架构的提出者，得允许别人的质疑甚至讥讽，不如抛开这些，去深入探讨更深层次的东西。现在interstage已经提出他的持续改善bi模型了，到时候你就是进攻方，你也尽可以去讥讽他，哈哈。
嘿嘿,还真别说;我还真觉得你这个"牛比行动"是大势所趋;下面可以展开一个新的话题
...
interstage
May 13, 2008, 2:42:03 AM5/13/08
to ttnn BI 观点
呵呵,你那个朋友的说法有的意思,对于持续改善,的确在目前的中国企业才开始关注(呵呵,忍不住再说那个牛人，说中国企业以前的系统个个都是基于持续改
善思路来做,简直就是望文生意,太虚了,真的让他展开,什么都不会,技术也是,管理思路也是,而且态度和心态极其敏感),而我们中国企业体现管理文化的
组织架构(呵呵,又是"架构"2字,所以架构很重要,它就是整体的核心提炼部分)才从亲"亲"模式逐步转向层科式的管理模式,而"持续改善"逐渐让企业
从层科式的管理模式走向了扁平式的管理模式. 所以经过30年发展和实践已经非常成熟,当然它还在修整,也有可能在未来修整中,创新出新的理论被取代.
所以目前的中国企业中全范围导入很难.
在企业管理中,与"改善"相对应的是什么?是"创新"(呵呵,忍不住再说那个牛人,牛人以为在企业应用中,创新可以随便说,随便起一个名字,随便总结几
个项目经验,就可以叫创新.然后又是架构,又是创新,真太神奇了),"改善"指的是把工作标准微幅渐进的改良;"创新"指的是经由技术设备投资,达成的
工作标准重大的改良.因此在企业管理中,对"改善"和"创新"有明确的定义.那么改善也好,创新也好,对于企业来讲为什么要采用这2种工作方式,因为企
业在运营过程中会出来问题.那么所有的非维持性(这就是规范化的工作)工作的起点都是为了处理问题,那么"问题"2字在企业应用中又是如何定义的.呵
呵,我不再展开了,等我有空,会给TTNN上传资料的.
作为BI系统,是IT系统中离企业管理最近的应用系统,以前有句极端的IT应用系统描述:"企业就2套系统,ERP和BI",其实已经把企业活动的内容
在应用系统中体现出来了,ERP主要是支撑企业维持性工作的系统,BI系统主要是支撑企业"创新"和"改善"非维持性工作的系统.当然最近一年内ERP
和BI系统的整合,是因为现在企业的工作模式把"创新"--"改善"--"维持"3个方式整合到企业的每一个员工,这也是企业管理的发展,也
是"Kaizen"的提倡模式.所以,我曾经说了"BI作为独立概念已死"的话.
至于牛人把BI概念缩小到DW平级,形成狭义的BI概念,其实对于这个我也不反对,因为这也是IT技术人员最能把握的东西,毕竟人的经历不一样,不可能
都象我从IT技术转向业务模式研究和管理.所以对于创新也好,架构也好,我也不会以企业管理的定义去苛求他,我只希望从技术层面按照Inmon的CIF
架构和Kimball的MD架构中如何定义和描述架构的角度入手,去探求他所谓架构的本质.但实在太让我失望的是,在技术层面中探讨架构本质,居然连一
点思路都没有.
所以,你的说法是对的,在技术层面说架构,一定是实体,有严格的架构定义格式(比如拓扑图,各组成部分,目前叫"组件",各组件之间的接口定义和管理规
则,组件内的模块定义和管理方式,行业模型的位置等等).但你的朋友也说的对,不在技术层面说架构,从人的思维方式上说架构,这个架构是虚的.
至于,我提了"持续改善"BI模型,但我没有能力去全面把它搞完,我只能会把管理思路,管理视点技术,模型的组成部分有一个总体说明,希望各位TTNN
一起去完善它.
On 5月13日, 下午1时44分, Qing <happys...@gmail.com> wrote:
> 有个朋友一直喜欢在msn上跟我讨论，不大愿意在ttnn发帖子。他喜欢探讨一些比较形而上的问题，这种问题有时候说说确实挺有意思的，比如这次，他关于这次争-论谈了自己的想法后，转到另一个话题----什么是架构？
>
> 其实，关于这个话题，在两年前的五月，就曾经有一个这样一个话题，架构之谈。http://groups.google.com/group/ttnn/browse_thread/thread/84d2b22e7c54...
>
> 那是跟非bi界的一位架构高手babituo探讨架构的问题，所以谈的比较玄乎。最后得出的结论是，我们对这个概念的认识还是存在差异，谈不下去。昨天在msn-上的探讨也差不多如此，对于"架构"这个术语，也许就是每个人心中有个想法，就像大家对什么是BI的理解一样。也许没有必要去纠正大家对这个概念的理解，虽然如-果有一个统一的说法，他是什么不是什么，能够有利于交流。但除非是存在一个几乎是公认的说法才行，目前，没有。
>
> 昨天这位朋友认为架构是一种虚的，是人们对问题的根本认识的本能反应。这句话说的让人很晕，我不理解他说的这个架构。举了例子，mvc、soa是架构。这让人容-易理解一点，有例子当然好理解，但例子并不能给出一个定义，因为一个实例里面总是包含了虚的东西和实的东西。比如soa，可以说本后有一种思想，存在一种服务接-口，以及对服务接口的查找机制。这是虚的，而实的，就是这套机制的实现，也就是具体的接口标准，如何查找的实现。soa这个术语包含了这两层意思。我更倾向于架-构是一种实的的东西，他是一种对机制（虚的）的实现。那位朋友不认同，不过没关系，不需要统一思想。
>
> 我之所以宁愿认为架构是实的，有理由。我们身处的是it界，架构这个词也是多在it里面谈论得多（也许这是从建筑业里面借鉴过来的吧，但保险在网上搜这个词都是-it界的条目居多）。it是一种手段，思想很重要，价值很高，但既然在it里面说事，就是实实在在地从一种认识转换成为一种可以运作的支撑手段。比如你可以用本-体论的思想来认识这个世界，但落到it，就可以是一种oo的语言。语言比思想实在。
>
> 对于innovate提出的混合架构。想支撑10年的变化，采用低耦合的分层方法，这是理所当然的。不论是dw的架构还是其他事务系统的架构，都希望如此。关键-是如何。这还是在谈架构的目的和原则，下一步，如果能够将架构背后的机制，以及如何实现都谈一些。
>
> 为什么在这次讨论中，innovate觉得interstage咄咄逼人呢，因为你是架构的提出者，得允许别人的质疑甚至讥讽，不如抛开这些，去深入探讨更深层-次的东西。现在interstage已经提出他的持续改善bi模型了，到时候你就是进攻方，你也尽可以去讥讽他，哈哈。
>
> 2008/5/13 life2008life <life2008l...@126.com>:
>
> - 显示引用的文字 -
善思路来做,简直就是望文生意,太虚了,真的让他展开,什么都不会,技术也是,管理思路也是,而且态度和心态极其敏感),而我们中国企业体现管理文化的
组织架构(呵呵,又是"架构"2字,所以架构很重要,它就是整体的核心提炼部分)才从亲"亲"模式逐步转向层科式的管理模式,而"持续改善"逐渐让企业
从层科式的管理模式走向了扁平式的管理模式. 所以经过30年发展和实践已经非常成熟,当然它还在修整,也有可能在未来修整中,创新出新的理论被取代.
所以目前的中国企业中全范围导入很难.
在企业管理中,与"改善"相对应的是什么?是"创新"(呵呵,忍不住再说那个牛人,牛人以为在企业应用中,创新可以随便说,随便起一个名字,随便总结几
个项目经验,就可以叫创新.然后又是架构,又是创新,真太神奇了),"改善"指的是把工作标准微幅渐进的改良;"创新"指的是经由技术设备投资,达成的
工作标准重大的改良.因此在企业管理中,对"改善"和"创新"有明确的定义.那么改善也好,创新也好,对于企业来讲为什么要采用这2种工作方式,因为企
业在运营过程中会出来问题.那么所有的非维持性(这就是规范化的工作)工作的起点都是为了处理问题,那么"问题"2字在企业应用中又是如何定义的.呵
呵,我不再展开了,等我有空,会给TTNN上传资料的.
作为BI系统,是IT系统中离企业管理最近的应用系统,以前有句极端的IT应用系统描述:"企业就2套系统,ERP和BI",其实已经把企业活动的内容
在应用系统中体现出来了,ERP主要是支撑企业维持性工作的系统,BI系统主要是支撑企业"创新"和"改善"非维持性工作的系统.当然最近一年内ERP
和BI系统的整合,是因为现在企业的工作模式把"创新"--"改善"--"维持"3个方式整合到企业的每一个员工,这也是企业管理的发展,也
是"Kaizen"的提倡模式.所以,我曾经说了"BI作为独立概念已死"的话.
至于牛人把BI概念缩小到DW平级,形成狭义的BI概念,其实对于这个我也不反对,因为这也是IT技术人员最能把握的东西,毕竟人的经历不一样,不可能
都象我从IT技术转向业务模式研究和管理.所以对于创新也好,架构也好,我也不会以企业管理的定义去苛求他,我只希望从技术层面按照Inmon的CIF
架构和Kimball的MD架构中如何定义和描述架构的角度入手,去探求他所谓架构的本质.但实在太让我失望的是,在技术层面中探讨架构本质,居然连一
点思路都没有.
所以,你的说法是对的,在技术层面说架构,一定是实体,有严格的架构定义格式(比如拓扑图,各组成部分,目前叫"组件",各组件之间的接口定义和管理规
则,组件内的模块定义和管理方式,行业模型的位置等等).但你的朋友也说的对,不在技术层面说架构,从人的思维方式上说架构,这个架构是虚的.
至于,我提了"持续改善"BI模型,但我没有能力去全面把它搞完,我只能会把管理思路,管理视点技术,模型的组成部分有一个总体说明,希望各位TTNN
一起去完善它.
On 5月13日, 下午1时44分, Qing <happys...@gmail.com> wrote:
> 有个朋友一直喜欢在msn上跟我讨论，不大愿意在ttnn发帖子。他喜欢探讨一些比较形而上的问题，这种问题有时候说说确实挺有意思的，比如这次，他关于这次争-论谈了自己的想法后，转到另一个话题----什么是架构？
>
> 他不愿意在这里谈，我觉得可能的原因是低调，或者是懒得写上一段，但肯定不去想。（嘿嘿，你肯定能够看得到）既然如此，我来整理一些他的想法。
>
> 对这次争论，他认为innovate的一直没有搞明白面对的问题，对于interstage的持续改善，他认为这在中国是难以执行的，因为不好汇报，不好出成绩-。恐怕正是因此而开始探讨"什么是架构"的问题。通常，这种问题没有答案，也许权威的说法能够让人不假思索地接受，但我们这里没有权威，所以都可以互相挑战的。
> 他不愿意在这里谈，我觉得可能的原因是低调，或者是懒得写上一段，但肯定不去想。（嘿嘿，你肯定能够看得到）既然如此，我来整理一些他的想法。
>
>
> 其实，关于这个话题，在两年前的五月，就曾经有一个这样一个话题，架构之谈。http://groups.google.com/group/ttnn/browse_thread/thread/84d2b22e7c54...
>
> 那是跟非bi界的一位架构高手babituo探讨架构的问题，所以谈的比较玄乎。最后得出的结论是，我们对这个概念的认识还是存在差异，谈不下去。昨天在msn-上的探讨也差不多如此，对于"架构"这个术语，也许就是每个人心中有个想法，就像大家对什么是BI的理解一样。也许没有必要去纠正大家对这个概念的理解，虽然如-果有一个统一的说法，他是什么不是什么，能够有利于交流。但除非是存在一个几乎是公认的说法才行，目前，没有。
>
> 昨天这位朋友认为架构是一种虚的，是人们对问题的根本认识的本能反应。这句话说的让人很晕，我不理解他说的这个架构。举了例子，mvc、soa是架构。这让人容-易理解一点，有例子当然好理解，但例子并不能给出一个定义，因为一个实例里面总是包含了虚的东西和实的东西。比如soa，可以说本后有一种思想，存在一种服务接-口，以及对服务接口的查找机制。这是虚的，而实的，就是这套机制的实现，也就是具体的接口标准，如何查找的实现。soa这个术语包含了这两层意思。我更倾向于架-构是一种实的的东西，他是一种对机制（虚的）的实现。那位朋友不认同，不过没关系，不需要统一思想。
>
> 我之所以宁愿认为架构是实的，有理由。我们身处的是it界，架构这个词也是多在it里面谈论得多（也许这是从建筑业里面借鉴过来的吧，但保险在网上搜这个词都是-it界的条目居多）。it是一种手段，思想很重要，价值很高，但既然在it里面说事，就是实实在在地从一种认识转换成为一种可以运作的支撑手段。比如你可以用本-体论的思想来认识这个世界，但落到it，就可以是一种oo的语言。语言比思想实在。
>
> 对于innovate提出的混合架构。想支撑10年的变化，采用低耦合的分层方法，这是理所当然的。不论是dw的架构还是其他事务系统的架构，都希望如此。关键-是如何。这还是在谈架构的目的和原则，下一步，如果能够将架构背后的机制，以及如何实现都谈一些。
>
> 为什么在这次讨论中，innovate觉得interstage咄咄逼人呢，因为你是架构的提出者，得允许别人的质疑甚至讥讽，不如抛开这些，去深入探讨更深层-次的东西。现在interstage已经提出他的持续改善bi模型了，到时候你就是进攻方，你也尽可以去讥讽他，哈哈。
>
> 2008/5/13 life2008life <life2008l...@126.com>:
>
>
>
> > 嘿嘿,还真别说;我还真觉得你这个"牛比行动"是大势所趋;下面可以展开一个新的话题
> > ...- 隐藏被引用文字 -
>
>
> > 嘿嘿,还真别说;我还真觉得你这个"牛比行动"是大势所趋;下面可以展开一个新的话题
>
> - 显示引用的文字 -
Solo Zhu
May 13, 2008, 4:11:37 AM5/13/08
to ttnn BI 观点
事实越辩越清，真理越辩越明
构架本没有固定的框架，没有那种理论行或者不行，大家都是讨论，实用性来自于你的态度。
不需要去攻击别人。就此打住
> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
构架本没有固定的框架，没有那种理论行或者不行，大家都是讨论，实用性来自于你的态度。
不需要去攻击别人。就此打住
>
> - 显示引用的文字 -
interstage
May 13, 2008, 4:29:48 AM5/13/08
to ttnn BI 观点
你在说什么，我没在攻击他,我在质疑他的架构,连这个权利都没有,不能质疑,那如何实现你所说的" 事实越辩越清，真理越辩越明",哈哈,太幽默了.
OK,不质疑他的架构了,反正每个人都有权利提架构.我不是也开始启动了牛比架构计划了,得到了全球各国政府各国人民的支持,在伟大的"XXX"思想指
引下,我的牛比架构必将为全球人民造福利. 以后他搞他的混合架构,我搞我的牛比架构.禁止质疑.
OK,不质疑他的架构了,反正每个人都有权利提架构.我不是也开始启动了牛比架构计划了,得到了全球各国政府各国人民的支持,在伟大的"XXX"思想指
引下,我的牛比架构必将为全球人民造福利. 以后他搞他的混合架构,我搞我的牛比架构.禁止质疑.
innovate511
May 13, 2008, 6:22:56 AM5/13/08
to ttnn BI 观点
按照Qing的意思，我可以对任何我觉得有问题的帖子而去刻薄挖苦和讥讽了？如果这样的话，那好，我从明天开始，你们就见不到客观我的了，对任何帖子，
我都可以提出主观的臆断和质疑，而且可能还不太靠边，让你们见识下"疯狂状态下的我"。
既然这是TTNN的默认规则，那就可以对任何人都有用了，除非那天规则改了。
架构状态下的抽象特点并不是不可以谈，只是不能细节到如何针对一个实际案例具体建模而已，方法可以抽象出来。
对于BI持续改善思想，我何时表示不认同了，请找出我的原帖。我能理解QING在这些方面判断会有所偏差，毕竟现在也搞偏业务分析，但也不能学某些人一
样臆断事实，何况你在第一个帖子总结的地方就说，我赞同他的观点，但和架构不矛盾。
架构的讨论我早就提到过了，这次也不是第一次，只是这次是在以前基础上有新的体会和看法。难道要搞DW架构，和BI持续改善就水火不容，非要一个对另一
个错么？如果某些人认为这样，那可不代表我的观点，我多次提到过，这是不同的细分领域，是相辅相成的，难道Qing这位大资深人员也不理解我说的这个意
思？
我们这里没有权威，世界上也没有绝对的权威，难道我们非得照搬Inmon or Kimball的东西才是真正的技术，融汇贯通或者有自己的实践理解，
就是不被认同而成为攻击的对象？某些人多次提到攻击我是因为我提出第三种架构思想，于是觉得我在挑战权威，自己树立权威。这是我提出的么？这是10年就
开始应用，现在广泛应用的技术架构，难道他们没有完全照别人的架构理论去做，就得不到业界的认可，非得照搬权威？
来TTNN这么久，第一次感觉莫名其妙。明明是人身攻击，居然被群主说成正常的质疑和挑战，那好，我经常挑战下，符合我们TTNN的精神。
> 有个朋友一直喜欢在msn上跟我讨论，不大愿意在ttnn发帖子。他喜欢探讨一些比较形而上的问题，这种问题有时候说说确实挺有意思的，比如这次，他关于这次争-论谈了自己的想法后，转到另一个话题----什么是架构？
我都可以提出主观的臆断和质疑，而且可能还不太靠边，让你们见识下"疯狂状态下的我"。
既然这是TTNN的默认规则，那就可以对任何人都有用了，除非那天规则改了。
架构状态下的抽象特点并不是不可以谈，只是不能细节到如何针对一个实际案例具体建模而已，方法可以抽象出来。
对于BI持续改善思想，我何时表示不认同了，请找出我的原帖。我能理解QING在这些方面判断会有所偏差，毕竟现在也搞偏业务分析，但也不能学某些人一
样臆断事实，何况你在第一个帖子总结的地方就说，我赞同他的观点，但和架构不矛盾。
架构的讨论我早就提到过了，这次也不是第一次，只是这次是在以前基础上有新的体会和看法。难道要搞DW架构，和BI持续改善就水火不容，非要一个对另一
个错么？如果某些人认为这样，那可不代表我的观点，我多次提到过，这是不同的细分领域，是相辅相成的，难道Qing这位大资深人员也不理解我说的这个意
思？
我们这里没有权威，世界上也没有绝对的权威，难道我们非得照搬Inmon or Kimball的东西才是真正的技术，融汇贯通或者有自己的实践理解，
就是不被认同而成为攻击的对象？某些人多次提到攻击我是因为我提出第三种架构思想，于是觉得我在挑战权威，自己树立权威。这是我提出的么？这是10年就
开始应用，现在广泛应用的技术架构，难道他们没有完全照别人的架构理论去做，就得不到业界的认可，非得照搬权威？
来TTNN这么久，第一次感觉莫名其妙。明明是人身攻击，居然被群主说成正常的质疑和挑战，那好，我经常挑战下，符合我们TTNN的精神。
> 有个朋友一直喜欢在msn上跟我讨论，不大愿意在ttnn发帖子。他喜欢探讨一些比较形而上的问题，这种问题有时候说说确实挺有意思的，比如这次，他关于这次争-论谈了自己的想法后，转到另一个话题----什么是架构？
>
> 他不愿意在这里谈，我觉得可能的原因是低调，或者是懒得写上一段，但肯定不去想。（嘿嘿，你肯定能够看得到）既然如此，我来整理一些他的想法。
>
> 对这次争论，他认为innovate的一直没有搞明白面对的问题，对于interstage的持续改善，他认为这在中国是难以执行的，因为不好汇报，不好出成绩-。恐怕正是因此而开始探讨"什么是架构"的问题。通常，这种问题没有答案，也许权威的说法能够让人不假思索地接受，但我们这里没有权威，所以都可以互相挑战的。
> 他不愿意在这里谈，我觉得可能的原因是低调，或者是懒得写上一段，但肯定不去想。（嘿嘿，你肯定能够看得到）既然如此，我来整理一些他的想法。
>
innovate511
May 13, 2008, 6:35:51 AM5/13/08
to ttnn BI 观点
没法深入下去，每一个帖子都会有人身攻击和非技术性讥讽，请问如何一步一步深入下去？
最典型愚蠢的问题就是，什么你的架构不符合企业标准，遇到鬼了，这个不符合企业标准，咋那么多企业在用，其中还有多个500强企业以及TTNN也有人在
琢磨这种架构变迁呢？那是一种主观臆断。
什么我提出的观点不符合Inmon或Kimball的权威，这是打击的理由么？那这样的话，任何套不上权威半点的论点，我们都可以去打击。这种学术风气
还能行么？
这种主观的“质疑和挑战”太多了，请问这些问题从技术上怎么回答？Qing可以告诉我么？
某些人的观点是"ＤＷ项目实施的问题永远是纬度和粒度的矛盾，这就是经典矛盾总结了．不用这么复杂写１，２出来"，意思是大家以后不用思考架构和模型
了，经典都出来了，还讨论啥？说这句话也不怕笑掉大牙，不知道说这句的话人实践的DW项目生命周期有几年？自己设计的DW项目生命周期如何？维度是可以
无限制变化下去，定义和结构层次也可以无限制变化下去，粒度有的时候需要高，有的时候需要低粒度，高低之间也在无限制变化下去。在数据仓库不同阶段的存
储和管理非常有讲究。一看这种言论就是本本思想，靠看书获得点皮毛就觉得掌握真理了。
我早说过，回答问题是正常的事，我回答了很多人的质疑和疑问，而且孜孜不倦，详细到直到对方理解，从不高傲拒绝。攻击行为的话，就请外行靠边站，看人家
是怎么讨论问题的。
最典型愚蠢的问题就是，什么你的架构不符合企业标准，遇到鬼了，这个不符合企业标准，咋那么多企业在用，其中还有多个500强企业以及TTNN也有人在
琢磨这种架构变迁呢？那是一种主观臆断。
什么我提出的观点不符合Inmon或Kimball的权威，这是打击的理由么？那这样的话，任何套不上权威半点的论点，我们都可以去打击。这种学术风气
还能行么？
这种主观的“质疑和挑战”太多了，请问这些问题从技术上怎么回答？Qing可以告诉我么？
某些人的观点是"ＤＷ项目实施的问题永远是纬度和粒度的矛盾，这就是经典矛盾总结了．不用这么复杂写１，２出来"，意思是大家以后不用思考架构和模型
了，经典都出来了，还讨论啥？说这句话也不怕笑掉大牙，不知道说这句的话人实践的DW项目生命周期有几年？自己设计的DW项目生命周期如何？维度是可以
无限制变化下去，定义和结构层次也可以无限制变化下去，粒度有的时候需要高，有的时候需要低粒度，高低之间也在无限制变化下去。在数据仓库不同阶段的存
储和管理非常有讲究。一看这种言论就是本本思想，靠看书获得点皮毛就觉得掌握真理了。
我早说过，回答问题是正常的事，我回答了很多人的质疑和疑问，而且孜孜不倦，详细到直到对方理解，从不高傲拒绝。攻击行为的话，就请外行靠边站，看人家
是怎么讨论问题的。
innovate511
May 13, 2008, 7:31:59 AM5/13/08
to ttnn BI 观点
你见过每帖必追着你挖苦讽刺，并且你不理他，他也会像蚊子一样跟在帖子后面的讨论方式么？告诉你，这在TTNN算正常质疑和挑战，至少某个回帖这么说
的。
的。
interstage
May 13, 2008, 7:54:52 AM5/13/08
to ttnn BI 观点
不是已经告诉你了,各国政府基于我的牛比架构的DW项目生命周期是300年,你为什么还在问我实施过DW项目的生命周期.
哦,不好意思,你的混合架构才10年呀,看来还是要加强研究和创新,别气寐,离300年也就290年,不远了.
>
> - 显示引用的文字 -
interstage
May 13, 2008, 8:56:48 AM5/13/08
to ttnn BI 观点
哎,看来你的确有点激动,有点语无论次了,请整理思路,其实对你的质疑就2点:
1,DW架构的创新与BI持续改善没矛盾,只不过你提了基于DW混合架构(因为那时候已经说2大师的架构生命周期有问题)的BI项目生命周期很长,其他
架构的BI项目生命周期,
哪怕目前是成功的,未来也不成功,基于你虚拟化架构的混合架构一定能支持10年的生命周期. 而且你举的建筑的例子(呵呵,其实现代建筑生命周期的长短
已经和架构没多大
关系,是其他原因造成的)实在不怎么样,所以我很质疑你的DW架构能带给企业BI项目的生命周期,当时并没有质疑你的DW架构
2,对你DW架构开始的质疑,是请教你的结果,既然叫架构了,你可以去参考一下2大师是如何定义架构的描述格式的(当然不一定完全一样),你的架构和2
大师的架构有无本质
的区别在我眼里并不重要(因为你一直没有详细文档,我没研究过你的混合架构,所以无法对你架构本身提出质疑).所以我请你描述一下你的架构,要从几方面
去描述
1,是什么,就是定义本身;2,是什么样子,就是拓扑图;3,是什么组成的,就是组件(当然也可以叫"构件");4,之间是如何通讯的(是如何定义接口
的,如何实现松耦合管理的);5,组
件本身是定义和模块组成,以及通讯(就是如何在组件内实现紧耦合管理的).这是最基本系统化学习技术的方法,所以技术定义的时候,基本上也是按照这个来
定义的.但是让我
失望的时,你真的答非所问,所以,目前你的混合架构还是没详细展现给大家.导致我们非常质疑你的那个东西究竟是架构,还是就一实施经验.
至于,其他什么持续改善BI模型与对你架构的质疑无关,只是回答TTNN对"持续改善"的问题. 还有那个牛比架构,的确有点讥讽你的混合架构的意思,
但主要是你一直没有展开
你的混合架构所至. 越到这时候越是要冷静,我和你又没什么实际过节,而且你我未来的方向也不一样(你走的是DW技术方向,我走的是业务管理方向,只不
过BI是联系技术和
业务的IT实现而已),构成不了什么权威之争.开始静下心来,好好描述一下你的混合架构,不要再空谈,虚谈那些名字了(松偶合,紧偶合,虚拟架
构,SOA等等),别空谈生命周期了.
其实,你只要在架构详细描述上展开,TTNN的高手们自然会理解和研究出来,对架构本身的生命周期也会有合理的判断.
1,DW架构的创新与BI持续改善没矛盾,只不过你提了基于DW混合架构(因为那时候已经说2大师的架构生命周期有问题)的BI项目生命周期很长,其他
架构的BI项目生命周期,
哪怕目前是成功的,未来也不成功,基于你虚拟化架构的混合架构一定能支持10年的生命周期. 而且你举的建筑的例子(呵呵,其实现代建筑生命周期的长短
已经和架构没多大
关系,是其他原因造成的)实在不怎么样,所以我很质疑你的DW架构能带给企业BI项目的生命周期,当时并没有质疑你的DW架构
2,对你DW架构开始的质疑,是请教你的结果,既然叫架构了,你可以去参考一下2大师是如何定义架构的描述格式的(当然不一定完全一样),你的架构和2
大师的架构有无本质
的区别在我眼里并不重要(因为你一直没有详细文档,我没研究过你的混合架构,所以无法对你架构本身提出质疑).所以我请你描述一下你的架构,要从几方面
去描述
1,是什么,就是定义本身;2,是什么样子,就是拓扑图;3,是什么组成的,就是组件(当然也可以叫"构件");4,之间是如何通讯的(是如何定义接口
的,如何实现松耦合管理的);5,组
件本身是定义和模块组成,以及通讯(就是如何在组件内实现紧耦合管理的).这是最基本系统化学习技术的方法,所以技术定义的时候,基本上也是按照这个来
定义的.但是让我
失望的时,你真的答非所问,所以,目前你的混合架构还是没详细展现给大家.导致我们非常质疑你的那个东西究竟是架构,还是就一实施经验.
至于,其他什么持续改善BI模型与对你架构的质疑无关,只是回答TTNN对"持续改善"的问题. 还有那个牛比架构,的确有点讥讽你的混合架构的意思,
但主要是你一直没有展开
你的混合架构所至. 越到这时候越是要冷静,我和你又没什么实际过节,而且你我未来的方向也不一样(你走的是DW技术方向,我走的是业务管理方向,只不
过BI是联系技术和
业务的IT实现而已),构成不了什么权威之争.开始静下心来,好好描述一下你的混合架构,不要再空谈,虚谈那些名字了(松偶合,紧偶合,虚拟架
构,SOA等等),别空谈生命周期了.
其实,你只要在架构详细描述上展开,TTNN的高手们自然会理解和研究出来,对架构本身的生命周期也会有合理的判断.
Qing
May 13, 2008, 9:44:48 PM5/13/08
to tt...@googlegroups.com
挖苦和讥讽谁挨上都很厌恶，但这完全是个人的风格态度问题，我想你也有你的风格，如果你能够转换成"疯狂状态下的我"，也是挺有趣的，但我想对你并不太容易。
你认为ttnn有什么默认规则呢？就是让每个人爱咋说就咋说，每个人为自己的言论负责。
刚看到你另一篇关于混合架构的起源，挺好的。我想你恐怕还真的做不到"疯狂状态"。唉，一个人呐，本我总是被超我压制，没办法。
2008/5/13 innovate511 <innov...@gmail.com>:
按照Qing的意思，我可以对任何我觉得有问题的帖子而去刻薄挖苦和讥讽了？如果这样的话，那好，我从明天开始，你们就见不到客观我的了，对任何帖子，我都可以提出主观的臆断和质疑，而且可能还不太靠边，让你们见识下"疯狂状态下的我"。
既然这是TTNN的默认规则，那就可以对任何人都有用了，除非那天规则改了。
...
innovate511
May 13, 2008, 10:58:24 PM5/13/08
to ttnn BI 观点
从05年（好像是05年底）首次加入TTNN讨论BIDW，感觉这里氛围不错，各种观点都有，不管是成熟的、不成熟的、直接的技术思想，还是间接的思维
方式，百花齐放。
那个时候没有谁在针对一个人不断追着挖苦和讥讽，而是就事论事，对于不了解的则问清事物的原委，对于貌似见过，却又不完全那么一回事，那就会问清楚细
节，看看和自己理解的是否有不同。良好的讨论氛围吸引了很多有识之士参加，成为业界有名的思想碰撞场所。
现在倒好，先不问细节，直接说你这玩艺不就是想自己创造一个架构，能超越经典么，牛什么牛，你那论点早就有提过，有啥意思。其实连发这个帖的本质目的都
没搞清楚就开始挖苦讽刺，TTNN是交流BIDW思想的场所，不是显摆的场所，如果某些人这么看，自然是只允许自己发表新的体会，别人的体会不去追问细
节，而是从自己粗浅的理论知识去直接挖苦和讥讽。
我也多次提到过，TTNN没有另外两人会这样，因为只有我在1、2年前的一个帖子中“得罪”了某人，于是这1、2年中在我的帖子中多以挖苦讽刺为主，并
未多问其细节和原由。如果长达近2年之久的这种状态，谁还能安心讨论下去，我真是佩服，这种人可以去修道成仙了。在屡次挖苦讽刺别人的时候，也要考虑到
不要超过别人的极限，别人不是不会反击，至今某些人的观点里我并非去回任何帖，更没让人不爽的挖苦讽刺帖，但某些人认为这是我的风格，是我的懦弱，居然
忍受1、2年了。
貌似我一直在自己的讨论领域发表自己的观点，并未在自己不感兴趣的地方发言，虽然很多言论我不赞成或者觉得还比较肤浅，但我尊重别人的思想意识，每一个
总结都得来不易，强行遏制是对业界的不好。
有鉴于此，我不再TTNN忍受任何挖苦和讥讽，所以也不再主动发帖成为所谓的“中心”，去接受所谓的“质疑和挑战”。这次我想让某些人也感受一下，按照
Qing的意思，我就是挨挖苦讽刺的料，因为我的风格如此。
挖苦讽刺非我之本意，多听广言，扬长避短才是中庸之道。只是既然这里放任如此，那何必拘泥于什么风格、态度呢？我的观点会继续发表其他论坛或群，我的观
点只需要质问、提问和讨论，不需要挖苦和讽刺。
方式，百花齐放。
那个时候没有谁在针对一个人不断追着挖苦和讥讽，而是就事论事，对于不了解的则问清事物的原委，对于貌似见过，却又不完全那么一回事，那就会问清楚细
节，看看和自己理解的是否有不同。良好的讨论氛围吸引了很多有识之士参加，成为业界有名的思想碰撞场所。
现在倒好，先不问细节，直接说你这玩艺不就是想自己创造一个架构，能超越经典么，牛什么牛，你那论点早就有提过，有啥意思。其实连发这个帖的本质目的都
没搞清楚就开始挖苦讽刺，TTNN是交流BIDW思想的场所，不是显摆的场所，如果某些人这么看，自然是只允许自己发表新的体会，别人的体会不去追问细
节，而是从自己粗浅的理论知识去直接挖苦和讥讽。
我也多次提到过，TTNN没有另外两人会这样，因为只有我在1、2年前的一个帖子中“得罪”了某人，于是这1、2年中在我的帖子中多以挖苦讽刺为主，并
未多问其细节和原由。如果长达近2年之久的这种状态，谁还能安心讨论下去，我真是佩服，这种人可以去修道成仙了。在屡次挖苦讽刺别人的时候，也要考虑到
不要超过别人的极限，别人不是不会反击，至今某些人的观点里我并非去回任何帖，更没让人不爽的挖苦讽刺帖，但某些人认为这是我的风格，是我的懦弱，居然
忍受1、2年了。
貌似我一直在自己的讨论领域发表自己的观点，并未在自己不感兴趣的地方发言，虽然很多言论我不赞成或者觉得还比较肤浅，但我尊重别人的思想意识，每一个
总结都得来不易，强行遏制是对业界的不好。
有鉴于此，我不再TTNN忍受任何挖苦和讥讽，所以也不再主动发帖成为所谓的“中心”，去接受所谓的“质疑和挑战”。这次我想让某些人也感受一下，按照
Qing的意思，我就是挨挖苦讽刺的料，因为我的风格如此。
挖苦讽刺非我之本意，多听广言，扬长避短才是中庸之道。只是既然这里放任如此，那何必拘泥于什么风格、态度呢？我的观点会继续发表其他论坛或群，我的观
点只需要质问、提问和讨论，不需要挖苦和讽刺。
interstage
May 14, 2008, 12:15:51 AM5/14/08
to ttnn BI 观点
看了你的申述,我感觉你很惨和很无辜,我一定让interstage向你道歉.但据他说,好象不是这样的,他加入TTNN是去年5月11日,在
ITPUB和你论战是去年4月份,谈不上你得罪他或者他不得罪你.只是他说你在DW技术上有一些项目经验,但每次在TTNN讲DW都是盛气凌人,唯我独
尊的样子,别人都说你经验是丰富的,但说话口气也是一副牛比的样子,而且对DW一副"技术至上"论的样子,让人很不舒服. 我已经指责他,不管你的做人
风格如何,是你的事情,不管他什么事情. 但他也说,对于谦虚的人,他说话很谦虚,对于越牛比的人,他说话就是充满幽默的讥讽式的方式,这也是他的风
格.
看来你们2人之间都太有自己的特点了,我已经在劝他对牛比的人宽容点.,但不知道你改还是他改.
> > 刚看到你另一篇关于混合架构的起源，挺好的。我想你恐怕还真的做不到"疯狂状态"。唉，一个人呐，本我总是被超我压制，没办法。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
ITPUB和你论战是去年4月份,谈不上你得罪他或者他不得罪你.只是他说你在DW技术上有一些项目经验,但每次在TTNN讲DW都是盛气凌人,唯我独
尊的样子,别人都说你经验是丰富的,但说话口气也是一副牛比的样子,而且对DW一副"技术至上"论的样子,让人很不舒服. 我已经指责他,不管你的做人
风格如何,是你的事情,不管他什么事情. 但他也说,对于谦虚的人,他说话很谦虚,对于越牛比的人,他说话就是充满幽默的讥讽式的方式,这也是他的风
格.
看来你们2人之间都太有自己的特点了,我已经在劝他对牛比的人宽容点.,但不知道你改还是他改.
>
> - 显示引用的文字 -
Qing
May 14, 2008, 1:45:07 AM5/14/08
to tt...@googlegroups.com
嘿嘿，刚才再另外一帖问了cdw的问题，算是紧扣主题。这个话题，已经跟技术关系不大，所以不喜欢看口水战的，可以不用看下去。
如果从论战技巧来看，innovate显然不如interstage，所以你吃亏是必然的，没办法，你要看看interstage是干啥的，已经不是当年那个厨师，不看菜谱看兵法了。估计也是整天跟人忽悠。innovate主攻技术，我想即便肚子里面有很多东西，也一时没倒出来。这点上，还是得相信innovate，因为他在这个领域天天说dw架构，已经说了这么多年，肯定是有货的。
本文，我想就两人的乱战技巧说说，挺有意思。
先说对于观点陈述，俩人一个说dw架构，说了三四年，一个说持续改善，说了一年多，但没见下文。从这点看，基本是棋逢对手。
在回应对方批评上，innovate比较冲动，容易上当，不停被记录。一旦批评到某个点，就做出反驳，但反驳的理由有时候还是比较不太完备。常用的理由是：
1、我有很多经验，是有大公司实践的；
2、你那个东西也不行；
3、其他大师、经典理论是这么说的；
而interstage比较阴险，他的讽刺挖苦还是比较厉害，我觉得他确实有些过分，不过这是他的事，我也管不着。对于观点的批评，他通常不会正面回应去直接为自己辩护。虽然也经常经验、实践、经历来证明，但这种情况不算多。他喜欢找innovate观点的漏洞，然后揪住不放，死磕。这点比较歹毒，因为innovate不是那种喜欢认输的人，便在有些被激怒的情况下，继续维护自己的观点。如此正中stage下怀，有后招等呢。这些招数大多还是有点逻辑性（但也很多没有逻辑性），或者有一些看起来能让很多人信服的理由来批判，比如个人经历，管理的角度（虽然这些很大可能根本不能证明什么）。
看来在论战技巧上，innovate还是得向interstage学习。但这是技巧问题，其实本身，大家都敢坚信自己的观点是对的吗？为什么那样坚定地维护自己的观点呢？大家探讨问题，无非还是为了分享和完善自己的观点。
其实这种探讨还真是难得。你说我的不对，为什么不对？什么逻辑证明？如果还真的有点符合逻辑，对观点的细化大有好处。如果真的是毫无逻辑地瞎抬杠，ttnn的人也不是瞎子，这人可能也会被人鄙视致死。
innovate511
May 14, 2008, 2:49:19 AM5/14/08
to ttnn BI 观点
我搞了多年技术, BI应用虽然也有经验, 但重点在DW技术上, 而且8年光阴全在项目实践中, 不像有的人读了很多书, 基础经验还不足就搞管理练
习嘴皮子去了, 还在帖子里说可以教人家做人, 连网络做人都不会, 现实生活中不是溜须拍马就是向上级或客户献媚之人.
至于论战技巧, 说实话我没时间去转弯抹角, Qing可以看看我的重点是说技术本身, 他的重点是挖苦人, 其技术上连半灌水都谈不上, 他多年都没
摸技术, 居然说出"没吃过猪肉, 见过猪"的笑话, 如果那样, 是个BIDW的人,熟读经典学习产品就可以了, 不用实践了.
Qing说的棋逢对手, 其实这个说法很偏颇, 我谈论DW从没想过要和谁的某某东西争高低, 是有人故意在我的帖子里捣乱. 虽然我不去捣乱人家,
去在1年多时间屡次受人恶意攻击, 一让再让, 忍耐已经达到了极限, 但人家却认为我就这性格, 没种反击.
就拿某些人说的态度, 我无论对谁的提问都有耐心地解答, 如果说我高高在上的感觉, 那可能是某些人个人感觉.难道作为一名资深人员, 每推出一个有
成功案例的项目或技术体验和新观点, 得态度卑微地向大家询问, 我这样是否可以, 是否可行, 这样才能让某人接受, 他就胜利了?
如果做人太过分, 欺人太甚, 脾气再好的人也会动怒. 我如果要动怒, 就不是简单的挖苦和讥讽了, 可能会很难听, 1年多忍耐爆发出来, 咱走着
瞧.
本来在这1年多时间里, 我在某帖子得罪某人后, 在各个帖子虽然受到攻击, 但一直在忍让, 想他会有收敛的时候, 但却越来越过分.
任何思想在开始之处只能介绍和粗略讲解, 然后再详细向下讨论. 我之所谓想请TTNN大家来协调一下, 就是为了防止大家在争吵中脱离了讨论的本质东
西, 一直闹下去也讨论不出什么东西来, 对TTNN的发展很不利. 而只有心平气和讨论, 才能各个方面都深入.
在这里发帖本来就很花时间总结, 还花时间回帖, 结果一天上来就应付别人的挖苦和讥讽, 以为我平时很闲啊.
既然某些人不让我的体验和经验在TTNN深入讨论下去, 那某些人的东西恐怕也很难深入讨论下去了.
On 5月14日, 下午1时45分, Qing <happys...@gmail.com> wrote:
> 嘿嘿，刚才再另外一帖问了cdw的问题，算是紧扣主题。这个话题，已经跟技术关系不大，所以不喜欢看口水战的，可以不用看下去。
>
> 如果从论战技巧来看，innovate显然不如interstage，所以你吃亏是必然的，没办法，你要看看interstage是干啥的，已经不是当年那个厨-师，不看菜谱看兵法了。估计也是整天跟人忽悠。innovate主攻技术，我想即便肚子里面有很多东西，也一时没倒出来。这点上，还是得相信innovate，-因为他在这个领域天天说dw架构，已经说了这么多年，肯定是有货的。
>
> 看来在论战技巧上，innovate还是得向interstage学习。但这是技巧问题，其实本身，大家都敢坚信自己的观点是对的吗？为什么那样坚定地维护自己-的观点呢？大家探讨问题，无非还是为了分享和完善自己的观点。
>
> 其实这种探讨还真是难得。你说我的不对，为什么不对？什么逻辑证明？如果还真的有点符合逻辑，对观点的细化大有好处。如果真的是毫无逻辑地瞎抬杠，ttnn的人-也不是瞎子，这人可能也会被人鄙视致死。
>
> 2008/5/14 interstage <buer0...@gmail.com>:
>
>
>
> > 看了你的申述,我感觉你很惨和很无辜,。。。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
习嘴皮子去了, 还在帖子里说可以教人家做人, 连网络做人都不会, 现实生活中不是溜须拍马就是向上级或客户献媚之人.
至于论战技巧, 说实话我没时间去转弯抹角, Qing可以看看我的重点是说技术本身, 他的重点是挖苦人, 其技术上连半灌水都谈不上, 他多年都没
摸技术, 居然说出"没吃过猪肉, 见过猪"的笑话, 如果那样, 是个BIDW的人,熟读经典学习产品就可以了, 不用实践了.
Qing说的棋逢对手, 其实这个说法很偏颇, 我谈论DW从没想过要和谁的某某东西争高低, 是有人故意在我的帖子里捣乱. 虽然我不去捣乱人家,
去在1年多时间屡次受人恶意攻击, 一让再让, 忍耐已经达到了极限, 但人家却认为我就这性格, 没种反击.
就拿某些人说的态度, 我无论对谁的提问都有耐心地解答, 如果说我高高在上的感觉, 那可能是某些人个人感觉.难道作为一名资深人员, 每推出一个有
成功案例的项目或技术体验和新观点, 得态度卑微地向大家询问, 我这样是否可以, 是否可行, 这样才能让某人接受, 他就胜利了?
如果做人太过分, 欺人太甚, 脾气再好的人也会动怒. 我如果要动怒, 就不是简单的挖苦和讥讽了, 可能会很难听, 1年多忍耐爆发出来, 咱走着
瞧.
本来在这1年多时间里, 我在某帖子得罪某人后, 在各个帖子虽然受到攻击, 但一直在忍让, 想他会有收敛的时候, 但却越来越过分.
任何思想在开始之处只能介绍和粗略讲解, 然后再详细向下讨论. 我之所谓想请TTNN大家来协调一下, 就是为了防止大家在争吵中脱离了讨论的本质东
西, 一直闹下去也讨论不出什么东西来, 对TTNN的发展很不利. 而只有心平气和讨论, 才能各个方面都深入.
在这里发帖本来就很花时间总结, 还花时间回帖, 结果一天上来就应付别人的挖苦和讥讽, 以为我平时很闲啊.
既然某些人不让我的体验和经验在TTNN深入讨论下去, 那某些人的东西恐怕也很难深入讨论下去了.
On 5月14日, 下午1时45分, Qing <happys...@gmail.com> wrote:
> 嘿嘿，刚才再另外一帖问了cdw的问题，算是紧扣主题。这个话题，已经跟技术关系不大，所以不喜欢看口水战的，可以不用看下去。
>
>
> 本文，我想就两人的乱战技巧说说，挺有意思。
>
> 先说对于观点陈述，俩人一个说dw架构，说了三四年，一个说持续改善，说了一年多，但没见下文。从这点看，基本是棋逢对手。
>
> 在回应对方批评上，innovate比较冲动，容易上当，不停被记录。一旦批评到某个点，就做出反驳，但反驳的理由有时候还是比较不太完备。常用的理由是：
> 1、我有很多经验，是有大公司实践的；
> 2、你那个东西也不行；
> 3、其他大师、经典理论是这么说的；
>
> 而interstage比较阴险，他的讽刺挖苦还是比较厉害，我觉得他确实有些过分，不过这是他的事，我也管不着。对于观点的批评，他通常不会正面回应去直接为-自己辩护。虽然也经常经验、实践、经历来证明，但这种情况不算多。他喜欢找innovate观点的漏洞，然后揪住不放，死磕。这点比较歹毒，因为innovat-e不是那种喜欢认输的人，便在有些被激怒的情况下，继续维护自己的观点。如此正中stage下怀，有后招等呢。这些招数大多还是有点逻辑性（但也很多没有逻辑性-），或者有一些看起来能让很多人信服的理由来批判，比如个人经历，管理的角度（虽然这些很大可能根本不能证明什么）。
> 本文，我想就两人的乱战技巧说说，挺有意思。
>
> 先说对于观点陈述，俩人一个说dw架构，说了三四年，一个说持续改善，说了一年多，但没见下文。从这点看，基本是棋逢对手。
>
> 在回应对方批评上，innovate比较冲动，容易上当，不停被记录。一旦批评到某个点，就做出反驳，但反驳的理由有时候还是比较不太完备。常用的理由是：
> 1、我有很多经验，是有大公司实践的；
> 2、你那个东西也不行；
> 3、其他大师、经典理论是这么说的；
>
>
> 看来在论战技巧上，innovate还是得向interstage学习。但这是技巧问题，其实本身，大家都敢坚信自己的观点是对的吗？为什么那样坚定地维护自己-的观点呢？大家探讨问题，无非还是为了分享和完善自己的观点。
>
> 其实这种探讨还真是难得。你说我的不对，为什么不对？什么逻辑证明？如果还真的有点符合逻辑，对观点的细化大有好处。如果真的是毫无逻辑地瞎抬杠，ttnn的人-也不是瞎子，这人可能也会被人鄙视致死。
>
> 2008/5/14 interstage <buer0...@gmail.com>:
>
>
>
> > 看了你的申述,我感觉你很惨和很无辜,。。。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
interstage
May 14, 2008, 4:29:16 AM5/14/08
to ttnn BI 观点
呵呵，有点意思．谈谈忽悠，其实我在做开发人员，支持人员时候是从不＂忽悠＂，但技术系统化的学习能力不强，只能是在单点上（主要是自己经历的事情）比
较深刻，当我开始会＂忽悠＂的时候，是开始做技术咨询的时候，主要是把技术发展性和功能性以及项目实施的经验＂忽悠＂给甲方技术人员，让他选择我们，并
实施它，那时候技术系统性学习能力强了．能开始做项目销售的时候，主要是把项目带来的价值＂忽悠＂给甲方管理者，接着继续把技术发展性和功能性以及项目
实施的经验＂忽悠＂甲方技术人员，这样技术和管理的系统性能力加强了；现在做的是业务运营的管理者，是＂忽悠＂下面的人按照统一的工作方式去完成业务运
营过程中的问题． 所以，这是我的＂忽悠＂史，深刻检讨，我准备明天开始放弃这个职业，从基本开发人员做起，不再＂忽悠＂了．
>
> - 显示引用的文字 -
较深刻，当我开始会＂忽悠＂的时候，是开始做技术咨询的时候，主要是把技术发展性和功能性以及项目实施的经验＂忽悠＂给甲方技术人员，让他选择我们，并
实施它，那时候技术系统性学习能力强了．能开始做项目销售的时候，主要是把项目带来的价值＂忽悠＂给甲方管理者，接着继续把技术发展性和功能性以及项目
实施的经验＂忽悠＂甲方技术人员，这样技术和管理的系统性能力加强了；现在做的是业务运营的管理者，是＂忽悠＂下面的人按照统一的工作方式去完成业务运
营过程中的问题． 所以，这是我的＂忽悠＂史，深刻检讨，我准备明天开始放弃这个职业，从基本开发人员做起，不再＂忽悠＂了．
> 嘿嘿，刚才再另外一帖问了cdw的问题，算是紧扣主题。这个话题，已经跟技术关系不大，所以不喜欢看口水战的，可以不用看下去。
>
> 如果从论战技巧来看，innovate显然不如interstage，所以你吃亏是必然的，没办法，你要看看interstage是干啥的，已经不是当年那个厨-师，不看菜谱看兵法了。估计也是整天跟人忽悠。innovate主攻技术，我想即便肚子里面有很多东西，也一时没倒出来。这点上，还是得相信innovate，-因为他在这个领域天天说dw架构，已经说了这么多年，肯定是有货的。
>
>
> 本文，我想就两人的乱战技巧说说，挺有意思。
>
> 先说对于观点陈述，俩人一个说dw架构，说了三四年，一个说持续改善，说了一年多，但没见下文。从这点看，基本是棋逢对手。
>
> 在回应对方批评上，innovate比较冲动，容易上当，不停被记录。一旦批评到某个点，就做出反驳，但反驳的理由有时候还是比较不太完备。常用的理由是：
> 1、我有很多经验，是有大公司实践的；
> 2、你那个东西也不行；
> 3、其他大师、经典理论是这么说的；
>
> 本文，我想就两人的乱战技巧说说，挺有意思。
>
> 先说对于观点陈述，俩人一个说dw架构，说了三四年，一个说持续改善，说了一年多，但没见下文。从这点看，基本是棋逢对手。
>
> 在回应对方批评上，innovate比较冲动，容易上当，不停被记录。一旦批评到某个点，就做出反驳，但反驳的理由有时候还是比较不太完备。常用的理由是：
> 1、我有很多经验，是有大公司实践的；
> 2、你那个东西也不行；
> 3、其他大师、经典理论是这么说的；
>
> 而interstage比较阴险，他的讽刺挖苦还是比较厉害，我觉得他确实有些过分，不过这是他的事，我也管不着。对于观点的批评，他通常不会正面回应去直接为-自己辩护。虽然也经常经验、实践、经历来证明，但这种情况不算多。他喜欢找innovate观点的漏洞，然后揪住不放，死磕。这点比较歹毒，因为innovat-e不是那种喜欢认输的人，便在有些被激怒的情况下，继续维护自己的观点。如此正中stage下怀，有后招等呢。这些招数大多还是有点逻辑性（但也很多没有逻辑性-），或者有一些看起来能让很多人信服的理由来批判，比如个人经历，管理的角度（虽然这些很大可能根本不能证明什么）。
>
> 看来在论战技巧上，innovate还是得向interstage学习。但这是技巧问题，其实本身，大家都敢坚信自己的观点是对的吗？为什么那样坚定地维护自己-的观点呢？大家探讨问题，无非还是为了分享和完善自己的观点。
>
> 其实这种探讨还真是难得。你说我的不对，为什么不对？什么逻辑证明？如果还真的有点符合逻辑，对观点的细化大有好处。如果真的是毫无逻辑地瞎抬杠，ttnn的人-也不是瞎子，这人可能也会被人鄙视致死。
>
> 2008/5/14 interstage <buer0...@gmail.com>:
>
>
>
> > 看了你的申述,我感觉你很惨和很无辜,。。。- 隐藏被引用文字 -
>
> 看来在论战技巧上，innovate还是得向interstage学习。但这是技巧问题，其实本身，大家都敢坚信自己的观点是对的吗？为什么那样坚定地维护自己-的观点呢？大家探讨问题，无非还是为了分享和完善自己的观点。
>
> 其实这种探讨还真是难得。你说我的不对，为什么不对？什么逻辑证明？如果还真的有点符合逻辑，对观点的细化大有好处。如果真的是毫无逻辑地瞎抬杠，ttnn的人-也不是瞎子，这人可能也会被人鄙视致死。
>
> 2008/5/14 interstage <buer0...@gmail.com>:
>
>
>
>
> - 显示引用的文字 -
hunter
May 18, 2008, 3:58:34 AM5/18/08
to ttnn BI 观点
看见晕鸡蛋（云计算），问个无关问题。。不好意思，以前Qing对BI的中文昵称是什么来着？
> > - 显示引用的文字 -- Hide quoted text -
袁旭
May 18, 2008, 8:50:06 PM5/18/08
to tt...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages