大视角、大方向、大问题、大架构：（二）应用的相关问题
互联网时代，以应用为主要运营途径的企业规模开始变得庞大起来，应用几乎承载了企业的所有业务活动，企业开始围绕应用为中心进行业务活动。由此应用的主体地位被空前提升。，其价值也远远超越了工具这一范畴，其重要性己经直接关系到企业的生死存亡，其战略地位被广泛重视。于此同时，应用的软件开发规范也进一步得到发展和完善，为研发管理中技术壁垒的淡化和去除提供了有力的保障。从而进一步为应用的繁荣发展提供了基础。然而人们在享受着应用给生活带来的方便的同时，却在不断扩大着数据和处理的规模。日益庞大而复杂的应用群、数据、运行环境、维护等问题的压力越来越大，然而这仅仅只是一个开端而已。
随着应用数量的增多，应用之间的关系开始像人与人之间的关系那么复杂，它们间的协作是如此繁忙、关系是如此众多，而且这些关系在不停的发生着变化。它们在不停的交换着信息，于是有了海量数据，有了波动性，有了连锁反应，并带来一系列新的问题，以至于比现在繁华而拥堵的大都市有过之而无不及。
应用的生态性
如果你是个“网络人”，你也许会知道苹果商店的应用有多少，每天会有多少新的应用产生，你也许会知道亚马逊或者Facebook的数据中心有多么庞大，你也许会知道世界上有多少人在网上购物或玩游戏……应用数量的发展是否可以用摩尔定律来预测？我不是很清楚，但我知道应用在迅速膨胀。在用户体验的驱动下，为了更有力的支持前端的产品特性，我们的后端正在疯狂的生长。为了服务既架构的理念，我们打破的以技术作为应用界定的传统，使得技术在更多的领域滋生和蔓延，于是人类的生活再也离不开应用。
我们来看一个网上购物的例子，一次购物可能会涉及到数十个应用，如商品、库存、购物车、订单、结算、库房、配送等都是业务线上的主要应用，除此之外还有诸如积分、优惠劵、评论等辅助应用就数不过来了。虽然还有库房、配送等大量的人工操作环节，但所有的业务活动都是以应用系统为核心进行驱动的。这些应用之间相互传递着数据，控制着业务的流转，于是形成了相互依附的应用链条。
而每个应用自身又可能是一个应用群，这个应用群要从两方面讲，一是应用可以再细分为更小的应用，如订单又可以分为接单、拆单、下传等多个子应用；二是用于应对庞大用户请求而进行的集群部署，如商品的展示就要用到成百上千台服务器。
上面讲的应用链条有可能还要更长，以至于我们可能不知道它的尽头在什么地方。如购物中的结算应用会和企业外的银行系统进行交互，而银行系统的内部和外部又链接了多少应用我们就不得而知了。所有的应用开始倾向于以某种方式接入互联网这个最大的应用网。它们自由得彰显着自己的存在，并从中吸收者养分，同时也强烈的表现出类似于生物界的竞争与协作的生态特性。孤立的系统已经离我们越来越远了。
应用之间的链接作用，强化了其开放性，我们通过这种开放性借力成长时，也会为这种开放性付出代价。比如一旦某一环节出现问题或波动，将有可能形成连锁效应被迅速传导，放大，于是蝴蝶效应经常让我们震惊和遗憾。如果这个网一旦被某一种方式所破坏，无疑将是一种没有流血的灾难。２００９年８月，台风“莫拉克”引发海底土石流，导致至少三条海底通信光缆受损和另三条光缆阻断，严重影响了亚洲地区的通信和互联网服务，因此我们不得不对诸如病毒、网络战争等恶性事件和自然灾害对网络的影响进行防控。
企业应用作为这个生态系统的一部分，以纯粹的技术方式面对内部与外部的这种高度的复杂性威胁显得越来越力不从心，而我们现在正越来越依赖这个网。我们不得不在非技术领域寻求突破，一方面，我们可以制定相应的网络文化、网络战略、网络布局等，以施加对开放环境的影响，这是从大的方面讲；另一方面，企业内部能够及时发现潜在问题，并迅速完善、调整业务流程，这是从小的方面来讲
当然技术层面上我们也需要加强，例如我们可以提高应用处理能力的弹性，这需要应用及运营环境有热部署能力，它的问题是：一、这种弹性不是无限的，资源毕竟是有限的；二、要有非常好的技术实力和服务器规模，否则没有用武之地；三、 这是一种被动适应技术，无法理解业务问题的本质所在。
另一种方法是通过监控系统来定位问题并排除问题。但目前的现状是领域分散，数据库有数控库的专用监控系统，网络有网络的监控系统，应用和业务则更是自我为用。使得面对问题经常是头痛医头脚痛医脚，不能很方便的找到问题的源头进行处理。我们需要一套能够进行实时关联分析的监控系统，然而非常困难，现有的基于管理的系统不能全面考虑生态系统的这种复杂性，甚至会带来新的技术上的或维护上的复杂性。下文我们会详细说明。
不管你信不信，应用已经深陷一个错综复杂的生态系统内，我们已经不能静止的看待应用的问题，也不能只凭借技术措施来解决全部问题，因为影响这个生态网的是众多的“人”在实时的动态的影响企业的应用，所以企业还需要“人”来及时的了解应用所承载的业务甚至业务的细节情况，并发挥人的聪明才智；还需要有能力及时地将控制落实到应用中去的能力。我们需要一种新的思维方式来打造一个新的管理工具，来帮助人们解决这些问题。
应用的关系
按照德鲁克的说法，管理应该是基于目标的，而这些目标正在被应用所包装、被深埋与代码之中。于是应用只能用业务数据来体现目标的达成。于是我们在全局管理上仅能得到可怜的业务数据而已，别指望现有的应用系统能提供更有用的信息。所以我们的管理工作比较的被动，比较的低效、比较的混乱。目标层次越小越低，这种问题就越严重，因为代码会将它包的更深。一个大象级别的应用系统，包含了千千万万个业务，其关系更是庞大。我们只能以人的方式达到我们目标管理的极限，而更多没有被充分管理的细节只能是只看结果，至于实现的如何我们只能依赖个人能力及生硬的测试，这同时也是我们过程管理中的难点所在。下面的两张图可以很好的说明这个问题：
管理中的关系图(2)
第一个图以业务为核心，很容易理解。第二个图把业务换成了应用，关系却发生了变化，决策管理和应用的关系变弱了，即决策者不关心用什么样的技术来承载业务，只要能满足需求就好。开发（员工）于是把“业务”变成了应用，这种映射只有开发了解，而其他协作部门还停留在“业务”层面。于是只要应用发生了问题我们只能被动应对，而对应用的控制只有通过开发人员来操作。因为协作部门对“应用”没有“明确”的概念而只对业务有明确概念，各个部门之间只能停留在“业务”这一意见相对统一的高层的层面进行协作。这样就导致在相对低层的细分领域上无法充分有效沟通。
举个例子来将，当我们了解某一业务数据异常时，我们可能“猜到”某个“应用”出现了问题，于是我们想找运维看一下状况。但可悲的是我们无法清晰的说明“应用”是哪个程序，而只能通过开发人员的介入才可。再举一个例子，运维人员发现一个应用性能居高不下，对其他应用影响较大，需要采取紧急措施，并通知到技术人员和业务人员。技术人员相对好找，但要找到业务人员就不太容易了。因为应用和业务没有统一的名称进行绑定，我们很难进行准确映射。
我们可以进一步发掘一下我们的潜在需要，如管理决策。我想每个管理者都会有一个“地图”，上面有业务的布局与流转等信息。但这个图只是个大概情况，我们无法放大某一区域进行精细或实时查看与操作。如在对决策进行资源部署时我们非常希望及时清晰的看到目前应用的子系统以及他们的承载能力、质量情况等。我们只能向下级索要这些数据，而下级也面临同样的问题，这种关系数据的缺失必然会造成决策的延迟。
而现实情况是现有的应用对这张图已经进行了精细化实现，它包含了所有的信息——项目管理系统包含了应用的质量、开发投入信息，运维系统包含了环境投入和承载能力信息，而应用自身则包含了业务信息，所有这些数据都存在着关系。但对资源管理来讲这些都是没有经过整合的信息孤岛。我不否认数据仓库有能力解决一些问题，但却不能很好的解决，请看后面的内容，我会提到这个令人不愉快的数据仓库的。
即使是应用之间的直接的业务关系，表现的也不尽人意，只知道自己的存在而不知道有多少依赖者是非常普遍的事情。我经常收到“谁使用了某某接口，请与我联系”之类的邮件通知，这对系统的维护是很不利的，有时会带来很大的风险。假如我们升级某一应用后得知某个已经存在的另外一个系统因此受到牵连并造成了重大影响，我们只有悲哀和无奈。由此可见应用之间关系的“非信息化”是对信息化时代的一种讽刺。
上面说了很多的问题，我们是没有发现这些问题吗？显然不是。那么我们为什么不能建立起管理用的信息化关系数据呢？原因有很多。如现有的人力资源、财务、运维、软件质量等领域都有各自的应用系统，因为业务上没有必然的联系，非常独立。但如果试图在这些系统之间建立起一种迅速的、直接的信息化的关系数据，则好像是一件可笑而多余的事情。事实果真如此吗？让我们来仔细的分析一下。首先，我们先分析一下看问题的视角，之所以有这样的结论我想很大程度上是我们只站在了业务处理角度上来看待这个问题，尤其是非管理人员更是有这样的想法。这是比较片面的。一个企业首先要有一个可靠的管理作用与业务之上，业务才不会偏离运行轨道。管理是全面的、而应用所承载的业务充其量只是一个点而已，从这方面讲这些应用之间应该存在着某种联系。
请别误会，我没有一丁点鄙视、责备已有应用的设计问题，相反我被今天的信息化程度所震撼！其实这是历史问题，前文提到过在应用少的情况下，我们是在“人工”管理这些应用，直到今天我们还在沿用这种做法而已。有人说我们进行了ERP的集成，这些领域我们都涵盖。但我要说的是这种涵盖并没有直接揭示出这些横向系统间的内在联系（后面我会对集成进行详细说明）。
其次，从资源角度上来讲，整个企业是一个资源池。每个应用都会直接或间接的使用其中的资源。然而资源毕竟是有限的，管理层会依据目标的轻重缓急统一调配这些资源，而这些横向领域间的应用虽然在业务上没有直接的联系，但在资源上，不但有着直接的关系而且还复杂的很。因为在协作的大背景下，一件事情的价值需要有很多不同类型的资源来支持。我们如何衡量哪种资源甚至是哪个资源对这件事的贡献情况？现在我们可能只能得到“某个人做过某件”是等类似的信息，而这个人做的事和另外一个人做的事有没有关系？关系程度有多大？想要搞清楚则是非常困难的，我们需要耗费大量的精力和时间。所以只有重要的事情我们才能费此周章，因为我们无法有效的取得这些“关系”数据。现在规模越大的企业，正在某种程度上广泛应用“矩阵式”管理模式，以提高单位资源的效率。更是需要这些直接的、快速的资源关系数据，以方便我们进行灵活的资源调配需要。
再次，应用系统的领域分散性和独立性，是有利于开发的管理和维护，然而我们现在所需要的关系数据涵盖了整个企业内的几乎所有信息系统。一方面我们需要给出统一的关系规范，另一方面我们要大量侵入现有的信息系统。所以无论从技术上还是实施上我们都将面临巨大的挑战，这也是管理信息化举足不前的重要原因。
对于拥有大规模应用的企业来讲，对这种关系的管理尤其要给以足够的重视。关系不能有效覆盖，企业便不能见微知著。关系数据的数量和质量直接影响到公司的管理规模与管理效率。当然关系是复杂的，我们必须客观的认识到这一点。然而关系是一切事物发生变化的根源，因为关系表示着相互作用，相互影响，是个人、家庭、企业、国家和社会发展变化的依据。正因为如此，我们更需要凌驾关系并为我们所用。当然我们不需要把范围扩的那么广，我们只需要把企业内的应用间的关系、领域间的关系搞清楚、条理化就好，这已经非常具有价值诱惑力了。
应用的动态性
应用的动态性从技术上讲主要有两个：
1、应用有自身发展完善的需要，我们需要对系统进行不断的升级与维护。
2、应用的运行环境会发生变化，如网络环境、硬件环境等。
但这并不是本文讨论的重点所在，我们更关注应用的这种动态作用对企业正在造成越来越大的影响，应用在企业中的地位直接与这种影响成正比。现在我们敢肯定的说至少有很多互联网企业对此很关注、很头痛、或者很疲惫。各种“意外”事件让企业蒙受了很大的损失，尤其是“信誉”问题。应用所带来的问题其影响力已经远远超出了技术解决的范畴。企业唯有更加的关注应用的运行状况。一方面我们需要加强管理，如开发过程的管理。另一方面则需要加强监控系统的建设，并试图使监控系统打破领域间的孤立情景。
大而统一的监控构想正在被大型应用企业越来越广泛地关注，这有点像市政交通管控网。交通管控网需要能够及时缓解一辆故障车或其他突发情况所带来的影响，而统一监控要比这个复杂的多，因为我们不光需要疏导，还要迅速修车，因为每辆车上拉的都是“钱”；甚至我们还要了解每辆车的即时车况，以有能力在它趴窝之前对其进行改进和加强。由此可知，统一监控需要涉及很多的领域，其实施的难度不容小视。但现在统一监控有一个致命的弱点，那就是统一监控所体现的信息的相关性是通过封装业务的应用反推业务影响的，这是一种被动的关系反映，是失真的、滞后的、不全面的、复杂的，是高维护难度和高维护费用的。这必然在事态分析在准确性与及时性及简易性上等带来不利因素。如果这样走下去，我认为是走错了方向，并不会有理想的结果产生。
因为应用的主导地位显现，应用的动态性还直接或间接体现在企业对市场的运营能力上。这一方面能够体现出公司的技术实力如何，另一方面则是企业对资源的驾驭能力强弱。在企业内部各个领域都可以认为是为公司创造价值的资源，他们创造的价值直接或间接的体现在应用上。领域内部的工作状况及领域之间的合作状况每时每刻都在变化，公司的规模越大，对这种变化所产生的动态影响了解起来就越困难，企业的市场反应能力和竞争能力就越差。
因此，如果说公司的发展规模存在着多个瓶颈的话，那么对应用的动态了解及调整能力将是其中的一个。这需要提高应用状况的采集效率和质量，但这还远远不够。现在的情况是企业的产出更多的来源于各个领域应用的协作能力，某一个高效的应用并不能从根本上解决企业的整体效率，反而多个时间关系上相互匹配的多个领域应用可能会有更高效的表现。由此可见应用间协作关系的动态觉察能力也是十分重要的。
但现实情况这些数据我们非常的缺乏。我们拥有的只是应用所仅能产生的海量业务数据，而协作却是需要同时考虑各个方面的。为了得到这些数据，大多的做法是借助笨重的、延后的、粗糙的、硬式的数据仓库来帮忙。面对决策、调配的快速、灵活需求我们只能无奈的等待。即使我们得到了这些数据，其价值也是很有现的，因为业务数据只是结果，我们无法确定产生结果的过程本身所具有的所有的细节。
有一个大家都非常了解的现象，小公司在资源上可以灵活的配置，但规模大的公司却非常的困难，其原因就在于对资源的各项属性的“动态”把控能力上。而应用间的协作能力以及应用本身的状况等应用属性的动态情况也正在深刻的影响着企业效率，那么应用是不是资源呢？如果是，那么我们是不是需要转变一下观念来应对应用的动态性所引起的问题。
应用的资源属性
也许我们很难将应用与能源、矿产等资源等联系在一起。这些东西本身没有价值，但他们都可以转化，经过转化其价值就体现出来了。能源可转化为动力，矿产可转化为材料。员工也被当作一种资源已经是好久的事了，而且成立了专门的学科，因为员工可以间接转化为利润。那么应用可以被当作资源吗？如果能它能转化成什么？我想问题并不难回答——我们只是通过键盘和鼠标的敲击，我们便可以实现购物、火箭发射、3d打印……。所以谁拥有了好的应用就是拥有了资源，谁就有可能发财。如微软、苹果和甲骨文，这一点可以通过世界财富排行榜得以证明，这同样也适用于国家。所以请给予应用以战略高度看待，因为我想象不到应用的所掌控的边际在哪里，这是一种强大的、可怕的、令人敬畏的资源。
应用投入使用后，其转化是需要代价的，它会持续的消耗电力、网络带宽、计算资源、存储空间、物理空间等其他资源，而这些都是要花钱的。有报道称当今的互联网需要30座核电站，一个数据中心的用电功率超过了美国的一个中型城镇，而亚马逊有8个。看一下这些巨头支付的场地、设备维护费用、提供的安保措施、环境污染问题……。我想大家不会无动于衷的，当然我们不能否认应用所产生的价值。但如此规模的消耗，我想精明的管理者必然会非常在意。
随着成本的显现，我们会最终关注到不同应用所具有的不同性价比的问题上，我们有理由为那些性价比高的和有潜力发展的应用给以优越待遇，但会讨厌哪些好吃懒做的家伙。此时应用就像工厂里拿着不同薪资的工人，应用的升级就像员工在不断的自我学习、自我成长从而不断提升应用自身的价值。当然也会发生这样的事情，随着时代的发展，需求的变化，应用的价值也会发生变化，就像打工者遇到的不同发展机遇而引起自身价值的变化。
应用只是企业的造钱机器，站在资源管理角度来讲，此时应用的技术特性已经不再那么重要，应用不是一个死板的机器，它可以被改进，它可以不设定报废日期，它可以进行持续产出，它就像一个忠于职守的“员工”，是需要消耗基础资源的高级资源，不仅如此应用还消耗着其他高级资源，如开发团队，项目管理团队等。由此看来对应用这种“高级资源”的资源属性的研究和控制不仅十分必要，而且非常重要，可以起到牵一发而动全身的效果。
可惜的是目前我们只能对应用这种高级资源的下游资源进行管理，即使当红的云技术也只能在硬件范围内提供“硬”资源的协调，但对“软”资源（如开发团队）就无能为力了。其原因就是我们对应用的“资源”属性意识的缺乏，这是事物发展所必经的过程，眼下是时候认真面对这一问题的时机了。当然我们还是非常的需要云技术，只是时代需要弥补这个空缺。
海量数据
任何应用都要和数据大交到，否则就不是应用，但这里只讨论海量数据。我们看一下现在数据海量到什么程度，Facebook每天收集500TB的数据；Twitter的每天产生8TB的数据，来源于《Yann Gourvennec：互联网产业的五大趋势!》。即使是Oracle这样的公司也会为其对当今数据量的处理能力感到尴尬，于是我们开始创造新的轮子——各种分布式数据库技术蓬勃发展起来。现在分布式存储和分布式计算已经不是什么新鲜事了。
以前一个数据库就可以搞定整个应用系统的所有数据，而现在一个表的数据都有可能分散到多台数据库上存储。数据虽然在物理上分散了，但在逻辑上还是一个整体，这意味着什么？有新闻这样说：“搜索一次耗能可烧半壶水”。这就是海量数据的代价，这是“集中”带来的问题。随着信息化的加速发展，即使是数据的“逻辑”整体形式也会受限，比如单一的出入口（单一网络接入点），当然现在考虑这个问题可能是杞人忧天了，但我们需要意识到需要有一种新的方式来解决海量数据的使用方式问题。请不要误解，我其实并不反对集中，而且提倡，尤其对于管理来讲更是要集中。但是除了提供更多的硬件、电力、人力等资源的投入等手段外，我们还有其他方法吗？
为了使分散的数据之间的关系得以体现和方便使用，我们使用数据冗余技术。但我们在做深层次关系分析查询时就只能借助数据仓库了。这要求几乎所有的数据都要向数据仓库里丢一份，这是一个浩大的工程，为此很多公司会有一个专门的部门对此进行运作。他们在不断的去多维度“钻取”、“发掘”潜在的逻辑，这是一种枯燥而乏味、重复且很苦的差事。这里的重复是指工作方法和流程的重复，而这些方法和流程是很难被计算机自动处理的。
数据部的工作需要将来自业务和技术两个方面的素材进行整合，而最大的问题就出在研发部门所提交的技术素材上。其表面上的原因主要是技术素材所表示的业务数据的多样性、异构性、复杂性使得我们难以有一种统一的方式去处理，因为技术素材的形式是由研发完全主导的，数据部只能工作在研发的下游。这是一种低级的、耦合度过高的、不友好的，协作困难的合作方式。我们讨厌研发部的屁股，尤其是跟踪研发的应用变更情况，所以你现在可以理解数据部有时专横、强硬的原因所在了，这会以某种形式阻碍或制约着应用的发展。由此我们不难想象对一个大规模信息系统出各种报表的代价是什么，至少我是不愿意去这样的部门工作的。
先有数据，后又分析完全符合人们的习惯性思维方式，顺序处理是符合逻辑的技术处理方案，然而这不是最优的。我们为什么不能将数据部的工作和研发部的工作独立开来呢？就像CPU的发展一样，原先是单线程的，而现在却是多线程的。可喜的是业务系统已经广泛应用多线程、分布式处理等并行技术来提升其处理能力，然而这只是某一具体业务在技术上的并行处理方案。研发部和数据部这两个资源系统之间的高层次的并行处理目前还是十分的困难，因为我们缺乏并行的指导原则。
也许是我们很难跳出固有的思维方式，也许是历史发展还不到时候，也许我们意识到了问题所在，但却缺少勇气找到解决问题的关键。报表无非关注的是业务上的“点”或（和）“关系”的计数情况，但点和关系在这里是一种高度抽象的概念，将概念变成具体的实现是一个复杂的过程，抽象的层次越高挑战性就越大。而且要让这些点和关系统领研发和数据两个部门，这就意味着需要在管理体系中的更高层次进行定义。这个层次已经不是可怜的两个部门所力所能及的了。技术上和管理上对高层次的要求难以实现也许就是制约数据部工作的深层次原因。
海量数量还有一个“不太大”的问题，那就是效率越来越低。或许所有人都知道在一个1万条记录与1TB记录的表中查询一条数据速度是有差距的，尽管从技术角度来讲我们有并行处理方案，但只要逻辑整体存在，也无法改变这个事实。而更为严重的是我们在这个“整体”内不断地重复着Counting、Summing、Ordering、Grouping……，这些操作都不能站在前一个台阶上生成一个新的台阶并服务于下一个台阶，而只能重头做起。复用技术在这里低效或非常有限！
总之我是不相信只依靠技术手段就可以解决这些数据量带来的问题！依据帕累托法则（80-20）那么只要有20%的数据就可以发挥80%的作用，我们是否可以认真考虑一下先人的这些建议，让我们更多的为这20%的数据倾注必要的精力和财力。尽管这很困难，但我想尝试一下，但不是在本章节。
集成
现在SOA很火，因为他规避了很多技术的障碍，使得应用之间更容易协作，更容易交流，我们会更方便地向信息系统中添加业务组件或调整业务流程。集成像ERP、HRM、CRM这样的系统已经是一种常规的做法，大规模的应用网之所以能够存在可以说SOA功不可没。系统间的集成实际上是应用关系的一种外在延伸，只是领域相对于应用系统来讲更加宽广。有了集成我们可以使某些资源得以复用，如用户系统的复用；我们也可以使业务得到强化和延伸，如在线支付和在线售票等功能。这给消费者带来越来越好的用户体验，并且提高了社会的运作效率，集成为信息化的发展历史写下了光辉的一页。
但如果我们仔细观察，请别把目光放到整个互联网上，因为那个层面我们无法看的清楚，我们来观察一个以信息为主体的企业，在其体量巨大的信息集成系统内，似乎还缺少一些重要的东西（或者严重不足！）。是的，目前这个集成只是“职能”上的集成，连接这些职能系统的是业务数据，它缺少一套“有效”的控制数据来把控所有的职能系统。但我们有监控系统啊，很可惜前面已经说了，它工作的不怎么样，它只能在局部工作的很好。
我们用生物体来做一个比喻，我们的应用网就像生物体内的消化系统，通过我们常规的进食活动，食物就会“自动”被胃、小肠、大肠等职能系统（业务系统）依此进行加工。这个过程不需要神经系统的“智能”干预（可能是植物神经在起作用）便可运作流畅。但如果这个生物吃了不卫生的食物，可能就要吐或泻，这时就需要在神经系统统一协调自身相关资源下才能完成，这是一种应急的资源协调。我再举一些生物对自身资源进行战略调整的例子：怀孕的不同阶段和非怀孕时期对自身各个资源系统的要求是不一样的；以及DNA通过神经系统决定着我们的身体在什么年龄段应该有什么样的特征或者什么样的行为方式。
应用系统是一种职能系统，同时又是资源系统中重要组成部分，我们希望它们在高效的按部就班的运作的同时能够更加聪明一些。这仅仅通过业务集成是不够的，我们还需要集成一套高级的神经中枢系统。现有的监控可以解决一些问题，然而还远远不足，他的意义目前至少没有按照统一协调全部资源这一更高目的而被体现。无论从技术水平上还是从管理水平上，它只能在局部起作用。
SOA实现了一种基于职能的一种系统集成方式，我们还需要一套基于协作控制的一种集成方式。因此目前的集成来讲还处于一个低级阶段，我们需要站在全局资源角度，建立一套全新的统一的资源监、控机制，以实现信息系统更高阶段的进化。如果得以实现那将是一种意义非凡的集成，或许信息系统由此进入“直立行走”阶段，或许人类真的该适时考虑一下到时该怎么应对机器人统治世界的情况了。请放心，本文的理论只涉及到神经中枢的通道和网络，而不涉及大脑的智慧与决策。
