eir products fairly recently. This is typically a work in progress resulting in gaps in required API functionality, inadequate documentation, and a continually moving target for integration. The Ultimate Guide to Building and Delivering OSS/BSS 9.1 Application Package Flexibility The success of the packaged software industry is at least partially attributable to the way vendors have generalized process and data models for their targeted application areas. For a generalized process and data model to become useful, it must be configured. All successful application packages contain capabilities that enable the package to be configured to a business' specific needs. Many IICs spend large amounts of time and money having packages configured to suit their individual products and processes. Unfortunately incorporating flexibility in the application's end-points, though necessary, makes integration more difficult. Consistent behavior among the end-points would be ideal for ease of integration. Data would be in a predictable format, and validation rules would be constant and predictable. As stated before, package flexibility comes from the use of highly generalized process and data models, and in particular the use of metadata concepts. For example, consider the data model in the diagram below. This simple model could store an order for a POTS line, a DSL line or a locomotive. Looking at the raw data, how would one tell a data order from a voice order? Order Option Order Option Parameter Figure 21. "Metadata" The answer is using metadata, or "data about the data," that is stored elsewhere in the data model. How and where this data is stored is highly dependent on the individual application package. Navigating through the metadata to determine the meaning of the underlying data can be extremely complex and very specific to the instance of the application and how it was configured. Sometimes, the rules and visual cues embedded in the user interface to guide users are, unfortunately, not also found in the underlying data mod