Compatibility of Changes 

In most cases it is intended that changes or enhancements to a product are compatible with previous versions meaning that, if a customer uses a certain product that he can switch to the new product without problem. Incompatible changes are those that render the program code of the previous version in some way invalid. The following section provides an overview of compatible changes to objects:

Interface Objects

For two systems to communicate there must be an outbound and an inbound interface. You must ensure that any change to either interface does not mean that the counterpart must be changed as well in order that the systems can communicate with each other. The following options for compatible changes exist:

●      Adding technical and semantically optional attributes or elements to the referenced complex data types. Semantically optional means that a field is not expected by a receiver although it is flagged as optional.

●      Communication partners can of course agree on changes. If a new version of a product depends on changes in another product, then the customer must be informed correspondingly (for example, new product A, version 2.0 requires at least product B, version 3.5).

Generally you check for an object that has had incompatible changes made to it whether it is referenced by other objects and whether you should inform the “owner” of the object about the changes (no where-used list function exists at present).