Dittberner's Examination of Nokia's OSS Middleware Proposal

Dittberner’s Examination of Nokia’s OSS Middleware Proposal Should Network Equipment Providers Support a Multi-Vendor OSS Frame? Dittberner Associates, Inc – 4641 Montgomery Avenue – Bethesda, MD, 20814 USA Phone: +1 (301) 652-8350 Fax: +1 (301) 657-8084 Toll Free: 1 (888) 652-8382 URL: www.dittberner.com TABLE OF CONTENTS Introduction The Evolution of Network Element Integration The Growing Importance of IT Middleware OSS Middleware: Adding Telecoms Value to IT Middleware The Advantages of OSS Middleware The Option of Building a Proprietary OSS Framework Why Nokia is Offering OSS Middleware Is a NEP the Best Choice to Offer OSS Middleware? Time to Give “Coopetition” a try? Exectutive Summary 3 4 4 4 5 5 6 6 6 7 2 Introduction “Beware of little expenses. A small leak will sink a great ship.” Benjamin Franklin, 18th Century Scientist and Inventor For years, the telecom industry has patiently tried to cut the huge OPEX required to integrate and adapt network elements and COTS software. But despite the efforts of organizations like TMF and OSS/J to jumpstart the integration effort, little progress has actually been made. And now we’re paying the price. The OPEX needed to deploy and maintain new and legacy network elements is now so high that it’s crowding out the CAPEX operators need to create profitable new services and globally expand. The heavy OPEX load is especially troubling for wireless operators who are busy protecting their revenue streams from a flock of new competitors: • VoIP providers providing low cost international voice for business travelers; • WiFi and WiMax providers eating into data revenue; • Triple play carriers offering a better multimedia and gaming experience; and, • iPod, Blackberry, satellite radio, MP3 and other devices providing low cost alternatives to premium wireless services. This battle for control of the communications/entertainment pocketbook should be no surprise. It’s the inevitable result of four industries crashing into each other: telecom, broadcasting/cable TV, information technology, and consumer electronics. Which is a round about way to say that the integration OPEX problem is no longer a “nice-to-solve” issue that can be delegated to a committee and forgotten. The integration tax is dragging the whole industry down and causing telecoms serious business pain. And history shows that when telecoms shiver, Network Equipment Providers (NEPs) always catch a cold. Where OSSs fail to deliver, NEPs will surely feel the pinch of lower investment in telecom infrastructure. Of course, the telecom industry faces some challenges of its own as it matures and transforms itself. For instance: • When fixed/mobile convergence and IMS fully arrive, mobile NEPs, fixed NEPs, and service delivery vendors will square off against each other. • New NEPs from China such as Huawei, ZTE and others are exploiting large economies of scale and low cost development resources to compete effectively against traditional NEPs. • Who knows what new technologies and service types operators will need in the future. WiMax? Quadruple Play? The-Next-Big-Thing? Whatever the future holds, telecoms will need efficient and flexible infrastructure partners like never before. So what’s it going to take for NEPs to solve service providers’ integration problems? Clearly we’ve had our fill of industry standards, integration components, and “around-the-campfire” discussions. Frankly, what we need right now is one thing: real solutions. Which brings us to the purpose of this paper. Nokia Corporation is proposing an OEM solution for the OSS industry, an OSS-specific middleware that sits on top of a standard J2EE middleware platform and features basic network management functionality, network adaptation framework and tools to customise and build OSS applications. To figure out how “real” a solution this is for NEPs, we’re going to carefully study Nokia’s proposal from many angles and answer a few key questions: • Exactly what is OSS middleware and how does it differ from IT middleware? • What are the advantages and disadvantages of such a platform? • Is a NEP better off building its own OSS framework or supporting a multi-vendor one? And. . . • How can one NEP seriously consider partnering with another in a seemingly mission critical area? Before we begin, a word about how Dittberner got involved in this paper. Knowing that Dittberner is an independent research firm that tracks the OSS/BSS market, Nokia hired Dittberner to write this paper -- not to endorse the solution -- but to objectively lay out the issues and expose the industry/ business forces that surround OSS middleware so that NEPs could make informed decisions on their own. Before writing this paper, we naturally interviewed people at Nokia to learn about the solution’s features and advantages. We also spoke to industry experts outside Nokia including experts at other NEPs. These potential customers of the solution gave us their candid and confidential opinions of OSS middleware. It’s Dittberner’s hope that this paper will lead to a more fruitful discussion of this serious -- and controversial -- proposal to address our industry’s urgent integration problem. 3 The Evolution of Network Element Integration In the 1980s and early 90s, the OSS and network equipment were inseparable. It’s only when operators purchased base station equipment from several NEPs and needed to connect those environments that the need emerged for independent vendor solutions on top of the EMS. Twenty years ago, the EMSs that NEPs developed were perhaps the most complex object-oriented systems developed by any industry. And remember, this was way before OSS software and IT middleware markets even arrived. Though EMSs were usually developed in silos, over the years NEPs have harmonized them as much as they could. One NEP Dittberner spoke to claimed it’s achieved 80% commonality across its elements, for example. But as the telecom industry has progressed, the siloed approach to EMS creation is now causing problems. In times past, when NEPs needed to insert new features or customize NEs for service providers, the amount of systems integration required was tolerable. Afterall, telecoms were eager to deploy new networks; integration costs were a secondary priority. Today’s a different story. Not only have wireline and wireless markets become so competitive that operators are pressuring NEPs to lower their OPEX, but the complexity of upgrading and adapting hundreds of elements across so many telecom technologies has become a daunting task. So NEPs are forced to rethink how they build their EMSs -- business as usual doesn’t work anymore. They must urgently move to industry-standard architectures that are more flexible and efficient to modify. And since the service management layer of the telecom business is moving to SOA, if the underlying network management layer is SOA-based, it may yield some important benefits, such as standards-based selfprovisioning. As more mobile handsets come equipped with computer operating systems, IT middleware has also become increasingly critical to the wireless business. In short, the world has changed. When a Washington DC-based software firm called Managed Objects sells large banks a platform that can manage 7,000 IT services, it’s time to concede that telecom is no longer the leader in distributed computing. OSS Middleware: Adding Telecoms Value to IT Middleware While NEPs love the great abstraction power and other advantages of IT middleware, IT middleware offers nothing to ease the task of network adaptation and testing. IBM’s WebSphere lets you connect with external applications like SAP, but it doesn’t provide the intelligence to connect to network elements or visualize their interaction. Likewise, Sun’s J2EE application server provides no tools to connect to a base station or get Key Performance Indicators (KPIs) from a network element. So what can be done? Well, Nokia proposes to enhance standard IT middleware by adding a network-elementaware layer on top. The result is an “OSS middleware” platform that knows where to go to get configuration, performance, and fault data and can synchronize the database and network elements so you always have an accurate representation of the element. If you’re looking for a more rigorous definition of OSS middleware, here it is: • OSS middleware is an integration framework for network elements and OSS software components. Using IT middleware as its foundation, OSS middleware adds telecomspecific building blocks in functions like network topology, inventory, configuration, fault, and performance management. • SDKs within the architecture make development more efficient, less error prone, and easier to modify later on. These SDKs can also be used to unite network elements of different network technologies to the same middleware framework. The Growing Importance of IT Middleware Though it seems like open systems have been around forever, their history in network management is a little more than ten years old. It wasn’t before the early 90s that telecoms first got comfortable with Oracle and Unix, for instance. A few years later, the J2EE application server took hold as the OSS management middleware of choice. One big advantage with J2EE is it allowed a more component based approach and provided built-in performance scalability. On that score, client server architectures such as C++ are comparatively weak. The Service Oriented Architecture (SOA) is clearly the next wave. For example, AT&T’s SOA is already well-established and connects to the network by encapsulating real-time CORBA functions. 4 The Advantages of OSS Middleware Below we’ve attempted to show the advantages a generic OSS middleware platform would bring to the market. Here they are starting with the most important benefits: Focus on Mission Critical Functions -- First of all, we can say with confidence that integrating an EMS to an OSS is not a revenue-producing activity for a NEP. It’s only a support function -- a necessary one to be sure, but a support function nonetheless, just like offering call center support for the NE. And invariably, the cost of integration support goes up every year. If a NEP is to grow its business, it needs to focus its development muscle on building value-added applications to its network elements. The last thing it wants is to get bogged down integrating to the OSS. But that’s exactly the situation we have today. So were an OSS middleware solution generally available, it makes good business sense for a NEP to buy it rather than continue to build this integration capability in-house. New Versions and Features -- The yearly maintenance fees a NEP charges operators are meant to cover NE version changes. But in recent years, network complexity has made the costs of version changes and software porting rather unpredictable. It’s easy for a NEP to get buried by excess engineering time and never recoup its costs. A related concern arises when a service provider requests the NEP to build some minor feature into the OSS. Here, even minor requirement can sometimes explode into a huge integration effort. It’s in situations like these where an OSS middleware solution really pays off. Since the platform is built on a layered architecture with standard interfaces, you can easily separate the applications from the middleware. And that can transform a previously ugly request for a feature change into a simpler and far more predictable development job. Third Party COTS Software Integration -- Even though NEPs are committed to getting their fair share of the OSS software revenue, let’s face it, the quality of third party OSS software has improved greatly over the years. And today, COTS software is integral to a NEP’s network management portfolio. A multi-vendor framework is a wonderful aid for supporting COTS vendors because it offers them an efficient development path for supporting your network elements. They can simply build to the interface and automatically support all your network elements -- and the elements of other NEPs using the framework. And should the framework gain critical mass in the industry, OSS ISVs will be highly motivated to support that platform, perhaps even spending their own development resources to adapt to it. Faster Time to Market -- Telecoms no longer have the stomach for adding new NE features that take 6, 12, or 18 months to fulfill. By that time, the market may have changed and the investment is no longer justified. Just as IT middleware has shortened application development times, OSS Middleware can do the same for OSS industry. Shared Service Management Layer -- A service management platform is more than its basic functions: fault, performance, and configuration management. It’s also a network view that shows dependencies and how physical resources are mapped to the services you are providing. Here, once again, an OSS framework can prove invaluable. Multi-Vendor EMS Interoperability -- Telecoms have long sought the ability to configure radio networks across different manufacturers. Here a multi-vendor framework could deliver a common desktop/environment that monitors and provisions across many elements. KPIs could be shared over the interface as well. Save IT Middleware Porting Costs -- Supporting IT middleware is not cheap and it’s certainly not as easy as it sounds. When, for instance, BEA’s WebLogic has a new version that’s drastically different from what’s come before, NEPs have to port software and thoroughly test the new version. So a common OSS framework is a way for several NEPs to share those costs. The Option of Building a Proprietary OSS Framework Some NEPs are choosing to merge their EMSs on an OSS framework of their own. One NEP Dittberner recently spoke to claims it will no longer build independent element managers systems and leave it to the operator to worry about integration. Instead it is rolling up its EMSs into a few Super Element Managers (or OSS frameworks). Eventually this NEP hopes to converge its wireless, wireline, optical onto one massive OSS framework. A proprietary framework like this would deliver almost all the benefits of a multi-vendor framework. It lets you do centralized testing such as loop qualifications -- even test broadband and narrowband networks on the same system. It also makes it far easier to adapt new network elements to the architecture. So it’s definitely the right vision. And if Nokia can build an OSS framework, other NEPs can do so as well. The big unknown, of course, is execution. Grand EMS integration visions have a history of failure. We know of one NEP who invested 900 engineering man years developing an OSS framework, then had to quietly “de-emphasize” it three years later. Without a doubt, the risks are high for any NEP who hopes to develop a proprietary OSS framework. The risks are even higher for 2nd Tier and 3rd Tier NEPs who have less money to risk in the first place. 5 Why Nokia is Offering OSS Middleware Necessity is the mother of invention. So perhaps it’s no surprise that a network equipment provider, Nokia, is now proposing a multi-vendor OSS framework for NEPs. Of course, other attempts have been made to build OSS middleware. Companies like Evidian, TCSI, BullSoft, Oracle, and HP have all toyed with the idea -- some seriously; others not so seriously. Being involved in the early history of OSS middleware, Nokia had no illusions about how tough it would be to “harden” a generic IT application server to cope with the capacity and real-time requirements of a network equipment provider. Nokia also had misgivings about the cost to migrate to IT middleware. But it figured that sticking to its older architecture would not give it the flexibility and efficiency it needed to support the fast evolving 3G market. While strengthening its own NE adaptation skill was the main reason for investing in OSS middleware, Nokia claims that from the beginning it also hoped it would someday share the cost of development and maintenance of basic NMS functionality with other NEPs. Dittberner also feel Nokia’s background brings certain advantages to the OSS middleware table. For instance: • It understands the needs of wireless operators end-to-end: base station to mobile handset. • Nokia has a history of driving successful middle ware, particularly the Series 60 enhancement to the Symbian operating system. • Its J2EE-based OSS middleware platform is now two years mature. in the service management, not network management space. • Telecom Service Providers: Can telecoms cooperate to drive a multi-vendor OSS framework? History suggests they can’t. For one thing, most telecoms around the world lack the required network expertise. The exception to the rule are the large Tier 1 telcos who have developed their own frameworks -- telecoms such as BT, AT&T, Verizon, Telecom Italia, and Korea Telecom. But these large carriers look to leverage those frameworks for their own competitive advantage. And who knows what it costs to maintain those frameworks -- their OPEX may be prohibitively high. • Independent OSS Vendors: ISVs who sell a broad family of network management software -companies such as Telcordia, Hewlett-Packard, and TTI Telecom -- also seem like potential developers of multi-vendor frameworks. How ever, targeting NEPs as customers is probably not a viable financial model for them. They earn much better margins selling to their current customers, telecom service providers. The chance to win software customization work is yet another reason for them to stay focused on selling direct to telecoms. Given what we’ve just discussed, it’s Dittberner’s conclusion that only a NEP can reasonably offer a multi-vendor OSS framework. NEPs are the only industry players with the depth of network experience to understand the subtle methods and tools needed to adequately support network element adaptation. NEPs also have the highest incentive to keep an OSS framework active since they ultimately pay the price when operators are saddled with a high integration tax. Is a NEP the Best Choice to Offer OSS Middleware? Now it’s time to discuss perhaps the most controversial question regarding OSS middleware, namely: why should a NEP trust Nokia -- or any other NEP -- to supply OSS middleware? To answer this question, it’s worth considering whether another kind of company could offer an OSS framework that appeals to NEPs. As Dittberner sees it, the three candidates are: telecom service providers, IT middleware vendor, and independent OSS software vendors. Here’s our thinking on the likelihood of a framework emerging from one of those players: • IT Middleware Vendors: Companies like BEA, Sun, Microsoft, and IBM serve many industries and cannot afford deep dives into telecom’s murky technical waters. Yes, each of these companies offers its own telecom frameworks, but those frameworks are geared to integrating third party software, not EMSs. Where IT middle ware vendors are staking their future claim is 6 Time to Give “Coopetition” a Try? “Nations do not have friends, only interests.” Benjamin Disraeli, 19th Century British Prime Minister “Coopetition”, the practice of sometimes cooperating with competitors, happens all the time in the IT industry. But what about telecom? Does it make sense for NEPs to work together in some areas? Dittberner believes the answer is “yes”. . . provided the relationship is tightly controlled and monitored. We recommend that those interested in Nokia’s OSS Middleware approach work with Nokia to develop a credible ROI model so the financial case is well understood and meets their technical requirements. And let’s not forget: our notion of who’s a “competitor” must be broadened since so many companies outside telecom are now competing for a piece of telecom’s revenue pie. In general, the more IP services displaces the circuit-based world, the more the line between telecom partner and competitor will tend to blur. And ten years from now, who knows? A Bill Gates or Steve Jobs might pose a more significant threat to a wireless NEP than Nokia. Also, as the world moves to IMS, partners like BEA and IBM will compete directly with NEPs for a piece of the service delivery business. Whether the industry gives OSS Middleware an up or down vote, Nokia’s proposal is at least an attempt to get the industry moving in the right direction. Yes, it’s a big leap for a NEP to even consider cooperating with a competitor. But hungry sharks are now swimming in telecom waters. And given the opportunity, they intend to eat as many slow and feeble fish as they can find. NEPs are the only industry players with the depth of network experience to build a credible OSS middleware. Nokia’s end-to-end understanding of wireless, it’s success driving the Series 60 middleware, and its 2 years of OSS middleware experience are other reasons to consider its solution. Aside from an in-depth technical and financial review of Nokia’s proposal, NEPs must weigh the urgent need to solve OPEX problems against the risk of buying an OEM solution from a competitor. Executive Summary The high cost of OSS integration OPEX can no longer be ignored. Either telecoms lower their operating costs or their revenue streams will be steadily siphoned off by competitors from inside and outside the telecom industry. Network Equipment Providers (NEPs) have their own reasons for making integration a priority: fixed and mobile networks are converging, new Asian NEPs are getting stronger, and networks are becoming enormously complex. To respond, NEPs realize they must move to more flexible industry-standard middleware architectures, but they hesitate to migrate because IT middleware offers nothing to ease the task of network adaptation and testing. Nokia has therefore proposed “OSS middleware”, an OEM solution that adds network topology, inventory, configuration, fault, and performance management building blocks to an IT middleware foundation. The benefits are many. First, outsourcing OSS integration, a support function, enables NEPs to focus on developing value-added network/service applications. Second, OSS middleware makes version changes and software ports more efficient. Third, it offers a bridge to off-the-shelf OSS software. The opinions and other statements expressed here are those of Dittberner Associates, Inc. alone, and are neither opinions of, nor necessarily reflect, the views and opinions of Nokia. The content in this document is created by Dittberner Associates, Inc. and is the sole responsibility of Dittberner Associates, Inc. and its accuracy and completeness are not endorsed or guaranteed by Nokia. Nokia has no control over any information in this document and Nokia makes no representation, and is not responsible for, the quality, content, nature or reliability of any information whatsoever contained in this document. 7