在《年度总结和计划：去年4个1，今年5个1》 中说过今年我准备在项目组引入一个架构方TOGAF。工业和信息化部副部长杨学山在一次内部座谈时提到：与西方发达国家比，国内的信息化建设在硬件方面已 经不相上下，在软件方面有5年的差距，在信息化管理方面有大概10年的差距，在企业架构方面则有20年的差距。而企业架构离不开我们IT技术领域的架构师 的支持，为了让更多人了解企业架构，我将会写一系列相关的blog与大家分享。本系列适合业务架构师、技术架构师或者有意做企业架构相关方面工作的人员。 本篇作为此系列的首篇blog，介绍一下企业架构以及对TOGAF进行介绍。

什么是企业

• 具有一个共同目标的组织的集合，可能是政府部门，一个完整的公司，公司部门，单一科/处，或由共同拥有权连接在一起的地理疏远的组织链
• 可能是一个“扩展的企业”，包括合作伙伴、供应商和客户

什么是架构

架构是针对某种特定目标系统的具有体系性的、普遍性的问题而提供的通用的解决方案，架构往往是对复杂形态的一种共性的体系抽象。

业务架构体系是针对企事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案，更确切的说，是基于业务导向和驱动的架构来理解、分 析、设计、构建、集成、扩展、运行和管理信息系统，比如业务架构体系认为一个信息系统必须由组织机构、业务流程、业务信息、业务功能、和业务语义等层次构 成。

复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。

在ISO/IEC 42010:20072中对架构有如下定义：

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

一个架构是系统的基本结构，它由多个组件以及它们彼此间的关系而组成，并且在一定环境和原则下进行设计和演变。具体可以参考我之前写的一篇bolg《架构 － 又一个类似与“平台”一样的词汇》。

火车工程师

火车工程师在做设计时，他不会去关心每节车厢里装的是什么，他们只需要关心这些车厢一节节连接在一起就好了，而把每节车厢中的具体事情交由相应 的责任人即可。将一节节车厢连起来就形成了一个隐式的（或抽象的）流程，好比一个灵活的流程应该有这样的能力：当一节车厢被替换成另一节车厢时不会对整列 火车造成什么影响。

车厢之间的连接的实现如同灵活的业务接口，其具体实现即是灵活的服务。

什么是企业架构

企业架构可以分为两大部分：业务架构和IT架构，大部分企业架构方法都是从IT架构发展而来的。

• 业务架构：是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容
• IT架构：指导IT投资和设计决策的IT框架，是建立企业信息系统的综合蓝图，包括数据架构、应用架构和技术架构三部分。

对比 RUP 和其他主要关注于实现的规程，企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范，及优先级划分，感觉它也是一个做企业信息化规划的方法。我认为，做工具型产品和企业级产品有个差别，那就是做企业级产品需要由工具型产品的产品型公司向咨询类的服务型公司转型。

1. 业务流程的组织逻辑(包含所有信息和技术服务，流程)和IT基础设施，反映了该公司运作模式的整合和标准化的需求 (MIT Center for Information Systems Research)
2. 概念蓝图，定义了一个组织的结构和运作。企业架构的意图是确定组织如何能够最有效的实现其当前和未来的目的 (SearchCIO.com)

企业架构如同战略规划，可以帮助企业执行业务战略规划及IT战略规划。在业务战略方面，可使用TOGAF及其架构开发方法论 （ArchitectureDevelopmentMethod/ADM）来定义企业愿景/使命，目标/目的/驱动力，组织架构，职能及角色。在IT战略 方面，TOGAF及ADM详细描述了如何定义业务架构，数据架构，应用架构，和技术架构，是IT战略规划的最佳实践指引。企业架构是承接企业业务战略与 IT战略之间的桥梁与标准接口，是企业信息化规划的核心。
源于90年代美国的企业架构框架，到目前已经衍生出多种企业架构框架，如DoDAF（美国国防部体系架构框架 The Department of Defense Architecture Framework）、TOGAF等。

为什么需要企业架构

有些人可能会问：“为什么要做要做架构，直接拿来需求就做不就行了吗？”。搭个简易狗窝不需要专门进行设计，但是建个大厦则必须经过设计阶段一 样，我想对于不复杂的东西，你怎么做我都觉得不会出什么差错，但是一旦业务复杂、规则麻烦、还涉及变革时，必须有一个清晰的架构才能保证做出来的东西是正 确的。

