云计算的服务模型有哪些？

Web服务作为炙手可热的技术 如何应用到企业的IT系统和商业流程之中 并给企业带来直接的经济效益 一直备受国内外企业管理者的高度关注和推崇 而在近两年 出现了一种技术架构被誉为下一代Web服务的基础架构 它就是SOA（Service oriented architecture 面向服务架构） 年 Gartner最早提出SOA 年 月 Gartner提出SOA是 现代应用开发领域最重要的课题 还预计到 年 SOA将成为占有绝对优势的软件工程实践方法 主流企业现在就应该在理解和应用SOA开发技能方面进行投资 更好支持商业流程 SOA并不是一个新事物 IT组织已经成功建立并实施SOA应用软件很多年了 BEA IBM 等厂商看到了它的价值 纷纷跟进 SOA的目标在于让IT变得更有d性 以更快地响应业务单位的需求 实现实时企业（Real Time Enterprise 这是Gartner为SOA描述的愿景目标） 而BEA的CIO Rhonda早在 年 月就提出要将BEA的IT基础架构转变为SOA 并且从对整个企业架构的控制能力 提升开发效率 加快开发速度 降低在客户化和人员技能的投入等方面取得了不错的成绩 SOA是在计算环境下设计 开发 应用 管理分散的逻辑（服务）单元的一种规范 这个定义决定了SOA的广泛性 SOA要求开发者从服务集成的角度来设计应用软件 即使这么做的利益不会马上显现 SOA要求开发者超越应用软件来思考 并考虑复用现有的服务 或者检查如何让服务被重复利用 SOA鼓励使用可替代的技术和方法（例如消息机制） 通过把服务联系在一起而非编写新代码来构架应用 经过适当构架后 这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发 使得在商业环境许可的时间内对变化的市场条件做出快速的响应 SOA也不仅仅是一种开发的方法论 它还包含管理 例如 应用SOA后 管理者可以方便的管理这些搭建在服务平台上的企业应用 而不是管理单一的应用模块 其原理是 通过分析服务之间的相互调用 SOA使得公司管理人员方便的拿到什么时候 什么原因 哪些商业逻辑被执行的数据信息 这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程 应用系统 SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚 轻松应对企业商业服务变化 发展的需要 企业环境中单个应用程序是无法包容业务用户的（各种）需求的 即使是一个大型的ERP解决方案 仍然不能满足这个需求在不断膨胀 变化的缺口 对市场快速做出反应 商业用户只能通过不断开发新应用 扩展现有应用程序来艰难的支撑其现有的业务需求 通过将注意力放在服务上 应用程序能够集中起来提供更加丰富 目的性更强的商业流程 其结果就是 基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合 服务是从业务流程的角度来看待技术的 这是从上向下看的 这种角度同一般的从可用技术所驱动的商业视角是相反的 服务的优势很清楚 它们会同业务流程结合在一起 因此能够更加精确地表示业务模型 更好地支持业务流程 相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力 企业流程（enterprise process）是流经企业框架的空气 它赋予业务模型里的组件以生命 并更加清晰地定义了它们之间的关系 流程定义了同业务模型进行交互 *** 作的专门方法 例如 会计可能是企业服务系统的一个组件 但是将发票寄给客户却是一个业务流程 服务被定义用来支持业务流程 因而贯穿整个流程始终的是 各种服务组件在流程和逻辑实现过程中的装配 *** 作 理解业务流程是定制服务的关键所在 有利于企业业务的集成 传统的应用集成方法（点对点集成 企业消息总线或中间件的集成（EAI） 基于业务流程的集成）都很复杂 昂贵 并且不灵活 这些集成方法难于快速适应基于企业现代业务变化不断产生的需求 基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问题 SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上 这些模式定制了系列机制用于描述服务 通知及发现服务 与服务进行通信 不同于传统的应用集成方法 在 SOA 中 围绕服务的所有模式都是以基于标准的技术实现的 大部分的通信中间件系统 如 RPC CORBA D EJB 和 RMI 也同样如此 可是它们的实现都不是很完美的 在权衡交互性以及标准定制的可接受性方面总是存在问题 SOA 试图排除这些缺陷 因为几乎所有的通信中间件系统都有固定的处理模式 如RPC 的功能 CORBA 的对象等等 然而 服务既可以定义为功能 又可同时对外定义为对象 应用等等 这使得 SOA 可适应于任何现有系统 并使得系统在集成时不必刻意遵循任何特殊定制 SOA 帮助企业信息系统迁移到 leave and layer 架构之上 这意味着在不用对现有的企业系统做修改的前提下 系统可对外提供 Web 服务接口 这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装 所以在不用修改现有系统架构的情况下 SOA 可以将系统和应用迅速转换为服务 SOA 不仅覆盖来自于打包应用 定制应用和遗留系统中的信息 而且还覆盖来自于如安全 内容管理 搜索等 IT 架构中的功能和数据 因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能 所以基于SOA的应用能更快地应对市场变化 为使企业业务部门设计开发出新的功能应用 下图提供了使用基于服务集成的企业应用的高级视图 与传统的企业应用集成架构的主要区别在于该系统使用基于标准的服务 并包括过程/数据服务 编排和组合 基于标准的服务成了应用间的集成点 服务的编排和组合增加了服务的灵活性 重用性和集成性 图示 使用基于服务集成的企业应用 SOA服务粒度 可以按基于服务的功能及发送和接收的数据数量来定义服务 如细粒度服务 粗粒度服务或组合服务 在 SOA 中服务粒度有两种相关的意思 服务是如何实现的 服务使用和返回了多少数据或多少消息 细粒度服务执行了最小的功能 发送和接收少量的数据 粗粒度服务执行了较大的业务功能 并交换了更多的数据 细粒度服务是供粗粒度服务或组合服务使用的 而不是由终端应用直接使用的 如果应用是使用细粒度服务建立的 则应用将不得不调用网络上多个服务 并且发生在每个服务上的数据量较少 因而会对对系统整体性带来影响 所以粗粒度服务的用户不能直接调用他所使用的细粒度服务 然而 由于粗粒度服务可能使用多个细粒度服务 因此它们不能提供粒度级的安全和访问控制 组合服务可以使用粗粒度服务和细粒度服务进行组装 数据数量数量不是粗粒度服务和组合服务之间的区别 粗粒度服务例子 如创建新客户 在这一过程的 *** 作是 需要通过一些外部服务验证对客户进行验证 并在 CRM 应用系统中创建客户记录 组合服务例子可以是提供一个新的DSL线 这需要一个服务调用来验证定单 创建或验证客户 确认产品库存及为数据线分配资源 下图描述了服务粒度的不同级别及它们之间的关系 图示 服务粒度 通过一组有效设计和组合的粗粒度服务 业务专家就能够有效地组合出新的业务流程和应用程序了 SOA与Web服务 SOA不是一定需要 Web 服务来实现 并且一个基于Web 服务开发出来的应用也不代表就是一个基于 SOA 构架应用 Web 服务只是服务实现的一个典型 是实现企业 SOA的一个组件（非必需组件） SOA 为基于服务的分布式系统提供了概念上的设计模式 Web 服务则是基于标准的 可经济实惠地实现 SOA的一项技术 SOA将IT资源透过服务这样一个在业务上有重要涵义的概念来提供 共享 把IT与业务的距离更加拉近了一步 服务在涉及的层次上要比组件 函数 流程等更高 而且往往在业务上可以找到与之直接对应的概念或实体 例如报价 订单 服务打破了IT系统间的藩篱 就像一家公司的各个部门 平常各自扮演特定对内或对外服务的角色 但彼此间如果能有效地通过共通的语言及文字 进行良好的沟通 便能协力达成更大 更高的目标 随着SOA和Web服务的潮流 带来了组合式应用（posite application）的开发方式和观念 开始逐渐被大量应用在Portal（门户）和Integration（集成）上 组合式Portal的做法 就是通过Portal界面所提供的应用 往往不是真的在Portal服务器上执行 而是将Web服务即时抓过来 再加以呈现 同时汇总给Portal的使用者 在整合方面也是采用组合式的方式 通过高级工具来设定 使系统得以灵活地配合任务的调整 对各项以Web服务方式提供的服务进行不同形式的串联和协作 同时快速地加以部署 年 月 BEA发布了一个企业门户合理化（enterprise portal rationalization EPR）战略 这个战略用来平衡BEA WebLogic Platform的SOA能力 凭借最好的行业实践和行业专家 帮助客户解决多年来形成的散乱的portal和Web应用程序开发 如果说Web服务等技术是SOA的血肉 那么正确的服务设计理念及系统运行平台则是SOA的灵魂 SOA试图让IT能更快和业务同步 在规划上以提供d性的业务服务为目标 从CIO到负责规划的系统分析人员 需要和业务单位 策略伙伴间有充分的沟通 CIO必须认识到 SOA的建立将是一个为期数年的承诺 基础建设需要按部就班地进行 资助的模式也必须在IT和各个业务部门间建立 来陆续支援基础建设及各项业务服务的开发 在中间件领域 SOA架构日益成为中间件软件供应商争 lishixinzhi/Article/program/Java/hx/201311/26963

