企业架构实施简介

IT不仅是开展业务的手段，而且正在迅速演变为业务，IT绩效会直接影响企业的盈利能力，但很多企业并没有适时或充分的让IT组织参与业务的规划和决策过程，没有给予在规划和IT决策过程中考虑的安全性、可扩展性、集成问题等IT问题足够的重视。

复杂性驱动改变





传统的应用集成方式存在诸多弊端，仅仅依靠在两个数据库中传递数据或者相互之间调用接口的模式很难解决企业的整体集成问题。无论是在理论上或是实际中，这样的集成方式注定意味着项目的失败。

仅仅从技术角度去思考集成系统只能是说是技术实现手段，但要真正发挥 IT 的价值，技术人员必须从技术架构视角提升到业务架构视角，从企业架构规划开始考虑 IT 和架构的融合，不仅解决集成问题，更能能从根本上改善 IT 带来的价值。

企业架构是承接企业业务战略规划与信息化建设之间的桥梁，是企业信息化的核心。企业架构中 97%是业务，3%是 IT 技术，那么企业架构到底是由哪几部分组成的呢？现在又有哪些企业架构方法？我们又应该选择哪个企业架构方法？选择之后又该具体如何去做呢？

下面我简要说明一下企业架构实施落地的几个步骤。

企业架构理念和知识工具的导入

IT系统如果不能满足商业需求，那将是大大的浪费，而业务过程没有相应的IT支持，效率很难提高。企业架构的目标是通过IT投资获取最大的商业价值，它是一种高层次的企业视野，聚焦与组织的IT架构和业务架构之间。

首先我们会给客户进行四天的企业架构培训，快速准确的导入企业架构理念和知识工具，让架构工作组所有人员对企业架构有一个统一的认识，保证架构工作开展前的准备工作有效。

那架构工作组需要包含哪些人呢？不同企业架构工作组成员组成可能不一样：





架构实施范围不同也会造成工作组成员的不同，例如只是对车间管理进行EA设计，那所涉及的成员和整个企业的EA设计是不一样的。

架构现状分析







如果你经常和软件系统打交道，那么你可能会发现软件开发过程中其实存在几个重要的断沟（GAP）。

1. 业务架构到技术架构的不一致

a.业务架构是一拨人做，技术架构师另一拨人做，结果做业务架构时缺少技术架构的考虑，而技术架构缺少服务于业务的意识，最终没有为业务服务。弄到最后业务架构和技术架构并不能很好的结合起来，导致还需要很多适配或反复工作。

b.还有一种情况是，业务架构做完之后扔给技术架构来实现，但是业务架构提供的东西并不全面，不能提供技术架构的输入，导致沟通效率极其低下。

2. 业务架构到业务需求的不一致

a. 有些公司虽然岗位分的清楚，但是方法并不清楚。业务架构是一套方法，需求分析是一套方法，甚至于没有方法，而是靠着个人能力去做，结果导致架构和需求交付物是独立的，业务架构的东西不能顺利转移到需求阶段

b. 还有时候一个人就负责产品的业务，架构和需求一起做，这时候没有方法的指导，其实很容易迷失在业务细节。 过早的进入业务细节对于产品来说是及其危害的，因为产品架构还未明晰时进入细节只会浪费时间导致重心偏离方向。

3. 业务架构和实现的不一致

开发产品时，开发问一句，”做这个对系统有什么价值？”结果发现需求根本无法追溯回系统的价值点上，有时连需求人员都不知道为什么做了这个功能。如果产品生命周期较长，中间换了好几拨人来做这个产品了，那么不仅是需求文档不能追溯，就是靠口头讲也讲不清。

a. 业务架构采用的是业务语言，而技术实现采用的技术语言，两者不是同一个语言，很难做到顺利过渡，还需要再一次翻译，有时候甚至在实现阶段根本不看业务架构出来的东西