中国的大多数企业在进行IT投资时都会跳过企业架构这个环节而直接进入了IT项目的建设，这样就会导致重复投资、信息孤岛等必然现象。缺少规划 就会发现很多开发的功能重复，也有的功能开发完成后被打入冷宫，这里列一个简单例子：如hr系统中的HR服务台的一个功能，我填写了一个问题，但是没有回 复，估计这个功能就被打入冷宫了，这样满意度可想而知。

我觉得EA是一个业务和IT对齐的战略执行工具，一种设计、管理、沟通的工具。通过企业架构，我们可以达到：

• 企业内不同的人要对企业现状（as－is）和企业愿景（to-be)有一个整体的的理解
• 业务、信息、技术人员的共同愿景，是理解、沟通的基础
• 如果没有一个清晰的架构，就不能保证正确的决策和好的实现，EA是理解和实现企业IT建设的保障

TOGAF在国外的认知度很高，目前企业架构方法有很多，但TOGAF是最主流的，已经有超过15年的历史。不仅有80％的福布斯( Forbes)全球排名前50的公司在使用，而且支持开放、标准的SOA参考架构。目前已得到国际主流厂商的推动，德国有SAP在推动，美国IBM、 HP、SUN等公司在推动，中国在企业架构方面并不是很成熟，以前讨论多半集中在软件架构或是单独的系统架构，在02年才有一个企业架构出现。金蝶在 TOGAF 8.1成熟之后，引进9.0，因为它包含对SOA的支持，所以这个也是金蝶选择在这个时期把它导入的原因之一。金蝶加入The Open Group，希望能够提升中国企业信息系统及业务架构的水平，并率领国内软件产业参与国际标准的制定。对金蝶而言，引 进TOGAF和Open Group的SOA参考架构及治理原则，将推动金蝶集团产品，开发过程及治理的国际化与标准化。未来金蝶ERP产品EAS、BOS及金蝶中间件等产品都将 遵循TOGAF企业架构框架，架构开发方法论及SOA参考架构，以提升产品质量及全面SOA服务化。在金蝶产品获得成功后，将建议金蝶用户采Open Group的TOGAF及SOA标准。在2009年11月份上海的金蝶年度客户大会及中国管理模式杰出奖颁奖典礼中，金蝶发布了EAS 7.0新版本，这是中国第一款使用TOGAF企业架构框架规划及SOA的ERP产品。

为什么选择TOGAF

根据The Open Group的2009年调研报告，各类企业架构框架的市场占用率如下：

根据以上三个调研机构的报告，TOGAF的占有率已经超过百分之五十。

TOGAF目标

• 长期
  • 行业标准，通用的企业架构方法
  • 可单独使用或与对特别群组产品相关、特定的框架联合使用
• Version9
  • 从TOGAF8.1.1的一个演变，密切对齐业务，重组的易用性，总体架构和企业架构核心方法，可在今后几年被充实

什么是架构框架

大型公司和政府部门可以由多个企业组成，和可能开发及维护一些独立的企业架构来处理每一个企业，但是每一个企业的信息系统经常有太多共同之处， 而且使用一个共同的架构框架通常有大的，潜在的收获。例如，一个共同的框架能提供架构储藏库开发的基础，和重用模型，设计，和基线数据。

• 一个架构框架是一个工具包，可用于开发范围广泛的不同架构
• 它应该说明了信息系统设计的方法，依据一套企业连续统一体，并说明企业连续统一体如何组成一个整体
• 它应该包含了一套工具，并提供一个共同的词汇
• 它还应包括一个建议的标准和相容的产品清单，可用于实施企业连续统一体

TOGAF 是一个架构框架，简而言之，是一种协助开发、验收、运行、使用和维护架构的工具。TOGAF已被80％的Forbes 50（福布斯）的公司使用，并支持开放、标准的SOA参考架构。

TOGAF是透过300多家开放群组架构论坛会员协同努力发展的，会员包含全球的领导IT客户及厂商，和代表了架构发展的最佳实践。使用 TOGAF作为架构框架将允许被开发的架构是一致的，反映利益相关者的需要，使用最佳实践，和给予应有的目前需求和未来业务可能需要二者的考虑。
架构设计是一个技术复杂的过程，和设计异质、多厂商架构是显著地复杂。TOGAF扮演重要的角色来帮助“非神秘化”和去风险化架构开发流程。TOGAF提供加值平台，和使能使用者建立真正的基于开放系统的解决方案以处理他们的业务议题和需要。

The Open Group

