本书是一本关于如何精简企业架构的书。全书分为两部分。第一部分，作者通过一些直观的问题展示复杂性带来的问题，接着从数学的角度进行分析；第二部分，讨论解决复杂性问题的过程。这个过程就是SIP，即简单迭代分割。

一种全新的思考企业架构的方式。
——Paulo Rocha，Fronde Systems Group公司策略服务部经理

在我们领域，Roger是最具有创新精神的思想家之一。
——Paul Preiss，国际软件架构师协会主席为什么很多IT项目以失败而告终？企业顾问Roger Sessions曾经为数十家大企业提供过解决方案。在提供解决方案之前，这些企业大多在同复杂的项目和糟糕的结果作斗争，而Roger成功地帮助他们改变了这种状况。
他的秘笈是对复杂的问题采用简单的解决方案。根据他的观察，太多的企业之所以失败，都是源于使用了过长、昂贵的工序构建昂贵、过于复杂的实现。在本书中，Roger讲告诉你如何让简化成为核心的架构需求（像性能、可靠性和安全性一样关键），更好、更灵活地满足你的业务。
内容简介
减少IT项目的，使业务的回报最大化。
理解复杂性的数学原理和控制的过程。
鉴别企业构架中的基本业务单位——自治业务能力。
在软件架构领域，作者是一位知名的顾问和专家。他是国际软件架构协会（ASA）的董事会成员，还是该协会《Perspectives》杂志的主编，同时，他还是微软最有价值专家(MVP)。到目前为 止，他写过七本书，其中包括（Software Fortresses:Modeling Enterprise Architectures）》。他出席过世界范围内的数十场研讨会。
创建业务过程和软件系统间的逻辑关系。
采用迭代途径控制，使其带来效益。
软件城堡的10条规则应用到IT解决方案中。
本书中提到的方法论如何拯救现实中的项目。
把精简视作关键的业务财富，使之产生效益。
在软件架构领域，作者是一位知名的顾问和专家。他是国际软件架构协会（ASA）的董事会成员，还是该协会《Perspectives》杂志的主编，同时，他还是微软最有价值专家(MVP)。到目前为 止，他写过七本书，其中包括（Software Fortresses:Modeling Enterprise Architectures）》。他出席过世界范围内的数十场研讨会。

那是最美好的时代，那是最糟糕的时代；那是智慧的年头，那是愚昧的年头；那是信仰的时期，那是怀疑的时期；那是光明的季节，那是黑暗的季节；那是希望的春天，那是失望的冬天；我们拥有一切，我们一无所有……这是查尔斯·狄更斯（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系统，并且它们满足商业需求，那么你的企业架构一定相当棒。如果不满足，祝你下次好运吧！
在其他科学领域里，这种途径根本就是行不通的。没有人会在发射登月火箭之前不通过行星的数学模型计算运行轨道；不通过重力压力模型计算所需的燃料。没有人认为建一座大桥之前不需要进行压力、负载、流体流的架构测试。
那为什么我们不在实现一个昂贵的大企业架构的时候首先通过数学模型来测试它是否有效呢？原因很简单，我们根本就不知道如何来测试。换句话说，站在数学的角度上，我们缺乏对“优”的理解，也缺乏一种测试“优”的模型，我们甚至缺乏“优”的基本定义。

