北京IT培训分享MVC和三层架构

很多时候，在一些IT咨询/治理或SOA集成项目中，相信大家一定听过企业架构，这是一个出现频率较高且都会在项目中重点强调的词语。事实上，若想真正的发挥信息化价值，使信息化可以支撑并顺延企业后续的发展，在项目进行前，是必须要规划出企业架构的。

讲到这里，有人会问：“我建设IT信息化的目的是解决当前问题，直接开始就好了，为什么要花费金钱和时间规划企业架构？”对于该类疑问，我的回答是：企业架构是一定要做的！虽然构建一些简单的信息化系统，或做几个系统间简单的集成来解决当前业务问题是不会出现大偏差的。但请试想一下，如果是一个复杂的信息系统构建或大型集成项目，涉及到几十个信息化系统，其中包括通用和专用系统，同时存在多层业务管理关系、多道流程工序时，如果没有事先规划梳理好彼此之间的业务流程、资源复用、IT技术等就直接 *** 作，百分之九十的结果是项目延期或做成烂尾。

这时必须要规划出一个清晰的企业架构，才能保证业务流程相互运转、信息化系统合理支撑、构建步骤有条不紊。可以说，企业架构是IT决策的重要依据，是支撑企业后续发展的重要基石。

企业架构（Enterprise Architecture），简称EA。是指对企业事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案，更确切的说，是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统。复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成，有效的企业架构对企业的生存和成功具有决定性的作用，是企业通过IT获得竞争优势的不可缺少的手段。

企业架构可以分为两大部分即业务架构和IT架构。

业务架构： 是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。

IT架构： 指导IT投资和设计决策的IT框架，是建立企业信息系统的综合蓝图，包括数据架构、应用架构和技术架构三部分。

业务架构相当于企业的运营模式，一个公司要发展，一定会有自己的商业目标和运营模式，而这些就是企业的业务层面，可以说企业的业务架构是在市场上区分与其它企业的关键，通常包含运营模式、组织机构、业务流程、地域分布等。

运营模式： 简单来说，运营模式就是企业通过何种方法进行盈利的，即使在同行业范围内，每个企业的运营模式也大不相同，因为运营模式通常是根据企业的战略、目标、优势、发展方向等因素孕育而生的。运营模式一般分为：行政管理、资金管理、技术、生产、销售五个层面，每个企业都会对以下层面进行特殊的设计。

组织机构： 组织机构是企业的运筹体系，包括企业的部门、岗位、职责，当企业的战略发生变化，组织机构也会相应的调整变动。

业务流程： 这里的业务流程不是指针对企业的某个关键业务的一种描述，而是企业整体运转上的大流程，体现在整体资源的梳理、组织机构的分配、管理制度的优化，对业务运营存在着指导意义。

地域分布： 地域分布主要确定业务活动在什么地域执行，地域分布对运营模式的规划、组织机构的划分、业务流程的设计起着关键作用。

企业架构中的IT架构是构建企业IT信息化系统的基础，它能够有效指导IT信息化项目的开展和执行，IT架构又分为数据架构、应用架构、技术架构。

>>>>数据架构

数据架构是企业IT架构的核心，众所周知，数据是对客观事物的真实表现，具有权威性和价值性，企业信息系统下的运营状况都是通过数据反映出来的，数据可以作为企业的重要资源，因此在考虑IT架构建设前首先需要考虑数据架构对当前业务的支持，即企业需要哪些重要数据、企业数据如何治理规划、如何实现重要数据的运用。之后，根据上述几点进行数据架构规划，数据架构规划主要包括数据模型、数据分布、数据治理三个方面。

数据模型: 良好的数据模型可以反映出业务模式的本质，确保为业务需求提供全面、一致、完整的高质量数据，且为划分应用系统边界、明确数据引用关系、定义应用系统间的集成接口提供分析数据。然而数据模型不只是与应用架构关联，同样对业务架构提供生命周期治理和管控，在业务架构中的数据模型分析重点是主数据和核心业务对象，而应用架构中的数据模型则进一步转换到逻辑模型和物理模型，直到最终的数据存储和分布。