The Open Group于1993年开始应客户要求制定系统架构的标准，在1995年发表The Open GroupArchitectureFramework (TOGAF) 架构框架。TOGAF的基础是美国国防部的信息管理技术架构(TechnicalArchitecturefor Information Management:TAFIM)。它是基于一个迭代(Iterative)的过程模型，支持最佳实践和一套可重用的现有架构资产。它可让您设计、评 估、并建立组织的正确架构。

TOGAF范围

强调商业目标作为架构的驱动力，并提供了一个最佳实践的储藏库，其中包括：

• TOGAF架构开发方法（ADM）：ADM是一个可靠的，行之有效的方法，以发展能够满足商务需求的企业架构，它是TOGAF的关键。
  
• TOGAF架构内容框架：提供了一个详细的架构工件模型，包括交付物、交付物的工件和架构构建块
  
  上图的中文版如下：
  
  
  上图的中文版本如下：
  
• TOGAF参考模型：提供了两个参考模型，Technical Reference Model (TRM) 和Integrated Information Infrastructure Model (III-RM)
  
  
• ADM指引和技术：提供应用ADM的一些指导（迭代、安全等）和技术（定义原则、业务场景、差距分析、迁移计划、风险管理等）
  

• 企业连续统一体：EA 专业人员和涉众的资源库，例如，模型、解决方案模式，和其他可以在企业架构实现和裁减过程中用作构建块的资产。
  
• TOGAF能力框架：一套资源、指导、模板、背景信息等等，帮助在组织中进行架构实践
  

经过上面的一些介绍，我们知道TOGAF是一个优秀的企业架构框架，剩下就是我们如何去学习和实践它了！

参考书

下载这两本书请点图片链接,口袋书下载好像有问题，重新上传了一个

1. 企业架构框架－TOGAF v0.3.pdf （适合架构师）
   
   使用TOGAF来做业务架构 – 价值驱动产品开发

   2小时初探企业架构TOGAF

   TOGAF 是一个企业业架构方法，适合复杂的、面向组织级别以上系统的架构开发方法。今年1月份刚升级到9.0版，对业务建模和可操作性上都有很大的提 高。我在这里把之前写过的一些内容集中在一起，方便大家学习。 由于TOGAF是一个比较大的体系，想掌握它并用好它还需要付出更多努力和实践。 

2. 企业架构语言ArchiMate.pdf（适合架构师）
   
   

   企业架构语言ArchiMate PPT

   ArchiMate是一种架构描述的建模语言，它使用清晰的概念和关系来描述架构领域，提供简单的、一致的结构化描述模型。我也写了一系列相关blog，大部分内容都来自于Open Group已经发布了1.0版本上，现在把这些内容集成次电子书，也便于大家学习。 

 《TOGAF、ArchiMate、需求》打印书籍购买

 TOGAF培训讲义（周金根）

讲师介绍

周金根，独立咨询师，专注产品管理、敏捷开发、企业架构、个人成长。十几年的IT工作经验，从技术到产品，到研发管理，围绕软件产品开发全生命周期积极探索和实践，发布了多本电子书，《模型驱动软件工厂》、《报表引擎设计》、《敏捷方法之Scrum》、《开源信息系统开发平台 – OpenExpressApp框架》、《敏捷个人-认识自我、管理自我》、《业务分析与需求》、《规模化产品开发方法-产品线工程》、《架构语言ArchiMate》、《企业架构框架TOGAF》等， 获得2010和2011年十大杰出IT博客，在中国软件技术大会、中国软件工程大会、全球软件技术大会、Scrum Gathering等大会多次做过企业架构、产品管理、定制化开发以及敏捷方法等主题演讲。给建银、工行、国网、中油瑞飞、英华达、工程设计研究院等不同类型企业做过企业架构、敏捷开发、需求等方面的培训和咨询，深受企业好评。

课程简介

企业架构TOGAF给企业信息化规划带来的新的思考和指导，通过课程的学习将会获得：

1. 企业架构各个阶段的工作方式和交付物
2. 对集成的顶层思考
3. 掌握一种架构方法
4. 掌握一种架构语言
5. 掌握一种架构工具

内容安排

培训讲义

培训PPT只提供部分讲义内容，培训企业需要可在培训前获得讲义PDF后自行打印

五天课程培训大纲

内训企业沟通后进行调整，以下为公开课培训大纲