近年来，随着互联网尤其是移动互联网技术在各行各业的渗透逐步深入，部分传统行业也从最开始的排斥互联网到现在急迫的想拥抱互联网，努力学习互联网思维，学习互联网技术，希望借助互联网技术来完成企业的转型或者升级。而互联网应用的发展，在“以用户为中心”理念的指引下，带来的最直接变化便是用户需求的升级，一方面来自被动接收的用户需求升级，另外一方面来自企业主动提供服务满足用户需求的服务升级。To C用户需求自不用说，在互联网的影响下，伴随着To B 用户需求的升级，其价值空间已经越来越得到关注。

如何快速响应用户诉求，验证用户需要在企业信息化的过程中，很多公司或多或少都做过不少尝试与探索，甚至已经取得了不错的成果，如敏捷开发转型、DevOps建设、双模IT、系统产品化建设，微服务架构等等。这些当然都是很好的方法，都能够直面用户需求，直接提供用户需求的解决方案，各有千秋。然而纵观各种方法，大都是自下而上的直接解决问题型，今日笔者想从另外一个维度，即企业架构，自上而下的角度和各位探讨一下看看如何更好的满足用户需求。

信息化建设存在的问题

企业架构框架理论最早是由美国架构规划专家约翰·扎克曼（John Zachman）于1987年提出，扎克曼（Zachman）也因此被誉为EA之父，在此之后，EA的框架和方法论不断的被提出。目前影响比较大，使用比较广泛的企业架构框架和方法论主要有Zachman、TOGAF、FEA和DODAF等。其中TOGAF 由国际标准权威组织The Open Group制定，也是目前应用最广发也最主流的架构框架，FEA是有美国联邦政府预算管理办公室提出的适用联邦政府行政管理体系，而DODAF则是由美国国防部于1996年首次发布。

