From Jigsaw to Lego

Standardizing OSS Integration

Custom integration between two proprietary interfaces is done on an as-needed basis, often by systems integrators, a process that can take weeks and millions of dollars. Standards-based integration requires vendors to build APIs adhering to a pre-defined standard, reducing the customization burden before implementation even begins — a big benefit to carriers looking to speed service rollouts.

Click to Enlarge Cramer accelerates service delivery with the MTOSI integration standard.

“Technologies and services are evolving at a rapid pace, with increasing convergence between wireless and wireline, and the migration to IMS,” says Telcordia’s Ed Pinnes, executive director of service assurance business development. “Service providers are moving at a pace they’ve never moved before, and they rely on the OSS to enable it. Carriers have to be reactive to the market, and you don’t want to be in that boat where the OSS is the thing holding you back.”

Quick integration with existing systems can help to avoid massive capital outlays for systems integrators. “Fifty percent of the OSS spend is around integration,” says Paul McCluskey, senior worldwide product manager at Cramer Systems Ltd., a charter member of the TM Forum’s Multi-Technology Operations System Interface (MTOSI) initiative. “So we split the problem in half. We own ours, they own theirs, but the part in the middle remains constant.”

MTOSI will offer Release I of its standard this month. Using the XML language and a technology-neutral approach to underlying transport, the group tackles inventory management and alarm management in Release I. A central inventory architecture common to all systems is critical for data flow, as are common alarm management vocabulary and processes across the OSS components involved in resolving network issues, Pinnes says.

The 5-year-old OSS/J tackles integration using the open-standards Java 2 Platform, Enterprise Edition (J2EE) to define specifications for a group of APIs for various functions like service provisioning or trouble ticketing, along with design guidelines. “A top goal at OSS/J was to solve the problem of integration costs and maintaining integration as systems change to accommodate new services, through tested, mainstream technology (J2EE),” says Eric Dillon, CTO at Tigerstripe Inc., which provides an API design environment for modeling OSS/J APIs and integration profiles.

The world of standards is not perfect. For instance, systems integrators must find new revenue streams, or play a volume game. Also, some say the available standards don’t go far enough. “The [MTOSI data model] does not [yet] model the customer, their context or their unique requirements ... this is necessary as more operators start to approach service creation and delivery from the customer’s perspective,” says Joe Frost, vice president of marketing at JacobsRimell Ltd., maker of the APS Adaptive Provisioning System product suite. He also notes that carrier product catalogs need to collect and exchange data from multiple components, including billing and CRM, the service delivery infrastructure, and the order management and fulfillment platforms: “This is not yet fully defined within the [MTOSI’s defined carrier] architecture.”

Nonetheless, standardization may be the new face of systems integration. British Telecom plc’s 21st Century Network (21CN) aims to be a single, global IP MPLS infrastructure that carries voice, data and Internet services. To reduce complexity, BT has required vendors for the project to use OSS/J APIs and to support the MTOSI interface. “This gives them a way of customizing off-the-shelf components while still putting the system together in a plug-and-play way,” says Dillon.

Share this article: Email, Slashdot, Digg, Del.icio.us, Yahoo!MyWeb, Windows Live Favorites, Furl
Add this article feed to: RSS, My Yahoo, Newsgator, Bloglines