-
Notifications
You must be signed in to change notification settings - Fork 77
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Tony Deng <[email protected]>
- Loading branch information
Showing
4 changed files
with
61 additions
and
0 deletions.
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,62 @@ | ||
# TOGAF | ||
|
||
一直以来,人们对架构理论的研究比较严谨,很注重用词。早期的架构理论,无论是Zachman还是TOGAF,都被称为“框架”,而非“架构”。 | ||
|
||
> Zachman框架为理解架构提供了一个很好的视角,但是没有给出具体的构建过程。在Zachman框架的启发下,TOGAF尝试去解决这个问题。 | ||
与以往的“单打独斗”不同,TOGAF发展成了一个横跨多个行业的论坛型组织,目前已拥有850多个成员机构,为TOGAF的通用性奠定了基础。 | ||
|
||
TOGAF的前身是美国国防部的“信息管理技术架构框架”(`TechnicalArchitecture Framework of Information Management`,`TAFIM`)。1993年,Open Group接受委托设计企业架构理论,期间还接受了美国国防部的指导,因此吸收了TAFIM的经验。经过Open Group近两年的努力,TOGAF 1.0于1995年诞生。由于当时正处于企业架构理论的兴盛期,TOGAF一直以每年一版的频率持续更新,到2002年更新到了8.0版,正式扩展为完整的企业架构,并且开始对外提供架构认证培训服务。之后,TOGAF的更新速度放慢,2009年发布了9.0版, 2012年发布了9.1版,而最新的9.2版到2018年才发布。TOGAF认证目前也是企业架构领域比较权威的认证。 | ||
|
||
## 1. TOGAF更完整 | ||
|
||
与Zachman框架相比,TOGAF给出了对架构过程的完整指导。TOGAF构建过程包括八个阶段,依次为: | ||
|
||
- **架构愿景** | ||
- **业务架构** | ||
- **信息系统架构**(应用架构和数据架构) | ||
- **技术架构** | ||
- **机会及解决方案** | ||
- **迁移规划** | ||
- **实施治理** | ||
- **架构变更管理**(涵盖了远景描绘、架构构建、架构实施、架构治理等方面)。 | ||
|
||
在俗称[“麦田怪圈”](https://baike.baidu.com/item/%E9%BA%A6%E7%94%B0%E6%80%AA%E5%9C%88/81806)的架构构建过程中,需求管理处于中心位置,说明架构构建各个阶段都是需求驱动的,也说明了需求的变化对构建过程有着深远的影响。 | ||
|
||
“麦田怪圈”如图所示。 | ||
|
||
 | ||
|
||
“麦田怪圈”只是TOGAF六大构件中的一个,此外还包括架构内容框架(详细的架构工作产品模型)、参考模型、ADM指引与技术、企业连续统一体(类似具有演进特征的架构资产库)、架构能力框架(运转企业架构必需的技术、组织、角色等,类似管理体系),可以说是应有尽有了。TOGAF 9.0的交付物如表所示。 | ||
|
||
 | ||
|
||
## 2. TOGAF具有适配性 | ||
|
||
**TOGAF的构建过程本身就是瀑布式的,因此与瀑布模型更加适配**。 | ||
|
||
在2002年之前,TOGAF更新比较频繁,大部分工程都是按照瀑布模式执行的,尤其是对于认可企业架构理念的大型企业而言,TOGAF理念很适合构建企业架构和指导企业工程,也正因如此,TOGAF声称自己曾占有企业架构领域半壁江山。咨询机构将TOGAF如此清晰的流程吸收,并将其转化为咨询产品进行输出。TOGAF清晰的体系也提高了过程的可控性和对交付物的管理能力,但由于其交付物比较多、体量庞大、不易维护,TOGAF后来也遭人诟病。 | ||
|
||
此外,即使到了9.2版本,TOGAF依然只是在探讨与SOA的结合,并没有考虑更新的架构风格和工程方法。 | ||
|
||
## 3. TOGAF对企业和业务架构的定义 | ||
|
||
TOGAF应该是第一个明确提出业务架构概念的架构框架。在TOGAF 9.2版中提到,业务架构定义了企业战略、治理、组织和关键业务流程。 | ||
|
||
为了理解TOGAF对业务架构的定义为何如此模糊,需要先理解它对企业和企业架构的定义。TOGAF将“企业”定义为“有一系列共同目标的组织集合体”,也就是说,企业还可以是政府、团体和某组织中的部门等,相当宽泛。“企业架构”的定义也类似,既可以是完整的企业架构,也可以是领域层面的架构,它强调的是多个系统或者功能之间的交叉。 | ||
|
||
TOGAF采用了模糊的定义方式,定义的边界并不清晰。对于Zachman提出的架构缺乏统一概念和认知的问题,TOGAF给出了一个“灵活”的答案。 | ||
|
||
除了业务架构外,TOGAF还重点提出了另外三个架构:应用架构、信息(数据)架构、技术架构。这三个架构一般合称“IT架构”,其中应用架构与信息架构又合称为“信息系统架构”。业务架构与应用架构、信息架构、技术架构共同组成了人们常说的“4A架构”。 | ||
|
||
## 4. TOGAF的重要意义 | ||
|
||
**企业架构是需要业务人员和技术人员共同建设的**。无论是在TOGAF诞生的年代还是在今天,传统企业中的技术人员都不是很多。如果没有一个清晰的流程指导企业开展企业架构建设,那么业务人员是很难融入架构开发过程中的。所以,流程对业务人员和技术人员而言都是很重要的。与此同时,正是由于TOGAF在流程方面的特点,要看一个企业是否采用了TOGAF理论指导企业架构开发,不是看最终的交付物,而是看过程。 | ||
|
||
> 传统企业在比较不同的企业架构理论时,不能只看一些对新锐工程方法的表面宣传,而是必须深入理解工程和架构的基本原理,这样才能找到最合适的工程逻辑。 | ||
不得不说,TOGAF是一个让人“爱恨交加”的框架,它的诞生使大家更加意识到,企业架构注定是一项庞大的工程,无论是架构开发还是架构维护,都很有挑战性。 **Zachman在论文中强调过架构工具的重要性,没有工具支持,繁重的架构管理工作会成为企业采用架构框架的“绊脚石”。** 然而,与TOGAF配套的工具似乎不太容易被业务人员接受,只能让技术人员尝试。但是,这些缺陷并不会影响人们对TOGAF的评价,它依旧是企业架构成为可设计架构的关键性理论。 | ||
|
||
对企业架构的需求一直是真实存在的,架构管理能力优秀的企业无论其采取的是何种方法,都是企业架构价值的证明。 | ||
|
||
企业架构的价值并不依赖于特定的方法论而存在,这也要求我们在实践的基础上不断吸收各类方法论的合理之处,持续加强对方法论的研究,以便让企业架构更好地指导我们的工程实践。 |
Binary file not shown.