主题：【原创】谈一谈企业架构（序） -- zhutou
原来经常在英文论坛里混。现在看到企业架构这个不算新的概念在中国大有风起云涌之势，本人不妨也开个铺头卖一些经验。目前有下列更新计划：
企业架构队伍设置及规则责任（rules and responsibilities)
怎样推动企业架构的落实（落地问题）
架构仓库（architecture repository）的集成与意义，架构工具的选择
TOGAF的实用性
企业架构在国外的发展与其国内前景的思考
架构在铺陈时的一些常见问题
企业架构队伍设置与责任
架构是一种平衡的艺术——某架构师
一般来说，企业架构很不幸的不属于直接贡献价值的队伍。IT在大多数公司本身就算是后台，在后台部门中做一个不直接贡献价值的队伍（相对于开发测试等），真是不幸中的不幸了。当然，本身企业架构是否应该从属于IT还是一个未完话题，这一点我会在之后的国外EA发展中阐述。
作为一个不幸中的不幸，怎样存活？寄望于CIO的重视或者领导团队对于当前“潮流”的追随，当然可以苟活一阵，然而长期来说，一个没有价值的队伍在充分竞争的环境中是难以生存的。从另一个方面来说，合格的架构师们一般都属于精英阶层，收入和素质往往相对其它队伍更高，这也进一步要求作为架构队伍的主架构师或者架构总监能够将队伍的价值通过适当的设置充分体现出来。
一个比较常见的错误就是望文生义，比如只在架构队伍中设置若干企业架构师，而不设置相应的业务架构师或者解决方案架构师。这种设置，由于企业机构师的特殊性，往往会导致“象牙塔”的情况。即架构师们专注于自己创造的完美前景，而缺乏与外界包括业务部门和IT部门的互动，更不用说怎样让自己的愿景落地并在一些项目中实现了。笔者曾经提供咨询服务的一家澳洲银行就有这样的情况。项目经理和成员当时形容企业架构师们坐在云端（sitting in the cloud)，难以触及也无法提供方向。这样的队伍当然难以提供价值。
另外一个极端则是项目架构权力过大，缺乏企业公司级别的统筹和规划。体现在设置上，就是项目架构师（很多情况下甚至是项目经理）负责选型和方案决定，造成孤岛或者重复建设。这可以说是目前国内甚至亚洲大部分企业的现实情况，也是企业架构在国内推行的主要动力之一。笔者目前供职的公司，在若干年前进行IT队伍大整合前，就是这样的情况。类似的一个客户关系管理能力（功能），两三个业务部门都通过不同的项目上了不同的系统。同样的一种文档管理系统（Data Management System DMS）需求，整个公司有超过5种不同实现。这就是典型的缺乏统筹的后果。
怎样避免走向以上的极端，而达到平衡呢？
首先需要能够在企业（enterprise）和项目（project or programme）之间取得平衡。这就要求架构队伍必须能够在企业和解决方案之间建立联系，即需要有对应的企业架构师与解决方案架构师。需要注意的是，这里的解决方案架构师并非所谓技术专家，而更应该是架构队伍派往项目中的大使。对他们的要求其实是异常复杂的，因为他们必须要有企业级的视野，同时兼具对项目细节的触觉。企业架构师则相应的可以将更多的精力投入到研究与趋势考虑中。例如企业集成架构师（Enterprise Integration Architect）可以更多的参加SOA国际会议，了解主要提供商的发展方向。企业信息架构师（Enterprise Information Architect）则可以对现有企业中的信息进行分类和建模，并与企业安全架构师（Enterprise Security Architect）一起对各类的信息制定安全规范和设计条例。
其次是要能够在业务和IT之间取得平衡。这要求一些架构师们可以把业务的长期远景（Vision）与IT的发展方向联系起来。这些架构师需要能够与业务部门交流和联系，并根据自己对于IT发展方向的预测和了解，帮助业务部门制定发展蓝图和纲要（Blueprint and Roadmap）。这些架构师就是业务架构师（Business Domain Architect）。从严格意义上来说，这些架构师也属于企业架构师，但是他们的兴趣如上所述与企业架构师略有不同。他们以自己对业务的深刻了解，为企业架构师提供业务知识，以确保企业架构师的研究方向与公司的业务发展方向一致。他们也从企业架构师的研究中取得成果和营养，帮助自己制定蓝图和纲要。
架构队伍需要一个强力的领导。主架构师是一个极其具有挑战性的位置，它需要候选人具有超强的学习能力（否则无法与整个公司的业务发展和新技术潮流同步），过人的沟通交流能力（很多架构方向需要CIO乃至CEO批准，同时架构的实现需要与项目经理或者开发主管交流，有些架构设计会有限制无法照顾所有人的需求），令人信服的领导能力（大多数架构师是经验丰富的专业人士，有时会难以推动和管理），当然最重要的，还要有极深的IT背景和经验（否则无法对很多问题或者方向作第一时间的判断）。这些要求几乎不可能完全被达到。然而相应的，一个出色的主架构师，能够为整个公司带来清晰和可计算的价值，并且能够显著的被管理层发现和欣赏。一个出色的主架构师，很多情况下都会出身于好的咨询公司，或者可以从成熟的架构队伍中提拔。
TOGAF提供了一些架构队伍设置的参考方案。以上则是我根据个人经验提供的建议，供大家（尤其是国内思考新设立架构队伍的企业）参考
我目前发现最好用的其实是twitter
如果有Gartner用户的话，Gartner也不错
iCMG的网站原来不错，现在参加讨论的人貌似少了
Linkedin的一些群组也有用
想真正按TOGAF全套或者多数套路玩下来，前提条件很多，包括稳定明晰的业务战略与路线图，强势CIO与架构师团队，自有系统开发力量或灵活的项目管理，明确的业务需求等等。很多时候必须按照客观条件，利用EA或者TOGAF的几个有用概念和方法为实际工作服务一下。
个人感觉，目前国内万人以下非IT密集型企业，搞EA没那个资源。数万人以上的集团企业，确拿不出足够的灵活性和协调力。
想起写一些东西，也是为了尽量跟清晰的说明EA的意义和作用。个人感觉，目前国内最缺乏的还是对EA有足够了解，在技术和执行力上都有能量的主架构师更是凤毛麟角。
希望多交流。
企业架构的落地与实现
SA是EA的大使，无法通过项目实现的EA不是合格的EA——某架构师
上一篇说到架构队伍的组成和责任。据笔者目前的观察，很多的企业，尤其是国内的大型企业，经过前两年的预热和一些IT企业的推广，已经对于EA有了很大的兴趣和热情。一些和国外公司有密切交往的大型企业（例如航空业），更是由于目睹了国外公司对于EA的应用和从中得到的好处，而迫不及待的希望尽快推动自己的架构建设。这无疑是一件好事，尤其对于笔者这样目前还在国外的从业人员来说。
然而不幸的是，如同TOGAF或者FEA这样的框架结构，对于企业实际应用来讲用处相当有限。TOGAF 9可以说是目前为止最接近于实际应用的框架（这也是其受欢迎的原因）——可是TOGAF 9仍然远远达不到拿来即用（plug and play）并马上生效的水平。这造成了很多努力推动企业架构的企业，尤其是CIO的困扰：明明已经投入了资源，明明自己的架构师们接受了培训甚至通过了认证，明明已经请了咨询公司（IBM，Mckinsey，Cap Gemini etc）做了远景规划甚至于路线图，为什么总是看不到架构带来的好处？为什么信息孤岛情况得不到改善？为什么规划和路线图无法在项目中实现？
这就要说回到企业架构的落地问题。架构最为一个高屋建瓴的部门，需要有强有力的执行力和交流能力，同时也需要和IT以及业务的其他部门密切配合，以期能够将架构目标真正实现。同时架构作为一个提供监管（governance）的部门，很多时候也会与具体项目产生兴趣上的冲突。解决不了这些问题，就无法保证架构的真正实现。
笔者认为，以下一些因素能够推动企业架构的落地：
CXO的支持。这个听上去有些官僚的因素却是最重要的，以下提到的一些其他因素如果没有CXO级别的支持都是纸上谈兵。必须要指出，这里所说的支持，并非泛泛的资源上的支持。在企业架构规划的初期，在机构、人员和实现框架都不成熟的情况下，CXO必须要卷起袖子与主架构师一起担当起推动企业架构的任务。这里说的CXO，在大多数的企业中都应该是CIO。在一些企业特别巨大，企业关系特别复杂的情况下（如国内很多超大型企业）甚至可以是COO。
主架构师需要与CXO密切合作，清晰有条理的向CXO说明企业架构的方向、愿景和路线图，务必要使CXO有深刻的了解。CXO需要在项目委员会（project committee）中，确保不符合企业架构的项目无法立项或者无法获得资金。如果这是一个业务部门迫切需要的项目，CXO需要要求架构部门提前参与可行性研究，以确保架构要求能够尽早体现。
项目经理必须理解架构的重要性。重大的项目设计决定必须有解决方案架构师的签署，否则没有效用。
与业务部门的交流（business engagement）。在很多企业的IT部门中都有专门与业务部门进行交流的队伍（business analysis or portfolio）。他们的主要任务就是在项目前期分析业务部门提出的各项需求，寻找其中潜在的可以合并或者同时进行的需求。这样的队伍有时候也会存在于业务部门中。架构部门需要与这支队伍建立联系，在项目初期通过业务架构师(之前介绍过的business domain architect）对其施加影响。业务架构师也应该经常性的向这支队伍介绍业务领域架构方向。
项目架构设计和监管。项目架构设计是一项必须的工作，很多企业都有不同的部门在执行这项职责。也有一些企业是依靠IT服务公司或者外包公司进行设计。必须要指出，项目的架构设计是极其重要的。一个关键项目的架构设计方向错误，也许就定义了企业今后10年的架构方向。笔者个人非常反对让外部人员决定甚至参与项目架构设计。解决方案架构师应该基于项目架构路线图设计项目架构。即使项目架构设计正确无误，如果开发队伍无法理解架构设计，或者由于开发时间或者其他一些实际问题而无视架构设计，一样会造成灾难性的后果。解决方案架构师必须能够在整个项目的生命周期中起到关键作用。在大型和关键项目中，可以成立由解决方案架构师领衔，开发和测试队伍参加的项目设计委员会（Project architecture board），处理开发队伍的问题和分析需求更改的影响。
将正确和错误的设计实体化，使得架构能够成为“有形的”（tangible)。一个可以应用的概念是“企业债务”（enterprise debt）。这种债务不是我们平时理解的经济金融债务，而是由于不正确的架构设计或者短视的决定而造成的长期在IT或者业务流程方面造成的浪费和重复建设。企业债务概念一般需要基于某种数学模型。它不可能非常精确，但是可以用一种直观的方式向重要决策者（stakeholders）解释某些架构决定的背景。例如，一个很多架构队伍希望的架构原理是重用先于购买先于自建（reuse>COTS>build）。如果有一个重大项目，业务部门利用业务需求复杂作为理由，要求进行自建或者大规模客户化，则可以利用这个模型尝试计算长期维护费用（如可以以20年为核心系统生命周期计算人力成本）。如果某些重要决策者一定要推行自建方案，则需要同意并且签署计算出的企业债金额。这在一定程度上也帮助了CIO将来的工作。
累了，歇一会……………
希望学术味咨询味淡点，与国内外企业实际更紧密些，行文少点术语，多点例子，可能可以创造点机会。
再说一点体会，关于架构队伍在企业信息化的定位。
个人认为，一个完善的企业IT部门，应该由四部分组成：
1、架构办公室，对应于一般企业的办公室、规划计划部门和政策研究部门。负责需求信息的汇总分析，整体IT架构的设计与更新，项目架构的审核，支持CIO和信息化领导小组（委员会）进行架构和项目审批，作为与业务部门高层次交流的统一窗口。
2、项目经理部，对项目经理进行统一管理，排出人员作为IT项目的甲方经理。
3、技术运维中心，对应于一般企业的生产运行部门。负责机房、网络和IT系统的技术运维、优化和一定程度的开发修改工作。
4、服务支持中心，对应于一般企业的销售、客服部门。为业务部门提供一般性IT服务，并进行问题和需求收集，向技术运维中心和架构办公室反映。
各部分的负责人，应有四个部门的轮岗工作经验。同时，应选定一套术语体系，根据公司特色进行完善，作为各部分间交流和与业务部门交流的标准。
挺好的分析文章，就是在海外也是很实用的说。
如果有比较接近您贴子的E文，给个链接请。不过这些E文的也很多，就是平时对这个兴趣缺缺，再有就是自动鹰说的，都是干巴巴的学术气息很重的行文，如果能像闲总那样加点八卦说实例，肯定就好看多了。
企业架构更多还是指的internal IT，而不是Commercial IT,这个特点也决定企业架构们着眼点是跟着公司整体经济效益转的，比如你提到的减少Silo这个问题。这就不得不提到，EA与企业架构并不是一个新事物，当然规范化，产业化是近年出现的。IT的中心化与去中心化始终是随着技术本身的进步与发展而此消彼涨，可以说是逻旋式上升。
比如PC时代带来的去中心化是随着Wintel平台开发的快速高效而出现的，相对于的是主机时代，那个时候企业级别的架构不开玩笑的说，也就数据库还免强有人信，唯一被IT牢牢掌控的是data center这些网络硬体等“粗活”，业务部门用户那时候最喜欢的是自己组建自己队伍，三五条枪，掌着低价的wintel优势，许多需求自己就办了，少了IT衙门，效率还高，但缺点是Silo的出现，从整个公司看就是重复投资，万国牌系统以及没有整合的资源，外加基础设施的维护这些“粗活”没人干，还得回头去求IT。
这几年IT中心化又开始抬头，理由总是很好找，除了上面这几条，很大的原因是互联网，外包，造不如买，这些IT业的变化需要在整个公司的层面上整合资源以获取在新的IT经营模式下的利益最大化。比如ERP等的上马就是典型的这个资源整合的思维模式下的产物，这些思潮的源头是SAP，IBM等这些主机时代的遗老遗少们，靠着他们过人的公关与在大公司中的影响力。
而互联网的出现，导致的数据中心化（类似主机），轻终端的计算模式，本来是顺应互联网远程用户使用的需求，但这个架构被一些反wintel的有心人过分鼓吹，另一个被有意利用误导的是病毒，浏览器轻终端于是被标榜为万用钥匙，所有的IT架构与整合接口都向其过度。这个架构虽然类似于主机时代，推动了IT资源的中心化，对靠从大企业中挣顾问费的IBM们是个好事，对于CIO们拿funding也是好事，在多个修饰过的企业架构理论的光环下，IT部门似乎迎来了春天，但是一个付带的现象是，这种架构一是受互联网的技术发展影响很大（比如SOAP vs JSON），外面世界很精彩，企业内部很黑暗，而且还身不由己，因为在造不如买的影响下，用户眼中的IT除了不能造出象样的产品外，似乎就是整天靠企业架构来要钱，这个企业架构倒底是个什么东西。二是云计算的兴起，这个可是不折不扣的仿主机模式了，不是中心化么，干脆也别设IT部门了，都中心到公共云里去得了，这下子可是要了IT的命根子，为什么？云这个事不是个换个基础设施的问题，虽说这也会要了一批IT部门的命，但更重要的是上面说过的技术架构上的变化，公司内部那些企业架构，根本与云的架构不是一回事，区别与男人跟女人区别差不多，私有云？也还是差不多。除非有厂商推出为企业量身订做的私有云，不过就是做出来，也不是企业IT能用的了的，这种真需要IBM这个级别厂商的时候，IBM反倒很腼腆了。言而总之，下面几年是企业IT抓瞎的几年，但也会是个英雄倍出的年代。
中国如果现在开始推广企业架构，可能是在步美国的后尘，还不如直接接管IT外包业，利用这个云雨一番的难得机会，把印度拿下，接管美国财富500的IT部门，到时IT在手中，都不需要买下整个公司，想要什么没有。我以前在河里写个相关的贴子，云是出现对于外包业来说，是让印度人英语优势荡然无存的一个机会。
企业架构容易写的干巴巴。实例多了容易暴露目标