nies and then migrated to support IICs. The application only allows for two or three levels of hierarchy in an order. Consequently, order data coming out of the SFA system was sometimes flattened into a long string - lots of data, none of it organized or identified correctly. As a result, the order manager could not determine an order's real content because data could not be mapped to the order manager's detailed, multi-level hierarchical structure. To fix this problem and integrate the systems, logic was embedded in the integration layer to map information correctly into the order manager. This required some sophisticated parsing code to break orders down to the lowest level of hierarchy. The parsing code was based on a tag value approach, mapping data semantically rather than syntactically, because it is always unclear how many levels of hierarchy a given order requires coming out of the SFA system. In this case, the integration layer did much more "thinking" to determine an order's content, organize it properly into however many levels of hierarchy it might need, translate it, and then map it into the order manager. The solution was effective, but it certainly added time, cost and complexity to the overall project. Furthermore, the BLEC needs staff to maintain the integration layer logic as product catalogs and other requirements change in each application. The trade-off in this case was achieving greater levels of operational efficiency that improved service delivery through order accuracy. The Ultimate Guide to Building and Delivering OSS/BSS 18.2 Order Management to Billing Company: Data and voice provider serving the business marketplace following a CLEC strategy in tier-two cities. Goal: To flow completed orders from a leading order management package to an advanced billing package upon order completion. The expected benefit was to automate the manual transfer of data between systems, a significant bottleneck and source of errors. Integration Technology: Java Message Service and Java Utilities Challenges: