随着企业的业务发展，系统的不可靠以及无法扩展等问题都成为了企业CIO的烦恼。在当前云架构环境下，表面上看这些问题都是因为SaaS产生的，实际上从架构上看是PaaS的问题，是没有PaaS平台、PaaS不合理或者PaaS无序的问题。
说起来，无论是云、架构还是应用扩展都不是新鲜的话题，但很多企业一直没有很好地解决，甚至成为很多企业信息化发展的障碍。同时，这也是很多CIO难以逾越的一道坎。尤其是在互联网＋时代，企业的转型更加依赖信息技术，无论是信息化的深度和广度都在发生重大的变化，给CIO带来新的机遇与挑战。
本文内容从两个方面展开：第一个是CIO的使命，第二个是企业信息化的现状。
CIO作为企业的首席信息官，主要有两大使命：第一个是IT管理，第二个是IT 架构。
IT管理是什么？
所谓IT管理，即我们通常所说的IT战略、IT投资、IT组织、IT服务、IT风险等等，这些不是我们今天讨论的话题。IT架构是CIO与其它高层管理者不同的专业方面的内容，其核心内容是围绕企业的战略，通过构建与企业业务相适应的IT架构，来适应企业业务的发展，其中包括应用架构、数据架构、技术架构。
在我们日常工作中，围绕企业的IT架构，除了构建外，集成与扩展成了我们CIO的工作主要内容。这些源于企业战略与业务的变化，对IT架构提出很多挑战，所以我们很多时候围绕企业的业务架构在集成和扩展方面苦思冥想，如何适应企业的发展。
IT架构的挑战
按照我们企业的现状，我将其分为三个阶段：各自为政、五花大绑、困死。
众所周知，在企业信息化发展过程中，企业信息化建设基本都是从部门级开始的，基本上是各自为政。有的从单一业务开始，随着协作效率的提高，开始整合系统，比较原始地开始做集成、接口，各个系统五花大绑。刚开始的时候系统集成起来了，随着系统集成的接口不断增多，之后一旦公司业务不断变化，各个系统就会“动弹不得”。
在我的印象中，很多用SAP产品的公司，当时选择SAP是由于原来的系统五花大绑，没有办法适应企业的业务变化，整个IT架构重新推翻，这才开始选择SAP。这些现象表现在信息孤岛、不灵活、不可靠、无扩展，表面上看这是一个个系统问题，实际上通常是我们的架构不合理引起的问题，或者说是被动地应对业务的变化，出现“困死”的情况。
围绕这些问题，我们主要通过架构的角度，如何进行企业的应用集成与扩展，谈到架构，进入了云时代。因此，今天从云架构的角度来谈，如何进行企业的应用集成与扩展。
云架构概述
云的架构，分公有云，私有云、混合云，这些是云的类型。类型不是我们今天讨论的内容，我们主要从云的层次展开，分为基础架构层IaaS、平台层PaaS、软件层SaaS。
基础架构层随着云的技术发展及云服务商的出现，给CIO带来了更多的方便。
SaaS层，在互联网时代转型，企业很多应用非常无序，尤其是大量app的产生，随着无序的扩展，产生了很多“孤岛”，这是CIO很苦痛的问题。
如何解决这些无序应用的问题，需要我们企业的应用要像基础架构一样需要有很强的张力，适应企业业务的发展。通常从几个方面来解决：首先一个很重要的问题需要把公共服务抽取出来，比如：附件。构建一个内容服务器，进行统一的管理和存储，变成一个公共服务，提供内容管理服务。对很多应用共性进行抽取，把应用分成了变和不变的部分，不变的部分就是平台的各种服务，还有一部分业务是需要适应企业的变化的。
这样在我们整个云架构中，基础架构和平台架构部分相对比较稳定，属于不变部分，具有一定的可靠性和扩展性。PaaS层一方面适应业务的变化，另一方面形成了一个统一整体，由PaaS平台为所有应用提供公共服务，使系统的扩展性和可靠性得到很好的保障。
所谓公共服务，所谓PaaS...
我们通常所说的公共服务有哪些呢？不同的企业不同的应用，公共的服务也不一样。
第一个业务流程BPM，所有系统都需要业务过程管理，这个时候就需要业务流程。
第二个portal门户，把应用系统集成起来，需要有一个统一的与人交互的平台，就是门户平台承载的，主要是集成展示、信息发布、集成搜索等等。
还有一部分，所有的系统都有文档管理、都有附件。员工需要上传、存储、搜索文档，企业应该提供一个公共的内容管理服务。
另外，ESB总线，应用集成公共服务、大数据等等，构成我们PaaS基本内容。
在目前的实践中，其实PaaS也并非一个统一的概念，不同的厂商、企业，在构建PaaS层过程中，使用的方法和技术都不太一样。一般来说，PssS分为两个大的分类，一个是iPaaS（集成PaaS）,一个是aPaaS（应用PaaS，包括portal PaaS、mobile PaaS等等），这些就构成我们PaaS的主要内容。
有些厂商提供专业的PaaS，如：BPM PaaS、portal PaaS、综合类的PaaS，关键是要根据自己的业务需要，选择适合自己的技术路线。
需要注意的两点：第一，各个PaaS的组件必须是专业的，不应该是大而全的；第二，跟组件之间的兼容性要求比较高，如果有缺陷，就意味着所有的应用都有缺陷，包括功能、性能等等。
构建PaaS平台常见的误区
第一，以SaaS平台来承担PaaS的功能。比如很多企业用OA来承担PaaS的功能，通过工作流来串起整个企业的业务流程，OA是一个典型的SaaS，他是有范围的，也许购买了30个应用，但从来没有说OA要承载BPM的功能，这个时候实施者发现有很多需求超出了OA的范围。在这里，我们就已经犯了一个错误——以SAAS的功能来承担PAAS的功能。
第二，以偏慨全。有些BPM产品，以业务流程为主，也有一些简单的门户、简单的应用开发功能，实际上其核心的功能就是BPM。这个时候，如果将其作为一个完整PaaS平台，会在实施过程中碰到很多我们无法逾越的问题。
第三，组件之间的不兼容。例如BPM与主数据的不兼容，做BPM的表单的时候需要调度主数据里面的基础数据，表单里面的基础资料没有办法读到主数据，会给我们带来很多的不便。
第四，缺少预见性，不适应未来的发展。PaaS是一个相对不变的基础的平台，在构建的时候一定要预见未来的发展，比如可靠性、容量等。必须要有一定超前性的规划发展，否则刚建起来，又不适应了，这样对企业来说是种浪费。有的时候PaaS带来的问题会比SaaS带来的问题更加严重。
基于云架构集成和扩展功能
谈到集成和扩展，其本质就是“2个对象、3个关系”。2个关系就是人与系统，3个关系就是人与人、人与系统、系统与系统。
先谈谈集成的问题...
基于企业的现状，绝大多数企业用OA来做集成，前面讲过，OA是个SaaS，之所以以OA为中心是因为OA有内容、工作流、全员协作，基于这3个特点，企业通常以它为中心与ERP、HR、CRM等等做集成。
再看这个图的右边，这是典型的通过平台来做集成，各个系统之间是不打交道，全都是通过PaaS平台打交道。各个应用之间是松耦合的，全部通过底层的地下工程各自分工，通过各种专业的服务为各个应用保驾护航，使整个企业应用底层构成一个有机的整体，形成一个平台架构。
这种集成，就好像我们建一个园区一样。早期的园区先建起来房子，各个房子之间是孤立的。随着园区的发展扩大，开始需要在地下建立地下工程，包括通气、通水、通电等各种线路，这样使整个园区变成一个整体，这是我们讲的集成。
围绕我们前面说的3种关系，如何构建集成的平台？基本上借助SOA的架构，首先解决人与人、人与系统的问题。
这方面，我们会想到门户，分为信息门户、个人门户、协作门户、知识门户、社交门户等。除此之外，还通过业务流程把所有的人与人、人与系统的关系有序规范起来，系统与系统的关系又通过ESB总线这样的方式有序起来。还有部分内容管理，把企业和系统提供的内容统一存储管理，还有主数据、统一身份的管理都是为构建PaaS的时候提供的服务。
需要注意的是，这门户与我们业务系统所说的门户不一样，门户其实是有严格定义的。
我们在实现业务集成的时候，往往不是单一地靠某个服务完成的。比如在做工作流集成，尤其是与业务系统集成的时候，往往业务表单会调用主数据，也会调用业务系统的数据，这时做工作流是需要建立主数据的，同时主数据又与大数据、数据仓库是相关的。集成这么多业务系统，同时需要统一的身份认证，需要一个门户展现，其实构建的时候不是单一服务，是需要很多专业的服务来协同完成，同时也需要PaaS服务之间有很高的兼容性。
在很多企业构建PaaS平台的实践中，由于异构的专业PaaS之间的兼容性和可靠性，买了很多专业高档的服务，但因为这些服务之间的不匹配，或者对人员要求过高，导致整个PaaS平台运行过程中磕磕碰碰。正如大家所知道的，PaaS平台一个小问题到了SaaS层就会无限放大，到了用户层就会更明显地放大。
关于扩展...
关于扩展呢，是不一样的。先做规划，做三通一体，先做地下管网，建立各种不同的房子实现园区的功能，这是我们所说的扩展。事实上，从某种角度来说，集成和扩展是逆向的。
应用的扩展通常基于PaaS平台开发，市面上有很多开发平台，我认为一般的PaaS开发平台，不应当直接面向技术人员，而应该直接面向业务专家。通过一些业务专家的构建，就像实施SAP一样，业务顾问为主、技术为辅这种方式，能够快速构建或者更改应用适应企业的变化。
当然，这样的开发平台，应该具备管理应用的全生命周期的管理，包括设计、开发、维护、移除等等。那么这种PaaS层的扩展，还有一个要求是全业务流程的管理，包括工作流、业务逻辑处理、分析等完整的业务流程，而不是单一的工作流，应该包括全业务的构建。还有一个特点，要求实现“大规模个性化”。这个是一个很矛盾的名词，以前觉得不可能，现在基于PaaS平台的构建变得可能。
PaaS平台的扩展功能是否强大，就看它的建模功能。一般业务建模包括五个部分：
第一个是组织建模。这个属于基础，表面看是组织机构、人员等，但实际上这个问题十分复杂，既要满足业务流程要求，还要满足权限要求，组织架构、业务架构、虚拟架构岗位角色等需要进行合理的规划建模。
第二个是实体建模。包括数据结构、业务逻辑、业务规则、视图表单等等。
第三个是流程建模。这个在我们在很多BPM中见的比较多。
第四个是分析建模。
第五个是报表建模。
在企业实践中，对建模的要求是比较高的，很多专业的PaaS都有一些建模的功能，只是侧重不同。一个综合性的应用建模平台，每个环节都应适应到现在和未来的发展，而且要求每个环节之间衔接得比较好，这需要PaaS的功底比较深。
未来的大趋势
这几年移动发展得比较快，以后，新的应用无论是SaaS还是PaaS，其发布都应该是多路发布，平板的、桌面端和移动端同时多路发布存在，这应该是未来一个发展趋势且目前整个趋势比较明显。
从现状来看，基于PaaS的SaaS应该是一个大的趋势。这里有三个心得：
第一、国内软件业发展了二三十年遇到很多瓶颈，无论甲方还是乙方，由于原来的SaaS技术和业务模型为一体，不够开放和灵活，不能快速适应业务的发展。
第二、市面上看到很多有名气的SaaS，发现他们在业务发展模式中也碰到了增长瓶颈。主要是业务适应性问题，也是后端没有好的PaaS平台，使SaaS更好地适应业务的发展。
第三，基于这方面来说，在企业架构中，如何适应企业的业务架构，PaaS才是核心，而不是SaaS。
PaaS的扩展应用有哪些优势?
第一，敏捷开发、快速迭代提高项目满意度。我们很多的企业，在做这个调研的时候很快就做出原型，直接给客户进行双向沟通，快速交付，一开始就抓住客户的满意度，而不是像传统的软件公司一开始写了大量的代码，最后发现客户不满意，这样效率就很低了。
第二，大规模个性化交付。这一点，很多软件企业体会都比较深，一直想做的事情，希望能通过PssS思维去突破。这个大规模，是我们可以在PaaS平台配置基本的原型；而所谓个性化是可以满足每个用户个性化的要求，通过原型和定制的方式来形成大规模个性化交付，一方面提高了客户的满意，另一方面降低了项目的风险。
第三，扁平加自主服务。以前很多软件的开发方式，都是总部开发模式。所有软件都是总部研发中心开发完成后，分发到各个地方做实施，实施顾问的作用是有限的。现场需要二次开发的部分，需要发到总部进行修改，这是一个漫长的过程，弊病很多。一方面客户满意度下降，另一方面项目实施周期大大延迟，很多项目风险就是在这个时候出现的。
践行扁平化的方式以后，实施顾问就可以现场直接改动所有的业务逻辑，进行重新配置，快速适应客户的需求。最重要的部分就是技术架构与业务架构的分离，包括ERP、财务软件过几年就要升级，因为业务变化了，所以产品要发生变化。
以后的时代通过PaaS构建的应用，技术架构与业务逻辑分离，业务发生变化，只要配置业务就可以实现新的业务了，与技术无关；而技术的升级，也只要升级技术就可以了，与业务无关，这样技术与业务就分离了。就好像升级邮件系统，邮件的内容不受影响一样。
另外，在PaaS平台上可以无限制地扩展业务应用，可以自己定制，也可以到应用商店购买。同时，很多企业做了很多小应用，形成了孤岛，小应用又很重要，在统一的PaaS平台就可以互联互通，可以高效的协作，以后的发展趋势也是基于统一的PaaS平台，由一个个小的轻应用构建整个企业的SaaS生态，这将是一个比较大的趋势。
多种形态的云架构方式
总的来说，多种形态的云架构方式，我们讲的三层IaaS、PaaS、SaaS，不同的企业，有的做电商、有的是集团、有的做供应链等等，其应用场景不同、规模不同，对系统的性能、功能的要求都不一样。这时候把架构分成三层（IaaS、PaaS、SaaS），在规划的时候要进行合理的部署规划。
多种形态的云架构方式
通过上面的内容，我们主要围绕企业的架构谈了一下应用的集成和扩展。谈这个问题首先是因为我们碰到了问题，有孤岛的问题、有应用系统架构的不适应的问题、有系统的可靠性的问题。
随着企业的业务发展，系统的不可靠以及无法扩展等问题都成为了企业CIO的烦恼（因为CIO是做IT管理和IT架构的）。在当前云架构环境下，表面上看这些问题都是因为SaaS产生的，各个业务部门及领导反馈是某个系统不好用，某些功能不好等等。实际上从架构上看是PaaS的问题，是没有PaaS平台、PaaS不合理或者PaaS无序的问题。