b. 很少有开发人员清楚产品的业务架构，那么如何能够做出好的产品来？

其实业务架构和业务需求本身就不冲突，两者只是处在一个事物在不同层次的东西。架构关注的是更全面、概括、组织方面的东西，而需求关注的是用户关心的业务细节，业务需求是业务架构的进一步分析。但是很多企业在进行企业架构规划时，却不知道如何区分这些，导致业务人员叫苦连天。

这些差距还不是最重要的，还有更大更重要的一个差距，就是战略与IT的差距，这个可以看之前我写的一篇《企业战略和企业架构的关系？ 》

从上面说明可以看出主要问题，现实中产品开发存在的隐性问题其实还有更多并且很严重的，我也都经历过。而解决这些问题就必须做到以下几点：



1. 找到一个指导顶层架构的方法和框架

2. 结构化架构交付物才有可能把架构知识转移到架构迁移实施阶段

3. 有一个业务开发平台来集成业务架构、技术架构和开发框架





企业架构框架和方法

有很多不同类型的企业架构框架方法，因为TOGAF通用性较强，近几年发展也不错，应用也逐渐广泛， 其完整性和实用性都比较高，所以我们在咨询中使用TOGAF为客户进行架构规划。

TOGAF有一个ADM架构开发方法，它是一个可靠的、行之有效的方法，是TOGAF的关键。







虽然TOGAF9已经提供了内容框架，但框架本身并没有告诉你太多如何具体去做架构的细节，大多时候我们要借鉴已有的一些模型或者方法，例如PCF、SCOR、CBM等。具体设计方法等也需要自己去拓展学习，大家也可以去学习我们IT帮的BangEA方法，更多内容可以购买EA2020讲义。EA2020讲义中汇集了之前只会在内训课中讲到的内容，可以说是知识+实践的一个大合集。





企业架构语言

企业架构是顶层设计，所以我们不能沿用开发阶段的UML等语言来描述，也不能简单的使用Viso随便拖放一些图例，在咨询中，我们给企业导入企业架构语言ArchiMate，当然每个企业也可在此基础上扩展自己的模型。

我们以某保险公司为例，看看使用ArchiMate做出的一个分层视图：







业务开发平台

这个在咨询过程中只做建议，更多需要结合企业的开发能力而定如何实施。

过程交付物示例和简要说明

企业架构适用于大型企业，也同样试用去中小型企业，关键点不在于组织大小，而是系统是否复杂，企业是否需要敏捷，是否需要使用IT来帮助你构建企业未来的能力。

基于不同规模的企业，业务复杂度自然不一样，所以咨询过程也是都不一样的，但是一些方法和步骤还是相同的，下面我们简单来看看其中一些过程交付物和简要说明，以便对未接触过企业架构的推动者有一个初步的认识。

在企业架构预备阶段，核心之一是确定企业的范围：















在业务架构阶段的流程设计时，制定统一的流程层级和流程分类十分重要



















不要夸大IT的作用

IT信息化是帮助企业运营的，而运营执行的是战略，从这个先后顺序来看，那就是IT是在战略规划之后，而且这是由两拨不通技能要求的团队来完成。我们不能把IT太高估了，他们并不是无所不能的，我倒不是说软件企业没有这种能力，只是术业有专攻，企业不能把一个管理上的问题直接简单转换成一个IT问题来解决，否则得到的解决方案也一定是一个IT方案，而不是解决管理的方案。我认为管理问题还是通过管理的方式来解决更好些，该做企业战略咨询的还得做咨询，该自己思考业务的还得自己规划，IT相对这些来说，更向是一个战略执行的工具而已，不能本末倒置，IT工作的输出绝对不会是战略，否则容易出漏子的。 战略管理一定要由富有经验的企业战略专家团队来完成，而IT系统完成也一定需要专业的团队来完成，软件开发商不能帮你做这些事，你需要能对企业IT信息化做整体规划的人。