爱华网大型企业中的整个IT架构是很庞大而复杂的，是由许多个相互独立却又紧密相关的应用系统组成。这些系统之间是通过应用接口连接在一起的。这种系统之间应用接口的稳定性，直接关系着整体架构的稳定性和各个应用系统的灵活性。如果应用接口比较稳定，就能使得组成整个架构的各应用系统相对独立，降低系统之间的耦合度，在增加了各个应用系统内部的灵活性的同时，也降低了单个应用系统的调整对相关系统的影响，从而提高了整个架构的稳定性。系统之间的标准接口的管理，历来都是IT应用管理的一个重点，通过制定标准接口，将企业整个IT架构有效的分割成多个部分，每个部分可以由具体的应用系统来实现，正是通过这种分解，才使得整个IT架构的实现和维护具有了可操作性。应用接口是两个应用系统之间交换数据的标准。其实，接口本身是一个独立的标准，是双方的约定，不是属于某个系统的，只能说某个系统支持某个标准接口，而且一个标准接口会被多个系统所使用。所以，当标准接口发生变化时，所有使用这一标准的系统都需要随之进行调整。这一点可以参考网络ISO/OSI的七层模型，正是因为制定了网络通讯的七层协议标准，才使得全球各个网络设备、网络软件的制造商有了发展的机会，网络协议本身不属于某个厂家的产品，而是公共的，有独立的组织来维护。我们的各应用系统之间应用标准接口，就相当于不同网络设备之间的网络通讯协议。因此，对于应用标准接口的管理，应该是独立于任何具体应用系统的，在制定标准接口中要考虑兼顾所有可能使用这一接口的不同应用系统的要求。将标准接口本身的管理和不同应用系统对标准接口的采用分别管理，这样既能保证标准接口的兼容性，又能跟踪标准接口的具体应用情况，以便在标准接口发生变化时，能够知道其影响的范围。为了保持接口的稳定性，特别是为了避免大量在运行的系统因为某个系统的小的调整而需要全面改动，就特别需要注意接口的兼容性。如果接口的兼容性做得好，那么接口的一个调整可能就只影响很小的范围，无关的系统都不会受到影响，否则，接口的一个调整，就可能会导致所有相关系统的修改，这不仅增加大量额外的工作量，还导致整个架构的不稳定。aihuau.com标准接口的修改是难免的，问题是如何修改接口，才能够保持最大的兼容性，尽可能降低对相关系统的影响。我们目前的主要做法是，当接口需要增加参数时，我们直接修改原有的标准接口，这就必然导致所有使用这一标准接口的相关系统，都必须同步修改，即使这些系统中绝大部分都不会用到新增的参数，这就意味着很多系统配合进行的修改、测试、投产的工作，都是很“无辜”的。我们在这方面有许多实际的例子可供参考。我们同时也看到许多开发语言本身所提供的类库、库函数的标准接口，是如何保证兼容性的。当需要对原有标准接口进行调整时，不是直接修改原有标准接口，而是新增一个接口函数，或者是新定义一个类方法，即使新的接口中有大量与原有接口重复的代码。这样，外部用户使用原有的标准接口，或者是使用新的标准接口，都是可以的。这时，只有需要使用新标准接口的相关系统，才会受到影响，而使用旧的标准接口的相关系统，则不需要进行修改。例如，假设原有接口定义为：
function A(parameter1,parameter2)当需要增加一个接口参数时，不是把原有接口定义改为function A(parameter1,parameter2,parameter3)而是新建一个接口为function B(parameter1,paremeter2,parameter3)在新建接口的处理程序function B中，可以照抄function A中的处理，或者直接调用function A，具体实现方式是可以根据情况灵活处理的。总之，建议在维护标准接口时，不要轻易改变已有的标准接口，而是通过新增标准接口来适应新的接口需要。一个系统多维护一个接口程序，总比所有相关系统都“无辜”的跟着一起进行修改、测试和投产，要好得多。随着时间的推移，等到旧的标准接口已经没有任何用途时，自然就可以淘汰了。一个系统对外所支持的标准接口，就相当于是对外的一种承诺，是相关系统进行接口设计或者是用户作客户化开发的依据。我们使用其他供应商的产品时，当然都希望这种接口是稳定的，不希望厂家的每次产品升级都导致我们要重复开发。那么在我们内部，在中国银行整体架构之内，我们自己的系统之间，也应充分考虑到这种接口的稳定性，考虑标准接口的维护方式，尽量保证接口修改的兼容性，降低我们自己的各个系统之间的耦合度，也降低对分行个性化业务应用的影响。记得当年与花旗银行国外IT部门的管理者有过交流，花旗银行的处理中心的系统集中度比国内银行要高，在各地的前置系统分散程度又比国内银行大，往往涉及不同国家的不同具体环境，在集中统一与分散灵活之间的控制，依靠的就是标准接口，而且是由总行直接管理的。应用标准接口，是IT架构管理的一个关键问题。