数据分布: 数据分布包括业务分布和应用分布，数据分布一方面主要是分析数据在业务各环节的增删改及引用的关系，另一方面是分析数据在单一/多个系统中的数据结构与应用系统各功能模块间的引用关系。

数据治理: 数据治理包括元数据管理，数据质量管理、数据标准规范、数据字典、数据安全、数据采集、同步、分发等内容，即主数据管理内容。数据的治理在整个数据架构中起着非常重要的作用，高质量的数据是构建数据架构的重要支撑，同时也是企业后续梳理业务流程建设的前提。

>>>>应用架构

应用架构向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。应用架构是业务架构、数据架构、技术架构、信息安全及IT管理等方面综合的体现，它包括了企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。

在构建应用架构时，满足当下需求的同时，需要进行长远的规划，即符合企业未来的发展方向，并能根据业务进行扩展。

灵活性

体现在应用系统之间的连接是否灵活、简单、松耦合，激烈的竞争和产业变革，需要企业不断调整其组织、流程和商业模式，以获得竞争优势。这时，应用架构要可以适应企业业务的变化，快速做出响应，提供稳定可扩展的应用支撑平台，为企业的业务发展、随需应变提供重要的支撑，同时能保证部分应用功能的升级或替换不会影响到其它应用系统，实现平滑升级。

整合性

整合性部分常见的整合包括数据集成、应用整合、流程整合、门户集成等。

1数据集成

数据集成主要针对企业信息系统底层的数据同步性、时效性问题，解决数据来源的唯一性、真实性、实时性，一般通过消息队列技术或者Web服务等，将散布在企业各个系统中的数据，以一种松散耦合、集中呈现的方式进行统一管理，促进数据在企业范围内互联互通。

2应用整合

应用整合主要针对企业业务变化适应性和信息孤岛问题，通过对系统功能的服务化编排，实现快速调整的d性应用。应用整合提供面向服务所需的软件基础设施环境，为分散服务提供了交互、组合和治理的基础架构，集成企业内部各个IT 应用系统，并使之互相协同工作，形成一个更大的整体系统。要求不只是实现系统间的技术集成整合，还要实现业务之间的有机整合。

3流程整合

流程整合通常也称之为流程集成，主要针对企业业务逻辑在多个信息系统之间流转的问题，具体体现为跨异构系统的流程集成，以业务流程为中心，帮助企业各业务环节与客户需求对齐的管理方法，有效整合人力、信息等资源，实现跨系统、跨部门、跨组织的企业运营，支撑企业实现业务的“纵向贯通”与“横向集成”，帮助企业实现从战略到运营端对端的跟踪、反馈与优化。

4门户集成

门户集成主要针对企业交互访问层集成问题，把企业内部原有的零散系统中的信息、应用、服务通过统一认证、页面集成、菜单集成、数据门户等技术整合在统一的访问平台，提供企业范围内的统一授权和身份认证，基于单点登录、个性化配置方式，为企业IT架构提供一个标准的、可扩展的Web 应用基础框架。平台支持多端登录，即PC门户、移动门户，移动门户同样提供统一身份认证、单点登录、信息/页面/应用集成等功能，通过移动门户可以访问PC端系统大部分功能，用于满足出差在外流程审批、办公不受时间地点限制。

复用性

随着企业信息系统越来越多，在构建企业架构面前必将精减或新增一些信息化系统，过程中不可避免会替换甚至是除掉一些平台或功能相似的系统，如果每次都要推到重来，在时间和成本上是不可控的，所以复用IT资产在构建应用架构时，也是重点规划的一部分内容。

>>>>技术架构

技术架构是支撑应用架构与数据架构的技术基础结构，主要由IT技术、组件、相应技术标准构成，具体包括：安全管理、应用软件、应用平台、物理环境、系统管理。

安全管理： 安全管理是指应用软件、应用平台、物理环境各层面的安全管理架构、安全配置模型、安全管理工具以及安全管理标准等。

应用软件： 应用软件是指应用系统或工具，包括业务应用和支撑应用，业务应用一般分为通用管理软件、套装管理软件、行业管理软件，如CRM、ERP、MES等，支撑应用为基础软件工具，如：Office办公。

应用平台： 应用平台是支撑应用软件运行的 *** 作平台，包括系统服务和 *** 作系统。系统服务是搭建在 *** 作系统之上的各种服务引擎，如：Web Server、APP Server、DB Server等， *** 作系统是管理和控制计算机硬件与软件资源的计算机程序，是直接运行在“裸机”上的最基本的系统软件，常见的 *** 作系统为Unix（AIX、HP—UX、Solaris）、Linux、Windows Server等。

物理环境： 物理环境是支撑数据和信息的采集和进入、处理和传送，以及应用软件与应用平台运行的物理设施架构、模型和标准等，包括系统硬件与网络设施。

系统管理： 系统管理是贯穿应用软件、应用平台、物理环境各层面的系统管理架构、系统管理模型、系统管理工具以及系统管理标准等。

很多企业在建设IT信息化的时候，一般都会忽略或刻意不提及企业架构的规划，殊不知，从那刻起已经埋下了隐患，一旦系统过多，隐患立即显露，造成这种现象的原因有很多，具体表现在两个时间节点中。

很多企业在系统建设初期，往往都是根据现有业务需求去构建相应的信息化系统，极少数甚至没有企业在建设初期会统筹的考虑企业的整体架构。后续，随着企业业务需求不断增多，对信息化系统的需求也随之增多，无规划的构建系统，只能导致信息孤岛产生。本是为了优化业务而上的信息化系统，反而造成了IT与业务的脱节。

一般企业进行系统整合，多半是消除信息孤岛及优化业务流程，系统整合期间是构建企业架构的第二最佳时间，因为在系统整合时，根据企业特定的企业架构不仅可以对企业业务流程、内部数据、应用功能进行统一治理集成，还可以为企业后续信息化建设搭建平台，奠定基础，对于后续业务扩展变化，提供快速响应。即便这样，也有很多企业忽略企业架构的建设，没有站在整体业务上和系统现状上进行规划，这样做的结果就是集成顺序与先前条件不符，导致集成失败或效果不明显。

那么企业在信息化建设初期为什么不进行企业架构规划呢？分析原因如下：

1企业建设初期规模相对较小，资金能力不足，对于花费过多资金规划企业架构是奢侈的。

2企业整体对信息化意识薄弱，认为信息化只是辅助业务的工具，没有必要与业务、文化、架构等联系起来。

3企业领导对企业架构意识模糊，不了解企业架构的重要性，或对企业未来发展没有明确的定位及目标。

4忽略集成整合项目的前提条件，如集成的顺序、信息化状况、业务相互关系等，认为不需要架构梳理规划，直接整合即可。

通过上文中对企业架构的深层次理解及未及时建设企业信息化所带来的问题之后，也许很多人还是没有清楚的了解企业架构究竟能为企业带来什么，企业架构到底有多重要。

下面就来具体谈谈企业架构对企业的重要性。

1支撑业务发展，保证IT投资的正确性

有效的企业架构对企业生存和成功至关重要，它为企业IT系统演进提供了战略指导和分析，使企业能够应对不断变化的业务环境，同时按照企业架构中的规划进行IT信息化建设，可以有效分清IT项目的优先级，然后根据优先级制定IT投资战略。

2节省企业成本，减少IT资源复用情况

企业架构在规划IT建设的同时，会兼顾企业的组织角色和业务流程的关系，可以平衡IT资源与业务间的依赖关系，识别出部门间重复的业务需求和数据重复利用率，从根本上有效避免业务级、功能级、数据级的重复投资。

3有效推动创新，使企业业务更好发展

企业架构能够平衡IT效率与业务创新之间的关系，支持企业业务的创新，使各业务单元的业务流程与信息保持高一致性。同时，可以保证组织的全面IT战略需要，实现企业范围内最紧密的协作。

当下，企业架构的建设还未使绝大多数企业引起足够的重视，保持业务与IT信息化对齐仍是当今时代所有组织面临的一项基本挑战，而构建企业架构是应对这项挑战的最佳途径，无论是公有还是私营，无论是企业单位还是事业单位，都会按照自身的业务特性去构建信息化建设，随着业务增长，一定会追加在信息化建设方面的投资，至于投资是否可以有效换来收益，很大程度上是取决于是否具有完整的、适合企业自身业务发展的架构规划。企业架构提供全业务视角的企业治理体系，保障业务、战略保持一致，促进数据架构、应用架构、技术架构等IT架构建设，保障企业信息化的合理稳步建设，帮助企业实现使用更低的IT成本、更快的设计与开发，降低IT风险的同时获取更高的收益。

一、IT营运管理方法论现今的企业为了强化自己在这个新世纪的竞争力，导入了ERP系统、供应链系统、CRM系统、决策支持系统、知识管理系统等等，这些系统最后都要进到企业的IT营运体系中。当我们透视解决方案生命周期时，可以看到，所有的解决方案最后都要进到企业的IT营运体系中，为企业员工所使用。如果IT的整个营运管理做得不好，那这些花大钱建置起来的系统再好功能再强也没有用，因为使用者根本无法顺利地使用它们。某大型电子公司，共运行了四十多个应用系统，当他的信息主管被问到，哪一个系统最重要时，他回答：「IT的营运与管理最重要！唯有好的IT营运管理，才能让公司上上下下好好的用每一个系统。」这个见解实在是一针见血。既然IT营运管理非常重要，那么如何提供好的IT 服务，对IT 主管或CIO 而言当然是非常重要的课题。答案是采用更新的技术或添购功能更强的设备吗？在1999 及2000年Gartner Group 广泛访问企业CIO 有关服务或应用程序无法使用(downtime) 的原因。结果大家最常认定会出问题的技术或产品(包括硬件、软件、网络、电力失常及天灾等)，其实只占了20%，那么占大宗的是什么呢？我想你已经猜到了，作业程序(Process) 失误就占了40%，另外作业人员(People) 疏失也占了40%。作业流程失误包括变更管理(Change Management) 没有做好、超载、没有测试等等程序上的错误或不完整。作业人员疏失包括忘了做某些事情、训练不足、备份错误或安全疏忽等等。Gartner Group 这份访查结果正是80/20 法则的再次印证。我们常想要把系统的可用度提高，当然就是要花大钱购买标榜可提高可用度的硬件或软件。孰不知这个部分事实上只占了系统停机原因的20%。如何做好IT 服务管理，首要工作当然是加强流程和作业人员管理，因为那才是造成系统无法使用的主要原因－ 两个原因加起来共占80%！我们常听人家说大型主机(Mainframe) 的 系统比较稳定可靠，所以经过了这么多年还是有许多企业愿意花大钱继续一年年采用。其实真的是它的系统软硬件更好吗？恐怕并不尽然。我们知道，大型主机系统 有着一套完整清楚的系统运作规范可遵循，人员在训练时花在运作程序方面的心力绝对不亚于系统软硬件，甚至是更多。有了严谨的程序，加上完整的人员训练，自 然就可以把那80%的系统停机风险降到最低。那么是否有方法论，可以用来建构企业内IT 服务管理而且是主要IT 厂商都支持的呢？

二、什么是ITILITIL（Information Technology Infrastructure Library）是信息系统运营与服务管理标准，用于定义IT部门管理工作中需要的各个工作程序(Process)，以及各个工作程序之间的相互关系。在跨国公司IT经理中素有"IT界MBA"之称。80年代中期，英国政府部门发现提供给其的IT服务质量不佳，于是要求当时的政府计算机和电信局（CCTA），启动一个项目对此进行调查，并开发一套有效的和可进行财务计量的IT资源使用方法以供本国的政府部门和私有部门使用。同时，这种方法还应该是独立于厂商的并且可适用于不同规模、不同技术和业务需求的组织。这个项目的最终成果是一套公开出版的IT服务管理指南，即ITIL（Information Technology Infrastructure Library）。虽然ITIL当初只是为英国政府开发的，但是在90年代初期，它很快就在欧洲其它国家和地区流行起来。到90年代中期，ITIL成为了事实上的欧洲IT服务管理标准。90年代后期，ITIL又被引入到美国、南非和澳大利亚等国家和地区。2001年英国标准协会（BSI）在国际IT服务管理论坛（itSMF）年会上正式发布了以ITIL为基础的IT服务管理英国国家标BS15000。2002年BS15000被提交给国际标准化组织（ISO），申请成为IT服务管理国际标准。国际标准组织已接受这个申请，并为此设立了一个专门工作组。该标准有望在2006年前后生效，可以说，ITIL已是事实上的国际IT服务管理标准。ITIL的目的是帮助企业降低IT运营管理成本，并且提高IT服务水平，提高业务部分的满意度。

三、ITIL的核心思想ITIL它并不是一套理论模式，它所根据的是最佳的实际经验。其中的许多经验不但广为人知，而且有无数的IT机构都是采用它来提升IT服务的效率及加强IT部门间的横向沟通。这套方法论历经了十数年的考验，证明它是最被IT业界广为接受的一套经营IT经验指南，等于是IT管理的业界标准。ITIL将IT的工作分为两大类：分别为《服务支持》（《Service Support》）和《服务提供》（《Service Delivery》Service Support针对的是一般系统的运作部分，目的是让使用者可以顺利存取到IT服务。其中包括Service Desk、事件处理与追踪、问题处理与追踪、系统变更、系统配置设定的记录与维护，以及版本的发行与控管。第二大类Service Delivery则是针对IT部门对客户提供信息服务时应有的工作程序。其中包括服务层级的约定与管理、IT服务的财务管理、系统可用度管理、系统容量的测量与未来规划、灾难情况的业务持续运作规划与系统复原。《服务支持》（《Service Support》包括如下流程：

1 事件管理（Incident Management）: 识别偶发的事件。

2 问题管理（Problem Management）：对服务台识别的偶发事件的潜在原因加以诊断，安排改正IT基础设施的错误并进行问题预防指导。

3 变动管理（Change Management）：变动管理过程确保使用标准方法和规程有效且迅速处理所有变动。变动管理旨在提高组织的日常运作水平。

4 配置管理（Configuration Management）：识别、控制、维护和检验现有的包括基础设施和服务在内的IT资产。

5 发布管理（Release Management）：通过控制软件、硬件的发行和版本确保信息系统资产的安全，并消除不同版本引起的潜在问题。 《服务提供》（《Service Delivery》）包括如下流程：

1 服务水平管理（Service Level Management）：服务水平管理的目标是通过协调IT用户和提供者双方的观点，实现特定的、一致的、可测量的服务水平，以为客户节省成本、提高用户生产率。

2 可用度管理（Availability Management）：可用性管理的目标是优化IT基础设施的性能，它的服务和支持的组织。可用性管理导致成本节省的、持续的服务可用性水平，这种服务可用性确保业务满足其目标。

3 能力管理（Capacity Management）：使组织在危机出现时管理资源并提前预测需要的额外的能力。它描述了计划、实施和运行该过程必需的规程。

4 持续性管理（Continuity Management）：在尽量少的中断客户业务情况下，提供IT服务，并在IT系统出现问题时，以可控的方式恢复。

5 财务管理（Financial Management）：确定IT服务的成本核算，设定预算，监督预算执行情况，根据提供的服务收取费用。 针对ITIL管理流程的具体实现，ITIL标准又将实现工具分为三类：Process Management Tools—过程管理工具Analysis Tools—分析工具Execution Tools—执行工具 四、XX银行IT管理规划建议全面实施ITIL模式对任何IT企业都至关重要，但在实施时通常需要循序渐进，并且要从最急迫需要解决问题处入手。最重要的是要采用统一的符合ITIL标准的信息架构。另外，在实施前，切记先记录下现有环境数据，以便随着时间的流逝来衡量成效。我们建议xx银行将规划分为：短期目标，中期目标，长期目标三个阶段实施，从而构建符合ITIL标准的IT服务和管理平台。短期目标：达到目的1）立符合ITIL标准的统一的信息架构（altiris notification server）

