ny cases. As their base applications become more mature and stable, it is likely that vendors will have more resources to dedicate to developing their APIs, helping ease the integration process. We already see trends in this direction in the many partnerships formed among vendors, working together to pre-integrate their systems. IICs must take the time to identify which of these partnerships are likely to persist in the long run and can continue to support the IIC's needs. Taking this view to the extreme, some envision a future where the need for integration is entirely minimized. With acquisitions occurring in the OSS vendor community, some large vendors are gearing up to release integrated, end-to-end OSS suites, sometimes called "telco-in-a-box" offerings. Questions remain as to whether any company has the long-term commitment and breadth and depth of knowledge to pull off a high quality, customer-specific, end-to-end package. One advantage an equipment vendor would have is the ability to synchronize network device feature releases with OSS support for them. This would be a difficult task and it seems unlikely that fully integrated packages would be flexible enough to keep up with constantly changing market and user demands. On the flip side, the integrated platform could address or solve some tough challenges, such as product catalog integration and other application conflicts. It remains to be seen how successful such OSS packages will be, but done correctly, an integrated, end-to-end package could have a huge impact on the entire OSS market. Whether an integrated package succeeds or not, certain integration problems may remain virtually unsolvable. Product catalog integration is one such problem. Proposed solutions include standardizing an external product catalog and product definitions that the industry would agree to use, but such an approach only solves part of the problem. Even if product catalog data is mastered in one system, the product catalog must still be mapped and hooked into ordering and provi