80年代、90年代学习软件工程里都会提到软件危机，软件危机的原因主要是软件的复杂性和经常在变化的用户的需求。或者说我们没有办法用一种统一、又能够理解的，为行业界人士和IT技术人士都能理解的需求。它导致的直接现象就是项目完不成，软件效益不高，或者说经常会出现各种各样的问题。另外根本上来说不能满足需求的变化。还有很多花掉几百几千个代码以后被迫取消。
重要的点从软件工程角度来讲，怎么样做一个正确、又能够被人们所理解，而且还能够被验证的计算机程序?我们有没有办法做到这个事情?软件危机80年代出现，到现在还没有完全解决，但是有了更好的方法个工具支持我们的工作。从通信行业来讲我觉得这个问题可能比银行、政府问题更加严重。最主要的，举几个现象：
第一，从大的厂商来讲，我们现在很多公司有成百万、千万的代码在支持运营、管理、服务。我们不知道大的供应商有多少人愿意花时间重构这些几百万行、几千万行的代码?可能不会很多。根本上没有解决复杂性的问题，比如说网络里有多少协议?各个层次以千来计算。从产品上来说，每一个厂家、每一个型号、根据不同的协议度支持度产生的产品也是成千上万，我们要组合一个可靠的可以管理的网络难度自然存在。所以最后一点就是可管理性。大家都知道，很多情况下网络已经变得越来越不可管理，这就是08年的时候斯坦福和伯克利的教授和两位学生期望以更简单的方式描述网络，在校园里先提供一个实验的平台。看看这些简单更加可行的方法能不能变得通用。
刚才说了软件危机以后从软件工程这个方面我们经历了好多次的革新，从80年代中后期的面向对象，到90年代初期的面向组件，后来到面向服务。这样一种越来越更加开放，面向重用这样一种整体的软件架构慢慢的为更多人所接受。但是我们觉得还是应该强调，没有一个很完善的方法解决所有的问题。所有大型的复杂度比较高的，特别是需求比如说我们的协议的定义不很完善。比如说Openflow这个协议本身从1.0、1.1到1.2、1.3里面可圈可点的地方还挺多的。走进去以后会发现这里面一个小问题一句话理解就要多少人/天。
软件工程学想干什么呢?是把做工程的办法推到做软件的产业里面去。最重要的是三个方面，一个是我们能不能以系统的办法?另外有一套严格的方法，有一套工具管理需求构建中的一整套方法支持，同时我们能在设计、开发的过程中能够测度我们在哪些方面取得了进步?离我们的整体目标到底还有多远，能够去测度这样的一个工程的系统性。有一整套的比较完善的严格的过程定义和工具支持，另外能量化，这样做工程的办法去实现软件。
我们从90年代末开始有没有看到这方面的变更?我觉得是有的。我想强调的是IBM90年代中后期提出来的RUP，现在叫统一过程大家应该听说过。它强调了三个点：第一是以架构为中心。就是我们所设计的软件必须基于一个已经认为可行，而且能够把软件的各个层面从底层硬件支持到上面的数据管理，到安全、到集成，能够把一个所有软件系统的方方面面能够串起来的架构。在这个基础上根据场景、业务、根据技术、根据数据的需求提出了各种通用的组件。在组件基础上进一步的发展到我们应该需要什么样的标准服务?这样的话我们的系统才能够真正的实现互相能够互通。
另外一个就是架构师的工作并不是简单的画一些框图，我们是要以一种可以重复工程化的方式来实现我们的架构和设计我们的架构，就是以模式驱动的架构和它的开发方式。我们必须有这样的开发方式以后架构才可以扩展、重用。而且我们可以把我们的设计建立在前人已经完成的工作的基础上。
第二个是要业务驱动。具体来说用统一过程来说就是用例驱动。就是我们要有了有效的把我们对业务的理解和业务需求的理解，具体到统一过程里面所要实现的支持网络控制和转化分离的那些功能，我们怎么样把它描述出来。以一种可以管理的方式，可以不断的更新，用它来指导我们的架构设计以及后面的其他模型的设计。
第三点是我们不可能一下子把所有的东西都做出来，要按照一定的优先级。以一种循环迭代的方式实现软件工程方面的工作。这里提到一点，最开始统一过程是强调先把最关键的技术点设计好，把圆心做出来，这样能够在最早的时间里证明我们的方案，我们的问题可解还是不可解，如果不可解或者不可行，我们能够尽早的控制风险。这三条原则是大家需要一直遵循的。
为了简化复杂度两个最重要的事情一个是抽象化。我们要不断的把很多共性的东西抽象出来。在模式驱动方面底下我们提到过原模型与平台无关的模型，或者是分析模型或者是设计模型。
另外一点就是怎么样把大的复杂的系统分解以后怎么能够一块一块的研究它，研究系统与系统之间相关的程度，以什么样的方式让它们进行互动。
当然我提到的所有这些作为一个架构师或者项目设计师我们不能简单的就以画一个图为我们的终极目标。我们需要有集成的工具支持。最近这两三年在支持模式驱动开发方面，尤其在工具进一步能力扩展和集成方面，我们已经取得了突破性的进展。主要的就是我建了这些模式以后，可以在模式上进行各种不铜模是的转换，可以进行扩展。另外我们可以把全周期的需求到一些功能、一些组件，服务，全周期的管理这些产品都把它很好的串起来。这样当我们的技术发生变化和需求发生变化的时候我们知道从什么方面入手。比如1.3出来一个新的特性，我们通过模型做的比较好的话，能够很快分析出来大概什么地方出现了什么影响，要花多大的代价。
另一个就是能不能尽可能的实现双向从模型到代码从代码再回到模型的软件工程的方式。
讲到了一些很基本的东西不知道大家听没听明白，现在讲讲华为设计LAB的过程中所涉及的原则，我们是一个开放的平台。我们反复强调几个着力点，一个是功能要能扩展，协议变了能花最小的代价把新的功能实现出来。第二个1.0里只有一个单一的控制器控制大的网络，这是不太可能的。而且这个东西一旦出故障怎么办?所以怎么样把控制器系统变成一个很容易添加，而变得更加可靠。第二点是怎么样最有效的使用基于模型驱动开发的方式来做架构组建、集成和扩展。
另外一个就是承用，Openflow从08年开始到现在基于Openflow1.0的版本，从控制器、交换机有很多开源的代码，而且还有好几个博士论文专门做这方面的工作。这些东西是我们需要充分学习、理解的。知道人家在某一个关键点上为什么用某种技术。所以我们要尽可能的重用，要利用人家做的应用缩短我们的研发周期。
刚才提到了SDN Openflow，第一个它很多地方需要更深层次的了解。另外我想强调，从Openflow1.0到2011年2月份公布的1.1，再到12月份公布的 1.2是有很大的差别的。Openflow1.0我们可以看作它是一种概念验证的协议，它提了很多思想。但是它主要的目的不是为了产业化，它是希望能在校园网络的环境下尽快的验证这种简单的思想可不可行。所以它在性能、高可靠性方面没有太多的考虑。为了节省昂贵的存储资源加速查找和找到更好的路由。再到 1.2是多控制器，就是需要多个控制器来管理一个大的子网。
另外对一些新的比如IPv6的支持，我们希望能够尽量使用现在已经开发、编写更加成熟的一些技术。由于这些东西的加入。Openflow1.1、1.2更加复杂了，所以最近为有1.2恩的交换机，这是经过一年多以后才看到有一些新的东西出来协议本身已经是不兼容了。
以软件工程的方式做软件，我们是怎么做的呢?首先是需求开始，比如说就SAAS主要的特性从协议支持、网络控制、虚拟网络支持、交换机管理和网络配置几个特性方面把一些重要的特性列出来。我们自己有一套模型。我们在特性效果根据1.2的协议，把它需要的主要功能需求也组合到了一起，在业务或者需求模型底下。
有了比较抽象的功能需求以后，我们说到了要用例驱动，这样就更加具体化，比如主机控制器、管理运用、网元包括交换机各自希望能做一些什么工作。当然在很多情况下是大家协同一起完成。
另外做软件工程一些项目失败或者变得不可控制的原因就是我们花了很多时间做前期的需求文档。大的项目我看到过13卷的需求文档，最后项目还是失败了。有了需求文档还不够，怎么样从需求到用例到组件到关键对象和逻辑服务，怎么样把这些通过一种矩阵追踪的方式让我们很容易的查到在什么地方实现了什么特性?这是软件工程里面现在需求管理里面融合软件架构和设计很重要的一点。
整体架构：第一步是SOX，里面有对交换机的管理，局部化的网络信息库。另外一个是中央集中控制逻辑，包括公共的共享功能。包括底层对主机，对链路的管理、拓扑的管理，包括现在一些比较基本的路由的算法。再往上走是API，上面还有一层管理应用。这个看作控制器的话，要利用北上的API支持上层的管理利用，我们把管理利用和控制器的组合叫做智能网络控制器操作系统，这个操作系统稍微扩展了一点点。因为我们华为自己有一个管道操作系统，是比较抽象比较大的概念。
领域一个就是东西向，多个控制器的集群能够把下面的网络有效的控制起来，通过基于服务的分布式管理方式，我们叫做软件服务定义的网络，中间有一层就是网络软件服务层，通过它来实现东西向的集成。我们这个网络就可以一步步的做大。
最后给大家汇报一下我们去年10月份参加ONF测试的结果。我们第一次实现了1.2的组网事件，目前实现1.2对很多厂家都是非常困难的。第二我们实现了自动网络拓扑的发现，交换机能力的学习以及可以和交换机谈判、学习。用外了完成对1.2关键点特性的验证。比如说多控制器、多流表，对IPv6部分支持。当我们把配置做好以后，我们网络的展示界面可以把拓扑以及我们所学习到的能力展示给用户。
另一个是多控制器。在我们这个网络里面当逐步增加网络流量的注入的时候可以看到控制器的矢量同开始的两个慢慢增加到六个，流量降下去的时候回到了两个，是根据独立需求和网络状态。
我们未来想做些什么事情：我们完成一个控制性集群，现在想把它做分布式的网络操作系统，基于完全丰富的网络信息库加上分布式的控制集群。第二个是进一步提高性能。其中某几个重要的过程是把原模型或者说各种支持Openflow或者未来协议的模型构建出来。另外就是基于全网拓扑状态和流量特征的资源分配。第四个是应用场景。我们希望能够从对数据中心的支持到更加复杂的校园网、企业网包括运营商网络更加具有意义的运营商层上来。