没有这些模型（和定义），就没有方法来验证企业架构，没有方法预算成本，没有方法确保它的交付能否带来商业价值，甚至没办法知道它是否能够交付。这就是企业架构领域有这么多麻烦的原因所在，也是我们经常听到IT失败的原因：项目经费超支、交付延期、无法满足需求等，不一而足。
最近，在一个影响力很大的IT论坛上，我曾和两个高级架构师就企业架构问题讨论过。我问他们，他们的IT项目中有多大比例能够准时地交付，项目符合预算，好钢用在刀刃上。他俩面面相觑，其中一人说，“按时交付、符合预算、好钢用在刀刃上？我觉得我的项目中没有一个项目能够达到这样的标准。”他把脸转向另外一位，“你的呢？”另外一人遗憾地摇了摇头。我也和很多企业的专业人士聊过相同话题，聊天对象包括架构师、首席信息官（CIO）和首席技术官（CTO）。
《IEEE Spectrum》最近有篇文章中写出了如此令人沮丧的断言：看看最近五年新建的软件项目（包括政府项目和商业项目在内）的总投资，我估计项目失败引起的损失至少有250亿美元，甚至可能达到750亿美元。当然，这750亿不是反映在那些超支的项目上（大多数项目都会超支，也不反映在那些延期发布的项目上），相当多的项目都延期发布了。这750亿也不包括那些遗弃后又可能重新启动的项目成本，也不包括那些充满Bug而不得不返工的项目成本。
“Why Software Fails”，《IEEE Spectrum》2005年9月，作者Robert NCharette。鉴于这种情况，我们该如何应对呢？放弃企业架构？Gartner不是预言40%的企业架构会消亡吗？我们该放弃吗？不，我们不能放弃这个领域。企业架构的目标实在是太重要了，我们不应放弃。相反，我们应该解决这个问题：怎样构建优秀的企业架构。
谈到“优”，我指的是五个方面。第一，我们必须定义好一个“优”的企业架构的含义；第二，利用这个定义，建立“优”的数学模型；第三，扩展这种数学模型，使之成为一个至少看起来优秀的企业架构的正式模型；第四，创建一个基于这个模型的“优”的企业架构的开发过程；第五，在实现模型之前，通过模型来验证架构的结果。
以上这几点都是以“优”的良好定义为基础。这儿，我的定义是：一个“优”的企业架构就是一个“简单”的企业架构。在两个能够有效整合商业需求和IT性能的架构中，如果哪个简单，哪个就优秀。两个架构中，较复杂的那个就是拙劣的。
在解决已存在的复杂问题时，我们不应创造新的复杂问题，否则只会越弄越麻烦，毕竟商业方面的问题已经够复杂了。商业活动历尽千辛万苦去适应新的技术，与日益严格、不断变化的需求作斗争。所有这些都是复杂的问题，并且只会越来越多。至于IT方面呢，复杂变成了家常便饭。对公司或组织机构而言，软件变得更加分布式，种类日趋繁多，交互日益频繁。所有的这些都是复杂的问题，并且越来越多。
鉴于业务和软件系统都日益复杂，它们之间的关系也变得更难理顺。业务部门和IT部门处理各自的工作也变得更加专业。他们开发了自己的语言，甚至创造了自己的文化。他们都没有时间关注他们之外的世界。因此，业务部门和IT部门之间的隔阂也越来越大。
在大多数组织里，业务部门和IT部门之间的裂痕正在扩大。大多数读者对这些不足为奇。尽管众所周知，但知道裂痕原因的人却寥寥无几。IT部门责怪业务部门，而业务部门又归咎于IT部门，两边互相埋怨。彼此逐渐不信任，相互指责成了家常便饭。业务部门的人对IT部门提出过分的需求，这样使IT部门的人工作压力越来越大，工作难以完成。反过来，IT部门的人阻碍业务进展，使销售额在竞争日益激烈的环境里难以提升。
其实，问题既不出在业务部门，也不出在IT系统。这根本就是在IT部门和业务部门普遍存在的一个基本问题。实际问题就是复杂，而复杂其实就是每个人的问题。
所以，问题就复杂了。但是复杂的问题，它本身并不需要一个复杂的解决方案。反之，本书的前提就是用简单的方案来解决复杂的问题。复杂的解决方案太麻烦了。
对付复杂问题的杀手锏就是简化。如果能够化繁为简，那么你已经成功了一大半。当然，化繁为简并非易事。本书会教你如何做。
要简化问题，首要事情是把焦点放到简单上，并把它当作核心价值。我们都在讨论软件系统的敏捷、安全、性能、可靠性等重要性，好像它们是所有需求中最重要的一样。实际上，我们应该把简单放到与它们同等重要的位置上。我们在理解怎样让架构系统变得安全、高效、可靠上肯定不遗余力，同样我们应该多花精力让系统变得更简单。实际上，我并不是说简化问题同其他的特性有同样的优先级，而是说它的优先级应该更高。在众多特性中，它才是核心。
就安全而言。如果一个简单的系统不安全，想要让它变得安全并不难。而那些看起来安全的复杂系统往往并不安全，但想让这些不安全的复杂系统变得简单或者安全却几乎不可能。
现在，我们再看看敏捷。那些定义良好、互操作达到了最小化的简单系统，可以把它们以新的方式整合在一起，尽管这些整合方式是在系统创建之初没有考虑过的。复杂的系统就不能以这种敏捷的方式整合，它们太复杂了。当然，想让它们变得简单也不是一件容易的事情。
尽管对一个系统需求来说，简单的重要性非常高，但在架构计划、开发、评审过程中却往往被我们忽视了。最近，我在不少国家和组织做过很多演讲，演讲的对象（至少上百人）是企业架构师、CIO和CTO。几乎每次演讲中我都问过同样的问题：在他们参加过的项目中，是否有人曾经把简单作为系统的一个特性考虑进去。回答是没有。
对简单的寻求还没结束。甚至那些在设计之初就把简单考虑进去的系统（确实，很少系统会这么做）在以后仍然会陷入永无止境的挑战。当系统的性能需要提高的时候，这儿做个补丁；当需要改进互操作性的时候，那儿做点改进。差不多一两年后，曾经简单的系统就会变得臃肿，甚至一团糟。所以，本书不仅仅是教你如何创建一个简单的系统，而且还教你如何使系统保持简单。
首先声明，本书并非适合所有的人。如果你们的系统基本上都能准时交付，符合预算，满足业务需求，那么本书对你来说完全没用。要么，你做的系统比我们讨论的简单得多，要么你已经找到了如何管理复杂问题的方法。无论属于哪种情况，我恭喜你，你属于比较幸运的少数。
最近，我认识了一个人，Kevin Drinkwater，他是Mainfreight公司的CIO。Mainfreight是新西兰最大的跨国公司，它每年给新西兰政府提供的税收就高达5亿多美金。Kevin因为他在IT方面的创新和解决方案的成本效率和敏捷而著称。他曾经一夜之间放弃了公司购买的价值1300万的JD Edwards ERP实现，而用一个25万美金的国产系统取而代之，就因为这事，在新西兰曾经轰动一时。他是ComputerWorld 的年度CIO候选人，也是一位知名的演讲家。同时，Kevin在他的商业部门还是一位值得信赖的顾问，很少有CIO能够享有这种地位。
在由Fronde发起、ComputerWorld新西兰分公司主办的圆桌会议中，Kevin和我交换了企业架构中关于简单性的意见。我们彼此描画了对简单企业架构的看法，结果显示，我们双方都对简化持赞成态度。Kevin就不需要我来传达简化的思想。他和他的IT组织每天都在简单地吃饭、喝水、呼吸。简单就是他们每天所做的事情的核心需求。这也就是为什么Kevin每发布一个系统都能按时、符合预算的原因，而且系统也完全符合业务需求。
如果你和Kevin是同一类的人，你压根就没必要看这本书。然而，这类人少之又少。很有可能，你们组织开发的系统超时、超过预算，并且可能你的技术部门和业务部门不和睦。那么，你非常需要这本书。如果你是IT执行官、IT经理、软件架构师，或者项目的业务分析师，如果你发现你的项目的复杂性成指数增加，那么，你将会发现本书相当有价值。
为何我要说本书相当有价值呢？因为它可能会改变你对企业架构的理解，它可能会改变你在某些方面的观念：为什么我们需要它们？怎样才能做得更好？怎样高效地实现它们，它们怎样才能提供更多的业务价值？
所有的这些，都归于简单。简单是核心价值，简单是推进器，简单是业务价值。正如一个大航空公司的首席架构师曾经对我说过的，“我同很多人、很多组织讨论过企业架构的问题。他们讲的都千篇一律，没有一人切中要害。你是第一个与众不同的人，也是第一个一语中的的人。”其实，并非我一语中的，而是简单。
怎样让问题变得简单呢？很简单，避免复杂性。认知它、理解它、消灭它。等你读完这本书的时候，你就会知道怎么做了。你会从数学的角度理解复杂，从数学的角度理解以复杂性为基础的模型，从数学的角度理解消灭复杂性的过程，从数学的角度理解那些确保复杂性不再光临企业架构的方法。到那时候，你的生活、你的架构，都会变得更简单。
本书表面上是在讲企业架构，实质是在讲述更基本的东西：简单。本书中提到的控制复杂的方法不仅可以成功地应用于商业架构，还可以应用于IT架构。不过，如果它应用于某个层面（这个层面包括既应用于商业架构，也应用于IT架构），它的效果将会充分发挥。这个层面就是企业架构的层面。
本书组织结构
本书开始从一个比较直观的复杂性问题着手，接着转到一个正式的理解，最后转到一个以过程为中心的讨论。这个特殊的过程叫做SIP，也就是简单迭代分割。SIP是唯一一个以问题复杂性为中心的企业架构方法论。
第一部分，“复杂性问题”给出了企业架构上关于复杂性问题的基本理解。
第1章，“当今企业架构”介绍了一般的企业架构，包括当今主流的方法论和它们在对付复杂性问题的优缺点。
第2章，“初识复杂性”以一种非数学的方式介绍了划分、遍历、简化的主要内容，以及在复杂性控制中，这三者之间的关系。在读这章的时候，你会发现你在企业架构方面可以学到很多，尤其是执行官午餐、紧急救护和国际象棋这几节。
第3章，“复杂性的数学原理”正式地从数学角度介绍复杂性。别担心，本章并不需要很深的数学基础。文中涉及的掷骰子、分割、布尔问题这些内容都很通俗易懂。而且，所有这些都会从基础讲起，它们都是基础的复杂性模型。这些模型帮助我们更好地理解：当维护企业划分时，复杂性是如何改变的。
第二部分：“简化的需求”描述了我提倡的解决企业架构复杂性的一种方法论。
第4章：“企业划分的ABC”，介绍了自治的商业能力(Autonomous Business Capability，ABC)。ABC是划分子集的企业等价。理解了ABC的属性和它们之间的相互关系，我们就能创建一个以简单为核心的企业架构。
第5章：“SIP过程”详细地描述简单迭代分割（Simple Iterative Partitions，SIP）。这是我们控制复杂的方法。它着眼于数学复杂性，基于鉴别、操纵、再划分和再认知ABC。
第6章：“复杂性的案例研究”。本章举了一个相当复杂的项目实例，IT方面的国家项目，英国的国家保健系统（National Health Care System）的一部分。如果你认为你见过复杂的项目，先别忙着说。这个项目已经花费了几十亿美金，把好几个公司带到了财政崩溃的边缘。说不定，最后将会以世界上最大的IT失败项目而告终。本章将讨论到底是哪儿出了问题，如何运用SIP方法挽救这个项目。
第7章：“警戒边界：软件城堡”。ABC的软件组件，讨论在维护自治系统的边界时面临的挑战。我将会讨论一种称之为“软件城堡（Software Fortresses）”的模式，它允许你把SIP的简单数学模式应用到软件系统。
第8章，“复杂性展望”，回顾本书讲到的关键点，怎样能够把你带到对复杂性的更深层次的理解，使用它使简单融入到公司文化中。
本书包含一个附录，“本书一览”，它对本书中用到的主要数学规则、SIP方法论、软件城堡模型作了简单的描述。读完本书之后，你就成了反复杂联盟中优秀的一员，面对各种难题，你都可以使用你定义的企业架构来简化它。

