After experiencing an 80-90% reduction in management systems integration costs using earlier releases of MTOSI 1.0, BT seeks to utilize the soon-to-be-released MTOSI 2.0 specifications in the design of its internal BT capabilities.
The reduction in resource integration costs is attributed to earlier iterations of MTOSI 1.0, especially in “Verification, Validation and Testing (VVT),” which has greatly improved BT’s ability to integrate additional new vendors with minimum effort.
With MTOSI 2.0, BT expects to significantly reduce the complexity of managing network resources and services so that development lifecycles are shorter and significantly less expensive.
“By introducing and deploying software and APIs into our network using COTS rather than proprietary products and in-house development, we saw huge savings in integration times,” says Steve Orobec, BT’s OSS standards manager. “Furthermore, managing thousands of APIs in a communications organization means managing the ‘how, what, why, where and when’ of APIs—what they do, how to implement them and, more importantly, why they are there.”
He explains that managing a “spider web of hundreds or thousands of APIs across the OSS” can be quite daunting for designers and architects. “It is something I hope to address with the new TM Forum standard called NGOSS Business Services, for which MTOSI is the first stage and foundation of that evolution.”
Making life simpler
The entire rationale behind using the Interface Program’s MTOSI specification has been to reduce opex and capex costs, and to simplify the problems of managing multiple vendors in a multi-technology network.
“By using MTOSI to define all of our data variables, BT was able to better manage legacy systems and integrate new network resources into existing network environments,” Orobec says, referring mainly to the “re-use” aspects of MTOSI, which has helped not only internal BT staff, but also network vendors. “They manage complex element management solutions, which translates into nothing but big overhead for them, so MTOSI is a benefit to them as well.”
Because of the past success with MTOSI API version 1 for Inventory Management, BT was initially able to develop a common interface among three of its key vendors—its OSS vendor HP and network equipment vendors Fujitsu and Huawei.
“We integrated those vendors using a consistent API design for our domain management system, which manages multiple element managers in our networks,” Orobec relates.
BT went on to use the same API design for other Layer-2 technologies such as SDH, as it was “easy to extrapolate network management capabilities using the ‘plug-and-play’ aspects of the MTOSI API design, due to its consistent multi-technology data model,” he adds.
In the past, creating a common API for DSL and SDH technologies might have taken several months, but by using MTOSI, it took significantly less time and de-risked the whole project management plan.
Better info organization
The same type of success is expected to be carried over with MTOSI 2.0 in 2008/09 as the company began developing the MTOSI-based MART API used for Multi-Action and Request Transactions. Using MART as a flavor of the MTOSI standard provided BT a consistent way of packaging information such that one OSS component could send data to another to more readily link components together.
The API was used to package information for transmission among OSS components. “Using the MART API for packaging information will enable us to more quickly establish communications among OSS components, which now execute ‘operation sets’ independent of each other,” Orobec says.
This has helped reduce issues around individual operation sets that in the past imposed dependencies on other operations sets. “Now that operations sets are organized and contained in different MART ‘containers,’ they can act independent of one another.”
BT continues to develop on MART and plans a full deployment in a few months. “We try to go as close to spec as possible, but we do have to make little changes here as we are deploying in a brown field environment,” he says.
Once MART and the impending MTOSI 2.0 spec is rationalized and finalized, Orobec expects to build on BT’s success by having MTOSI “self-package” into TM Forum’s new Solution Frameworks (NGOSS).
“It’s like building a house, as you need to build a solid foundation with the MTOSI capabilities, and then you can wrap them in NGOSS Business Services from the Architecture Harmonization team work. This will standardize device management of the network with a type of hardware abstraction layer,” he says.
Orobec expects the same types of significant savings experienced with MTOSI 1.0 from the impending MTOSI 2.0 release. “For that reason, we’ve made it a ‘business-as-usual’ practice for architects working in our network domain.” That means architects and engineers going forward will use MTOSI specifications as a standard model for future development.
Getting vendor buy-in
The next step, he says, is getting vendors to productize standards. “When we buy new equipment, we want it to come with MTOSI and other TM Forum Interface, process and framework standards incorporated into the products,” he says, adding that he wants to use standards “wherever possible” as demands for managing broadband networks puts more pressure on service providers to better manage resource and service management areas such as inventory, assurance and activation.
He predicts some SIs may resist, “but it’s a no-brainer for service providers that no longer want to be shocked by integration costs.”
For that reason, he hopes to leverage the success of MTOSI in the resource domain by exploiting its success and promoting NGOSS Business Services as the next evolutionary standards product for the remaining domains such as Service Management and B2B Orders.
Susana Schwartz is editor of TM Forum Publications and Research