 with information about them. This may require IICs to offer privacy control functions from the call center or on a Web portal. Customers will also insist that the Web portal, armed to the teeth with service configuration controls and account data, is entirely secure both in terms of access and transaction security. INTEGRATION With increases in device intelligence, dynamic service control, settlement requirements and data collection will come an increased need for integration. And though integration tools and technologies are improving, the task is unlikely to become much easier. We have already discussed the widening gap between network device intelligence and OSS support. New network technologies will also require new OSSs to support them, or they will be built with functions, perhaps normally housed in a policy server, already on-board. This will only increase the amount of analysis and semantic mapping required to integrate and configure applications and processes. As tough as integration is today, much progress has been made. The kinds of integration being done, and the tools being used, were not possible and did not even exist just a few years ago. With the influx of new integration elements, what could make integration easier? Some argue that an industry-standard The Ultimate Guide to Building and Delivering OSS/BSS common data or object model would go a long way toward easing the analysis and mapping burden, and could, perhaps, enable an intelligent integration bus that could handle most of the mapping and transformations automatically. It is generally agreed that standards could help, but in the past such initiatives have not had much success or enough industry collaboration to take hold. It is also suggested that integration would be easier if application vendors would embrace it more and work to make it easier. Many OSS vendors seem to offer their APIs reluctantly. They're focused on enriching their core applications and developing all of the functions they need. APIs thus become an afterthought in ma