TOGAF框架是一个企业架构方法，它本身具有很好的体系性，但缺乏比较具体的方法指导，这让学习者会有较陡的学习曲线。再加上会遇到很多晦涩难懂的词汇，这也会让初学者更难掌握这门方法。本次培训共分为八个部分，是在标准TOGAF的5天培训体系之上，去除机考时间，增加了TOGAF概观的导入以及TOGAF的实践。在对标准体系讲解过程中，融入工作中的使用一些方法，让参训人员更容易理解和掌握TOGAF。

日程安排

• 第一天上午：第一部分
• 第一天下午：第二部分 1.2.3
• 第二天上午：第二部分 4
• 第二天下午：第二部分 5.6
• 第三天上午：第二部分 剩余部分
• 第三天上午：第三、四部分
• 第四天上午：第五、六、七部分
• 第四天下午：第八部分

第一部分：TOGAF 概观

1. 信息化
2. 企业架构
3. 企业架构方法
4. TOGAF概述

第二部分：TOGAF 架构开发方法

1. 介绍
2. 预备阶段
3. 阶段A：架构愿景
   
4. 阶段B：业务架构
   
5. 阶段C：信息系统架构
   
6. 阶段D：技术架构
   
7. 阶段E：机会和方案
9. 阶段F：迁移计划
10. 极端G：实现治理
12. 阶段H：架构变更管理
13. 架构需求管理
    

第三部分：TOGAF 架构指引和技术

1. 介绍
2. 架构景观
3. 迭代架构
4. 安全架构
5. 定义和治理SOA
6. 架构原则
7. 涉众管理
8. 架构模式
9. 业务场景和业务目标
10. 差距分析
11. 迁移规划技术
12. 互操作能力需求
13. 业务转化准备评估
14. 风险管理
15. 基于能力的计划
    

第四部分：TOGAF 架构内容框架

1. 介绍
2. 内容元模型
3. 架构工件
4. 架构交付物
5. 构建块
   

第五部分：TOGAF 企业连续系列和工具

1. 介绍
2. 企业连续系列
3. 架构分区
4. 架构存储库
5. 架构开发工具
   

第六部分：TOGAF 参考模型

1. 基础架构 TRM
2. 集成信息基础参考模型 III-RM
   

第七部分：TOGAF 架构能力框架

1. 介绍
2. 建立架构能力
3. 架构委员会
4. 架构一致性
5. 架构契约
6. 架构治理
7. 架构成熟度模型
8. 架构技能框架
   

第八部分：TOGAF 实践

1. 启动TOGAF项目
2. TOGAF裁剪使用
3. ArchiMate架构语言
4. Archi工具
   

第九部分：如何做咨询顾问

使用TOGAF的几个初衷

在我们开发软件时，如果你做过设计和架构工作，那么你会发现软件开发过程中其实存在很多断沟。

1. 业务架构到技术架构的不一致
   1. 业务架构是一拨人做，技术架构师另一拨人做，结果做业务架构时缺少技术架构的考虑，而技术架构缺少服务于业务的意识，最终没有为业务服务。弄到最后业务架构和技术架构并不能很好的结合起来，导致还需要很多适配或反复工作。
   2. 还有一种情况是，业务架构做完之后扔给技术架构来实现，但是业务架构提供的东西并不全面，不能提供技术架构的输入，导致沟通效率极其低下。
2. 业务架构到业务需求的不一致
   1. 有些公司虽然岗位分的清楚，但是方法并不清楚。业务架构是一套方法，需求分析是一套方法，甚至于没有方法，而是靠着个人能力去做，结果导致架构和需求交付物是独立的，业务架构的东西不能顺利转移到需求阶段
   2. 还有时候一个人就负责产品的业务，架构和需求一起做，这时候没有方法的指导，其实很容易迷失在业务细节。 过早的进入业务细节对于产品来说是及其危害的，因为产品架构还未明晰时进入细节只会浪费时间导致重心偏离方向。
3. 业务架构和实现的不一致
   1. 业务架构采用的是业务语言，而技术实现采用的技术语言，两者不是同一个语言，很难做到顺利过渡，还需要再一次翻译，有时候甚至在实现阶段根本不看业务架构出来的东西
   2. 很少有开发人员清楚产品的业务架构，那么如何能够做出好的产品来？
4. 开发产品时，开发问一句，”做这个对系统有什么价值？”结果发现需求根本无法追溯回系统的价值点上，有时连需求人员都不知道为什么做了这个功能。如果产品生命周期较长，中间换了好几拨人来做这个产品了，那么不仅是需求文档不能追溯，就是靠口头讲也讲不清。

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