在企业的信息化发展过程中，普遍存在一种现象，即“信息化”就是若干个“信息化系统建设项目”的总和，采购或者开发一个系统也并不是对业务需求的IT解决方案。相信几乎所有的公司都会制定短期、中长期的总体规划和分步实施计划，但大都是“项目导向”型，这种模式在互联网的时代当面临着不断变化的需求时总是有一种力不从心的感觉。在证券基金行业，信息化系统尤其是核心系统又大都以招标采购为主，自主研发为辅，信息技术部也大都定位为中后台支持服务部门，从公司到部门的关注点更多的是在业务具体需求的技术实现上面，而忽略了对企业需求获得能力和信息化感悟能力的造就。特别是当IT人员缺乏对公司战略目标和业务规划全面了解的时候，IT人员也只能把视角放在技术层面。

随着企业业务的发展，公司组织结构也逐渐变得复杂，为满足业务运作逐步建立了很多分割的部门、流程、和系统，由于边界的模糊经常会出现各种冲突，导致运营效率较低，业务与IT人员沟通不顺畅，系统建设滞后，用户需求无法及时响应的情况。总结下来信息化建设的过程中普遍存在以下问题：

1、烟囱式的系统建设。这种建设模式主要有三大弊端，第一，重复功能建设和维护带来的重复投资；第二，打通烟囱式系统间交互的集成和协作成本高。第三，不利于业务的沉淀和持续发展。其中前面两个弊端是基于成本和效率的角度，第三个弊端则是基于发展的角度，危害最大，不利于企业业务服务能力的积累与建设。烟囱式的系统建设在很多时候不得不打破“以用户为中心”的服务理念，不是不想，而是不能。

2、对信息化建设的认识不够。企业信息化一直处于手段和工具层面，认为信息化的主要工作仅仅只是改进工作效率，提供系统支持，认为只是信息技术部一个部门的工作。但实质上企业信息化建设应该是一个企业全局性的工作，从管理层到各部门骨干应该要有一些对企业信息化基本的共识。

3、IT不懂业务。IT人员不懂业务主要体现在三个方面，第一，对基本的业务流程，业务规则和业务模型不了解，导致业务与IT人员沟通成本高；第二，IT人员不仅要懂业务流程和规则，还需要对业务的发展提出自己的理解与看法，并对如何优化业务 *** 作，提高流程效率能够提出一些创新的想法（可大可小），在门槛相对较高的金融行业，要能够达到这一点，需要对应的IT人员在相关的业务领域中有足够长时间的沉淀和积累。第三，能够识别关键业务，所谓关键业务就是能够产生相对较大的经济和社会效益以及能够产生公司核心竞争力的业务。资源总是有限的，IT人员需要权衡将有限的资源正确的投放到满足关键业务的需求中。现实情况是在证券基金行业能够满足第一点已实属不易，能够达到第二点要求已实属难能可贵，而第三点对IT决策层与管理层提出了更高的要求。IT的价值体现往往更多的是表现在对业务的理解与把握上，IT与业务、用户对需求能够更快速的达成共识。

在企业的信息化发展过程中大大小小的问题很多，在这里就不再一一列举。而架构其本质是一门“描述语言”，通过架构让管理层、业务部门、IT部门对战略、规划、计划在同一个维度进行表达，是业务与信息技术之间的桥梁，是业务、应用、数据、和技术之间的协同。企业架构从企业的业务和战略出发，制定企业的整体信息化蓝图，希望能够在对业务战略和业务流程的理解上能够对信息化进行顶层设计，逐层设计，形成灵活稳健的IT结构，企业的战略、业务和技术的变化都可以反映在企业架构之中。

如何构建良好的企业架构

在开始进行企业架构工作之初，首先我们应该清楚IT工作在企业架构内部的定位如何（此处不是单指IT部门），由于各企业业务模式的不一样，其IT工作在企业内部的定位也会不同，IT的定位一般可以分为如下四种，而传统证券基金行业一般都属于第一种模式，由业务运营来驱动。

在清楚了IT的基本定位以后，便清楚了企业架构的工作方向，业务战略，业务架构，和IT架构构成了工作的核心，而其中IT架构又包括应用架构、数据架构和技术架构。

企业架构的工作的第一步便是对现状的调研与分析，从对公司战略的解读，到业务现状的梳理，以及信息化现状的分析，了解基本信息并形成基线架构，对于业务愿景从业务目标和业务战略入手，梳理当前存在的业务问题及业务发展方向，并对相关问题达成共识。

业务架构是企业架构的重中之重，通过一种结构化的方法将业务目标与业务具体需求结合在一起，形成业务需求框架，可以清晰的描述业务需求，使得业务与IT对需求的理解保持一致，可以达成共识，同时通过整个企业范围内的需求整合工作梳理了企业全部的业务方向，明确了各业务的业务价值，可以清晰IT对业务支持的重点和支持边界。

业务架构框架可以以价值链为基础，进行流程的逐级细化，主要包括4层：

一、业务价值，即（价值链视图）

二、业务管理视图

三、业务流程视图

四、流程活动图

在业务架构设计框架中，可以把企业内外价值增加的活动分为基本业务域和支持性业务域。其中基本业务域涉及企业对外服务的活动；支持性业务域涉及人事、财务、研究与开发、采购等内部支持活动。

基本业务域和支持性业务域构成了企业的价值链。不同的企业涉及的价值活动中，并不是每个环节都创造价值，实际上只有某些特定的价值活动才真正创造价值，这些真正创造价值的经营活动，就是价值链上的"战略环节"。

根据业务价值链设计的业务能力，每一种能力都可以用业务域来表达。

按照业务域的划分，逐步丰富和完善业务，形成公司的业务组件模型（CBM），同时从流程的角度对业务进行分层分级描述。

通过对业务架构的梳理与设计，整合后的需求是未来项目开发的需求指导，可以提供更多的信息给架构师，让他们可以以更高的视角、更远的场景、更合理的方法进行架构设计，保障系统的先进性、稳定性、可扩展性。当接收到新的需求时，可以直接与业务架构进行匹配，也可通过业务架构的设计主动产生需求。

应用架构可以描述各个部署的应用，它们之间的交互，以及与核心业务流程之间的关系。应用架构不是对某个具体系统的设计或者需求分析，而是定义企业向业务部门提供的整体的IT应用系统和功能，即IT对业务的信息化解决方案。通过它明确了业务功能的边界和划分，并且展示了不同划分以及之间的关系。

