With much of the world so focused on being environmentally friendly, including the green mantra of “reduce, reuse, recycle,” we shouldn’t be surprised that this mentality has crept into the world of communications with the popularity of the Service Oriented Architecture – a computer system’s architectural style for creating and using business processes packaged as services.
The basic idea of the SOA approach is that there is a huge amount of reusability and repeatability across all the products a service provider sells. They may sell a huge number of distinct products to customers. To the customer, the products may look enormously different, but from an internal carrier perspective, they might be 98% the same. The concept of being able to reproduce that 98% from product A to create product B is utterly brilliant to anyone in the communications space.
In the world of communications, it’s reasonably well accepted that internal capabilities and functionality are called “services,” and services are put together to create “products.” So, products are the things that consumers buy.
In the past, this distinction didn’t really exist in a non-service-oriented environment. So for every new product an operator wanted to sell, they basically had to design it from scratch and write all its constituent parts.
An example of what would apply to the idea of reusability is bundling. Where traditionally we might have thought of voice, Internet connectivity and television as three separate services, someone had the brilliant idea of “triple play” and suddenly it became a brand new product, when in reality it’s just three things stuck together.
Next-gen services
If you’re a provider trying to get back on its feet after a tough recession or stay several steps ahead of an increasingly tough market, you probably want to be able to offer new products without having to invest significant human resources and time getting things off the ground and to customers.
But to get to this ideal scenario, providers need to reboot their way of thinking about product development. Rather than the old method of coming up with an interesting idea and then passing it off to the development team, who then has to come up with something almost out of thin air, the SOA mentality requires a bit more planning.
This generally comes in the form of building capabilities within the organization, like toy building blocks that can be mixed and matched and plugged together in various ways to create new and interesting products. So you might take some parts to make product A, another set for product B, and maybe a combination of A and B to create product C.
To the end user, these are three different offerings, but the cost to the provider to create them is much lower than starting from square one and the time-to-market is much faster.
So that’s the grand vision for what SOA will enable, but the problem is you have to have that rock-solid base underpinning your architecture. There’s really no point if, as I’m trying to develop product A, I have one particular way about how data is structured, and for product B I have an entirely different data model with different structures for data.
Some of the underpinning elements of an SOA will have to be consistency of data and consistent, open interfaces for each individual service within a provider. For a service to be truly usable, there’s got to be a way to announce to the world – or at least to the developers within the organization – that you have these services and here’s what they do.
You’d want to define exactly what input the services need and what the expected output would be. Armed with that knowledge, developers can now take any one of these services off the shelf, so to speak, and plug them into hundreds or thousands of possible products.
Debating the issue
There are still a lot of issues, both big and small, to be worked out before we are all living in the sunny utopia of an SOA-enabled communications world. Case in point is the discussion over how granular services should be. Should they be incredibly granular or less so?
For example, if we think about services as building blocks, what if each service was the size of the tiniest block that can fit anywhere? There’s almost no scenario where it won’t fit, but the downside is that it’s very laborious to put together a million of those blocks to build something very big.
So at some stage, you don’t need them all to be small blocks; you might need larger pieces. Granularity of services really depends on how usable they are; make them small enough to use but no smaller.
In some cases, you will need the services to be very small because they are very specialized; in other cases they can be quite large.
At TM Forum, we’ve spent quite a bit of time talking about and working in the realm of SOA and the service oriented enterprise, which is what companies that employ an SOA strategy hope to create – an agile and flexible infrastructure that can easily adapt to new business models, new technologies and new partner agreements so critical to today’s communications market.
We’re helping providers by defining the framework for SOA so that they don’t have to do it themselves. The end-goal will be that anyone within a provider organization, no matter where they are located, can pull services out of a library as needed to create new and innovative products.
Once such a framework is widely accepted, it’s still up to providers to take the next step by populating their library with these service parts. This step is key to making this whole ecosystem work. Sure it’ll be a lot of legwork up front, but there’s a huge payoff down the road for anyone who embraces the concepts of SOA and follows through.