1. 找到一个指导业务架构的方法和框架
2. 结构化架构交付物才有可能把架构知识转移到开发环节
3. 必须有一个业务开发平台来集成业务架构、技术架构和开发框架

业务架构和业务需求

TOGAF并没有太多内容来描述如何做业务需求，但是这是我们必须要做的事情。从上面的阐述能够发现，我是希望业务架构和业务需求能够有一种方法进行衔接的。其实业务架构和业务需求本身就不冲突，两者只是处在一个事物在不同层次的东西。架构关注的是更全面、概括、组织方面的东西，而需求关注的是用户关心的业务细节，业务需求是业务架构的进一步分析。

在研发峰会上我讲过一次使用TOGAF来做业务架构，下面是裁剪后的轻型迭代流程和交付物。其中的设计开发步骤中有Backlog，这个就是从业务架构和业务需求的产物。

在我写的敏捷方法之Scrum.pdf电子书中提到产品backlog是在项目开始的时候，由Product Owner准备的一个根据商业价值排好序的客户需求列表。而在我们工作中，这个产品backlog如果要做到承上启下的作用，考虑到它来自于业务架构，而又服务于产品开发，所以我们会定义一些格式，例如考虑功能的抽象、721的分析以及与开发框架匹配的文档组织格式等。

以下的文档是根据我所做业务以及实现框架而做的格式，你可能需要根据你们自己的情况来制定属于自己的backlog格式。

制定Backlog的考虑点

1. 由于流程可以动态变化，以静态的功能分解和信息结构作为backlog的主要输入
2. 考虑软件产品线工程，进入开发前，设计产品的721
3. 结合业务框架的模型抽取来编写业务实体以及功能
4. 尽量结构化文档，不采用纯文字描述，逐步抽取出具有确定含义的文字
5. 术语和规则作为sprint文档之外的重要文档

产品业务模块backlog

以下是实际工作中的一个示例：

• 按照子系统、业务模块来组织产品backlog
• 每个子系统和模块都附上唯一的编号，文档中任何地方都可以引用
• 输入、输出表达模块之间的关系，这个从业务架构的流程、功能分解中输入
• 执行者和目的对应业务架构的角色和价值点
• 范围、工具和技术属于业务需求内容
• 7/2/1是根据业务、市场来划分此模块是通用功能、可变功能还是定制功能

产品模块功能backlog

产品业务模块backlog大部分内容除了7/2/1之外，大部分内容只是业务架构的另一种表现形式而已。到了需求阶段，必须对产品业务模块backlog进行细化工作，那就是产品模块功能backlog：

• 按照业务模块、功能点来组织模块功能backlog
• 抽取公共业务功能、通用业务规则，例如列表模板、通用编辑方式、通用业务功能，这些通用规则和说明形成单独文档，作为技术架构的输入
• 业务规则列链接具体的业务规则说，业务规则的写法根据遇到的规则类型定义自己的结构化格式
• 功能点仍旧也要做721设计
• 对于非通用性的业务功能需要描述具体任务操作步骤以及价值点
• 加入关注的非功能性需求，我们现在只加入了效率
• 大多数情况下，这个文档的模块能够对应到开发中的实体，功能点能够对应到界面上的一个按钮或右键等，这样有利于以后转向模型驱动平台下使用设计器来进行产品开发

术语表

如果术语很多，可以进行分组编号

规则表

业务规则对系统来说是核心内容，这部分内容必须仔细查看。规则分析得是否正确、完整是系统实现的前提，每个业务需求通过抽取应该能够形成一些通性规则，对于通行规则可以作为技术框架的输入，由框架统一实现

一些问题

• 业务架构需要做到什么粒度？
  架构是产品的上层框架，只需要到具体功能模块以及主要业务功能就行，具体的业务规则和异常处理都不需要考虑，那是需求分析的事情
• 业务架构是否需要做原型？
  需要，只是会很粗，并且不在意具体的UE，但是需求阶段的原型应该可以从业务架构阶段的原型中细化下来
• 有没有统一的规则表模板？
  不同业务的规则是不一样，不同小组的设计能力也是不一样，不同平台支持的规则DSL也是不一样的，这个需要根据自己的情况来定义自己的格式，但必须能够把规则描述清楚，做到自己、开发人员和测试人员都能一看就明白
• 需求阶段需要出以前的详细需求规格说明书吗？
  对于内部来说不需要。但是必须要有原型，还有我上面说的几个文档，记住一定要保证同步。