在应用架构中应通过不同的应用域、应用组件等来集中表现，通过应用域视图来描述应用架构中域的划分，以及应用域与应用系统的关系。对应用组件，可按照基础组件、通用组件和业务组件来进行分类设计。

对于大部分在传统证券基金行业的公司而言，其IT解决方案，尤其是核心系统大都仍然以从供应商采购为主，而部分供应商的一些系统随着其产品的成熟度提高和市场的发展，已经基本发展成为行业的标配，如在资产管理行业，投资管理系统O32几乎已成标准配置，在涉及相关应用域的架构梳理与规划的过程中，也需要考虑此类行业通用的系统，充分融合其架构。只有在此行业通用的架构基础上规划和设计的本公司内部的专有架构，才具有更高的可行性和更稳健的架构演进路径。

在数据架构阶段，以业务架构为基础，设计数据主题域视图，以展示数据域与数据主题以及数据主题对业务能力的支撑关系；设计概念数据模型视图，展示数据主题下的数据实体，并展示数据实体之间的业务关联关系。

通过数据架构的规划，能够确保应用与数据之间的关联性，保证数据的唯一创建从而保证数据的准确性，明确数据源及数据保存机制，保证数据的一致性。数据本身是一种资产，需要能够真正做到可共享，同时符合安全性要求等。

而技术架构的核心工作即是通过技术的手段把前面设计的架构蓝图实现出来，技术架构由支持企业应用的、以及各种IT基础资源和设施为描述对象的技术域构成。通过技术架构来建立一个IT运行环境以支持数据和应用架构以保证业务的正常开展。

企业架构创造需求

回到关于需求的响应，需求管理的能力一般可分为3个阶段：管理需求，发现需求和创造需求，而企业架构就是一种创造需求。企业架构在企业信息化的过程中起着承上启下的作用，如下图，在满足用户越来越个性化需求的同时，不仅需要自下而上的直面需求，更需要自上而下的全局把控，双管齐下来满足需求，而个性化需求的满足能力也正是一家公司竞争能力的表现，需求与个性化需求，从需求的提出到需求的实现，均可有对应的架构规划来更好的支撑。

在本文中笔者并未对具体如何详细开展企业架构工作（如何做调研，如果做现状梳理，如何做架构设计等）做过多深入的讨论，仅仅从企业架构的必要性角度进行了阐述，抛砖引玉若有兴趣欢迎一起探讨。

由此引发了笔者进一步的思考，当互联网/移动互联网已经成为基础设施的时候，人工智能时代的序幕已经拉开，你又准备好了吗？或许企业架构设计的思维也能够助您一臂之力。

注：本文发表在《恒生世界2017年第6期》

云计算走过了激荡十年，可谓势不可挡，风雨兼程。它如此巨大和丰富，虽万字不足以道其一二。成天到晚都在说云，到底啥是云计算？在维基百科中，云计算是可配置计算机资源和更高级别服务的共享池，可以通过最少的管理工作快速配置（一般是用互联网）；在百度百科中，云计算是基于互联网的相关服务的增加、使用和交付模式非专业人士很难理解，基本看完一句话就溜了。

其实，云计算你可以理解为资源共享池。举个例子就是，我有很多东西，家里放不下了，放到一个特定的地方存着，随时提取，别人碰不了，保质保量。“东西”一般是指数据、软件、服务等，而“特定的地方”就是云。下面千锋给大家说一下云计算的模型都有哪些：

云计算有4种部署模型，分别是私有云、社区云、公共云和混合云，这是根据云计算服务的消费者来源划分的，即：

如果一个云端的所有消费者只来自一个特定的单位组织（如微算科技公司），那么就是私有云。

如果一个云端的所有消费者来自两个或两个以上特定的单位组织，那么就是社区云。

如果一个云端的所有消费者来自社会公众，那么就是公共云。

如果一个云端的资源来自两个或两个以上的云，那么就是混合云。

目前绝大多数混合云由企事业单位主导，以私有云为主体，并融合部分公共云资源，也就是说，混合云的消费者主要来自一个或几个特定的单位组织。

私有云

私有云的核心特征是云端资源只供一个企事业单位内的员工使用，其他的人和机构都无权租赁并使用云端计算资源。至于云端部署何处、所有权归谁、由谁负责日常管理，并没有严格的规定。私有云的部署这有两个可能，一是部署在单位内部（如机房），称为本地私有云；二是托管在别处（如阿里云端），称为托管私有云。

