联邦企业架构之CIO委员会的企业架构实施指南（上）
联邦企业架构之CIO委员会的企业架构实施指南（上） 企业生命周期
FEAF为联邦企业架构的建设提供了方法论，但是该框架还只是在概念层面提出了联邦企业架构建设过程的各组成部分以及他们之间的关系，而对于如何以步进式的方式建设企业架构，FEAF的详细程度还是不够的。那么该如何使用架构框架理论为联邦政府以及各个机构建设企业架构呢？企业架构的建设、维护和使用又该如何融入到各个机构中？面对这些问题，2001年CIO委员会发布了《A practical guide to Federal Enterprise Architecture》，用于为各个机构提供一份关于建设和维护企业架构的详细指南，并且该指南还介绍了如何将企业架构融入到各机构的生命周期中，从而促进机构的良性发展。这份指南虽然名称上是为联邦政府各机构提供一份实施导则，但是对于联邦政府之外的各种企业也有着重要的意义。
企业生命周期
在企业的存续和发展过程中，企业需要不断的吸收新的技术、业务流程等新鲜事物，并将其转换为能够促进企业前进的各项能力，而这样一个循环往复的过程就可以看作为企业的生命周期。为了维持这个过程的良性发展，企业需要借助于各种管理过程和方法，并通过他们之间的协调合作来达成。在联邦政府中，相比于项目管理以及资金规划和投资控制，企业架构过程可以说是一个新晋技术，因而为了确保整个组织的良性持续发展，仅仅强调企业架构过程而忽视其他过程的结合是不够的。在这份指南中，企业生命周期被描述为上图所示的样子。在这里，企业架构过程（EA Process）是一个独立运行的迭代过程，而除此之外一个企业的良性发展还需要企业工程和项目管理（Enterprise Engineering and Program Management）和资金规划和投资控制过程（CPIC，Capital Planning and Investment Control）。在这三个核心过程中企业架构过程是用于企业架构的建设、维护和使用的指导过程；企业工程和项目管理用于负责针对企业各个实施或采购项目的管理；资金规划和投资控制过程是企业关于投资的选择、控制和评估方面的重要工具。这三个过程并不是相互隔绝的，企业架构过程的实施最终要落实到一个个具体实施项目之上，而确保这些项目能按时按质的实现就需要企业工程和项目管理以及资金规划和投资控制过程方面的强力支持。除了企业架构过程受益于这两个核心过程之外，企业架构过程所产生的企业架构内容也为这两个核心过程提供了准确可靠信息基础，并且企业架构过程还可以保证这些信息能够快速反映和消化外界环境的变化。除了这三个核心过程之外，企业生命周期的良性发展还需要系统生命周期、人力资源以及安全管理这三个支持性的管理过程的帮助。这三个支持性过程具有普适性，他们不像上面三个核心过程那样直接作用于企业的具体任务，但是他们确实是支持各个核心过程并保证企业任务能够顺利进行的重要保障。
企业架构过程理解了企业架构过程在整个企业生命周期中的位置以及与其他重要管理过程的相互关系，我们再来了解一下CIO委员会对于企业架构过程是如何进行阐述的。与FEAF不同，在CIO委员会的这份指南中采用步进的方式将企业架构的开发、维护与应用描述成一个循环往复的迭代过程（如下图所示）。这一循环往复的企业架构过程与后面将要介绍的TOGAF的架构开发方法（ADM）有着异曲同工之妙，两者都采用了循环迭代的方式，并且大部分的步骤都有着相似的意义和内容，不过在针对每个步骤的具体描述方面，CIO委员会只是针对此过程中的每个步骤进行了较为详尽的说明，而TOGAF的ADM的描述方式则更具标准性，除了各步骤的说明之外还包括了每个步骤的目标、输入、输出以及进一步细化的分支步骤。
企业架构过程
CIO委员会将企业架构过程分为九个部分，除了最后的“控制与监督（Control and Oversight）”之外，其余八个部分是都是如上图所示那样以前后衔接的方式来布置。也就是说，按照箭头所指方向前面步骤的完成为后面步骤的启动奠定基础，并且这八个步骤都处于“控制与监督”这一过程的控制之下。这些步骤按照在企业架构的开发中的出现顺序列举如下：
取得上层主管的认同和支持 （Obtain Executive Buy-In and Support） 建立管理结构和控制 （Establish Management Structure and Control） 定义架构过程和方法 （Define an Architecture Process and Approach） 开发基线企业架构 （Develop Baseline Enterprise Architecture） 开发目标企业架构 （Develop Target Enterprise Architecture） 开发序列计划 （Develop the Sequencing Plan） 使用企业架构 （Use the Enterprise Architecture） 维护企业架构 （Maintain the Enterprise Architecture） 控制与监督 （Control and Oversight） 取得上层主管的认同和支持取得所有上层主管的认同和支持是一个企业架构过程建设的起始，也是决定一个企业架构是否能够被成功建立的先决条件。由于企业架构是一个涉及到全组织的信息资产，其开发和维护需要整个组织提供持续的资源支持，因而得到组织全体尤其是高层的支持是非常重要的。在此企业架构过程各步骤之中，作为企业架构的主要推动和执行核心，CIO和主架构师需要在企业的不同层面分别获得相关人员的支持和认同，而其中最主要的是获得管理层对架构过程所必需的资源支持的承诺、各业务负责人和领域专家在业务角度对企业架构目标的认知以及在预算及其他约束方面的分析。
首先企业CIO需要创建市场策略，并与企业最高领导进行交流，使其了解企业架构开发在战术和战略上的价值。在取得最高领导的认同之后，CIO需要取得他对企业架构支持的承诺，为获得必要的资源支持打下基础。同时，CIO需要与最高领导在高层管理团队中选择主架构师。然后，CIO还要和最高领导一起基于各项用于治理企业架构的开发、实施和维护的架构原则创建企业架构方针（Architecture Policy）。
接下来，CIO需要起草市场方案来进一步强化企业架构的价值，并在高层管理团队中获得认可，并得到他们以及他们下属组织和资源会积极投入的承诺。主架构师需要起草一份更为具体的企业架构计划，从而获得企业中包括业务负责人和领域专家在内的各个业务单元的支持，并且还需要他们从业务策略角度，结合预算以及其他约束条件对架构的业务层以及相关序列计划的合理性进行分析。
最后，CIO和主架构师需要举行一个企业架构项目的启动会议，用于阐述企业架构的目标、里程碑、流程、产品，以及企业架构过程与系统生命周期活动、资金规划和投资控制过程等相关过程之间的关系，从而在业务的中层和下层的参与人员中获得共识和支持。
建立管理结构和控制
企业架构管理组织结构概念图
在此步骤中，企业需要建立用于管理、控制和监督企业架构过程中各项活动的组织结构。在这个组织结构里，各种角色的责任以及他们之间的责任和沟通关系需要被清晰地定义出来，而且该组织架构的构成应该有助于其中的各个角色在企业架构中职能的发挥。需要注意的是，由于企业规模的差别以及业务复杂度等方面的不同，此企业架构管理组织中角色的构成以及角色的职能也是具有不小的差别。在CIO委员会的这篇指南中，该企业架构管理组织包括了企业架构执行委员会（EAESC，EA Executive Steering Committee）、技术审查委员会（Technical Review Committee）以及企业架构项目管理办公室（EA Program Management Office）这样的专为企业架构过程所设的部门，也包括诸如质量保证（Quality Assurance）、配置管理（Configuration Management）、风险管理（Risk Management）、安全以及评估这样的较为通用的信息技术支持职能单元。
定义架构过程和方法
架构内容深度和详细度制约因素
在此步骤中，企业需要指定用于建设企业架构的过程和方法。首先，企业需要明确企业架构的使用目的和范围，而这也是推动后续企业架构过程活动的主要动力。在确定了企业架构的使用目的和范围的基础之上，企业还需要判断出其对企业架构在内容深度和详细度方面的需求，并保证各个视角下的视图内容都遵循相同的深度和详细度标准。接下来，企业需要选择适当的企业架构制品，并使用上一步指定的深度和详细度水平来约束架构制品的内容。这个选择既包括挑选包含了必要内容的核心架构制品，也包括明确用于进一步阐述核心制品或在特定领域和范围内对其进行描述的支持性架构制品。从架构制品内容这一角度来看，他们需要包含企业的业务和技术资产这两个方面。
在明确了针对架构制品内容的需求后，企业需要选择适当的架构框架理论和用于辅助架构建设的自动化工具。在联邦政府的范围内，已经出现了不少企业架构框架理论，例如上面提供过的FEAF，DoDAF和TEAF等，因而各机构可以按照自己的实际情况在这些框架中选择并定制出符合自身情况的框架理论。同时，为了加强架构的可用性并提升架构开发的效率和准确性，选择适当的自动化架构工具是必不可少的。需要注意的是自动化工具的选择也要照顾到企业的规模、复杂度以及员工熟悉度等多个方面，因而主架构师对于自动化架构工具的选择既可以是诸如微软Office办公软件系列这样的通用性工具，也可以是像Rational Rose这样的专业建模软件，当然也可以是它们的组合。
（待续。。。。。。）
忙碌了一年了项目又到了交互了，虽然项目能成功上线（因为还有维护支持的团队）。但是个人从技术上看，这是一个不那么成功的项目，因为后期艰难的修复bug,添加feature。这与简单设计有什么关系呢？在某模块开发起初，由于架构的经验预见性的告诉我这模块开发中会出现什么问题，所以选择了提出某些比较好的解决方案，但是由于团队成员一致的所谓简单设计，通过TDD,重构达到”合适”的”完美”的设计，可是最后的结果如我所料一切的发生。这里插一句，现在在一家敏捷公司，敏捷强调是合作，所以没有一个人统一规划决策，不同之前的公司作为架构师决策一切架构设计。敏捷合作交流我不否认你正确性，因为我也相信软件是人和时间的问题，方法论都是解决我和时间的问题。但是对于一个在成长中团队，成员的设计或者某些预见性或者重构能力，力度相对不足的情形下，这样是不是合理？
回到主题，简单设计英语 Keep It Simple, Stupid。我们常说的KISS原则，保持产品或设计的简单性，同时功能的足够性。我想说的是翻译成为简单这是一个错误的决定，因为这不是绝对的简单，在我看来最简单的系统就是没代码的系统，代码越少，甚至没有就没有bug没有维护。所以我更愿意以产品设计如家庭装修一样翻译为”简约”，简约而不简单。在 《简约至上-软件交互式设计四策略》 这本书以遥控器为例提供了删除，隐藏，转移，组织产品设计四策略，但是其简化改善后仍然五脏俱在，核心价值仍在。但是对于软件而言，我们最大对手是需求变化，所以我们常说“拥抱变化”，敏捷就是为了拥抱变化适应变化给用户提供更好优质可用的卓越软件。但真的所谓简单设计，我们起初就不设计？靠我们的测试驱动，行为驱动，重构等方法论就能解决软件设计？这些就是万能的灵药，软件的银弹？我还没见过这样的人，我不否认在这样牛人的存在， Martin Fowler 在 《重构改善既有代码设计》 一书提到XP发起一帮人能够比较好的完美利用这些方法论将代码改造为一个比较好的设计。但这毕竟是少数人的世界，我辈望山莫及，再加上项目开发周期中的由于时间，环境等等压力导致重构力度大幅度缩减，或者根本就没有把重构日常化，只是拿着重构这个感觉好nb的术语招摇撞骗（本人见过很多人或者博客将如果重构，但在鄙人鄙见下这更大程度的是重写，重新设计，只是招摇撞骗的幌子），那所谓的简单设计真的还能启用？
在回到简单设计，在软件变化的需求下，我认为简单设计的目的是保持代码的整洁，以及不要花费太多时间在无谓的设计猜测需求中，减少类数量的庞大，其目的是减少时间人力资源的浪费，其相对于过度设计而言。但绝对不是不做设计，不留任何一点扩展，起终点在于时间资源的投入。所以我认为基于资源的投入，如果不是那么大浪费或者必须的设计，我们让然需要去做，因为程序员都是追求完美，适应以后潜在的变化。相反如果是将一个相对好的设计，或者扩展，花时间去做到所谓的简单设计，丧失扩展等，这不是减少资源投入，这是在捣蛋，花时间精力去搞破坏，即使是你认为不变，何况谁能预测未来世界。
如果我们不是牛人，你却也追求卓越软件，我觉得我们还是需要考虑下设计，不要一味的“简单设计”，平衡各种方法论，权衡各种利弊，找到适合自己的方式方法论，如果只是”简单设计“却没有足够的重构力度，抑或完全的优先设计，不进行不断的持续改进，逐步细化，做到“简约而不简单”记住所有的技术债早晚会需要你偿还的。对于我来说没有万能的方法论，我也不是牛人，我选择设计，重构等方法论的权衡。
作者： 破 狼
出处： http://www.cnblogs.com/whitewolf/
本文版权归作者，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。该文章也同时发布在我的独立博客中- 博客园--破狼 和 51CTO--破狼 。
分类: Code Life , 架构/设计 , 敏捷/持续集成
作者： Leo_wl
出处： http://www.cnblogs.com/Leo_wl/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
版权信息查看更多关于联邦企业架构之CIO委员会的企业架构实施指南（上）的详细内容...