主题：【原创】谈一谈企业架构（序） -- zhutou

企业架构的落地与实现

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将来的工作。

累了，歇一会……………