企业私有办公云现在被很多大中型单位组织采用，用云终端替换传统的办公计算机，程序和数据全部放在云端，并为每个员工创建一个登录云端的账号，账号和员工一一对应，相比传统的计算机办公有如下好处：

员工可在任何云终端登录并办公，可实现移动办公。有利于保护公司文档资料。维护方便。终端是纯硬件，不用维护，只要维护好云端即可。降低成本。购买费用低，使用成本低，终端使用寿命长，软件许可证费用降低。稳定性高。对云端集中监控和布防，更容易监控病毒、流氓软件和黑客入侵。

社区云

社区云的核心特征是云端资源只给两个或者两个以上的特定单位组织内的员工使用，除此之外的人和机构都无权租赁和使用云端计算资源。参与社区云的单位组织具有共同的要求，如云服务模式、安全级别等。具备业务相关性或者隶属关系的单位组织建设社区云的可能性更大一些，因为一方面能降低各自的费用，另一方面能共享信息。

公共云

公共云的核心特征是云端资源面向社会大众开放，符合条件的任何个人或者单位组织都可以租赁并使用云端资源。公共云的管理比私有云的管理要复杂得多，尤其是安全防范，要求更高。公共云的一些例子：深圳超算中心、亚马逊、微软的Azure、阿里云等。

混合云

混合云是由两个或两个以上不同类型的云（私有云、社区云、公共云）组成的，它其实不是一种特定类型的单个云，其对外呈现出来的计算资源来自两个或两个以上的云，只不过增加了一个混合云管理层。

公/私混合云的优势架构更灵活：可以根据负载的重要性灵活分配最适合的资源，例如将内部重要数据保存在本地云端，而把非机密功能移动到公共云区域。技术方面更容易掌控。具备私有云的保密性，同时具有公共云的抗灾性（在公共云上建立虚拟的应急灾备中心或者静态数据备份点）。

云计算历史性地对IT硬件资源与软件组件进行了标准化、抽象化和规模化，某种意义上颠覆和重构了IT业界的供应链，这是一个巨大的革新与进步。如今，云计算正迎来最好的时代，在中国这片广阔热土更是如此。我们由衷希望，云计算行业不仅取得商业上的成功，更能扎实服务各行各业，为社会经济发展提供数字化引擎和强大动力。让我们继续与云计算同行，与伟大的数字时代同行。最后给大家一张详细的云计算学习图作为结束，希望大家都能系统的学习到云计算的教程。

本方案对于企业管理的作用和价值

随着现代社会中企业对IT系统的使用越来越深入和频繁，如何管理好企业的IT系统成为不可忽视的管理议题。如果在IT建设过程中缺乏总体架构和规划，企业将在IT管理上面临众多的挑战。比如：业务越来越复杂，IT系统越来越庞大;难以统筹地管理;看不清楚IT建设的现状，更谈不上合理规划新的IT建设;企业内IT和业务沟通困难，业务人员用不好系统，IT人员服务质量也不高。

企业架构(EnterpriseArchitecture)是对构成企业的所有关键元素和关系的综合描述。它是一个用于描述和分析企业的现状，并对企业做出合理诊断和规划的方法。企业架构就类似于医学上将人体构造分解为骨骼、肌肉、血液等组成部分，既考虑每个部分的成分，也考虑这些部分是如何结合并协同工作的。它是现代企业用于自我分析和自我管理的工具。

单纯地从IT的视角管理IT系统让许多企业深陷管理困境，解决问题也是按下葫芦浮起瓢。实际上，IT的服务对象是企业的战略、组织、流程等一系列的要素。因此对IT的管理如果不考虑这些要素，那就会理不到头绪，产生诸如系统庞大并与业务脱节等症状。因此，需要通过企业架构的管理思想来管理IT架构，并实现如下价值：

1)理清IT架构，明确IT管理现状

IT架构管理对于企业来说，首先是需要“理清楚”然后才是“管起来”。与IT架构相关的内容既包括企业的业务流程、信息数据、应用功能、服务器和网络等管理要素，也包括传输类型、控制方法、管理策略、开发技术等技术层面的要素，合理清晰地梳理这些内容并了解相互管理，才算是帮助企业真正明白目前IT管理的现状。

2)分析企业现状，找到IT管理的可改进点

