企业架构实施简介
原文：https://zhuanlan.zhihu.com/p/22154771
IT不仅是开展业务的手段，而且正在迅速演变为业务，IT绩效会直接影响企业的盈利能力，但很多企业并没有适时或充分的让IT组织参与业务的规划和决策过程，没有给予在规划和IT决策过程中考虑的安全性、可扩展性、集成问题等IT问题足够的重视。
1. 复杂性驱动改变
传统的应用集成方式存在诸多弊端，仅仅依靠在两个数据库中传递数据或者相互之间调用接口的模式很难解决企业的整体集成问题。无论是在理论上或是实际中，这样的集成方式注定意味着项目的失败。
仅仅从技术角度去思考集成系统只能是说是技术实现手段，但要真正发挥 IT 的价值，技术人员必须从技术架构视角提升到业务架构视角，从企业架构规划开始考虑 IT 和架构的融合，不仅解决集成问题，更能能从根本上改善 IT 带来的价值。
企业架构是承接企业业务战略规划与信息化建设之间的桥梁，是企业信息化的核心。企业架构中 97%是业务，3%是 IT 技术，那么企业架构到底是由哪几部分组成的呢？现在又有哪些企业架构方法？我们又应该选择哪个企业架构方法？选择之后又该具体如何去做呢？
2. 企业架构3大实践
2.1 战略、业务、IT的不对齐
很多企业没有进行过统一的企业架构，即使有的话，也是各种架构独立存在，不能达到统一规划，加上各子业务部门自己进行信息化工作造成了企业应用竖井，导致集成性差而不能有高效的信息化，以及变更能力差而IT不能跟上业务的脚步等众多IT和业务不能对齐的问题。
如果你经常和软件系统打交道，那么你可能会发现软件开发过程中其实存在几个重要的断沟（GAP）。
- 业务架构到技术架构的不一致
- 业务架构是一拨人做，技术架构师另一拨人做，结果做业务架构时缺少技术架构的考虑，而技术架构缺少服务于业务的意识，最终没有为业务服务。弄到最后业务架构和技术架构并不能很好的结合起来，导致还需要很多适配或反复工作。
- 还有一种情况是，业务架构做完之后扔给技术架构来实现，但是业务架构提供的东西并不全面，不能提供技术架构的输入，导致沟通效率极其低下。
- 业务架构到业务需求的不一致
- 有些公司虽然岗位分的清楚，但是方法并不清楚。业务架构是一套方法，需求分析是一套方法，甚至于没有方法，而是靠着个人能力去做，结果导致架构和需求交付物是独立的，业务架构的东西不能顺利转移到需求阶段
- 还有时候一个人就负责产品的业务，架构和需求一起做，这时候没有方法的指导，其实很容易迷失在业务细节。 过早的进入业务细节对于产品来说是及其危害的，因为产品架构还未明晰时进入细节只会浪费时间导致重心偏离方向。
- 业务架构和实现的不一致
- 业务架构采用的是业务语言，而技术实现采用的技术语言，两者不是同一个语言，很难做到顺利过渡，还需要再一次翻译，有时候甚至在实现阶段根本不看业务架构出来的东西
- 很少有开发人员清楚产品的业务架构，那么如何能够做出好的产品来？
这些差距还不是最重要的，还有更大更重要的一个差距，就是战略与IT的差距。
从上面说明可以看出主要问题，现实中产品开发存在的隐性问题其实还有更多并且很严重的，我也都经历过。为了解决IT与业务对齐、业务和战略对齐问题，企业架构的导入和落地需要三个方面的支撑：
- 找到一个包含架构生命周期的管理框架
- 采用一种共同语言，结构化架构交付物
- 使用具有指导意义的企业架构设计方法
2.2 企业架构管理框架
捷创成首推联邦企业架构框架 FEAF
2.3 企业架构语言
企业架构是顶层设计，但我们也可以沿用开发阶段的UML等语言来进行高阶描述，当然每个企业也可扩展自己的模型，但要注意使用元素和粒度问题。
我们以某保险公司为例，看看使用ArchiMate做出的一个分层视图：
2.4 企业架构设计方法
大家熟知的通用企业架构框架虽然提供了内容框架，但框架本身并没有告诉你太多如何具体去做架构的细节，大多时候我们要借鉴已有的一些模型或者方法，例如PCF、SCOR、CBM等。具体设计方法等也需要自己去拓展学习，大家也可以去学习我们IT帮的BangEA。
3. 实施落地的几个步骤
下面我简要说明一下企业架构实施落地的几个步骤（每个企业情况都不一样，以下只是给出一个通用的示意步骤，仅供参考，请勿完全套用）。
3.1 理念、知识和工具的导入
有很多不同类型的企业架构框架，因为 FEAF 落地性更好，近几年发展也不错，应用也逐渐广泛， 其完整性和实用性都比较高，所以我们在咨询中也会给大家普及一下 FEAF ，作为EA工作的一个基础。
IT系统如果不能满足商业需求，那将是大大的浪费，而业务过程没有相应的IT支持，效率很难提高。企业架构的目标是通过IT投资获取最大的商业价值，它是一种高层次的企业视野，聚焦与组织的IT架构和业务架构之间。
首先捷创成咨询会给企业进行1天的EA导入课程内训，快速准确的导入企业架构理念和知识工具，让架构相关人员对企业架构有一个全局粗略的认识，保证大家对EA有个正确认识，并对此工作产生兴趣。而企业可以基于导入课程的学习之后，决定是否需要进行企业架构投资。
| 1. 企业架构概述 | 企业架构的重要性 当前IT规划的主要问题 企业架构是什么 企业架构的目的 企业架构实践成熟度 |
| 2. 架构管理框架概述 | 架构框架回顾 企业架构定义 初步认识 FEAF 了解架构开发方法CPM 了解FEAF其他模块 |
| 3. 架构建模语言概述 | 掌握视图/视角概念 了解企业架构描述语言 了解Archi工具 |
| 4. 架构设计方法概述 | 了解面向结果的设计 了解业务架构基本逻辑 |
| 5. 架构师的成长 | 认识到架构也是门管理学科 知道职业进阶路线 了解学习路径 守破离 |
3.2 企业架构内训
导入课程结束后，企业决定进行企业架构工作，则需要对架构工作组所有人员进行企业架构的系统全面学习，保证架构工作开展前的准备工作有效。捷创成咨询会与客户进行沟通，针对企业现有资源和能力确定内训课程和先后顺序，以及开展周期和时间（如果不只是纯内训，而是微咨询方式，则内训的时间一般会与后面的步骤结合在一起安排）。
3.3 建立组织，确定职责
通过导入和内训，企业已经具备了开始企业工作的基本知识。现在可以开始启动架构工作了。那架构工作需要包含哪些人呢？不同企业架构工作组成员组成可能不一样，有的企业也没有企业架构师，所以可能会看到原有企业角色承担企业架构不同工作的职责映射：
3.4 架构分析
企业架构适用于大型企业，也同样试用去中小型企业，关键点不在于组织大小，而是系统是否复杂，企业是否需要敏捷，是否需要使用IT来帮助你构建企业未来的能力。
基于不同规模的企业，业务复杂度自然不一样，所以咨询过程也是都不一样的，但是一些方法和步骤还是相同的，下面我们简单来看看其中一些过程交付物和简要说明，以便对未接触过企业架构的推动者有一个初步的认识。
在企业架构预备阶段，核心之一是确定企业的范围
以及确定各架构原则
愿景阶段需确定企业核心能力
并在核心能力上进行热点分析
以及改进分析
还需要确定绩效衡量指标
如果你们仍旧是以传统的流程架构为主，那么制定统一的流程层级和流程分类十分重要
核心是要做高阶流程分析
经过业务流程分析之后，就可以去做信息系统架构了。信息系统架构主要做实体模型以及应用组件设计。
技术架构除了部署设计之外，还有技术架构选型，之外还有一个重要的是需要进行核心技术梳理
架构完成之后，开始进入项目组合管理
到这一步，一个充分支持业务的架构才算初见雏形。
3.5 路标
架构设计工作结束后，你就可以依据架构差距生成的需求来进行未来工作包的计划，形成路标
4. 不要夸大IT的作用
IT信息化是帮助企业运营的，而运营执行的是战略，从这个先后顺序来看，那就是IT是在战略规划之后，而且这是由两拨不通技能要求的团队来完成。
我们不能把IT太高估了，他们并不是无所不能的，我倒不是说软件企业没有这种能力，只是术业有专攻，企业不能把一个管理上的问题直接简单转换成一个IT问题来解决，否则得到的解决方案也一定是一个IT方案，而不是解决管理的方案。
我认为管理问题还是通过管理的方式来解决更好些，该做企业战略咨询的还得做咨询，该自己思考业务的还得自己规划，IT相对这些来说，更向是一个战略执行的工具而已，不能本末倒置，IT工作的输出绝对不会是战略，否则容易出漏子的。 战略管理一定要由富有经验的企业战略专家团队来完成，而IT系统完成也一定需要专业的团队来完成，软件开发商不能帮你做这些事，你需要能对企业IT信息化做整体规划的人。