2） 保证统一的配置管理数据库（Configuration Management Database）

3）实现变更管理、配置管理、问题管理变更管理（Change Management）为何要做变更管理呢？这里举两个因为变更管理没做好而蒙受重大损失的例子来说明。2001 6 ，NASDAQ当机长达半天，原因是 *** 作人员做了一个未经测试的变更动作，结果导致整个系统停机。同样也是在2001年6月，NYSE在半夜做了一个软件变更的变更动作，导致部份系统当机，无法完成股票买卖交易。这两件事都上了报纸及新闻头条，包括华尔街日报、CNN 及CNBC等等。这反映出了变更管理真的很重要，一旦没有做好它，企业的关键任务(Mission Critical)系统就会受到影响。以银行业为例，只要是IT部门当机一小时，其导致的结果可能是全体员工要花上数倍或甚至是数十倍的时间来补救，而且因为分行里客户大排长龙，负面报导上了晚间新闻及报纸，企业形象受损的损失更是无法估计。这也可以说明为何企业CIO 把变更管理视为第一要务。为进行变化管理，IT组织中应该有变更管理员（Change Manager）及CAB（Change Advisory Board）的编制。变更管理员是全程负责监督RFC从提出到结案整个过程的人。CAB代表是变更咨询委员会。配置管理：在公司内，通常会做所谓的资产管理(Asset Management)，也就是把每项公司资产是何年何月何日购入、哪一个会计科目、负责人是谁等信息记载在数据库中，这是一般传统的资产管理方式。但是实际经验显示，如果用这种方式来管理IT相关资产，包括硬件、软件、网络等等，结果会因为记录的信息太过简化而衍生出许多问题。IT资产的管理所必须记录的信息要比一般资产多得多。目前有经验的IT部门都有一套方式来记录IT资产。但是IT资产的管理难道就只是详尽记录它的型号版本等等这些规格信息而已吗？其实这是不够的，还要包含该项资产所有的配置设定，以及它与其它IT资产之间的相互影响关系。这些配置都会输入到所谓的「配置管理数据库」(CMDBConfiguration Management Database)中。准确而完整的CMDB是相当重要的。因此要有一个机制来提供这个信息，这个机制就是配置管理(Configuration Management)。配置管理可存取并提供IT资产正确信息和这些资产间的关系，还能提供对系统的影响及趋势分析，降低未经授权软件的使用情形，以及控制所使用的IT资产。问题管理问题管理的目标就是要找出事件或问题发生的真正原因，并找出对策或步骤来解决问题。我们常说要对症下药。没有针对原因来解决问题，可能可以让服务暂时还可以使用，但如果错误原因没有被消除的话，将来还是会发生问题，事件还会再重复发生─ 进而再度影响IT服务的提供。这 也就是为什么要有问题管理的原因。唯有找到原因，才能解决问题，避免同样的问题一而再，再而三的发生。问题管理分成两个部分，一个是被动的部分─等事件通 报变成问题，再来分析问题，找出问题发生原因，加以诊断，再提出解决方法及步骤。一个是主动的部分，分析趋势，事前先找出可能潜在的问题，主动提出解决方 法及步骤，预防问题将来发生。

4） 对应altiris工具

配置管理Configuration Management 过程管理工具/分析工具/执行工具

Altiris Architecture- altiris notification server 建立统一的信息管理架构

Altiris Inventory solution 资产管理

Altiris web reports 报表分析功能

Asset Control solution 固定资产管理，建立最完整统一的资产信息及相关联信息

变化管理Change Management 分析工具

Altiris Inventory solution 资产管理

Asset Control solution 固定资产管理

Altiris web report 报表分析功能

Application Metering Solution 应用软件管理

执行工具

Altiris software delivery 软件部署与升级管理

Altiris client management suite 客户端 *** 作系统部署、升级；软件的部署与升级；微软补丁自动安全管理；远程控制等。

