Service Agility: It's Not a Single Magic Bullet

This article original appeared in the Sept. 2012 issue of Next Gen Mobility.

There is much talk about service agility in the industry. Some say that over-the-top companies will win the service wars due to their agility. This implies that our industry can’t be agile. Others take the approach that we must become agile to innovate, compete among ourselves, and compete with other industry forces.

Let’s start from the position that regardless of how the industry plays out, if we are more agile and more cost effective in our innovation, we will perform more competitively. Maybe we’ll gain market share. Maybe we’ll retain a larger proportion of end-to-end services. Or, maybe we’ll be agile partners of web-based companies with complementary skills.

But, one way or the other, I’d like to talk about how we achieve agility. Agility, in my definition, means that a service provider can develop a service (relatively) quickly and cheaply compared to traditional methods. It stands to reason that this is driven by shorter development cycles, more personalization, more media and service types, more competition. In other words, we plan to – and we must – develop more services and service permutations.

Most industries transitioned away from custom manufacturing to interchangeable parts ages ago. More recently they moved to flexible manufacturing, also known as mass customization. This approach defines common processes; standard components; clear assembly rules and dependencies; and then allows for variation within that construct.

Let’s think about that because, as simple as it sounds, it changes fundamental assumptions that have driven the industry’s methods, thinking, economics and gut feel for decades. If you develop relatively few services – and management support for relatively few services – it is like building aircraft carriers. You have to build them one at a time, each an individual engineering and manufacturing effort. There is no long production run of similar vehicles to divide fixed costs over, so you optimize your process for low volumes of semi-custom manufacturing --- or, in our case, semi-custom workflows. If we now truly believe that the number of services will rise, we must re-think our divide by assumptions and the resulting economic lore. Efficient development platforms do cost money, as do automated factories. But they also give tremendous competitive cost advantages to their owners – if you make more than a few widgets.

Too many approaches to agility appear to involve a single magic bullet. Buy this sequencing engine and your problems will vanish. Buy this overlap activation system and life will be good (and agile). Unfortunately, these are at best pieces of the solution, and at worst, band-aids that kick the can down the road, only to become worse problems in a few years.

Here are a few salient points we’ve discovered.

• Not only must you be able to create a service (e.g. on a SIP server or in an SDP environment), but you must be able to generate fulfillment, assurance and changing support just as efficiently.
• Rip and replace remains a costly, slow impractical and unpopular idea.
• Flexibility and complexity remain trade-offs, and CSPs must make strategic decisions as to the level of granularity – and thus flexibility – that is optimal.
• Theory is nice, but practical solutions reduce risk and implementation time immensely.

Before I close, let’s think about the many financial and competitive benefits a component-oriented, agile, service-OSS-BSS-SDP environment can deliver, because it extends beyond agility.

• Yes, it’s agile. Services can be turned up and scaled faster – giving time to market, competitive response and micro-segmentation benefits.
• But also, the cost-per-service is lower – allowing more innovation within the same budgets – the trick everyone is under pressure to deliver on.
• Next, if we do this correctly, the vast majority of code is now in re-useable objects – which mean far lower maintenance. I have heard anecdotal estimates that as much as 75 to 80 percent of budgets go to maintaining existing workflows as opposed to building new ones – so this can be significant.
• It frees deep network and OSS/BSS engineers from having to play as active a role in each and every new service idea “oh, that’s hard”, “Patricia’s away for three weeks and we need her” etc. Now, the services are defined, hopefully documented, and usable by those without familiarity of the legacy – a very good thing for cost and scale.

In conclusion, I encourage the industry to think systematically about its future, what that means for service innovation numbers and cycles, and consequently what investments in agile processes yield big returns. Today’s answers may differ greatly from those that have guided our thinking until today.