在两三年前就关注过EA了，只是没有怎么深入的去了解它，经过这几年的工作和思考，发现架构越来越重要，做企业级的IT系统企业架构也越来越重要。
TOGAF 或非 TOGAF？
在组织中不用强迫实行企业架构，对企业架构实践的需求应该是人们了解了业务过程与技术框架的结合的不断发展的复杂性的结果。如果不确定是否适合TOGAF，那么组织试用一下也是一个好主意。试验可能要包含一组热情且值得信任的解决方案及业务架构师，重要的是要加入业务和技术角色，以确保利益均衡。
在《企业架构 － 企业架构成熟度模型（EAMM）》中介绍了一个成熟度的模型，从这个我们也可以看出我们为什么要做企业架构以及我们还需要做哪些提高。今年准备开始实践一下企业架构，在《企业架构 － 开篇：TOGAF介绍》中我也说了TOGAF的完整性和实用性都比较高，所以我把它作为我实践EA方法的框架。
那么选择TOGAF后，我们怎么去做呢？我发现不仅设计难做，框架难做，架构更难做。TOGAF的体系虽然很清楚，但是要完全领悟还是需要时日的，在看了几天资料后仍旧不是很清楚如何实施，不像Scrum方法一样，外部资料特别多，实施起来也很容易上手。
在学习时，大家更多的可能还是关注如何具体做什么事情，这个我也非常关心，只是现在我习惯于在做一件事情之前能够对它有认识，至少是方向性的把握。对我来说，我目前更关心的是在执行之前自己能够从整体上理解它并形成自己的一些思考和观点。
经过一周的时间，终于有一个大致的实施路线了，现与大家交流一下。
组织保障
前面的都是一些工作任务的方法和指导，具体实施时人是非常重要的，特别是对于这样一个新的方法，在 企业架构 － 组织角色和技能 中罗列了一些组织角色和技能，我们从中可以看到我们可以提高的地方。
TOGAF 实现路线图
推荐组织在引入 TOGAF 之前先适应几个技术、标记，和 SDLC 方法，如图所示：会UML会更容易使用ArchiMate，会迭代开发更容易适应架构的迭代开发，经历过完整的产品开发会更快适应架构开发。
企业架构路线图示例
对比 RUP 和其他主要关注于实现的规程，企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范，及优先级划分。EA 路线图可能比单路线解决方案包含更多内容:首先有一个计划，产生一个愿景，然后做基线架构、目标架构，产生项目列表后再实现。图中的时间只是一个示例而已，不作为实际参考。
基于基线开发(Baseline first)的迭代步骤
如果是完整的企业架构，其时间跨度可能比一个项目还长。大家都知道现在敏捷在开发管理中盛行，做架构其实也使一样，也是可以基于迭代来进行的。下图为基于基线开发的迭代步骤图：
迭代分四个大的阶段进行，每个阶段的主要工作对应到了ADM的方法：
- 架构上下文（Architecture Context）：初始、愿景
- 架构定义（Architecture Definition）：业务、信息、技术架构 （＋机会及解决方案、迁移规划）
- 转换规划（Transition Planning）： 机会及解决方案、迁移规划
- 架构治理（Architecture Governance）：实施、变更
企业架构主要元素
主要技术和交付物
明确了开发迭代方式和各个步骤后，就需要确定一下每个阶段具体有哪些工作和交付物了，下图为各阶段的主要任务和交付物：
上面的交付物和任务会比较多，之前也说过我们使用的是迭代开发，那么下面这张图可以供我们参考：我们可以先实现白色的核心部分，再去实现其它部分（裁剪后的内容）
具体实施
基于上面的工作路线和参考，具体实施时主要参考togaf9e.pdf中的步骤来，在实践中提高
参考：
本文转自 jingen_zhou 51CTO博客，原文链接：http://blog.51cto.com/zhoujg/518625，如需转载请自行联系原作者