如果说明确IT管理现状是企业对自身的一个审视和了解，那么IT现状分析就是企业对自身的“望闻问切”。通过对企业流程与应用系统覆盖度的分析，我们可以知道企业IT应用主要存在于企业哪些地方，而通过对企业流程与应用系统冗余度的分析，我们又可以知道企业IT系统之间存在的功能重复或冲突集中在哪里。

当然，企业IT分析同样不能零散的开展，因此需要有一个整体的分析设计体系和科学的分析设计方法，本方案基于在流程分析领域一直处于世界领先地位的ARIS平台，提供了一套在IT架构现状分析上成熟的方案。

3)合理地规划与改进IT建设

以往的IT规划往往从IT系统本身出发，或借鉴国际先进的经验，或追求新的产品与技术。而一个真正适合企业的IT规划既要有适度的前瞻性，又要能够贴切地满足企业战略和企业的生存环境。否则就像在水下穿了一件太空衣，虽然外表光鲜亮丽，但实际上花费巨大却没有解决实际问题。

企业架构下的IT规划强调的是从企业战略出发，首先规划业务架构层，然后延伸到应用架构和数据架构，最后结束于企业的基础设施架构，其中包含战略、流程、系统功能、模块、数据、数据接口、系统实例、应用机房、网络信息和技术细节等等各种管理要素，可以说是对企业IT建设的量体裁衣。

4)完整地管理IT资产与技术

仅仅规划和实施IT系统是远远不够的，大多企业在实施IT系统后，更重要的是运维和管理IT系统。在这样一个层面上，IT系统无疑于企业的IT资产。结合IT服务管理标准和企业资产管理的思路来统筹的管理IT系统，也是企业架构可以发挥力量的地方。

同样，企业里面往往也有专门管理IT配置的工具(CMDB)，但这些工具往往又忽略了企业业务与战略和IT之间的关系，如何将这些内容集成和统筹地管理，也是企业架构管理思想所考虑的内容。

借用企业架构的管理思想来管理IT架构，将保障IT系统不再与现实脱节，也不再落后于战略和业务的发展。IT系统将像企业的设备等重要物质资产一样有效地管理起来。

基于企业架构(EA)的IT架构管理解决方案及其交付物

在企业架构(EnterpriseArchitecture)的管理方法中，IT的规划需要与业务的需求统筹地管理起来。因此，一般将企业的IT架构划分为四个层次：

业务架构层：包含企业的战略、组织与流程等业务相关的架构，主要用于分析业务的驱动与业务的需求。

应用架构层：包括应用系统，系统功能，系统接口，相关应用的服务等，主要用于从业务层面将需求层层分解为系统的功能。

信息架构层：包括数据体系，数据架构，数据实体等于信息数据相关的内容。由于数据是流程流转的实体，也是应用系统需要实现的功能载体，因此对数据的设计需要与应用和业务层进行统一。

基础架构层：数据的存储实体，系统实例，硬件设备，软件技术等等属于企业基础设施的内容，需要按照资产管理的模式进行管理。

企业架构中的IT架构的四个层次

如何基于企业架构进行IT应用功能的规划？

交付物一：搭建从贯穿IT架构的模型体系

企业架构就是对企业各个管理要素以及关联进行管理的过程。因此我们对IT架构的管理，需要将企业如下要素进行统筹地梳理与整合，并形成模型体系。

战略：通过BSC战略模型梳理企业战略与目标。

流程：通过增值链与EPC模型梳理企业的流程架构与现实业务流程。

功能：通过流程步骤梳理系统所因提供的应用功能。

系统：通过应用系统架构模型梳理系统类型与模块。

基础设施：通过系统与系统实例，梳理系统所存储的相关硬件与设备等基础设施。

资产：通过整理相关资产获得资产的生命周期。

资产集：通过整理资产并分类获得完整的资产集合。

架构生命周期：管理各个业务单位的IT架构的生命周期。

企业架构各个层面的整理

交付物二：企业架构现状评估与分析报告

企业架构的IT架构现状评估与分析方法是以企业架构方法论作为理论依据，分析企业的各个架构元素和架构元素之间的关联性，例如：应用系统架构下应用系统的岛屿数量和程度，以及应用系统对业务流程的覆盖率。然后对现状的业务进行科学地诊断。

采用目标分解与纬度分析方法开展。分析包含一个总体目标，按照多视图分解到多个分目标，每个分目标包含多个分析指标，而每个分析指标都有相应的定性分析方法和分析结果。沿用的分析手段采用了平衡积分卡的思想，便于企业长期使用。

