企业精简架构(走出软件百慕大)
点此进入淘宝搜索页搜索分類: 图书,管理,企业经营与管理,经营管理理论,
品牌: Roger Sessions
基本信息·出版社：机械工业出版社
·页码：164 页
·出版日期：2009年09月
·ISBN：7111266269/9787111266266
·条形码：9787111266266
·包装版本：第1版
·装帧：平装
·开本：16
·正文语种：中文
·丛书名：走出软件百慕大
产品信息有问题吗？请帮我们更新产品信息。
内容简介《企业精简架构》主要论述如何精简企业架构的书。全书分为两部分：第一部分，作者通过一些直观的问题展示复杂性带来的问题，接着从数学的角度进行分析；第二部分，讨论解决复杂性问题的过程。这个过程就是SIP，即简单迭代分割。读完《企业精简架构》之后，你会成为反复杂联盟中优秀的一员，面对各种难题，你都可以使用你定义的企业架构来简化它。《企业精简架构》内容详实，图文并茂，可作为企业架构师的参考用书。
作者简介Roger Sessions，作者在软件架构领域是一位知名的顾问和专家。他是国际软件架构协会(1ASA)的董事会成员，还是该协会《Perspecttves》期刊的主编，同时，他还是微软最有价值专家。到目前为止，他写过7本书．其中包括《Software Fortfesses：Modeling Eriterprise ArchitecttJres》。他出席过世界范围内的数十场研讨会。
媒体推荐一种全新的思考企业架构的方式。
——Paulo Rocha，Fronde Systems Group公司策略服务部经理
在我们领域，Roger是最具有创新精神的思想家之一。
——Paul Preiss，国际软件架构师协会主席
编辑推荐在《企业精简架构》中，Roger讲告诉你如何让简化成为核心的架构需求（像性能、可靠性和安全性一样关键），更好、更灵活地满足你的业务。为什么很多IT项目以失败而告终？企业顾问Roger Sessions曾经为数十家大企业提供过解决方案。在提供解决方案之前，这些企业大多在同复杂的项目和糟糕的结果作斗争，而Roger成功地帮助他们改变了这种状况。
他的秘笈是对复杂的问题采用简单的解决方案。根据他的观察，太多的企业之所以失败，都是源于使用了过长、昂贵的工序构建昂贵、过于复杂的实现。
·减少IT项目的，使业务的回报最大化。
·理解复杂性的数学原理和控制的过程。
·鉴别企业构架中的基本业务单位——自治业务能力。
·创建业务过程和软件系统间的逻辑关系。
·采用迭代途径控制，使其带来效益。
·软件城堡的10条规则应用到IT解决方案中。
·《企业精简架构》中提到的方法论如何拯救现实中的项目。
·把精简视作关键的业务财富，使之产生效益。
走出软件百慕大
百慕大三角（Burmuda Triangle）的具体地理位置是指位于大西洋上的百慕大群岛、迈阿密（美国佛罗里达半岛）和圣胡安（波多黎各岛）这三点连线形成的三角地带.面积达40万平方英里。在这个地区.已有数以百计的船只和飞机失事，数以千计的人在此丧生。从1880到1976年间，约有158次失踪事件，至少有2000人在此丧生或失踪。正因为如此.百慕大三角也称为魔鬼三角区和丧命地狱。
软件开发的漫长航程中，也有这样的百慕大三角存在。在很多情况下.项目经理不得不同时对付资源、范围、进度这三个问题。而无数的软件项目之船，被拖入这个百慕大怪圈.丧失了自己的航向……
走出软件百慕大系列丛书
源自微软出版社的“最佳实践（Best Practices）”系列！
凝聚世界一流的软件项目管理专家的智慧！
从不同角度揭示软件项目管理的成功之道！
我们将带领你穿越软件百慕大三角，驶向成功交付的彼岸！
目录
前言
致谢
第一部分 复杂性问题
第1章 当今企业架构
为何困扰
问题：不可靠的企业信息
问题：不及时的企业信息
问题：新的潜在复杂项目
问题：并购新的公司
问题：企业想分离部门
问题：需要鉴别外包机会
问题：规章制度要求
问题：需要自动调节与外部伙伴的关系
问题：需要自动调节与客户的关系
问题：IT部门和业务部门糟糕的关系
问题：IT系统糟糕的互操作性
问题：难以管理的IT系统
企业架构的价值
一些定义
什么是企业架构
企业架构中的复杂性
企业架构的Zachman框架
开放组架构框架
Federal企业架构
小结
第2章 初识复杂性
分而治之
执行官的午餐
合唱团排练
紧急响应
服装店
国际象棋游戏
孩子们在星巴克
魔方
分区的五条法则
法则一：分区必须是正确的分区
法则二：分区的定义必须恰当
法则三：所划分的子分区必须
合理
法则四：分区中子分区大小应基本相等
法则五：子分区间的相互影响必须最小化且明确定义
简化
迭代
小结
第3章数学复杂性
复杂性
复杂性规则
同态
骰子系统中的复杂性控制
增加桶
分割
等价关系
等价类
反等价关系
等价关系和企业架构
实践中的相互作用
减少面
减少桶
其他复杂性
理论和实践中的复杂性
小结
第二部分 简化问题
第4章 企业划分中的ABC
复习数学知识
分割企业
企业等价类的ABC
ABC类型的关系
实现和配置
ABC类型
类型层次
组合关系
伙伴关系
关系和分割简化
再回到零售操作
小结
第5章 SIP过程
概述
状态0：企业架构评估
问题：不可靠的企业信息
问题：不及时的企业信息
问题：新的潜在复杂项目
问题：并购新的公司
问题：企业想分离部门
问题：需要鉴别外包机会
问题：规章制度要求
问题：需要自动调节与外部伙伴的关系
问题：需要自动调节与客户的关系
问题：IT部门和商业部门糟糕的关系
问题：IT系统糟糕的互动性
问题：难以管理的IT系统
禁忌
状态1：SIP筹备
保证准备就绪
培训
管理模型
SIP混合
企业相关的工具
状态2：分割
状态3：分割简化
状态4：ABC优先级
状态5：ABC迭代
小结
第6章 复杂性的案例研究
概述NPfIT
NPfIT的当前状态
SIP途径
小结
第7章 警戒边界：软件城堡
技术划分
规则1：自治
规则2：清晰的边界
规则3：功能分割
规则4：依赖定义
规则5：异步
规则6：数据分割
规则7：无交叉事务
规则8：单点安全
规则9：内部信任
规则10：保持简单
小结
第8章 复杂性展望
复杂：真正的敌人
值得简化
简化的哲学
本书内容回顾
告别
附录 本书一览
数学内容
分区的数学定义
分区的五个法则
骰子系统中的状态计算
同态
等价关系
反等价关系
分区
等价关系的分割计算
企业架构内容
企业架构的合适定义
理想架构的定义
Boyd迭代原则
企业复杂性法则
协作和自治
SIP内容
SIP定义
SIP过程
ABC
软件城堡模型
ABC的三种通信方式
SIP信条
……[看更多目录]
序言那是最美好的时代，那是最糟糕的时代；那是智慧的年头，那是愚昧的年头；那是信仰的时期，那是怀疑的时期；那是光明的季节，那是黑暗的季节；那是希望的春天，那是失望的冬天；我们拥有一切，我们一无所有……
这是查尔斯·狄更斯（Charles Dickens）1775年写的《双城记》（A Tale of Two Cities）的开头部分，书中的两个城市是伦敦和巴黎。如果狄更斯活到现在，我猜他一定会写一本企业架构领域的书，一本涉及整合商业需求和IT解决方案的书。
这是最美好的时代。企业架构的目标就是通过IT投资获取最大的商业价值。对大多数企业而言，无论是大规模的还是小规模的，盈利性质的还是非盈利性质的，公有的还是私有的，它们都越来越强烈地希望通过IT投资使商业回报最大化，并帮助IT更高效地配合商业的需求、促进业务增长。毫无疑问，他们对企业架构的兴趣变得空前高涨。
这是最糟糕的时代。企业架构的目的是确保IT系统带来商业价值，但实际往往事与愿违。执行官们现在正在对企业架构失去信心，他们觉得企业架构和一般的IT没什么区别。这种信任危机正逐渐蔓延到各种规模、各种领域、各种类型的公司。2007年10月，Gartner就曾预言：到2010年，有40%的现存的企业架构将会消亡。在那本影响广泛的书《Enterprise Architecture as Strategy》（哈佛商学院出版社, 2006）中，作者Ross、Weill和Robertson说：真正能够有效利用企业架构的企业还不到5%。从我对企业架构的研究和该书作者提到的实现中，我发现了一个共同点：企业架构在高付出后却没有高回报。因此，对企业架构回报能力的质疑达到空前也就不足为奇了。
企业架构以一种高层次的企业视野，聚焦于组织的IT架构和业务架构之间。IT架构描述IT系统，业务架构描述业务过程。IT系统如果不能满足商业需求，那将是大大的浪费；业务过程如果没有良好的IT支持，效率很难提高。企业架构描述这两者之间如何互为补充，以确保组织中的IT系统能够高效地支持业务过程。
显然，这是个好主意。然而，企业架构却正趋于失败。
哪里出问题了呢？根据我的经验，目前实现企业架构的途径有三个基本问题尚待解决。首先，这些途径执行起来代价不菲；其次，耗费的时间太多；最后，没有方法验证结果。我们耗费大量资金、大量时间来创建架构，而为了测试这些架构的效果，我们还必须构造数量众多、费用昂贵的实现。尽管如此，我们不仅没有一种方法来评价某个给定架构的优劣与好坏，甚至大多数企业架构方法论都没有一个标准来衡量什么是“优”，什么是“劣”。
你怎么知道一个典型的企业架构是优还是劣呢？很简单，尝试着实现它。对于存在的业务过程，构造支持它的IT系统。如果你成功地交付了这些IT系统，并且它们满足商业需求，那么你的企业架构一定相当棒。如果不满足，祝你下次好运吧！
在其他科学领域里，这种途径根本就是行不通的。没有人会在发射登月火箭之前不通过行星的数学模型计算运行轨道；不通过重力压力模型计算所需的燃料。没有人认为建一座大桥之前不需要进行压力、负载、流体流的架构测试。
那为什么我们不在实现一个昂贵的大企业架构的时候首先通过数学模型来测试它是否有效呢？原因很简单，我们根本就不知道如何来测试。换句话说，站在数学的角度上，我们缺乏对“优”的理解，也缺乏一种测试“优”的模型，我们甚至缺乏“优”的基本定义。
文摘插图：
第一部分 复杂性问题
第1章 当今企业架构
本书讲述怎样把企业架构做得更好。于是问题就来了，和什么相比更好？答案是比我们现在做得更好。我将详细讲述那些我认为非常重要、但在已有的方法论中却没有涉及的问题。当然，在所有的这些问题中，最重要的还是复杂性。
在我们讨论如何改进之前，你必须理解这门艺术（不妨把它理解成艺术）的当前状态。哪些方法论需要改进？这些方法论是如何阐述复杂性的？
大多数企业架构师多多少少都有些方法论的经验，但是能够在这个领域有很开阔视野的架构师却为数不多。本章中，我们将讨论为什么这个领域存在以及这个领域的当前状态。我将比较当前使用中的企业架构方法论的优劣点和相互之间的关系。
这些方法论中的每一种都为企业架构师的工具箱的实践性做出了重要贡献。尽管大多数人认为这些方法论是相互排斥的（你可以使用zachman、TOGAF或FEA），实际上它们是相互补充的，你应该知道在解决你手中的问题时，应该使用哪种方法。
在你知道一种方法的优点时，你还应该知道它的缺点。因为没有哪种方法在。创建企业架构时能够提供一个完美的解决方案，甚至把所有的方法都加起来也不能提供一种完美的解决方案。这就是我写这本书的原因：弥补那些别人遗漏的东西。
我指的遗漏的地方就是管理复杂性。这些方法可以帮你理解业务过程，通过这些方法使其更好地服务于那些过程。当然，要想它们高效地工作，首先还得针对企业理顺这些方法的次序。这本书就是告诉你如何驯服你的企业达到理顺次序这个目标，这样它们才能够发挥高效的作用。
因而本章就是告诉你当前企业架构的状态。哪些东西工作，哪些不工作，哪些需要进一步完善。
