996. OSSs were originally designed as stand-alone systems, each supporting a different, previously manual, business process. They were built primarily on mainframe systems that were never intended to share data with other systems or to partition data securely. They certainly weren't designed to integrate them with other IICs' systems to support automated processes. This, however, is exactly what the Act requires. ILECs are required to open their systems to their competitors, sharing data on everything from customers to network resources. They have struggled to integrate their systems to support interconnection and data sharing with competitors, a fact that has kept most ILECs out of the long distance business. The incentive for ILECs to open and integrate their OSSs is that they are not permitted to offer lucrative long distance services until they meet stringent OSS requirements. Each state's public utility commission determines its own set of requirements and testing procedures. Some ILECs have spent hundreds of millions of dollars upgrading, replacing, integrating and testing their OSSs to meet these requirements, though few have been granted the right to offer long distance services. Though the Act's creators have often been criticized for taking a vague approach to OSS interconnection requirements, they can be applauded for their foresight in The Ultimate Guide to Building and Delivering OSS/BSS understanding how critical OSSs are to both competition and the growth of an open supply chain for Internet infrastructure and services. The older, stand-alone OSSs that have created SO many challenges for ILECs and their IIC competitors are generally referred to as legacy OSSs. These now make up a decreasing percentage of the OSS population, but still house a large percentage of customer data. New, advanced OSS software should not be confused with the older, purpose-built legacy OSSs. New software and computing technologies, as well as the introduction competition, have created a new, burgeoning market for state-of-