 | Issue: | Asia-Pacific III 2014 |
| Article no.: | 9 | |
| Topic: | NFV means culture change for service providers | |
| Author: | Alex Henthorn-Iwane | |
| Title: | VP | |
| Organisation: | QualiSystems | |
| PDF size: | 1500KB |
About author
Alex Henthorn-Iwane joined QualiSystems in February, 2013 and is responsible for worldwide marketing and public relations.
Prior to joining QualiSystems, Alex was Vice-President of Marketing at Packet Design, Inc., a provider of network management software, and has 20+ years of experience in senior management, marketing and technical roles at networking and security startups.
Alex holds a Bachelor of Arts degree from U.C. Berkeley.
Article abstract
Network functions virtualization may not only revolutionize customer-facing network architectures and service delivery, but also spur telecoms to transform their internal operations. How service providers develop, qualify and bring new services to market can become more agile via NFV, but only if legacy waterfall-based development methodologies give way to a new culture of agile development and DevOps practices. Ultimately, NFV success will be equally dependent on service providers executing internal cultural transformation as well as cloud-like infrastructure.
Full Article
A new kind of change is in the air
I have been involved in the service provider industry from the technology vendor side since the 1990’s, and have been amazed at the technology transformations that have taken place in that time. Successive generations of computing, networking and consumer technology have wrought powerful changes in both the ability to deliver and the expectations of telecom and mobile services. I spent most of the past 20+ years working on network infrastructure and OAM technology going into customer-facing service delivery networks. Most recently though, through my association with QualiSystems—an infrastructure automation and orchestration software company—I’ve gained a deeper appreciation of and perspective on the pre-production aspects of service provider operations—how services are developed, tested and readied for market. What’s interesting to me about NFV is that it signals a new kind of change. I’ve come to believe that NFV is not just about, or perhaps not even primarily about yet another shift to newer, virtualized technology. I submit to you that NFV is primarily about culture change—in customer expectations, in the nature of the competition, and most importantly in how service provider service development happens.
The consumerization of IT
A fundamental cultural shift that has happened in recent years is the consumerization of information technology. Not so many years ago, the average business or personal technology user was completely helpless and dependent on technology professionals to perform nearly every technology enablement task. Applications were relatively static—features didn’t advance very quickly. IT technology was like factory equipment. Then, based on advances in consumer technology and Internet speeds, technology has become much more user-friendly—so much so that even technology-phobes can easily adopt the latest technology. Smartphones and tablets have unleashed a new eco-system of applications that aim to satisfy rapidly evolving consumer tastes and a never-ending appetite for new features, capabilities, and convenience. Like the sea and land trade routes of a thousand years ago that created a huge appetite for and trade in new flavors to literally “spice up” life, IT consumerization has created an insatiable appetite for new flavors of technology. This has in turn affected expectations from business IT. Bring Your Own Device (BYOD) movements have started to change formerly strict IT department policies around the world. But more importantly, business users now question why technology shouldn’t be able to rapidly deliver new capabilities to support new business innovation and initiatives. They experience it in their personal lives—why shouldn’t IT and by extension, telecoms, be able to deliver the same? Yet, telecom services are still relatively slow-moving and static by comparison to consumerized expectations. That would be okay if it weren’t for a breed of competitors who were ready and able to embrace radical culture change.
OTT competition is a clash of cultures
Over the Top (OTT) competition is a well-known issue for telecoms. These OTT businesses have benefited from a lack of regulation, low-cost infrastructure, and abundant financing that isn’t tightly tethered to quarterly financial results. However, their major advantage is one that has certainly been enabled by these other factors—a completely different cultural approach to innovation. OTT businesses typically have operated in a rapid and continuous delivery model, which allows them to bring features to market much faster than traditional telecoms. OTT businesses are predicated on the notion that rapid innovation will allow them to execute creative destruction on traditional telecom business models. The onslaught of OTT competition challenges one of the fundamental cultural assumptions of service providers who have had a long-term, regulated franchise—that time is on their side.
Culture change from the inside out
There are many ways in which NFV and SDN infrastructure technology can bring greater agility to service delivery networks, and they are fairly obvious to technologists. Yet, if that customer-facing infrastructure isn’t paired with a culture change in how services are developed, tested and deployed to market, service providers can miss much of the business opportunity from the consumerization shift, and could be losers in the “culture struggle” against OTT businesses.
Carriers, most notably AT&T, have underscored the cultural aspects of NFV as they draw up plans for remaking their infrastructure and operations. The documentation for AT&T’s ambitious Domain 2.0 initiative cites both agile and DevOps as enablers of the project, insofar as they facilitate the sharing of knowledge and expertise, along with multi-faceted skill sets, required for evolving the network so that it becomes more conducive and responsive to multiple services. Process change will be as important as technology for ensuring that NFV, as well as software-defined networking and its attendant ecosystem of vendor partners, is successful.
An agile and DevOps culture
If NFV is predicated on methodology as much as technology, then service providers must rethink their internal operations, so that both every day and long-term procedures are designed with agility in mind. Reimagining service development broadly requires replacing old processes with new, not for the simple sake of doing so but to ensure that organizational culture coincides with today’s increasingly cloud-like infrastructure. Here are four steps toward realizing NFV’s potential for operational change:
Shift from waterfall development to agile cycles
Waterfall development cycles had their time and place, when the service catalog was limited to a handful of applications like voice, data and video based on closed systems based on highly proprietary hardware, and where the goal was simply utility-like reliability rather than rapid service feature advancement. Its sequential process, though, is ill-suited to the age of consumerized expectations.
As a more continuous and incremental methodology than waterfall, agile development is naturally suited to NFV in particular and to software-defined operations in general. After all, one of the core benefits of NFV is outstanding flexibility in how services are designed, implemented and modified, an advantage that runs the gamut from freedom in hardware choice to extensible network architectures that can easily accommodate new features.
Agile is the perfect complement to the frequent changes and shifting service requirements that are now facts of life. There’s more flexibility in conception, analysis, design, testing and deployment of services, plus time-boxing of tasks and engagement with stakeholders can lead to better deliverables.
Break down silos and make the way for collaboration
Service development and operations teams have traditionally been siloed and treated almost as distinct sub-organizations. This arrangement is no longer ideal, now that service providers have become more invested in the cloud and are seeking to use it for rapid, continuous delivery of service features.
Enter DevOps. As its name suggests, this movement entails the synthesis of many of the responsibilities once cordoned-off as a “something for dev” or “an ops job.” In regard to NFV specifically, a network DevOps practice facilitates an approach that has infrastructure teams working to automate the network and cloud datacenter infrastructure platforms needed to facilitate rapid development and testing of services. This in turn allows developers to bring their software into contact much earlier with production-like environments and ensure the highest possible quality.
But there’s also the cultural issue of preventing DevOps from itself becoming another silo. This isolation can take the form of engineers and project managers focusing exclusively on only the newest type of infrastructure, when many service providers actually use many. Abandoning older technologies and services to legacy practices isn’t the answer.
Move from manual to automated, continuous processes
Doing everything by hand in increasingly virtualized environments isn’t just costly and time-consuming – it doesn’t scale, either, which defeats the point of NFV. Automation across the entire organization is essential for realizing the benefits of NFV and not becoming overwhelmed by its potential for custom service chain creation. Too many devtest processes and the infrastructure they rely on are manually operated today to be effective. Embracing automation is part of the culture change needed for NFV success. One example is continuous integration, which ensures that all software development work builds quality rather than setting it back. Like DevOps and agile, continuous integration isn’t predicated on a specific technology, but is instead a broad methodology for streamlining software creation.
An Open Lab in Okinawa gives a DevOps example to follow:
Of course, change is hard, so it’s always helpful to have something concrete to consider as an example. One example of DevOps in practice is the Okinawa Open Lab (OOL), which was founded by NTT Communications, NEC, and IIGA Co to foster collaboration and advance the state of cloud, SDN and NFV technologies. Its 30-plus member organizations range from service providers, technology manufacturers, and academia, and is growing as more organizations from Asia-Pacific join. OOL, as its name implies, is interested particularly in figuring out how to enable service concepts like SDN and NFV service chains based on open source technologies—that are most prevalent in OTT provider infrastructure. OOL’s key service concept is cloud-based lab orchestration, where members could work collaboratively in dynamic DevOps sandboxes experiment with a combination of commercially available, early access and open source products and components. For example, a manufacturer, university and service provider might explore a NFV service chain concept together in one sandbox environment. These sandboxes needed to facilitate more traditional physical as well as completely virtual technology components, multi-tenant collaborative work, and rapid integration of new interfaces to support agile development and testing cycles. OOL members are actively working together on proving out interoperable SDN network scenarios and NFV service chains. This type of collaboration, and the infrastructure orchestration that enables it, is a prime example of the DevOps in practice. One prime sign of the kind of openness and flexibility that OOL exhibited is, even though they are focused on open source software, their IT operations team chose a commercial DevOps orchestration framework, because that would allow them to meet their member development and test users’ agility and collaborative goals more efficiently. What’s helpful about OOL’s example is that though they are not themselves a commercial service provider, they are supporting real service provider eco-system players to live out an agile, collaborative development and testing culture and practice.
Conclusion
NFV may come across as a technologically dense concept, but there’s also an important cultural aspect to it. The design, creation and delivery services that evolve the network requires agility across the whole organization, and the best way to achieve it is through methodologies that bring user groups together, break down silos and facilitate collaboration and automation. Service providers that embrace internal culture change will maximize NFV investments and own their future.