使用ARIS模型与ARIS工具对于模型的统计分析功能来完成分析工作。由于前期的建模工作有了大量模型成果，一些关键的数据分析可以通过模型来开展，例如：流程的应用系统覆盖率。在模型真实的情况下，此类分析能够很精确地反映企业架构管理现状。因此为了达到更准确的效果，还将对模型的真实度加以评估。

应用系统架构良好支持业务代表了企业架构下应用系统架构建设的质量。应用系统的建设为业务信息流的自动化提供技术平台，并业务流程的标准化提供支持，可以说，企业应用系统建设的主要目的就是为了业务服务。应用系统架构的建设也是建立在IT的基础设施之上，因此对它的规划将直接影响IT基础设施的需求。应用系统架构良好支持业务流程需要在良好地支撑流程需求和数据运作的基础上，还要保留有良好的系统集成性和可扩展性。因此，应用系统对业务流程流程执行过程，数据流转过程的可服务性是很重要的。在此基础上，多个应用系统之间的系统接口和架构方式也是需要关注的。

基于ARIS平台的企业架构分析与评估结果示例

交付物三：经过合理规划的TO-BE的IT架构

在IT架构管理的整体下，如何通过对业务的变更获得系统的变更方案？博阳咨询推荐IT城市规划(ITCityPlanning)的规划方法。

IT城市规划方法

在IT规划中采用ARIS的信息系统视图(IS视图)，可以作为层次与层次之间转换的媒介。在ARIS中，IS视图中的对象类型必须放在功能和应用系统之间，这样便拓展了ARIS中的功能视图。如同各种功能一样，IS的元素与不同的结构相连接，出现在ARISHouse模型的常见视图中。这些扩充主要与流程视图和数据视图相关。在下面所述的IS视图中，涉及来自于ARISHouse模型的功能和流程视图中，用来描述IS元素之间的关系的模型类型，或者在其它ARIS视图的背景下，用来详细描述IS元素的模型类型。

交付物四：IT资产与IT架构的生命周期平台

对系统的功能进行规划后，不可忽略地就要考虑系统的实施过程。但对于完整的IT架构来说，系统从规划到实施，再到使用与维护，直至淘汰，是一个完整的生命周期。因此把系统当做IT的资产来进行管理是可以覆盖到系统的完整生命周期。

系统实施周期的评估过程

系统评估的方法有很多种，博阳咨询建议对规划好的系统以及系统模块按照成熟度与重要性进行评估，便可以知道哪些系统需要先期建设，哪些后期建设，有一个良好的系统引入的过程。

系统生命周期的评估过程

同样，系统一旦建设完成，系统的管理与评估工作远没有结束。需要持续地通过对系统功能满足程度的评估，不断地获取系统是否要升级或者淘汰的预期，保证系统能够时刻满足业务需求。这也是IT架构管理中持续改进的建设环节。

IT它的作用是主要是灵活性。在这个时代,电子商务、社交媒体网络和消费者的驱动,实时的业务。企业必须足够灵活,能够与时俱进,因此需要IT体系结构可以使企业快速响应各种情况的变化，那么灵活使用IT架构的三大要点是什么呢？下面昌平北大青鸟为大家具体介绍。

很多时候团队的一个挑战是如何让企业电子商务和社交媒体网络，当技术和业务过程加速和不可预测的变化中也能保持联系。很多人思考这个挑战会使我们感到头痛。这看起来是不可能完成的任务，但这是IT专业人员需要做的。

实现灵活性模型的步骤是实现内部系统和外部系统之间的连接，被称为编排层，北京昌平UI设计培训认为它的作用类似于一个缓冲区，主要是变化率两种环境之间的区别。

第二步，收集企业数据中心与各种云计算，数据存储，检索平台（混合云）之间的各种安全可扩展的连接。并且北京昌平IT培训发现您必须利用各种云能力来处理业务所需的计算峰值。

第三步是开发各种面向客户的应用程序，这些应用程序使用社交媒体、云SaaS平台，这些平台已经运行在各种IT消费设备上，如智能手机、上网本和平板电脑。电脑培训建议利用社交媒体和SaaS应用开发环境，可以为企业创造各种新的应用程序，与自己的客户进行交流。

以上就是关于下一代软件架构--SOA(面向服务架构)全部的内容，包括:下一代软件架构--SOA(面向服务架构)、寻找架构师：从企业架构的角度看需求的满足、云计算的服务模型有哪些等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！