一种全新的思考企业构架的方式。
－－Paulo Rocha，Fronde System Group公司策略服务部经理

在我们领域，Roger是最具有创新精神的思想家之一。
－－Paul Preiss，国际软件构架师协会主席

为什么很多IT项目以失败而告终？企业顾问Roger Sessions曾经为数十家大企业提供过解决方案。在提供解决方案之前，这些企业大多在同复杂的项目和糟糕的结果作斗争，而Roger成功地帮助他们改变了这种状况。

他的理论是什么呢？就是复杂的问题需要简单的解决方案。根据他的观察，太多的企业之所以失败，都是源于使用了过长、昂贵的工序构建昂贵、过分复杂的实现。在本书中，Roger讲告诉你如何让简化（作为核心构架需求，简化和性能、可靠性、安全性同样重要）更好、更灵活地满足你的业务。

减少IT项目的复杂度，使业务的回报最大化
理解数学复杂度和控制复杂度的过程
鉴别企业构架中的基本业务单位－－自治业务能力
创建业务过程和软件系统间的逻辑关系
采用迭代途径控制复杂度，使其带来效益
软件城堡的十条规则应用到IT解决方案中
本书中提到的方法论如何拯救现实中的项目
把精简视作关键的业务财富，使之产生效益

关于作者：
　 在软件构架领域，Roger Sessions是一位知名的顾问和专家。他是国际软件构架协会（International Association of Software Architects，简作IASA）的董事会成员，还是该协会Perspectives杂志的主编，同时，他还是微软最有价值专家(MVP)。到目前为 止，他写过七本书，其中包括《软件城堡：企业构架建模（Software Fortresses:Modeling Enterprise Architectures）》。他出席过世界范围内的数十场研讨会。
　 更多资源，请访问：http://microsoft.com/mspress.

Roger Sessions：暂无简介

张雄：暂无简介

前言
致谢


第一部分复杂性问题
第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信条