问题管理Problem management及事件管理 Incident management 分析工具

Altiris Inventory solution IT 资产管理

Asset Control solution 固定资产管理

Altiris web report 报表分析功能

Application Management Solution 应用管理

执行工具

Altiris Deployment Solution 系统部署、升级和管理

Application Management Solution 应用管理

Carbon Copy Solution 远程控制

中期目标：达到目的：实现事件管理、持续性管理（Continuity Management）、可用度管理在现今全球化经济社会下，可用度及IT服务持续性管理可说是最举足轻重的两个重要程序。营运服务能否持续每天24 小时，一周7天地正常运作，变得愈来愈重要。可用度能左右顾客满意度，并且能快速的影响企业整体声誉及业务是否成功。IT服务持续性管理程序是要确保正常可用的解决方案发生问题后，依然能够持续提供另一个等级的IT服务给客户。从这个观点来看，可用度管理及IT服务持续性管理的关系非常密切。这两个管理程序都是试图减小IT服务的可用度危机。可用度管理的焦点主要是集中在处理日常可能出现会影响到可用度的危机，如果无对应的反制措施或反制措施没有办法完全涵盖或应付时，这些危机就由应变计划及IT服务持续管理程序来处理。IT服务持续管理程序分做3 个步骤。第一步是取得Service Level Agreement，然后分析及找出每层的危机，将IT服务分成下列层级：服务、应用软件、中介软件、 *** 作系统、硬件、网络、环境、外在影响因素。第二步是提出这些紧急状况的解决方法；这包括两个部分：第一个部分是Failover，第二个部分是Recovery。Failover 包括有几种选择：Cold Standby、Warm Standby 及Hot Standby。第三步则是制作应变计划。对应altiris方案：

服务水平管理（Service Level Management） 过程管理工具/分析工具/执行工具

Altiris helpdesk Solution 建立统一的service desk

持续性管理（Continuity Management） 分析工具

Altiris Site Monitor Solution 网络站点监控模块

Altiris Monitor Solution 服务器监控模块

Application Metering Solution 应用监控模块

执行工具

Altiris Recovery Solution 恢复模块

长期目标：达到目的：IT财务管理分析（Financial Management）

IT财务管理分析Financial Management） 过程管理工具/分析工具/执行工具

Altiris Contract Management Solution 合同管理

Altiris TCO Management Solution IT 总体拥有成本分析

Step1情景概要

Hello,小伙伴们,昨天跟大家分享了JAVAEE企业级应用开发中大家耳熟能详的概念-三层架构,那么有的小伙伴可能就会有疑问了，这种代码书写方式我每天写这些web项目时都是在采用该方式呢，北京IT培训发现那跟我们所接触的MVC有啥区别呢，借着这样的疑问,我们今天聊聊我们程序员们在开发时经常提到的MVC。

Step2问题浅析

在开发中，我们可能总是不经意间就将三层架构与Mvc混为一谈，殊不知它俩并不是一个概念。下面我来为大家揭晓我所理解的一些“真相”。

三层架构:通常意义上的三层架构就是将整个业务应用划分为：界面层（UserInterfacelayer）、业务逻辑层（BusinessLogicLayer）、数据访问层（Dataaccesslayer）。区分层次的目的即为了“高内聚低耦合”的思想。

MVC：全名是ModelViewController，是模型(Model)－视图(View)－控制器(Controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

哈哈，看过概念感觉有点晕晕的，那具体该怎么去理解它呢

Step3回归代码

在步骤二中对于三层架构与MVC的概念性问题做了一个解释，当然对于我们程序员来说概念神马都是浮云，只有代码才是我们的钟爱，接下来我们来具体来看看通过代码怎么去理解两者区别。同样还是借助我们昨天的用户登录场景来分析。

在没有分层的情况下，也没有MVC概念的前提下，我们想要通过服务器端给浏览器响应一个登录页面。

以上就是关于论企业架构的重要性全部的内容，包括:论企业架构的重要性、如何基于ITIL构建有效的IT服务管理体系、北京IT培训分享MVC和三层架构等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！