Resource of EA

javaeye上介绍Enterprise Architecture, IT Goverance的好像比较少，在网上找到个不错的东东， http://www.opengroup.org/architecture/togaf8-doc/arch/ ，感兴趣的可以去看看。

象这种EA methology/Framework在国外还有好几种，这个东西可能比较适合企业IT管理者。在IT Governance里面从某种层面上可能会划分成为IT Strategy, IT Architecture and IT Delivery。 好像国内的企业包括我们大部分从业者基本上只是做着IT Delivery的工作，不知道有没把IT Architecture做得好点的。


(btw:标题输入英文好像有字数限制，不知道是不是Bug)

还有人记得林星么？
恩恩，还有一蓑烟雨任平生

应该还有charon吧？

如果企业中IT部门作为一个有支撑企业运作的战略性部门,并且企业本身的管理已经相当成熟,可能实施这类东西会有一定意义.
但是,国内企业里面好像满足这个条件的基本没有,那些本身属于广义IT的企业比如电信之类的可能好一些,但几乎所有核心业务与IT无关的企业,IT部门的战略性地位基本还没有确立起来,只是一个工具,以及支撑服务部门.
我们这儿曾经实施过所谓的信息资源规划,有点TOGAF的意思(但相对弱和窄一些),但是很不成功(虽然有极大量的业务相关文档产生).主要有两个原因,一个是本身方法论上的缺陷,以及没有合适的工具,即便花大力气理清了(实际上不可能理清)现有的业务流程并作出了合理的优化,确立了数据标准,理顺了各个现有系统及之间的关系以及它们对业务的支撑作用,如果没有合适的工具,那也只能是个瞬态的东西,要在日常的业务变更/机构调整/系统升级过程中维护这个庞然大物,显然是不可能完成的任务,毕竟不会像项目进行中那样保持一个强大的资源后备.

另一个原因是本质的,想要理清企业范围内的各个业务流程,即便只是关键业务流程,没有相关部门人员的主动化大力气配合,是不可能的.但是,这么做对他们的收益是什么?理清业务流程对信息部门的收益是显然的,但是对业务部门,他们的收益几乎是0,因为毕竟只是在理,而不是做具体的东西(除非能够在理清之后作出切实的优化,但从我的经验来看,除了能够优化跨部门的一些接口之外,别的基本不可能),在这种情况下,人家配合你1次2次(每次1-2小时)是可能的,但再往下,基本上不可操作,或者说,这个行为是实质上是信息部门的技术驱动的,而非业务部门的业务驱动的,是事倍功半的,成功的概率太小了....

也许成熟到哪一天,信息部门比业务部门对业务有更加全面和细致的了解,那才有可能. 这种情况只有在各业务系统逐步覆盖主要业务流程,并且各业务操作规范化,不允许有系统外循环,也就是一个管理和IT应用非常成熟的企业中才会出现. 目前国内绝大部分企业的管理水平远达不到这一点(我们这儿IT的成熟度应该是很高了,但是管理的成熟度差太多了,体外循环很多不说,有时候为了某些目的,会临时性的做大量非常规动作,导致系统瞬态和实际业务运作有一个较大的时间差,这个时候,系统数据的可信度都有问题).

还有internal control的问题，IT系统本来应该加强内部监控，但如果信息部门全照着业务部门说的来搞不定会出多少后门。Charon说'信息部门比业务部门对业务有更加全面和细致的了解'，实在是很难。所以国外很多CIO有财务背景，熟悉内部审计。

得盼到国内企业资源全球化，销售全球话，没有IT就活不了的一天才行。不过到那个时候我们的技术管理水平跟不上，可能整个EA就只有外包给国外的技术或咨询公司了。

另外，EA is not one-time project，Charon，你们的IT建设后来以及现在又怎么样了呢？

我们是愿意选择外包的,但是这个行业里面很难找到合适的外包对象,只能说是我们自己来培养自己的外包目标了(作为长期战略伙伴).合作方的技术力量相对容易满足(实际上也很难),但是对业务的理解能力和真正从客户角度开发项目的能力(很多乙方处于短平快目的而作的事情，后来都被证明比慢还慢),10个里面找不到一个合适的，只能慢慢培养.
对于国外的公司,也不报乐观.


实质上企业的信息化包括每一个独立启动的项目都是一个过程,有它自己的生命周期.对于我来说,更关注的是它的可维护性,或者说维护这个项目的人力.
项目在开发期和实施期会有足够的人力物力资源保障,但到了维护期,如果没有合适的办法,有些东西会很快烂掉.或者像被钓鱼一样,年复一年的升级(我们这儿就有这类项目),而且被迫锁定在特定开发商.
EA其实也差不多,只要花了足够的力气和采用一定的方法,我不怀疑基础设施的建立的可行性,但是我非常怀疑他的可维护性,或者说维护这样一个东西的人力成本太高.但收益却不明确(相对于不上ＥＡ但采用一些简单直观的方式).　就拿我们做过的IRP来说，理清楚企业范围内的各系统的各类基础表＼应用表以及之间的关系，各个系统过程的流转和接口，产生的文档就以千页计．在业务变化或者系统改造过程中从这些文档中找到受影响的部分并做同步修改，如果只动用一个人来做(实际上是半个人)，那简直是不可能完成的任务.这是一个相对重型的方法论．等SOA或类似的东西成熟以后，系统间的接口和集成从数据层面上升到应用层面(这个时候才能谈得上分治)，可能会有轻型的方法论出来.


现在我们的整个组织机构，所有业务流程，包括我们IT部门，正在暴力重组中.
hehe,现在只是维持各系统运作，等机制理顺了再说

厄....什么意思?

林星同志现在搞什么呢,
以前看过他的一个网站,很不错的,
后来就消逝了.