1. 综述能字诀。念、法、技、导、形、连、考、能。能力主要有三：1.设计能力架构师---我得有设计能力，得有架构师团队、2.治理能力管理部，得有个组织，专门做治理，按流程去办事得一个部门。3.决策能力委员会，架构得变更需要决策，不能随意更改，需要审批。在不同的能力线当中，如果出现数据流的冲突，a b两个部门到底谁给这些公共数据？需要决策能力来仲裁。决策能力委员会，一定是高层领导的代表构成。现实当中，这种委员会，一般是民主制+君主制的结合体，往往是一个上层的代表。解读：架构的三种能力，如何来沉淀呢，1.培训，用来入门，2.是实践中成长。古人云，真正有所悟，需要做到：知止而后定，定而后能静，静而后能安，安而后能虑，虑而后能得。知止而后定，先培训一遍，让你知道。然后定，作为你今后工作得一种规范和标准。然后安，安是开展工作，按照这种标准去开展。安而后虑，工作中不断地总结。虑而后得，通过工作中得总结，才能真正有这方面得收获。那个时候就成为一个真正得架构师了，无论是做架构设计、架构治理、架构决策，都可以成为一个合格的人了。如，广州某通讯企业，要搞教务管理部，把相关材料直接套用，属于太着急了，得慢慢来，知而后定可以，但不能就认为有这个能力了。要拿试点得东西。试点示范出样本，全局推广定标准。日常工作为常态。这是三步走得过程，不能太着急。有一本书中这样比喻：我们应用架构能力的提升过程，读万卷书，不如行百里路。学得再多，不如按照所学去实践一下。行百里路，不如高人指路。高人电波一下，就是弯道超车。高人指路，不如自我求。要学会不断地自我总结。这个时候就是专家了。读万卷书、行百里路、高人指路都是辅助作用，自我取物地人才能是最高级别，按照级别是自我优化级别的人，一定会成为1等1的专家。2. 建立架构能力/设计架构的能力解读：建立架构，建立，可以改为设计。设计架构的能力。设计业务架构、设计数据架构、设计应用架构、设计技术架构。设计能力，依赖架构师。既有通晓的总师，又有分项的架构师。沟通管理、文档管理是通用人才。专项人才是：业务应用数据技术。3. 架构治理（能力）解读：第二个是治理能力，依赖于管理部，放在业务能力口，还是放在信息管理口？放在信息管理口，做赋能、做引导性创新的职能。需要做一些组织结构的调整。按照标准去推进，心里有底。30年养出来的套路，比单纯经验主义要强。就这样推动，走的是正确的道路。推而不动，就和治理管理部没关系了，是环境问题。只要能推动，就帮助企业真正打通道路。治理能力管理部。有时候要求一定是领导+业务部门共同去治理，带领大家往前走的，总归要找个第三方。注意是内部的第三方。业务能力建设，是给大家今后发展和创新企业必然的一个导向。企业中心建职能，客户中心建能力。今后是拼客户的时代。客户纯天然不会选择我们，但我们要学会选择客户，这是一个方式问题。4. 架构委员会解读：决策能力，委员会。我们在相关过程当中，我们得建立一个民主制+君主制（集中制）的决策机制。民主制是投票解决问题，君主制是用领导力解决问题。在组件委员会的时候，领导层是哪些层，另外民主决策机制是什么。委员会可以跨业务主线的运营决策，跨业务部门，一块决策事情。架构委员会放在哪里好呢？有这几种类型选择：1.放在党委下面。2.放在总裁下面。3.比普通业务部门高半级的一个流放办公室的领导小组，既没有放在总裁办，也没放在党委，独立出来的一个流放办的领导小组。目的是形成一种自上而下的工作模式。有利于协调和推动。有利于形成我们未来发展的一个执行力。解读:决策过程中的主要内容有：1.架构之间的冲突问题，如，不同能力支线的数据流方向不一致问题，业务流方向不一致。2.哪些应该作为共性积累。哪些应当做成灵活型的。哪些重点关注技术赋能。这些都是在决策层级统一夺定的事情。比如某个高层，发起架构工作请求。提交给谁？提交给委员会.委员会如果接受，就可以做 ，拒绝就得搁置。不是某个领导说干就得干。找个角色是非常有帮助作用得。让专业得委员会，决策专业得事情。5. 架构合规解读:三大能力，架构设计、架构治理、架构委员会，共同推动我们走向一个 时代---架构合规时代。散而不同，散而不通得时代必将过去。同而不散，通而不散的时代必将到来。尤其是企业现在的数字化，很多企业数字化没有清晰的意识到，面向业务流，构建数据流这样一个数字化的本质。仍然停留在一些探索道路上。如果我们有了一个企业架构，把企业数字化，明确为面向几大业务流，推动数据流的建设。走业务集成支撑的管道，就可以大跨度的明确向前推动。需要引领做架构合规，很多企业把数据治理+大数据，作为企业数字化的一个标志。这只是看到了两只腿，就认为看见了全人类。矮视了企业数字化。真正的数字化人会认为，数字化解决的是企业跟客户的关系。信息化，总师先解决客户跟企业的关系。方向不一样。因此，在新的道路上，必须记住，企业数字化，是面向以客户为中心，构建一系列价值流的过程。何为价值流：让数据流赋能业务流的一个新型流程的简称。简单记一下：价值流=业务流+数据流。这是我们新型价值流的建筑。就是为了业务流当中实现数据驱动，让数据流反哺业务，数据必须通畅。因为企业数字化，从形态上来讲，体现出的企业变迁---是用数据流，替代人作为员工。让数据流作为企业的员工。不是让人作为企业的员工。智能制造过程中，让机器人作为企业的员工。企业数字化过程中，是把数据流作为企业的员工。推进企业信息化和数字化，势必会带来大量企业人员的转移。所以我们要让全员具备数字化的素养，成为数据运营能力的专业人士。而真正干运营的，让员工变成做数据运营的，跑路的事情交给数据流，以前跑路的大量交给人，骑着摩托车，汽车膜拜，解决从子公司到总部的事情。表面上挺忙。但是我们用数据流，这些人就可以专门做数据运营了。把数据能力发挥的更好，这是时代问题。结构合规流程：解读：架构合规，1.寿险要识别责任组织，是分工协同，要识别每一条业务能力建设主责业务单位是谁，相关部门有哪些，下属单位有哪些。我们要走业务驱动新型能力建设的时代，我们还要培养出一批企业架构总师，做企业架构的人要培养出来，从某中层面来讲，干系人队伍有哪些，塑造出、参与到企业架构中的典型干系人，典型的有，相关部门的负责人。主责部门的领导，还有分管相关工作的企业高层，都是我们关注的人。另外架构合规注重，当有了企业项目之后，用公平公正公开的检查单，指导下面的人去遵从。还会召开一系列的架构评估会议，来实现架构合规评估的审查，走比较正式的模式。在进展过程中，我们架构师评估，实际上是架构治理职能和项目经理管理，或者说项目实施项目的项目小组之间的日常。需要沟通推进的事情。考量哪些合规，哪些不合规。用正式评估检查的方式去推动，用这种方式持续去考量架构合规，在我们推进过程如何整个这件事情决策机制还把控在架构委员会手里面。解读:要做好整个合规流程，需要我们有一批专业人士，架构技能的拥有者。念、法、技、导、形、连、考、能。八个要素，我们就可以。
1. 概述：考字诀，我们在做架构设计的时候，所有的架构师，尽量不要走原始创新，要学会借鉴他人，假他人之志，而成自己之时也。借助已有智慧积累，做出自己的目标成果。考字诀是指一定要去沉淀架构资产参考库。解读：有了参考库，我们做支持的时候，就可以站在已有设计成果的肩膀上去做。比如B企业架构，我们拿出以往的10个案例来。2.TOGAF给出了两个典型的参考:第一个参考：第一个参考解读：第一个：1.也是按照连字诀进行分类它是基础级的，叫技术参考模型，TRM。2，指导基础架构设计，3.有利技术架构，明确位置与分类---左开放、右安全、上门户、下云化，具体架构内容有哪些平台构成，不是这个参考所关心。第二个参考：第二个，叫III-RM，注意，参考模型都叫RM，集成信息基础设施参考模型，什么架构关注集成？应用架构。它的作用：开放互联用标准，协同访问用代理。你别直接连，加一个中控措施，叫代理。应用集成器叫---代理应用。比如应用网关。IIIRM有两个补充点：1.打造无边界信息流（数据流）为宗旨---集成的目的。2.强代理管权限、弱代理管身份。强代理，管权限和访问控制，做集中访问控制。强代理，又名企业服务总线；弱代理，管身份。又名，目录管理。现代的分布式服务架构和微服务架构都是这个模式，不是总线式的。3.宗旨：解读:应用架构为什么要集成？因为要打造无边界信息流。当你要获取togaf信息，每天收到的邮件，都是无边界信息流大会，召开了xxx。间谍证书/身份。以上是考字诀
1. TOGAF架构内容框架综述内容框架模型主要解决我们在内容上的三统一问题，企业架构师各做各的事情、各做各的架构设计，那么如何保持相对一致而且结构化的方式？那么就是三统一：1.统一概念、2.统一视图（大家都做数据架构，那么我们统一出xx图）、3.统一分类，把做出来的东西形成统一的分类架构内容框架概览:解读：架构内容框架整体的作用，是让整个企业架构团队，一中四分来管理，做出来要形成一致的、结构化的形式。就是所谓的内容框架。架构元模型：解读：这个图是比较标准的概念+视图的元模型。企业在开展企业架构初期的时候，这张图需要裁剪定下来。每个企业都要定，要打出这张图来，这个时候主要是企业架构组和甲方信息部门一块来定，基本能定出123来。业务上，主要用到的概念是业务域，业务域是我们的一个能力主线，叫关键能力。业务域再往下细化出业务职能（各业务要承担），业务职能用来保证业务域内部的能力活动顺畅运转。然后把每个业务部门承担的每一个业务职责，定义为业务流程项，业务流程内部又细化为业务活动项。业务域划出的业务流程，也可以按个性叫能力主线，主线分职能，职能内部有流程，流程内部有活动---这些就是我们自己定的概念。我们出的业务能力视图，代表我们业务能力内部有什么样的要素。然后再按照组织结构角度，按照职能角度，把这个要素进行分割分化，看能不能落地，一旦能落地，就可以进行各个流程的建设，各自开发业务流程的开放，就落地了，这些就是业务上的概念和业务扣的视图。数据上，按照业务域产生数据域。数据域跟业务域用相同的划分，能否数据域偏离业务域呢？是不允许的，看图中箭头，就是要顺着业务域产生数据域，不允许偏离。有了数据域之后，我们把每一个数据域（或者说业务能力主线内部），按照生产关系，去找数据的构成。比如人力资源生产什么数据，财务生产什么数据，这些生产数据放在一起，叫做一个大的数据主题（一个数据的分类划分），即数据分类。然后数据主题再细化，就是数据实体的概念模型，概念模型又称实体关系模型，它主要关注什么关系呢？两种关系：主外、聚合。主外类似传统的主外键。一个数据为另一个数据提供主数据，比如身份证，为住店提供住店数据的主数据。聚合是指分散的数据统计统计为另外一个数据，就是聚合关系。是为了某个目的来聚合的。这些就是数据口的概念和视图。应用上，也是顺着业务域来划分应用域。应用的分类也是顺着业务的分类。每个应用域有哪些应用，也要梳理。然后再看每个用用里面有什么样的构成（模块/功能）。模块是粗粒度的，功能是细粒度的。然后再出交互，交互视图对应的是业务交互。我们把业务流程主线当中所规定的业务交互，反映在应用之间的应用交互上。统一概念，统一交互。技术上，技术跟应用是承载关系。建平台，定标准，上应用，通数据。通过支撑应用，集成运行，来达到数据共享贯通的目的。用平台环境来支撑应用集成运行，顺着每个平台的作用，我们会出技术支撑视图。每个平台出一个技术支撑视图，如何支撑应用集成运行，支撑数据共享贯通，标注支撑视图。我们把有哪些平台，叫技术框架视图。平台上提供哪些服务组件，叫技术组件视图。未来的系统，希望在平台之上，就需要部署相关架构元素---概念：解读：图中这些概念，就是统一概念，统一视图。 统一分类:解读：统一分类是指，架构工作产出的分类。做出来的东西，大家需要知道怎么分。分类的需求有很多种，这里只关注：日常产出构建块、阶段产出为制品、最终产出交付物。这是三个分类。我们平时架构师做出来的一个个架构设计单元，叫做构建块；构建块不断地涌现，不断地完成，达到了某个阶段性，比如业务架构阶段产出了，新系统架构阶段产出，技术架构阶段产出了，安全架构阶段产出了，服务架构阶段产出了，就叫做制品。当各阶段产出逐渐完善，并获得认可之后，就可以叫做交付物了。最终是通过架构合同来衡量地，如整个委托给合同公司，架构合同中约定了交付什么。比如我们在些一个材料地时候，今天早上就可以反馈，要明确我们地最终交付物，即完成标准，里面会约定交付物。中间做出来地产出，分为一维目录、二维矩阵、三维成图地说法。交付内容：构建块解读：在架构内容框架上，我们会把一个个地设计单元，放在可重用地架构存储库中，叫构建块存储库。做出来一个就放进去。然后会随着我们阶段化内部工作持续完善，会形成阶段制品库；阶段制品库逐渐完善，会形成交付物。都会放入存储库。所以，我们日常有，构建块存储库、阶段制品存储库、交付物存储库。这样来划分分类。有利于我们对工作内容地一个划分总结： 这些就是内容框架，就是三统一。就是形字诀。下一节是连字诀，企业连续系列
0.综述：四个向导四个向导：1. 裁剪-- 原则、方法、交付物。 原则立足我们原则模板体系进行裁剪选择，方法立足ADM框架，增补哪些步骤。交付，我们将来出哪些视图。 裁剪关注的是多少问题 2. 迭代 迭代是我们整个葫芦图中，做好接受、创建、使用、维护四件事情。这四件事情都谈及了迭代的问题：怎么做好，怎么做成共识，是比较难的一件事情，要想办法迭代去突破，最终变成大家共同认可的共识。 迭代关注的是先后问题 3. 层次 层次是指，当我们面对一个企业架构的时候，学会做好工作分解。首先把企业战略分割为业务战略，业务战略再分割为能力规划，归根到底，我们企业架构是顺着能力规划来做提升设计的。比如一个企业战略，你为整个战略做一个企业架构？没这种做法，做不出来，必须企业战略分割为业务战略，业务战略再分割为能力规划，顺着每个能力规划再做架构设计。出业务架构、出应用架构、出数据架构、出技术架构的统一支撑 4. 指导 指导，是指，如果我们在构建四大架构之外的架构，我们应该怎么做。用四大架构找关注，四大架构来判断设计的完备和满足。找关注、判满足，这是它的一个指导作用。比如说安全架构，我们在设计过程中经常考虑安全，安全未来在企业更加是一个整体环境的问题了。我们如何找安全关注点呢，我们要从业务安全、应用安全、数据安全、技术安全去考虑。当出来一个安全设计之后，我们要用业务视角安全否、应用视角安全否、数据视角安全否、平台视角安全否来进行衡量是否满足。27001等体系，是不是告诉我们要构建安全管理体系，构建安全顶层设计，利用这四个角度给它去衡量，有利于发现不完备之处。这就是它的指导作用，类似的都是一个道理。 ADM中的技术与支持向导的目的、区别：1. ADM技术：主要是指ADM周期各阶段所用到的策略、方法、技能、工具等，用于更好地形成各阶段交付物 2. ADM支持向导：主要用来ADM进行调整或扩展、以使用特定场景地需要。应用ADM支持向导目的是审查ADM的过程和输出看其是否适用，然后对他们进行裁剪以适应具体企业的环境。 3. 因此，ADM中技术和支持向导两者是有差异的。ADM技术用于各阶段；ADM支持向导用于ADM方法应用定制、裁剪。 解读:ADM四大向导，和32个技术的区别。32个技术是做法、向导是用法。到底细节怎么做，用32个技术；整体ADM这套方法怎么用，就用向导。 1.ADM指引介绍ADM指引：1. 一项重要的考虑是，ADM各个阶段的顺序在一定程度上是依赖于企业架构领域的成熟度水平的。 2. 各阶段的顺序也可根据企业的业务和架构原则来定义。 3. 企业可能希望将ADM和另一套企业架构框架联合起来使用或对ADM剪裁后再一起使用。 4. ADM是构成公司治理模型的众多公司过程中的一个。ADM补充并支持了其他的标准项目管理过程。企业应对ADM进行裁剪，以反映它与其他管理过程之间的关系和对这些过程的依赖。 5. 在外包的情况下，ADM可能被某个主承包商或领头承包商要求必须使用，那么就需要对其进行裁剪，以在承包商现有的做法和外包企业的需求之间取得合适的折衷。 6. 对于希望使用“精简”版ADM的中小型企业，应对ADM进行裁剪，以适应这类企业环境较典型的较低的资源和系统复杂度水平。 7. 对于由很多独立但互相联系的“企业”构成、这些企业又处在一个整体的协作框架之中的大型复杂企业，需要对架构方法进行调整以充份考虑这类企业的复杂情况。这种企业通常不能被视为一个单一的实体，需要使用一种更加联邦的方法。 解读：首先是裁剪的问题，ADM是一个通用性的架构开发框架，一个企业他的实体使用中有差异性。比如稳态业务，业务架构先行。敏态业务是数据架构先行。这里就体现了方法的微调。在比如，我们希望考虑扩展安全架构、服务架构、网络架构、通信架构、基础架构、部署架构等这些非核心架构的。我再ABCD中间加上了第一片/第二三四片等等去扩展。这个时候我们阶段增加了，这也叫裁剪。另外，企业也有其自身的特殊性。阶段顺序/阶段多少去裁剪，裁剪的时候也谈到了一系列特征。比如上面第3个，如果一个企业比较注重信息化管控体系的，不光有企业架构，还有27001，iso29000体系，甚至还有pmbok项目管理的体系、pgmp项目组合管理的体系，这些体系和企业架构的关系，要融为一体，就是我们治理框架和其他管理体系的一个裁剪融合问题。第4是说，在这个裁剪过程中，从标准层面，架构带出来的一些治理标准和其他标准的信息融合问题。第5是说，外包管理当中，用企业架构管理外包。自主可控。企业架构对外包多样化管理，就是一个自主可控的事情。在外包管理上，企业架构帮助企业进行信息化，面对多样化外包支持，走向自主可控第6是说，小企业也是可行的。比如企业比较小，是一个零售商，有7-8家店，实现连锁运行，可以做一个企业架构，保证24小时稳健运行的能力。小企业只是能力单元的规模性相对比较简约，但同样重视能力建设，它可能只注重一个能力，比如就注重零售能力，把零售做强了，内部的作坊不用改。第7，讲的是企业间的联邦关系（联盟）。比如作为一个行业，企业间共享库存，把物料的存量共享，价格指数，共享市场行情，不共享客户，但是可以共享行情等。裁剪总之，适应企业特定的状况。形成特定版架构开发过程的一个定位问题。2. 在ADM中应用迭代ADM支持一系列以迭代为特点的概念，爹地的场景可能包括如下图：迭代本身是一个共识导向的。古代是为了面向《正合》，是指我们如何在正位上让大家达成共识。这就是最早的迭代的目的，迭代是为了共识化。如果我们纯天然，共识环境，共识认知、共识背景比较强。那么我们迭代的频度肯定是比较稀松的。如果我们忍者比较脆弱，需要不断地巩固想法，最终才能夯实共识，那么迭代地频度就会加大。从迭代密度上，可以分为：能力建设发生之后地周期型迭代，还有阶段间迭代，我们在上下文之间，设计过程中、迁移规划过程中、治理过程中，都可以不断的去迭代，这叫阶段间迭代。还有阶段内迭代，是指，我们特别强调，在每一个做架构设计的内部过程中，要多次寻取交互。还有团队间迭代，是最为密集的迭代。是指甲乙双方协同工作。它对供需的诉求，是日常依赖性的，密集的。简单记下四种迭代的名字：1.周期性迭代、2.阶段间迭代、3.阶段内迭代、4.团队间迭代四种迭代：解说：迭代本身需要有四个共识，分为四种迭代；第一个是愿景共识，需要上下文迭代。上下，指搞定领导层，必须授权达成共同的xx能力愿景诉求。达不成则需要不断沟通、洗脑、引导。这叫愿景迭代，形式上叫上下文迭代。第二个是架构的定义共识，叫定义迭代。第三，迁移规划，架构的第一个用途，就是用来迁移规划，是共识，就叫迁移规划迭代。第四，治理体系是共识，需要搞治理迭代。以上是四种共识，四种迭代，同时迭代有四个位置：两种迭代风格：解说：两种风格，我们在架构设计过程中，做架构定义的时候，是先定义目标架构，还是先定义基线架构。有一个判断标准：我整个能力规划是大创新，还是小创新；是大的变革还是小的变革。变革的幅度多大。有如下判断条件：第一个是战略，第二个是资产。战略是未来的路标，资产是前进的路线。比如一个人敢放心的往前跑，必须看到这两者之一。可以面向目标先行的策略，看到前面有个坐标等着你呢。第二来讲，你脚底下已经有一个顺畅的罗马大道，直接接着跑就行了，鲁迅说，走的人多了，脚底下就是路，跑就行了。如果面对前方足下，既没有远方的路标，又没有足下的路线，该怎么办，该去哪里，那么只能是问题驱动，摸着石头过河，趟着走，看出什么来，识别出什么问题来，我就改进什么。当我们战略含混，资产较少的时候，那我们就基线先行。两种风格：战略明确，资产丰富---》目标先行，自上而下、目标为天，基线为地。战略含混，资产匮乏---》基线先行，自下而上如果一个企业，领导都是随性主义，即使让你搞企业架构，但是企业的战略又不明确。就基线先行，先把现状梳理出来。通过找问题，问题是要解决的，走问题驱动。假如是一个大型企业，我们发展的变革，及其深化供给侧改革、要求方法转型风险、保值、增值。战略明确了，而且同行经验也比较丰富，就可以先做目标架构，甚至基线架构，以往的积累已经有了，关注做规划支持，就把中心放到目标架构之上。3. 在企业不同层次上应用ADM使用ADM的意图是希望把它当作一个模型，来支持企业不同层次上架构的定义和实现。因为开发一个单一的架构来满足所有利益相关者的需要是不太可能的，所以必须把企业划分为不同的区域，每个区域都可以用一些架构来支持。解说：层次是指，我们整个企业架构在完成空间上有三个维度:主题、时间段、细节层次。主题是指我们的业务种类，可以理解为我们的业态。比如我们企业是7+2，一共9个业态。某些企业可以发展出10个业态。9个业态占收入的10%，一个业态占收入的90%，有这种类型的企业，就是它有主业，也有副业，是主副业多业态发展的主题。时间：我们企业架构的规划设计，需要放射几年，要识别出几年能够支撑起企业的发展路径和阶段。细节：细化，层次问题，细节粒度。所以架构，在完成空间来讲，有这三个维度来定义。要拆分成3个层次。主题看多少，时间看长短，细节看粒度/粗细。解说：三个层次，我们面对企业做整体架构，我们要把它的整个战略先分解，分解为业务战略，每个业态就是一个业务战略，业务战略再分为能力规划。最终还是面向能力的，企业架构是在能力规划层工作的。战略能力、架构行动四个层级。战略分为企业战略和业务战略，企业是按照：人力资源做了一个能力规划。人力资源就是企业的一个能力，忘掉部门，忘掉职能，它是一个能力。能力是跨部门的、跨层级的，我们要按照能力进行思维。战略看全局，分段看业态，能力看单元。这些就是我们能力的规划问题，归根到底我们是做能力规划，是面向特定能力建设做规划的。一定时期，我们的选择比较少，就有十来个能力去做架构规划就不错了。这些能力，要说明有助于发展什么业态。这些业态的战略，有助巩固和发展企业战略的布局层次划分解读： 在企业开展架构的时候，初期预备阶段，我们就要把能力的范围选定出来，用层次的思维，来理解整个企业战略分为什么样的业务战略，这些业务战略里面，重点是哪个业务战略，业务战略重点打哪个业务能力，最终能力组合确定出来。从发展角度来讲，需要这些层次。分解结构解读：战略架构分解为分段架构（又称片段架构/业泰架构），业态架构分解为核心能力的规划（能力架构）4. 指导---安全架构与ADM解读:指导，去面对安全架构、服务架构等典型扩展架构，需要做相对应的一些努力。安全架构---在企业内部，已经成为新时期顶层设计的热门话题，利用ADM方法如何帮助建设安全架构呢，我们体现在两点，第一个是识别关注点；第二是判断设计满足，利用核心架构视角能很好的帮助我们来开展这个工作。尽可能的让安全架构师，进入到架构项目当中去理解，让他知道企业架构对他带来哪些帮助。安全架构和其他架构一样，利用四大视角去识别关注点（BDAT），同样利用四大视角去衡量设计。安全顶层设计中，需要看业务维度/应用维度/数据维度/平台维度，是否充份展现和满足了。安全架构的一个实例：解说：这里面是7A一个R，用企业架构四大核心架构的业务/应用/数据/平台综合视角，帮我们找到了更加完整的安全关注点。这个图就体现了我们ADM对识别关注点的作用。解下来就可以识别满足SOA服务架构的一个实例：解说：服务架构是这样一个模式：传统服务是为了做分割，现代服务是为了做转型。传统服务把一些要素分割成一些服务单元。现代服务是从企业信息化方向来讲，从面向内部产品+职能，转型到面向客户+市场，做强了企业对外的能力。传统企业，是企业内部内控体系总结为中心搞信息化的，注重协同办公，所以传统服务做的是分割。所谓分割，就是把，业务、应用、数据、技术 有关的要素分割为一些服务单元，有利于共享和隔离变化，其价值体现在：传统服务注重，明确共性，隔离变化。现代服务注重数据聚合与资源聚合，比如说面对客户，客户想要的是一体化的综合视图，那么我们就把给客户创建单窗口综合视图作为一个服务，内部的用户/外部的客户，都有自己个性化的工作场所。单窗口就作为服务了，拼的是数据聚合、拼的是资源聚合。回到服务本身来讲，服务是我们信息化道路上，走的是服务化的特色，那么怎么去找服务呢？怎样衡量服务架构设计的完备性呢？答案还是用我们四大分析架构，分为业务服务、应用服务、数据服务、技术服务（平台服务）企业架构的工具---协助soa解读：企业架构为我们识别更加完整的服务关注点、更加完备的服务架构时间满足指明了一种选择。
32技术之24：基于能力的规划再阶段E和F中起到重要作用的是一种基于能力规划的原则、确定和规划企业转换的具体方法，这是一种聚焦业务成果的规划技术。它是业务驱动和业务导向的，它将各个业务线所需的力量结合起来，一道道企业期望的能力。它适用于大多数（甚至所有）的企业业务模型，尤其再需要具备快速响应的潜在能力（例如，应急准备单元),或相同的资源被投入到多种能力中的组织中有位有用。通常业务场景技术被用于发现和优化对这些能力的需要。解读:它再E和F角度，让我们做发展规划的时候，是：面向能力交付，定好阶段划分。每一个阶段交付的能力叫一个过渡架构。我们在能力规划过程中，你要知道我们在做发展规划，和以前交付系统不一样，系统上，我们叫交付能力，靠能力的落地，能力的展现。那所以我们来看，在做规划的过程中，我们面向未来的能力，我们阶段性划分是一系列能力增量的达成。每一个能力，是我们这个阶段性达成某种能力的增量：要完成一些列项目的组合。所谓跨项目组合：因为每个能力既涉及到业务流程改造、还涉及到数据治理、还涉及到系统建设、还涉及到所依赖的平台建设32技术之25：迁移规划技术阶段E和F中介绍了多种支持迁移规划的技术。下面各小节对这些技术进行了描述。解读：迁移规划技术，主要是，面对迁移规划，我们需要做好四个参数的细化：1. 时间进度规划2. 预算与投入规划3. 价值/目标规划4. 风险、保障规划迁移规划技术，是在阶段性划分的条件下，每一个项目，都要细化的去做这个四个规划。迁移规划技术，在提交领域，又叫tcvr技术。t是time，c是预算，v是价值，r是风险。32技术之25.1：实施因素评估和推论矩阵创建实施因素评估和推论矩阵的技术在阶段E使用，用来记录影响架构实施和迁移计划的各种因素。矩阵应包括影响因素的列表、他们的描述和推论（结论），这些推论指出了制定计划是必须考虑的行动或约束。示例矩阵：解读：我们如何排号进度先后、衡量价值高低、识别预算多少、分析风险状况。 我们往往先有一个推论（我到底要实施什么，我有一个推论），通过推论去找进度先后、价值高低、预算多少、风险影响。实施因素，就是我们要干的一系列实施行为，比如有什么样的流程建设、系统建设、数据项目、数据治理的项目、平台类的项目，都是实施因素。推论：整个过程中实施因素会带来什么影响。推论后有利于我们对四个参数的细化。tcvr是得益于实施因素和推论矩阵的应用32技术之25.2：整合差距、解决方案和依赖性 矩阵创建整合差距、解决方案和依赖性矩阵的技术，使架构师能够将各架构领域差距分析结果中所识别的差距进行分组，评估可能的解决方案、以及一或多项差距件的依赖关系。这个图表展现了一个例子。在创建工作包时，可将这种矩阵作为一种规划工具。识别出的依赖性关系将驱动阶段E和F中项目和迁移规划的创建。解读:有了实施因素评估和推论矩阵的基础，我们就开始整合分析他们的依赖。整合差距、做好依赖分析。依赖意味着进度先后、价值高低、风险和投资者倾斜32技术之25.3：架构定义增量表创建架构定义增量表的技术，使架构师能够规划出一系列过渡架构，概要地描述出在特定时间点企业架构的各个状态。应绘制类似如下表，列出各个项目，然后再各过渡架构中对其分配增量交付物。解读：有了25.2，最后我们按照先后的规划，把我们每个过渡架构项目组合的计划情况做出来。把每一个过渡架构/某种能力所要完成的项目组合-----一般叫架构定义增量表，它回答了，某种增量过渡能力需要完成什么项目组合。32技术之25.4：企业架构演进状态表创建企业架构状态演进表的技术，使架构师能够使用技术参考模型（Technical Reference Model,TRM)来展示不同层面架构的建议的状态。应当绘制类似下表，列出企业中用到的所有TRM中的付物，各过渡架构和建议的转换方式。应当描述所有SBBs的交付和它们对这些付物的影响。并且应对它们进行标识，以展示企业架构进展的过程。下面这个例子中，当已经达到目标能力时，将该SBB标记为“新增”或“保留”；当企业能力正过渡到新的解决方案时，将其标记为“过渡”；当能力被取代是，将其标记为“替换”。示例：企业架构演进状态表32技术之25.5：业务价值评估技术这种评估业务价值的技术基于价值指标维度和风险指标维度来绘制一个矩阵。如图，价值指标应当包括如与原则的符合、财务贡献、与战略的一致性，以及竞争地位这样一些标准。风险指标应当包括如规模和复杂性、技术、组织能力，和失败的影响这样一些标准。应对每一个标准分配单独的权重。指标及其标准和权重应由高级管理人员制定并批准。在选定这些指标前，应寿险制定决策的标准，这一点非常重要。解读：价值一定要分先后，分高低。预算一定要分出倾斜来、进度上分出先后来、风险性也要识别出影响来。这是一系列的。32技术之26：实施和迁移计划实施和迁移计划在阶段E和F被制定，它提供了实施过渡架构所描述解决方案的进度表。实施和迁移计划包括了时间、成本、资源、效益和实施的各里程碑。实施和迁移计划的一般内容包括：实施和迁移战略战略实施方向实施排序方法与其他管理框架间的相互关系使架构和业务规划相协调一致的方法整合架构工作的方法使架构和项目组合/项目管理使架构和运营管理相协调一致的方法解读；迁移规划技术，主要是四个参数的计划：时间、预算/投入、价值、风险。而最终的迁移计划作为一个结果，它应当充份展现从企业现状基线走向未来目标架构的一个提升问题，这样的话能更好的去推动我们的过渡架构及其能力的达成（叫做里程碑).每个内部要做的事情是工作包的组合，都是可行要完成的一些项目。32技术之27：过渡架构（里程碑）阶段E定义了一个或多个过渡架构，并将其作为输出。过渡架构展示了企业的递增状态，反映了在基线架构和目标架构之间各过渡时间段。可使用过渡架构来对各个工作包和项目进行分组，组成一些可悲管理的项目组合和项目群组，以清晰说明每个阶段的业务价值。以下使一个过渡架构中的典型内容：机会组合整合的差距、解决方案和依赖性评估对机会的描述收益评估情况能力和能力增量工作包组合工作包的描述（名称、描述、目的、交付物）与机会的关系里程碑和过渡架构里程碑过渡状态的定义每个过渡状态的业务架构每个过渡状态的数据架构每个过渡状态的应用架构每个过渡状态的技术架构解读：里程碑在企业架构里面叫做过渡架构，里程碑也叫能力达成里程碑。过渡---使能力提升过程中设置中间点的一个问题。在我们努力过程当中，我们需要说清楚每个阶段到底有什么价值，要从对能力的达成性上去解读。每一个过渡架构意味着我们需要从业务上、应用上、数据上、技术上一个提升性的描述。这个过渡架构/能力，意味着我们在业务流程上有哪些流程建设、意味着我做了哪些数据的数据治理、意味着我做了哪些系统支撑/系统建设、意味着我们做了哪些平台的提升改造。里面都有它特有的内涵，要理解过渡架构/里程碑是以能力为导向的里程碑32技术之28：实施治理模型一旦定义了架构，就有必要规划如何在实施过程中对实现了架构的过渡架构进行治理。在已建立了架构职能的组织中，很有可能已经有了一个治理框架，但是具体的流程、组织、角色、职责和度量可能需要针对具体项目进行进一步的定义。作为F阶段输出而产生的实施治理模型，确保了一个过渡到实施的项目也会平滑地过渡到适当地架构治理（对于阶段G而言）中去。实施治理模型地典型内容包括：治理的流程治理的组织结构治理的角色和职责治理的检查点和成功/失败标砖解读：治理，体现出我们如何把企业架构用起来的一个组织保障。它要求一个企业的信息部门必须做这四件事情：第一个，定政策：出红头文件；第二个，建组织，得有一个管理职能；第三个，明流程，明确流程，第四个，做考核。这些就是实施治理模型。基本上所有得治理模型都是这四个方位。我们信息部门要变成这样得一个部门。数据治理模型对于我们在G阶段实施治理得时候是一个组织保障。32技术之29：架构契约架构契约在阶段G：实施治理中被创建。架构契约是在开发团队和赞助者之间，就架构得交付物、质量和目标适用性达成得协议。解读:当架构治理落地到每一个实施项目上，我们需要一个遵从性得章程，就是架构契约。每一个项目，立项的流程。每一个项目，在企业债务时代，业务需要一个遵从行的章程。它主要是我们的流程建设，不能违背整体能力发展的规划。不能违背业务架构；我们的系统软件开发不能违背业务架构；我们数据库的涉及及其数据的共享流转不能违背数据架构；我们技术路线的选取不能违背技术架构。一样的道理。治理架构契约，就是以契约的精神来推动我们企业架构对实施项目的一个管理问题。契约精神，蕴含着公平公正公开的思维。我们每一个项目事先要遵循：公平公正公开。不能事后出xx治理要求，事后出xx治理要求是违背契约精神的。契约精神都是事前大家公平公正沟通好的，有利于公开仲裁的。架构契约是治理职能面对实施项目之间的一个锲约化的模式。如每个项目立项，我们作为架构管控/架构管理人员，我们要拿出一份架构契约。告诉每个项目组，要遵从性贯彻什么。比如：北京农商行企业的架构管理处，主要工作：项目立项--把这个项目整体的情况了解以下，给项目出一个架构契约，又名检查单。也会出台一个帮助项目组遵从的架构设计指南。总之就是检查大模式。契约是一个增量补充，架构开发的时候，委托咨询公司做的架构，也叫架构合同，更多是一个架构开发。注意和架构契约区分，不要弄混了。架构契约是面向治理的。32技术之30：变更请求对架构变更的请求在阶段H：架构变更管理中被考虑。在架构的实施过程中，随着越来越多的事实被了解，初始的架构定义和需求有可能不再适合或不足以完成解决方案的实施。在这种情况下，实施项目偏离原有架构方法或请求扩展范围就变得很有必要。此外，外部因素===如市场因素、商业战略的变化和新技术的计划---也会创造扩展和完善架构的机会u。在这种情况下，可提交变更请求以启动新一轮的架构工作周期。解读：变更源于两个，一类是需求的变化；一类是治理的偏差。需求变了，能力需求不一样了，业务部门主动举手，对不起，我们新的能力需求和当时前两年做的能力规划不一样了。原来的面向能力规划，问题在于：企业架构当时做的总体架构设计，能力提升模式，还不如项目选的实施方案呢（有这种情况），我们已经变更，这里的变更有两种类型（两种输入).三种思路。两种类型：需求变化，重新打造一个全新的能力，增量变高。第三简单变更，纯IT，业务战略没有调整，能力没有追加，单纯是IT架构的调整，我们把纯IT架构的调整，叫做简单变更。如应用架构，原来是总线型，通过结构解耦，变成微服务模式。这是尊重能力主线的思维。32技术之31：合规评估一旦定义了架构，就有必要在实施的整个过程中对架构进行治理，以确保最初的架构愿景能被适当地实现，并且确保实施中所有地经验教训都能被反馈到架构流程中去。在阶段G中对实施项目进行定期的、一致性的审查，就提供了这样一种机制，确保了设计和实施的进行能符合战略和架构目的。解读:合规评估既是行为，又是时代。我们的行为就是要确保企业架构有效反映到实施项目当中，有人去检查，是一个检查行为。时代表示，我们到了通过让实施项目遵从整体架构去打造新型能力建设的信息化时期了，这是一个时代。合规评估是一个时代问题，这个时候它会充份发挥原定治理契约的作用，把检查单有效的用起来，治理契约能规避合规评估的主观性，回到客观评估上来。合规评估是非常重要的，我们的目的就是推动信息化进入到合规评估时代，这是一个艰难的过程。我们积累了一套合规评估资产，什么方位，比如说需求分析材料、立项可研报告、系统架构材料、用户手册等一系列---怎么检查出跟企业架构的一致性。这是非常复杂的一件事情。其目的，让架构管理部门真的能够把各个项目通过合规评估往前去带，引领大家发挥追求整体架构的作用。32技术之32：需求影响评估在ADM的整个过程中，有关于架构的新信息在不断被收集。随着这些信息的收集，新的事实会显露出来，证明架构已有方面的不合理。一份需求影响评估表评估了现有架构的需求和规格，识别出了应该做出的变更以及这些变更的相关影响。需求影响评估的结果记录了对变更的评估以及对架构的建议。需求影响评估的建议内容如下：对特定需求的引用需求的利益相关者的优先级需要被回顾的各个阶段确定需求优先级的阶段阶段调查的结果和修正的优先级对需求管理的建议引用存储库的号码，这些内容通常作为对变更请求的回应而被创建。解读:需求影响评估是指在调研过程中，我们去各部门去收集了一些关于能力建设的一些想法。这时候，这些想法和业务架构有关、还是和数据架构有关、还是和应用架构有关、还是和技术架构有关？比如现在功能很多，系统很慢，应当通过平台建设提高系统性能，多引入云计算等---这是跟技术架构有关。这些就是需求影响评估，衡量这些架构的关注点，有利于我们再去做架构设计。所以需求影响评估，是识别我们业务需求跟我们架构关注点的关联性：业务/应用/数据/技术等。
32技术之12：业务转换的准备就绪评估业务转换的准备就绪评估这项技术在阶段A使用，用来评估并量化一个组织对接受变更准备就绪的情况。推荐的活动包括：1. 决定将会影响组织的准备就绪因素2. 使用成熟度模型来展现这些准备就绪因素3. 评估每个准备就绪因素的风险，并确定缓减风险的改善行动，将发现记录到能力评估的结果中，并在后续将风险缓减行动纳入到实施和迁移计划中去。业务转换评估---是识别能力建设的可行性。我们在推动业务能力规划和建设，我们企业架构师面向能力的规划，必须对能力可行性做一下转换评估。企业有：生产能力、管理能力、服务能力、运营能力；这些能力，一个组织在面对能力规划的时候，它能承受的度不一样啊。就像拔高一样，有的人向上跳跃的时候，能跳出多高来，有的人只能跳一点。所以我们在目标架构所蕴含的能力增量应该是可行的。否则就存在一个风险，叫业务转换风险。所有有两句话：1. 立足转换找风险。2. 立足增量判可行。这两个都是评估要做的。比如一个企业要推动全球四大销售市场，销售部门的整合，以实现在客户共享，市场情报共享情况下，全球市场的精细化开放。这是一个能力建设，它可行吗。32技术之13：能力评估专门把12项的能力评估提炼出来，在着手详细的架构定义之前，很有必要了解一下企业的基线baseline和目标能力水平。这些能力的评估将寿险在阶段A进行，并在阶段E进行更新。面向能力的，能力提升的可行性。面向增量判可行。这就叫能力评估。企业的基础能力越强，面向能力提升的弹跳力就越强。就像普通的小孩，走路都不稳呢。你让他学会跳舞，可能吗？所以说能力评估，有两个维度的作用：1. 哪些能力可行，适合做优化。2. 优化的能力，能优化多高。能力评估是，宽度看多少，高度看增量。 宽度是我有多少能力适合做优化的，优化能优化多高多低。先是宽度找范围，然后看下这些能力单元增加多少，增量高低。能力评估用在我们做业务架构的时候。或者用在我们做能力愿景考究的时候，重点是用在我们做能力愿景/架构愿景考究的时候：架构愿景重点描述的是：高层的授权、部门的支持、下属的宣贯和能力愿景。 嗨哟啊看下能力是否太多，太多的能力，也无法转化；还有能力提高的量是否可行，贪心不足蛇吞象。企业的整体能力水平怎样的?企业希望在哪些方面增强或优化能力？架构聚焦的哪些领域将支持企业所期望的能力建设32技术之14：风险管理业务转换风险及缓减活动的识别寿险在阶段A被确定。风险管理在TOGAF9第三部分描述，它是一种在实施架构项目时用于缓减风险的技术。它包括一个由以下活动组成的风险管理过程解读:风险管理是企业架构总师，在我们企业架构整个这个能力规划过程中，应建立起来的风险管理环思维。风险管理思维包括五步一环--五步：1识别、2度量、3量化、4权衡、5应对。一环：循环开展.总结为：1识2度3量4称5术6循环。企业架构总师，带领别人，引领别人去突破的时候，要有风险意识。没有风险管理，要么是壮士（没死），要么是烈士（死了）。通过风险管理，可以使自己运筹帷幄，决胜千里。风险为什么要循环的去做呢，古人说：安知千里外，不有雨兼风。你往前走一段时间，可能出现的情形，照样蕴含风险。1识，把风险找出来；2度，把严重的风险挑出来；3量，把严重风险的影响识别出来，量化以下；4称，看下积极的和消极的，如果积极的大于消极的，不要管它，这是好事，风险要养，否则就要应对。5术，应对之策，如何应对这个风险。用学术来讲：叫风险识别，定性分析，定量分析，风险应对与规划，风险跟踪与监控。32技术之15：架构定义文件架构定义文件是项目过程中创建的核心架构制品的可交付物容器，这份文档跨越了所有的架构领域（业务、数据、应用和技术），并检查了架构的所有相关状态（基线状态、各过渡状态和目标状态）。它首先再阶段B被创建，最初只包含与业务架构相关的制品，解下来在阶段C被更新加入信息系统架构的制品，接着在阶段D被加入技术架构的制品。解读：架构在我们梳理过程中，需要形成正式的交付物。架构定义从文档角度是必须要输出的。它将通过我们领导层这样的班子会议进行介绍，另外要向全系统有关业务部门、下属单位进行宣贯说明。架构定义文件时非常重要的交付物，一般是：原则、架构、（后期）指南这三个要素。原则：我们企业架构是传承什么原则做出来的，原则又称总体策略。四个架构：从说法上：业务架构---业务梳理及其梳理成果，因为它推动了以能力为导向，业务驱动的工作成果，是相关业务口，在我们的积极协助下，梳理出来的成果---有现状的还原、面向目标的优化。数据、应用、技术---是我们能力规划的塑造。再往下是指南，指南是遵从性的规则和治理管控的应用：在某个条件下我们应该如何去做，用来作为信息化治理依据。我们需要说明到底我们通过怎样的治理方式，让大家用起来。发展规划，不在这里体现，单独出。这里就是企业架构，文件怎么写，原则、架构、指南。32技术之16：架构需求规格架构需求规格提供了一套量化的声明，概要地说明了为了符合架构，实施项目必须做到什么样的程度。架构需求规格一版回城未 一份实施契约或更详细的架构定义契约的组要组成部分。 如上所述，架构需求规格是架构定义文件的伴随物，它对架构定义文件进行了补充，提供了定量的视图。架构需求规格通常包括以下内容:可进行有效测量的测度（Success measures）架构需求业务服务契约应用服务契约实施知道原则实施规格实施标准可互操作性需求约束假定解说：我们如果针对一些平台化，或一些专题做总体设计，这种总体设写出来的是企业架构版的需求规格。这里不是面向某个业务能力了，是面向平台（不管那种类的平台），我们写出来就是企业架构版的需求规格。它有利于招标和推动总体建设之用。 比如某河北省某企业提出，我们要开阵投资一个6000万的一体化集成平台，实现数据集成、流程集成、身份集成、功能集成这样一个平台。我们来开展相应的总体设计，利用企业架构来帮助我们做出一套企业设计来，有利于我们的建设支持，能实现总体的目标明确、内涵明确面向业务能力叫架构定义，面向某种平台做总体设计叫架构需求规格，叫企业架构版的架构需求你要从业务、应用、数据等这种架构维度来描述和衡量。同样是企业架构思维，面向能力规划出来的相对比较抽象；那么我们面向平台，设计出来的相对比较具体。如果对比而言，架构定义文件和架构需求规格哪一个更有利于遵从和实现：架构需求规格。这也告诉我们，企业架构可以面向能力做架构定义，也可以面向平台做总体设计。32技术之17：架构路线图架构路线图列出了变迁的各个增量，并把他们放在一条时间轴上，展示了从基线架构面向目标架构的演进过程。架构路线图是过渡架构的而关键构建，并在ADM从阶段B到阶段F的过程中，以增量的方式被开发。以下是架构路线图中包含的典型内容：解说：架构路线图是棉线架构迁移描述出来的进而紧致的极端路线图。那么在这个过程当中，我们主要有一个主线，两个要素。一个主线叫阶段划分，两个要素，一个要素叫做每个阶段的内部过渡架构，过渡架构是整个阶段要达成什么过渡架构，过渡架构呢，其实就是我们规划中要建设的能力。一个叫项目组合，能力当中有什么项目。这个业务架构或者这个能力实现：在业务上搞什么项目、在数据上搞什么项目、在应用系统建设上搞什么项目、在平台推进上搞什么平台项目---这就是项目组合，这些组合有利于我们能力的达成。整个路线图当中体现这个脉络：我不关注具体的时间，我关注阶段的划分：第一阶段、第二阶段、第三阶段。。。第五阶段，一般十三五，正好是5年，每年达成什么业务能力，能力当中有什么项目需要干，就是我们的路线图。路线图中最重要的就是过渡架构：我知道，每一种能力，根据能力的布局，我应该怎么先后建设。32技术之18：业务场景一、 对于识别和阐明隐含在新的业务功能中、满足关键业务驱动力的业务需求，以及隐含的架构需求二、 业务场景是对业务问题的一种描述方式，使需求能够在整个问题的上下文中，在彼此的关系中被看待。三、 如果缺乏对于背景的描述，解决问题带来的业务价值就会不清晰。业务场景就是一种帮助识别和理解企业业务需求的重要技术。解读:业务场景技术使用双流合一来描述交互：业务流看逻辑、数据流看数据----双流合一，描述我们业务能力与其他上下左右环境要素是怎么业务逻辑上的交互以及数据上的交互。逻辑交互一般是箭头，数据交互一般是交互的对象，最能体现出双流合一来。业务场景就是双流合一定义业务交互。目标业务能力对象与相关业务对象的交互问题。业务流+数据流描述交互，既有箭头，又有内容。如果只有箭头叫业务流，加上数据呢，叫数据流描述：中间是目标能力对象，然后和相关要素制定的交互关系。32技术之19：差距分析差距分析技术在ADM周期中被广泛的应用，用来验证正在被开发的架构。它通常是一个阶段的最后一个步骤。其基本的出发点是强调基线架构和目标架构之间的差异，即被故意忽略、意外遗漏或尚未定义的条目。其步骤如下：绘制一个矩阵，将其所有基线架构的架构构建块（ABBs Architecture Building Blocks) ，放在垂直轴，所有目标架构的构建块（ABBs）放在水平轴。在基线架构轴的最后一行增加一行，标示未“新增的架构构建块”，在目标架构轴的最后一列增加一列，标示为“除去的架构构建块”。如果一个架构构建块同事存在于基线架构和目标脚骨中，在交叉单元格将其标记为“已包括”如果基线架构中构建块ABB在目标架构出现缺失，检查每一个缺失的ABB。如果缺失应该将其出去，在“除去的架构构建块”列合适的单元格中对齐进行相应记录。如果不该将其出去，这样就发现了目标架构中意外遗漏的ABB，在“除去的架构构建块”列合适的单元格中对其进行相应记录，这些被遗漏的架构构建块必须在架构设计的下一轮迭代中被回复并进行处理。当某个目标架构中的ABB没有出现在基线架构中时，在该构建块所在列和"新增的架构构建块"行的交叉单元格上将其作为差距进行标记，这种差距需要通过开发或外购该构建块的方式进行填补。当完成上述步骤后，所有出现在“除去的”列或“新增的”行中的都是差距，这些差距要么解释为应该被除去，要么被标记出来，以便进行恢复或开发/采购其功能。解读：差距分析是识别我们工作包的一个过程。工作包和项目的区别：工作包通过可行性研究、解决方案优选后才能变为项目。在未来我们差距分析的结论上来讲：直接分析工作包，间接分析选方案。只有是我们的工作包，并且有方案的我们才能立项。差距分析，我们面对的是缺口，缺口体现为我们目标与现状之间的一个比较，往往呢，我们会绘制一个差距分析矩阵：把现状中有什么、目标中有什么，我们把要素描述为构建块，它是一种面向对象的思想，我们有哪些构建块，还缺少什么构建块，哪个构建块需要加强。找到一些“缺” 与“弱”的这两类要素。如果说现状已有目标，认为已经满足，说明我们就用继承，没什么可做的。如果现状没有，目标中有，说明时缺，缺一个构建块。现状有，目标中认为需要升级得，这个叫弱。也是一种差距。还有一种叫重：现状中有相关多个，在目标中集约化统一了。 缺弱重，比如现状中我们我们是总部部门，下属各单位都有人力资源系统，到目标应用架构当中，发现总部集约统一化了，这是一个集约化改造，重的问题。缺/弱/重就是我们将来要干的事情：一个是全新建设，一个是升级改造，一个是集约化建设。32技术之20：架构视点架构师在ADM周期从阶段A到阶段D的各个阶段中，使用视图和视点来开发每个架构领域（业务、数据、应用、技术）的架构。视图（VIew）是你看到的东西。而视点（ViewPoint）是你从哪儿看；即决定你看到什么有利位置或角度（一个视点也可以被认为是一种范式）。视点是通用的，可以存在视点库中供重用。视图对于它位置被创建的架构来说总是具体的。每个视图有描述它的相关联的视点，哪怕该视点是隐含的。解读：架构视点，是在我们架构设计之前，它的一个共识化管理的问题。我们有很多干系人，当干系人提出很多关注点的时候，企业架构师是按照共识做架构设计，还是按照共识加分期做全集架构设计。比如：财务部门和经济管理部门，两个部门掰扯的优点不一样，它俩似乎在某些通用能力，具体的业务场景上有些矛盾，怎么办？一般矛盾可以做成多套可选的架构；一般共识可以做成统一的架构。所以架构视点是---共识化的企业干系人关注。它告诉我最佳实践，比如财务部门、人力部门、营销部门、物价部门、设备部门，你看看大家没有冲突的有哪些，找出来，就是架构设计直接需要满足的所谓的需求空间，这种需求叫架构视点空间。那为什么不都满足呢？那还是一个共识驱动问题，因为共识代表大家接受，不接受的不创建，先接受后创建。针对有冲突，该行关注点的不同业务口，他们的关注点有很多冲突怎么版？你需要用一套原则去引导，看能不能化解，如果化解不掉，仍然矛盾重重。那应该是你没什么架构可以做的，这事你要暂停。如果能化解，之后能形成共识空间，仍然可以努力。这就是架构视点的作用。32技术之21：架构视图架构视图表现了整体架构，对系统中的一个或多个利益相关者来说具有意义。架构师再ADM周期从阶段A至阶段D的过程中，选择并建立了一套视图，以便可以通所有的利益相关者沟通架构，使其理解架构，并使他们能够验证系统将解决他们关注的问题。在ADM中建立视图架构师必须做出得关键决定之一，就是决定开发哪些特定的架构视图。架构师有责任确保架构的完整性（适合使用），即能充份解决其所有利益相关者的关注问题；以及架构的一致性，即能将各个不同视图联系起来，圆满地协调不同利益相关者之间存在冲突的关注点，并展示在协调过程中所作出的权衡（例如在安全性和性能之间）。解读：架构视图是指按照架构视点所完成的架构设计。架构视图有三种形态：1. 一维目录2. 二维矩阵3. 三维图形比如应用模块，对业务能力要素的覆盖：一个是业务能力要素，一个是应用模块。那么必须使用二维的矩阵。就是架构视图。三维就叫图形了架构视图尤其注重的是，架构师在做的过程中，尤其注意哪些要做出架构视图来，基本点是：有冲突的不碰，没有冲突的去做。所以要能圆满的协调不同概念之间存在冲突的关键点，在协调过程中，做出的权衡必须有利于共识化的接受做出的图。这就是架构视图，有时候做出个目录，拉个列表，有时候做个关联矩阵，有时候绘制一个上中下左右，相关关联的一幅图32技术之22：架构构建块架构构建块是架构的文档描述和模型，来自于按照架构连续系列进行分类的企业架构存储库。它们在ADM的过程中（主要在阶段A、B、C和D）被定义或选择。架构构建块有类似于组件、构件的特性，其特点如下：他们捕获了架构需求：例如业务、数据、应用和技术需求。他们指示并指导了解决方案构建块（Solution Building Blocks，SBBs)的开发。架构构建块规格的内容至少应包括以下内容：基本的功能和属性：明确的语义、包括安全性和可管理性接口：被选择的集合，提供的接口（API、数据格式、协议、硬件接口、标准）可互操作性，以及和其他构建块之间的关系所依赖的构建块，及其必需的功能和已命名的用户接口与业务/组织实体和政策的映射关系 每个架构构建块应包括一份对于企业架构存储库中任一架构文档和模型的声明，以便在架构开发中可被重复使用。使用ADM建立构建块的规格是一个循序渐进和迭代的过程。解读：构建块=一个视点+相关图形的封装统称。构建块有点类似面向对象的思想，在面向对象的模式的思想下，有利于把架构设计成果封装为一种设计资产。可以方便再架构过程中快速的集成和重用，也是提高设计效率、效果和质量的一种方式。架构构建块---能够单独面向关注点，比如单点登录，门户聚合，怎么体现门户当中客户身份的聚合--画一张图，怎么体现功能聚合---画一张图，信息聚合---画一张图、应用聚合等，另外怎么体现基于商务数据仓库能实现全局数据资产共享。从某种层面讲，架构构建块能够很好的形成企业架构的资产库，有利于重用32技术之23：解决方案构建块解决方案构建块SBBs与解决方案连续系列有关，他们是企业架构连续系列中被识别出的各个架构的实现，可以被外购或开发。解决方案构建块首先出现在ADM的阶段E,在第一次考虑特定产品的构建块的时候。解决方案构建块定义了什么样的产品和构件将实现所需的功能，从而定义了实现方式。他们满足了业务需求，与具体的产品或供应商相关。解决方案构建块，至少应包括以下内容：具体的功能和属性接口：被实现的集合被使用所必须的解决方案构建块及其所有所需的功能，所使用接口的名称。从解决方案构建块到IT布局和运营策略的映射共有属性规格，如安全性、可管理性、可定位性、可扩充性性能、可配置性设计的驱动和约束，包括物理架构解决方案构建块和架构构建块之间的关系解读：我们作为一个技术提供商，在产品规划的时候，我们也可以利用这个相应的思维来进行封装，把解决方案跟甲方的关注点封装---就叫做解决方案构建块。一般来说，是一个视点+相关方案==解决方案构建块。注意和架构构建块区分（一个方案+相关视图）。一个是实现相关的，一个是实现无关的。一般甲方会关注把自己的设计变成架构构建块，乙方把自己的设计变成解决方案构建块。架构构建块叫ABB，解决方案固件快叫SBB。乙方要多沉淀解决方案构建块，这样面对不同企业的企业架构，在进行产品解决方案选型的时候，能够更改好的识别自己的市场。SBB也是以视点为导向，做好封装。甲方和乙方是基于视点来衡量解决方案是否可选的思维。这样的话，有利于我们去匹配：当我们行业内部，我们SBB和ABB都以视点作为通用的沉淀、封装。当我们招标和比选选型的时候，就能很好的进行结构化的比选了。这是一个引领双方共同推进的事情。解决方案也可以作为资产，但是按照甲方视点进行封装
32技术之9：架构愿景架构愿景在阶段A应被创建，它提供了一份最终的架构输出的、高层的、愿景性的视图。建立愿景的目的是从一开始就对架构应该有什么样的预期结果达成共识，从而使架构师能够聚焦在关键的领域来验证其可行性。架构愿景也通过给出ige完整架构定义的总体汇总版本，来支持和利益相关者之间的沟通。业务场景是一种对于本阶段适合而且重要的即使，可在创建架构愿景文档的过程中被使用。架构愿景三个作用：高层的授权---企业架构师一定要面向高层薅出羊毛（承诺），达成架构愿景，明确能力的范围组合。否则没法进行。部门的支持---围绕能力建设出需求。向下的宣贯---介绍出领导层什么意识，各部门有啥需求。你们有啥补充没有愿景，就没有上中下三层共识的描绘。架构愿景经常用到一种技术：业务场景，用来描述每种能力在业务口上有什么能力建设的需求。一个个业务场景来叙述：现在有什么问题，能力建设我希望达到什么样的效果架构愿景文档的建议内容如下：业务场景模型对过程的描述流程步骤与环境的映射流程步骤与人员的映射信息流业务场景 = 业务流+ 数据流能力建设思维（企业数字化）：单一业务流的基础上，增加数据流，实现新型业务场景的能力描绘。32技术之10：利益相关者管理利益相关者是一门重要的学问，成功的架构师可以使用它来赢得他人的支持。成功地管理利益相关者帮助了架构师确保他们的项目能取得成功，否则的化就会失败。这项技术应当在阶段A中被使用，用来识别出架构项目的关键参与者，这些参与者在后续的各个阶段中会被不断的更新。这个过程中输出形成了沟通计划的起点。利益相关者----也叫干系人：领导层、业务部门、下属单位 是干系人干系人满足双力和四步双力：一类是权力者，一类是魅力者，都要作为干系人。权力大，魅力大。必须找出权力大、魅力大分别有那些人四步：一析二分三定四判。一析---把干系人找出来，二分，把关键干系人---权力大/魅力大，找出来。三定，以干系人的关注为导向，来定义架构工作的交付物。四判：引领干系人做评估评判，得到有益的反馈。意见早了叫反馈，晚了叫返工。信息管理学中表示：用反馈节约返工。做好干系人管理，让他们早点把意见说出来。干活得找对干系人啊，否则做了也验收不了。必须搞定权力大、魅力大得，·如主责部门得部长，还有意见领袖得部长，项目经理约好访谈之后，你要搞定他们，尤其是总架构师，搞不定他，项目基本上就是白了。成功得管理利益相关者有益于一下几个方面：可以在项目早期就识别出最有权力的利益相关者，并用他们的输入来确定架构的概貌；来自于最有权力利益相关者的支持讲帮助架构项目获取到更多的资源；从而使架构项目更有可能成功；通过在早期就与利益相关者进行频繁的沟通，架构团队可以确保他们能充份地理解架构开发的整个过程，以及企业架构的好处，这将意味着他们会在必要的时候更积极的支持架构团队。架构工作团队更有可能获得对架构模型和报告的有效反映，并将必要的行动编入计划，以充份利用积极的反映，同事避免或者处理掉任何消极的反应。干系人分类地图---对干系人进行定位和分类，对重要的哪些利益相关者进行深入的分析，并记录下分析结果它表示：对于这个项目来说，谁的权力最大/魅力最大，谁的承诺最有用。32技术之11：沟通计划项目经理要做好沟通的计划沟通计划的内容跟一般包括如下：识别相关干系人确认的沟通需求确认的沟通机制确认沟通时间表三向四定，沟通规划表三向：1。 向上沟通---求授权2. 对等沟通---求支持3. 向下沟通---求落实，就是为了落实一件事情。四定：1. 一定相关干系人，干系人管理当中分出来的人，研究跟他怎么打交道。因人而异2. 二定相关关注点，每个干系人关注什么，要一清二楚，比如财务部部长关注什么3. 三定时机与频率，在哪个时间点沟通比较合适。上午还是下午，8点还是9点，多长时间沟通一次。是一次性还是周期性的。4. 四定手段与方法，用什么手段沟通，用什么方法沟通，沟通的气氛，就是在这种条件下规划出来的。沟通的对象有上中下三位。为什么叫对等沟通。企业架构师属于部门部长的级别去谈，企业架构师，必须站在部长的位置去谈话，企业架构的味道才正。否则企业架构无从谈起。否则连一个部门的威信都不具备，都是垂直型的，将无从谈起。好的沟通效果有什么特征：坐茶饭。三个等级。尤其体现在领导层。坐能解决，一定会让你坐，好的沟通效果得益于你理解他，知道他想什么，知道他关注的问题该怎么办。当你跟他沟通差不多的时候，基本就差不多了，这个时候就可以上茶了。当聊到差不多的时候，要么下班，要么午间休息，那一块吃饭聊聊。去食堂一起吃个饭聊一下，基本差不多了到位了，领导访谈就成了。光坐，茶不上，饭没吃，基本就没谈成。一般两个小时才回来的，基本就成了。半小时就回来，完了，最起码这个方位再补一次沟通。
32技术之4：业务原则、业务目标和业务驱动力（简单理解为业务驱动）一份关于业务原则、业务目标和业务驱动力的声明，通常先于架构活动在企业的其他地方被定义。作为预备阶段的输出，它们将被重新生命，并作为阶段A：架构愿景的一部分被再次审查。阶段A的审查活动是为了确保当前的滚动一正确且清晰。TOGAF9第三部分：ADM指引和相关技术中包含了一个含有八项业务原则的集合的例子，可以作为一个有用的起点。TOGAF对于这一交付物的内容没有定义，因为其内容和结构可能会随不同组织发生相当大的变化。必须是业务驱动/能力导向，抓业务目标，抓业务驱动力。这一点需要在：整个企业的IT治理机制当中明确下来。今后的信息化总的就是能力导向、业务驱动的道路业务原则：能力导向，业务驱动。业务目标：能力导向。预备阶段：三个要素，一个位置。（其中要素中就有原则）。到各个部门访谈的时候：要谈原则，讲模式--讲信息化的建设模式和治理模式32技术之5：架构存储库（划分）架构存储库在企业中充当了与架构相关的所有项目的保存区域的作用。存储库使项目能够管理其交付物、定位可重用的资产，并向利益相关者和其他利益方发布输出物。需要有一个明确的结构来存储，比如方法目录、标准目录、设计目录、案例目录、治理评估---这样建目录。这里规定了跟企业架构相关的一些目录类型架构框架 存方法标准信息库 存标准架构景观 存设计参考架构 存案例治理日志 存偏差32技术之5：架构工具（选工具)作为预备阶段的一部分，架构师应选择并实施能支持架构活动的工具。Togaf并不要求或推荐任何特定的工具。对于选额架构工具来开发各种所需的架构模型和视图，togaf提供了一套建议的评估i保准。主要的工具有：viso，sparkea （商业),ares（商业),archi(开源,opengroup推荐的建模工具，软件模型定义用uml较多，架构模型用archi，语言是archimate)32技术之7：架构工作请求书这是一份由赞助组织发给架构组织的文档，由它出发架构开发周期的开始。它是在架构组织的协助下，作为预备阶段的一项输出而被创建的。架构工作申请书也可作为被批准的架构变更请求的结果而被创建，或是根据来源于迁移规划的架构工作的参考条目而被创建。架构工作请求：是企业中谁来发起企业架构项目的一个方式和方法，以及双高：高层发起，高层赞助。高层发起：任何业务部门/信息部门，不能以部门的名义发起企业架构的立项。能力发展规划，必须是管理层的代表发起。业务部门/信息部门是配合协同高层。高层赞助：能力建设所需要拉动企业各方面的投资（流程建设、系统建设、数据治理、迁移等工作），都需要赞助，比如筹钱：出钱出力，尤其是人财物保障方面。必须高层赞助。试想一下信息部门30%是信息部门发起的，就成了IT架构，不是企业架构，缺少了业务架构等。这样的后果是油水分离，业务和IT没有融合。高层发起就不一样，高层可以推动信息部门和业务部门。业务部门之间，主责部门、相关部门协同进行能力的规划、业务的梳理。高层可以做到推动，部门之间无法做推动，一个部门一个职能孤岛，不会互相推动。一个部门是一个职能孤岛（传统封建文明告诉我们:组织结构定分工,职能部门做孤岛）所以必须高层发起、高层赞助。面向核心能力做好顶层设计。业务侧，项目当中，写出来的某一种说法，就是架构请求，牵涉到立项问题。不是部门立项，是高层立项。立项之时，作为能力建设的赞助者，承受不了投入，就不要做。能力建设，需要一定时期，人财物的保证，否则企业架构变成了画图，企业架构工作申请书可以类比于立项，内容建议如下：赞助组织（高层）组织使命的声明业务目标（包括变化）业务的战略计划时间限制业务环境的变化组织的约束预算信息和财务约束外部约束和业务约束对现有的业务系统的描述对现有的架构/IT系统的描述对开发组织的描述对开发组织可用资源的描述32技术之8：架构工作说明书：类比于实施方案架构工作说明书作为阶段A的一份交付物被创建，实际上它是架构组织和架构项目赞助者之间的一份契约。这份文档是对输入架构工作请求书后的相应。它应当描述一份全面的计划，说明对架构工作有什么样的要求，并建议对已识别出问题的解决方案，将如何通过架构流程来进行开发。至少包含：四个调研：总概细剖内视外查；两个文档：调研报告、分析报告；四个架构：BDAT；一个规划；一个治理。每个工作项目可以用PPICTO--P背景、P目标、I输入、C成本、T是时间多长、O输出。来描述每个工作项目，就变成了实施方案。对于一个架构团队，首先要写出来架构实施方案。如果写不出来，那么架构团队自身的工作能力就是架构工作的风险。大概包含如下事项：工作名称的说明对项目的请求和背景项目的描述和范围架构愿景的概要或总体介绍管理的方法范围变更的流程各类职责和交付物架构被接受的标准和流程项目的而计划和时间表来自企业连续系列的支持（重用性）签署的正式批准
32个技术（最佳实践）32中技术每个阶段都有涉及，认识他们需要4天，但是用好他们需要4年。企业架构师没有3-5年是出不来的。32技术之1：裁剪过的架构框架选择并裁剪框架是一个架构项目的实际起始点。比起从零开始后创建框架，基于TOGAF建立框架有如下一些优点：当任务规模变得清晰时，它避免了最初的恐慌。确保对TOGAF的使用是系统性的，即“条理化的常识”TOGAF总结了其他人再实际中发现的哪些有用的方法TOGAF已有了一套可重用的基准资源TOGAF已经再企业连续系列中定义了连个参考架构。裁剪是一个选的过程，五个选择步骤：《1. 选原则，整点口号，ToGAF中有很多对口号的要求，可以选出来。《2. 选方法，《3. 选工具。ires/ark/wiki《4. 选交付物《5. 选参考裁剪过程最重要的，是原则和方法。其他三个是辅助性质的。选择一个原则，让大家接受，才是高手。或者，按照企业下一步信息化发展的诉求，该推出什么样的理念，搞文化运动。文化是解决人认识的一个源泉。而认识决定了人的认知，认知决定人的认责，这样才能走向分工协作。裁剪的必要性但是，在TOGAF可以被有效地用于架构项目之前，在若干层次上对其进行裁剪是必要的，而且应该在预备阶段进行。首先，裁剪togaf模型并将其集成到企业中是非常必要的。这种裁剪包括与项目和流程管理框架的集成、术语的定制、展现风格的确立、架构工具的选择、配置和部署等。锁采用的任何框架的形式和细节也应该与企业其他的环境因素相协调，如文化、利益相关者、企业架构的商业模式以及架构能力的现有水平等。一旦框架已经根据企业的情况进行了裁剪，对其进行进一步的裁剪以适应特定的架构项目就变得很有必要了。整个级别的裁剪将选定适合的交付物和制品，来满足该项目及其利益相关者的需要。注意不要做结果裁剪，古人讲：胜兵之法不可先传。水因地而治流，兵因敌而制胜。胜敌之法，不可先传，所以不能抄，没有说一个企业架构，你改吧改吧就能用，必须有的放矢，因地制宜。32技术之2：组建专业的架构管理团队一总四分两角色：一总：企业架构总师，togaf 9.1的证书，软考系统规划师的证书四分：业务架构/应用架构/数据架构/技术架构，四个维度的架构师，流程建模---业务架构师。集成规划的负责人---应用架构师，做数据治理，熟悉数据资产利用的----数据架构师。对新技术，大（大数据）、数（统一业务数据中心）、网（移动互联网）、云、端（物联网）、安（全）、智（人工职能）、链（区块链）、图（图论，企业和用户复杂的关系，客户反馈闭环的有向图）两管：1. 项目管理---沟通管理，帮企业架构师约时间，能做领导访谈。2. 文档管理---架构资产管理员企业架构组织模型，为企业架构提供组织保障。重点是业务架构师，让业务部门参与进来。32技术之3：架构原则架构原则,是预备阶段的初始输出。他们是对正在被开发的架构的一套通用规则要求和指导策略。四个模板，5个质量原则就是口号，打仗之前方针策略的统一性，需要在概念上统一。四个类型是：业务类/应用类/数据类/技术类《1. 业务类：推动战略契合、流程重构；在保证业务连续和业务合规条件下，推动开展流程重构，是能力建设之所需，企业发展战略之所需。《2. 应用类：应用架构注重统一设计、重用、保证柔性互联、使用应用安全。《3. 数据架构面向数据资产化，推动数据共享与重用。要从源头上数据治理的分工（即数据认责），认责制原则，谁生产---谁管理---谁负责的原则，来推动数据治理的工作。还要推动数据标准化/数据安全。数据架构师引领数据治理的前置行为，企业定数据架构，明确需要什么样的数据共享效果，然后通过数据治理塑造出来。《4. 技术类：形成标准化的信息技术环境，保证平台与应用及其数据共享呈现出集成交互的可操作性。要保证呈现出信息化的性能---通过平台化建设来保障，解决建的出，撑得住的问题：异地多活，服务管理要建立起来。根据组织的不同情况，可以在如下任一或所有三个级别上建立原则。有信息化原则，也有架构原则，规划有什么原则。《 1. 企业原则：这类原则提供了决策的基础，并规定了组织该如何完成其使命。这些原则常见于政府和非盈利组织，但也会作为一种协调决策制定的手段出现在商业组织中。他们师成功的架构治理战略中的关键要素。《 2. IT原则：这类原则对于整个企业如何使用和部署IT资源和资产提供了指导原则。确立这些原则是为了尽可能的提高信息环境的生产效率，降低生产成本。《 3. 架构原则：这类原则是IT原则中与架构工作相关的一个子集。他们反映了整个企业的共识，体现了企业架构的精神。四个标准：我们架构出来之时，每一条原则满足四个标准（见上图）：《1. 名称应积极，要用积极的术语、积极的观点《2. 声明无二义《3. 依据有价值，有利于业务能力建设，才能带来业务价值依据又称隐含，隐含了什么价值。依据什么价值才提出来整个原则。所谓价值：对业务能力建设的效益、效率、效果有促进作用《4. 相关保一致。 和其他原则有相关性，就需要保持一致五个质量：易懂、健壮、完整、一致、稳定注意质量是针对一套原则的，不是某一个原则《1. 易懂：看用户，用户认为---如总部领导各部门、下属单位---听完之后好理解《2. 健壮：看复杂，无论多复杂的业务能力规划需求，都能用原则给它说清楚。《3. 完整：看覆盖，原则的作用面应该是完整的，如果能指导人力资源建设，也得能指导财务系统建设。要考虑各个领域能力建设总体的特征。《4. 一致：看冲突，没有冲突就是一致的，有冲突就是不一致。<5. 稳定：看变化，如果业务能力是这种类型，就适用，业务能力发生变化了，就不适用，表示不稳定。比如：以能力为中心 ，能力为导向；以职能为中心，为垂直贯通。以客户为中心，推横向协同。这是两个方向的能力，一个纵向，一个横向。如果能力变化有所调整，仍然是主责部门/相关部门/下属单位来进行业务驱动的能力梳理、业务梳理---这个原则还是都适用的，这就叫做稳定。所以要清楚健壮和稳定的区别，一个是面对复杂的情况，一个是应对业务能力变化我们要推出一套系统性的好的口号。让大家都能理解，新一代、新时期、新型信息化建设与治理模式。这个时候原则是非常重要的。能用原则说明我们信息化如何建设和治理，就不要用方法来去说，更不要用交付去说。所以企业架构师要跟领导层、各部门、下属单位进行调研、访谈、沟通过程中，这些原则应传递出一些积极的信号，让大家都去认同。原则是企业架构师设计出来的。每次我们在做咨询项目过程中，我们都得拿出一套原则来。原则不在多，但是要四个维度的事情都谈到（BDAT），要保证大家在面向各项能力的信息化建设中明白怎么搞---建设模式的模式：能力导向，业务驱动、分工协同、统一架构、统一管控，要让大家体会到，这里有一套好的原则。企业架构师要以理念取胜、以沟通取胜。好的企业架构，其实是塑造了好的文化，提升了大家信息化的认知