long with their creation. Because conflicting assumptions meet at the integration layer, the integration layer is then called upon to do many things. For example, it must create default values required by the target application but not generated by the source, as well as create message flows that might allow the target to generate values that are passed back to the source. The integration layer can also maintain cross-reference or look-up tables to map identifiers and codes. Again, conflict resolution typically results in significant logic and processing being incorporated into the integration layer to manage the semantics of every interaction. The Ultimate Guide to Building and Delivering OSS/BSS A related integration problem often occurs when packaged applications are implemented independently of each other. In such a situation, it is not uncommon to find large discrepancies between how fundamental entities have been modeled and configured. For example, the way a customer hierarchy is modeled in one system may be completely different in the other. In these situations, a major data alignment exercise is often required within the individual application packages before any programmatic integration can be considered. APPLICATION PROGRAMMING INTERFACES The final major difficulty in application integration concerns the Application Programming Interfaces (APIs) themselves. Most contemporary application packages were not designed for integration with other applications. This capability has often been retrofitted, and is typically an ongoing evolutionary process. This evolution is generally slow because API development is not a trivial task for application vendors. As a result, many inadequacies often lurk beneath the surface of the proffered APIs. For example, validation rules that appear in the user interface, or business rules embedded in the core packages, do not always make it to the API, thus allowing the entry of erroneous data. The provided documentation does not always explain the subtleties of the data relatio