CoralTree's roundup of 2014

So in good order and good end of year tradition, we felt it worthwhile to recap some of this year's blog articles and see if they correlate with what the key goings on are in the industry.

Customer Experience

We started off the year with a blog on Customer Experience, at the time it proved to be very popular and it remains one of our most read blog articles. This is probably because in this environment of reduced ARPUs, general financial instability, and diverging customer habits getting the upper hand on the competition has been driven, in no small way, by improving Customer Experience.

Maybe that includes getting rid of customer bills?... it might sound controversial, but one operator is already doing it. This is something that we covered in a blog post ingeniously titled "Customers don't really want bills".

Even with things starting to pan out for many operators, as the European economy strengthens, superior customer experience has definitely become something that consumers expect of operators and driving the efficiency agenda can play a part in that as well. Talking of efficiency... 

Operational Efficiencies 

Other ways that operators have sought to improve their bottom line and increase their profits is through operational efficiencies. The OSS side of things has had a lot of focus in recent months with all the talk - and hype? - surrounding 'NFV' (Network Functions Virtualisation).

But BSS efficiencies have been talked about in a variety of flavours and incantations. We covered such topics in "Do we understand the meaning of convergence?" and "Expectations that have sped ahead: efficiency is crucial". 

These topics appear to have dropped off the radar a little bit in the wake of all the NFV talk. However, the OSS/BSS bottleneck that currently prevents some operators maximising efficiencies in NFV, could see BSS efficiencies and even new BSS implementations (make sure you know why they sometimes fail!) being put in place to enable the full benefits of Network Functions Virtualisation integration.

Hopefully this means the topic will get a whole new lease of life!

Viewing Habits

Consumer changes in viewing habits have also come to the fore this year. From the extremes of customers ditching pay-tv services altogether, which have been becoming more of an issue for CSPs, as companies like Netflix become more prevalent. We've started covering this in part one of the "cord cutters/cord nevers" series. To customers general viewing habits changing a topic we looked at in "What’s next? Interactive multi-tasking!"

In a strange twist, North Korea has show just how much viewing habits have changed and how much ready consumers are for change.

With major US cinema chains pulling Sony's new film 'The Interview', but high public demand to view it, Sony called on On-Demand providers YouTube, Google Play, Microsoft Video and more recently iTunes to host the video for a nationwide release which earned them $18m. As much as they had aimed to earn via a national cinema release, so is this the end of the cinema?

We'll be looking at this ever more important topic in the new year.

What can we expect from the coming year? 

Well, all these topics have been high profile topics throughout 2014, but the industry is still far from implementing these features fully. So we should expect to see more of them over the coming year(s)! 

But there are a great many other things that might well present themselves in 2015, such as an increased focus on BSS systems that are able to provide flexible, personalised offerings to customers. Or an increase in telecoms companies adopting more non-traditional services, which are predicted to grow from 8-10% of income, to a potential 15-20% of revenue. This could help sure up bottom lines that are constantly under threat.

What ever the new year brings, Happy New Year, and all the best in 2015! 

Cord Cutters and Nevers Part One: Could I be a Cord Cutter?

In a recent study carried out by Comscore: 18-34 year old's are 77% more likely to become cord nevers and 67% more likely to become cord cutter households. These should be 'sit up and take notice' figures for CSP's as this age group has already caused much of the change we've seen in viewing habits of late (multi device, second screen etc)

So in an effort get an idea on what it would be like moving from 'more likely' to actually 'cutting the cord' on linear TV or indeed why someone might decide to never pick up a subscription TV service in the first place, I decided to delve into the world of cord cutters and cord nevers by giving up TV for a week.

I guess I fall a little shy of an average 'linear' TV user, I do watch it and with some frequency, but I also have access to two leading OTT providers (you can probably guess the names) and access to the VOD offering from that well known UK satellite provider. All of which I use to supplement my linear viewing habits - by all measures I guess I'm well equipped to start this experiment.

Diving In

Not really knowing how this would pan out, I started off the week in a flummox and almost falling at the first hurdle - we usually put BBC Breakfast on in the morning... well that's not going to happen. Radio 4 it is then! 

In the evening I continued to watch a series on one of the OTTs that I'm currently in the middle of, whilst playing some computer games. My wife was out anyway, and Masterchef wasn't until Tuesday. Nice and easy - so ends Monday.

We had to wait until Wednesday to watch Tuesday's Masterchef because of my experiment, which a little frustrating, but ultimately no real hassle. Instead we proceeded to watch some other shows on 4oD (Channel 4's On Demand/Catch Up service) and caught up on some shows we'd neglected on one of the OTT services. We put it on the main TV through the xbox. At this point I'm thinking that the experiment is going pretty well really!

Mid week rolls around and we're a day behind in some of our viewing. So over the next couple of days we watched the things we missed via BBC's iplayer (which has seen enormous growth recently) or the other TV catch up services ITV player and 4oD again. We also binge watched some episodes from a couple of TV series such as American Horror Story and House M.D. via one of our OTT platforms - this time we watched it on the tablet.

Friday and the weekend - well, these followed the same routine as the rest of the week with the radio on in the morning, but we did start to find ourselves struggling a bit, particularly on the Sunday morning as we didn't really have anything we could just put on as 'background' television. 

It made me realise how often we'd put the TV on even if just for background noise - a bit of Friends or something we've watched a hundred times already - whilst we got on with other things. 

Sunday evening rolled around and the experiment was over, and I was starting to consider the pros and cons of the experiment.

Conclusion.

It was an odd week, and it was actually harder than I had anticipated. 

There's a wealth of TV and films available on catch up TV and OTT services, more than enough to ensure you didn't need to put the TV on. But, and there is a but, there are a couple of things that get in the way.

It didn't quite sit well with what, I guess, are my current viewing habits - It turns out that I'm very much a second screen kind of viewer and when I'm watching something on an OTT service I feel as if I've gone out of my way to watch it and so should give it my full attention. This might be little tricky if it was my only source of TV long term!

Secondly, it's all very fragmented. I do not believe cord cutting is possible with just one VOD or OTT service, which means that one must subscribe to several. You must find a device or SmartTV that gives easy access to them all (Chromecast, for example, doesn't natively support Amazon Prime Instant) which adds a certain amount of hassle. Having multiple services also decreases the cost advantage gained through scrapping a PayTV subscription.

In the UK, however, we have access to ‘Freeview’. It has a one off cost, access to all the terrestrial channels and a large number of additional channels as well as the option to use a DVR. 

If this was topped up with some monthly subscriptions to the Over The Top services like Blinkbox, Netflix and Amazon, It would make a compelling argument to ‘cut the cord’ on PayTV services altogether… though i'd maybe off on the scissors until all the seasons of Game of Thrones have been aired. 



In part two I'll be looking why people are cutting the cord, what the numbers are like at the moment, and what CSPs might need to do to change this trend.

Customer's don't really want bills...

Well, of course, customer's don't want bills - who really wants a bill? But this blog isn't about customers who would rather get free services, this is about whether customers want to receive bills or if they're just happy to pay each month.

Over on Billing Views as part of an ETIS community gathering in Budapest, one service provider said that their customers didn't really want bills. 

Taken aback by the comment he was then asked to clarify the statement. 
He responded with;

"Absolutely, of course consumers do not want bills anymore. It is too much trouble. What they want is to look at their bank statement. If the amount is about what they expected, they are happy. If it is different they want to pick up the phone."

This got me thinking... when was the last time that I actually, properly, looked at a bill? I receive both electronic bills and 'traditional' paper bills. But I don't ever read them. The paper bills go in a pile awaiting the inevitable, but often delayed, shredding and the electronic bills (an email telling me to check the bill portal on their website) usually gets opened and ignored. 

Why don't I check my bills? because I check my bank account, I have an account for my bills. I know what I put in each month and I know how much my respeqctive payments cost me each month. Just as the operators said, if there's something wrong - the amount isn't right - i'll check it out and if necessary pick up the phone.. but 9 times out of 10 i'm not interested. 

So how did they come to this realisation? 

A fluke apparently. Customers (for the most part) were notified that their bills were ready to view via text message and email. Typically bill related calls to the company's call centres are quite high, one day the text messages didn't fire to let customers know that their bill was ready and the number of calls about bills dropped dramatically "the percentage of calls about billing was virtually zero" - someone from Customer Relations brought the drop in calls to someones attention and they found out that the texts didn't trigger. 

"Customers only think about the bill when they are told about the bill. Very very few call us to say they haven't received a bill" 

With how easy it is to manage and track your banking and billing via online and mobile banking nowadays it's easy to see how this is the case. So should companies stop sending bills? What about the 'retail space' that comes with bills? the chance for cross-sells and up-sells? Irrelevant apparently. 

"A bill will always have a negative impact" It's a reminder that there's more money leaving your account. Bills are never nice, apart from that one I had from my energy supplier that said I'd saved up quite a bit of credit and they were dropping my monthly charge as a result - but how often does that happen?

As we move further and further into the digital, it's very rare now to find a customer who doesn't have an email account - typically an older customer - so who needs to spend time crafting the space on a bill to sell something to a customer who is disinclined to view the bill in the first place. Send them an email instead it has less negativity attached to it, and there's more space for the offers and incentives. 

Are there problems with this? 

Sure, some people don't check their bank accounts routinely or regularly, so there's a risk that a problem will build up over time resulting in a very negative experience for the customer, but I would hazard a guess that if they don't check their bank account regularly then they're not likely to check their bills either and the situation is likely to occur either way. 

What about customers' whose bill vary month on month? (fixed line and mobile, i'm looking at you) well, there could be a variable limit before a bill is triggered. Maybe 5% or £5 off the baseline monthly charge amount will trigger a bill to inform them of a deviation from their normal monthly charge.

By and large however, I'm seeing benefits - Bill related calls to the call centre virtually zero? A reduction in calls means less money spent on call centres. A reduction in the number of physical bill and text message prompts sent out means less money spent (and it's greener) and informing a customer of when they're bill is abnormal instead of reminding them of their charges each month looks proactive and procustomer - which is never a bad thing. 

An interesting proposal, with some merit by the looks of it. Will it become the norm? hopefully. 


Written by Craig Maxwell-Brown Business Development Associate at CoralTree Systems

Driving the Efficiency Agenda

Efficiency is often considered an internal issue for a CSP. Streamlining processes and minimising the steps to achieve a specific goal; creating efficiency to not only deliver a good service to customers, but also decrease operational costs.

Yet, the part that is often overlooked is evaluating efficiency from the customers’ point of view. Can they communicate and complete the tasks they want to do using the channel of their choice? Can they use multiple channels for the same task? Are the processes within each channel quick and easy-to-use?

In order for the customer to have that efficient experience, the channels have to address the needs demanded by the customer. All this requires an ‘outside in’ understanding. Without this insight, resources can be ploughed into systems that are ultimately not delivering the support demanded by the customers.

The channels desired may well differ from type of customer, or in fact each individual customer. Segmenting the audience to address the core demands is essential. A CSP cannot meet the requirements of all customers. Segmenting allows CSPs to address core concerns of high-value customers, or more loyal ones.

But whatever segment the CSP targets, understanding the customer is crucial. Analysing customer data is important, but further research needs to be done to establish what channels and processes customers want to do, which is not currently possible. This insight can then be applied when mapping out the support systems.

To deliver the ultimate efficient organisation, efficiency must be achieved on the inside, as well as for those using CSPs services. Start with the customers, then work backwards to understand how the vision can be achieved through efficient internal solutions. For the ultimate customer experience – ensure efficiency throughout.

This blog was written by Natasha Geldard, Marketing Consultant for CoralTree.

The Complexity of Simplicity

Why is simplicity so complex?

Less is certainly more when it comes to the IT BSS environment. Eight systems doing the job which one can do. Or even, a ten-step process to solve a customer enquiry, when it could be done in five – lowering the call handling time. Simplifying processes is an obvious win for CSPs. So, why aren't more CSPs simplifying their BSS?

I attended a TM Forum webinar last week in which, Rob Rich, TM Forum’s MD of Insight Research, talked about customer centricity. We heard all about the fundamental steps required for a CSP to drive profitability from having a more customer-centric business.

The majority of the content is not new, as Rob mentioned he has focused on it for many years. And it is fairly obvious. But TM Forum has packaged all the research together into an easy-to-understand format, which aligns to their best practice model for CSPs.

Putting Simplicity First

Rob put simplicity at the heart of achieving a customer-centric business. Simplicity that allows CSPs to increase the customer experience and agility of the business, at the same time decreases operational costs.

So why is simplicity not more readily adopted? Many say it is because they are stuck with back-end legacy systems, which are difficult to cut the ties to. Some claim it is too expensive to move to a new system, so instead invest in further systems to help alleviate some of the short-term pains.

This can work and can help mask many issues. But in order to achieve true ‘customer centricity’ simplicity is crucial. Cutting back systems to a solution that can manage customer interactions, across all channels, has to be the obvious choice. Only then, can CSPs be truly efficient, with simplified processes that benefit both the business and the customer.

This simplicity should not be so complex to achieve, especially as the benefits to the business vastly outweigh the investment. Simplicity – what a great vision.

This blog was written by Natasha Geldard, Marketing Consultant for CoralTree.

Seamless Service Activation

Enhance customer experience with robust provisioning

A customer makes the decision to sign up for a new service; the customer then expects the service to be available. They pay; they receive the service. It seems a clear concept, yet it does not always happen so simply. Operators are still having problems with service activation and this impacts customer experience.

In this digital era, with any service a customer purchases, it is considered to be unacceptable to pay for a service then experience a delay in receiving it. Or it not being authorised when you know the payment card being used is valid and in credit. Or perhaps even the system goes down…’we are not able to process your request at this time’. These are all frustrations for the customer.

This does two things. Annoys the customer, blemishing the company image. And deters them from buying the service, which means missed revenue. Repeat occurrences could have long-term impact on the subscriber base, as some move to competitors for a better service.

Activation of services in a timely and efficient manner for customers is essential for any operator providing subscription-based TV. 

So what are the essentials when looking for a provisioning solution?

1. High performance - you need to be assured that whether your solution is being utilised for hundreds, thousands, or millions of subscribers, it does the job regardless of numbers.
2. Content protection - a small percentage of the consumer market prefer to avoid paying for TV content. Securing authorised access to content is critical to protect revenues and ensure continuity of service to paying customers.
3. Interoperability - working alongside existing systems to ensure seamless, fast and reliable delivery of services.

Delivery of services does not only build revenues for operators, it can ensure a customer stays loyal. The experience is just as critical at this stage as when customers first signed up. Ensuring activation of services is streamlined with a robust and powerful service activation solution will help operators build customer satisfaction.

This blog was written by Natasha Geldard, Marketing, CoralTree

Real Time Convergent Charging and Policy Management are a necessity!

Real Time Convergent Charging (RTCC) and Policy Management go hand in hand, with 95% of the CSP’s that responded to TM Forum’s recent Insights Research paper ‘RTCC and Policy Management’ [Link] saying that they cannot remain competitive without implementing it in some form.

The benefits of introducing RTCC can be great for the CSPs for a whole number of reasons such as improving customer experience, minimising or negate bill shock and providing a means to monetise the OTT market.

As customer experience quickly becomes the critical focus for operators, RTCC and policy management will allow operators to be much more creative and agile in how they interact with the customer and a lot quicker in the introducing new services and products

Bad Profits

Currently the two largest uses for RTCC and Policy Management are bill shock management and threshold management, which are great, but - even now - there are companies who use them in rather blunt ways. Capping or throttling customers who reach data caps, or charging ‘premium’ prices for going over limits. This creates ‘bad profits’ and does nothing to enhance the customer experience.

However some CSP’s have the idea, using these tools to build a bond with the customer and ultimately using it to drive revenue growth. When customers get close to limits they are warned they're close, and offered ‘extensions’ to their data or broadband usage for a set price, repeat ‘offenders’ can be marked for upsell opportunities offering them a better package at a higher price, but one that would be cheaper than the charges they would otherwise incur.

In the short term, this doesn't drive as much revenue as the charges, but, as should be obvious, a loyal customer is more profitable than a customer who leaves because they feel they've been ripped off.

As the marriage between RTCC and Policy Management becomes more complete (94% will implemented a RTCC & PM strategy within two years and 64% within the next year) operators and CSP’s will be able to produce more innovative offerings to their customers.

This will enable them to increase revenue through USPs – introducing flexible services that the customer can control such as Holiday mode, sharing data, moving portions of broadband download limits onto mobiles – especially as networks move towards 4G LTE. And on the topic of LTE, Policy management and RTCC will be necessary for the introduction of VoLTE to ensure bandwidth is properly managed.

Over The Top

Lots has been made of the need to monetize the OTT trend, and with a RTCC and Policy Management, CSP’s and operators can. 

A good number of them are offering free data when using apps like WhatsApp and Facebook, others are offering Netflix or sports services when they sign up (Virgin Media, Vodafone) whilst others are competing directly with their own offering (Sky’s NowTV, UPC’s Horizon) Policy management and RTCC is vital in letting operators omit these services from customer’s data use. 

The nature of the relationship with OTT players is only really beginning to be explored, but it can be as simple as free data, it could be as one Indian MSO does, offering bundles of access to YouTube, Facebook and other OTT services instead of, or in line with data allowances.

Or CSP’s could really be involved with developing the relationship, making it a truly two way relationship that benefits both, working with Google’s Project Loon or Facebook's Internet.org to bring internet (and telecoms) to remote places with the knowledge, infrastructure and software they already have in abundance. OTT’s get more customers, CSP’s get more customers.

However the future unfolds, one thing appears to be a common theme throughout it all, the need for Real Time Convergent Charging and Policy Management, preferably together, to drive new revenue growth. 


This article was written by Craig Maxwell-Brown. Business Development Associate for CoralTree Systems Limited. Views are not necessarily the companies views.

Do we understand the meaning of convergence?

The communications industry is rife with vendors promoting their convergent systems. Technology aligned, all working smoothly, hand in hand. But is this so commonly used word, convergent, merely a buzzword?

Converge is defined as to ‘come together from different directions so as eventually meet.’ So do the systems that are implement into communications providers operations really converge with the existing systems in place? Or is the truth that they simply run in parallel?

I don’t think we should trivialise the importance of convergence here. Creating the competitive differentiation that a converged system allows is in every operator’s best interest. Convergence enables a joined up approach to customer service, more efficient call handling, and minimising billing and order errors.

But very few operators’ systems are really convergent. Many are ‘window dressed’. New systems on top of old, trying to disguise the disorganisation underneath. But the systems only work in parallel and are not often integrated. This can be beneficial in the short-term and helps speed up processes, but as more technologies and services are added complications will become apparent.

The long-term objective should be to converge all BSS systems. This will limit the support needs and issues faced by IT teams, as well as providing a wealth of knowledge to marketing and customer support teams, so service can be enhanced.

Systems must ‘come together from different directions so as eventually meet’ in order to stay competitive in this dynamic communications industry.

To read more about operator convergent strategy, read CoralTree’s latest Insight report: “Convergent strategy or conflicting goals?” by visiting our website: www.coraltreesystems.com/insights-papers

This blog was written by Natasha Geldard, Head of Marketing, CoralTree

CTO vs. CFO – focusing on company prosperity

The goals of the communications providers’ CTO and CFO are driving further apart. Both are committed to do what’s best for long-term business prosperity, but their strategies are far from converged.

In this face-paced sector communications operators have to innovate, to offer the latest services and packages to customers, in order to stay competitive. The CTO is under constant pressure from the business to ensure that the systems are in place for dynamic packages to be marketed, fulfilled, and billed. With many BSS systems dated, this requires investment to upgrade to next generation support systems.

In contrast, the CFO focuses on ensuring profitability and demands in fiscal year returns for any large investments made. The CFO role is to demonstrate to owners, shareholders, or the market, that the business is doing well. In simple terms, growing and making more money than it is spending.

Yet some CFOs are acknowledging this strategic problem. Industry news title, Global Telecoms Business published in an article that interviewed top global telecommunications CFOs in February 2014. Tom Fitzpatrick, CFO of satellite operator Iridium, was quoted saying: “The short-term earnings bias of Wall Street in the evaluation of results proves difficult in that many compelling long-term initiatives are not undertaken in the face of this short-term bias.”.

Many BSS out-of-date

The issue is that many BSS systems in place are so dated that they are unable to cope with next generation technologies and services. Quick fixes will not last for long and will not be able to keep up with the fast pace of change. In the long run, this will cost the operator more money than upfront investment in a long-term solution.

To stay competitive, it is crucial for the CTO and CFO strategies to be converged. Alignment must be made to support the business with advanced IT, creating long-term efficiency and cost-savings.

To read more about operator convergent strategy, read CoralTree’s latest Insight report: “Convergent strategy or conflicting goals?” by visiting our website: www.coraltreesystems.com/insights-papers

This blog was written by Natasha Geldard, Head of Marketing, CoralTree

Big (Little) Data and Customer Experience - CEM Blog Part Four

It has been a little while since the last blog article on Customer Experience Management, so if you're in need of a quick refresher then please follow these links

Part One: Putting yourself in the customers shoes
Part Two: Customer experience and the call centre
Part Three: Going Social

All clued up? excellent.

Big data is proving to be a very important and ever growing part of a business. The ability to collect more and more data from an increasing range of sources provides some very potent opportunities for business. However for businesses to really achieve that ‘write home about’ customer experience, you need ‘little data’.

Big data, better operations

Now, by its very nature, big data gives an extremely broad look at all our customers and what they're up to. It allows us to spot trends in customer behaviour and habits as a whole – both good and bad. CSPs can use this to great advantage, identifying behaviour patterns, trends and pain points for customers and work out solutions that build customer advocacy.

Let us use an example to make it more realistic. An increasing number of people are using OTT services like Netflix and Lovefilm. Not only are more of your customers using them, but they're using them more frequently and these data heavy services can impact the network.

Rob Rich, MD of Insights at TM Forum, says the operators are “using network and customer data to learn the habits of their most valuable customers.” They are using network data to determine where the most strain is being put on the network, so “by comparing the two, they can drive support for future network investments that will improve network performance and boost customer satisfaction.” [source]

This is a perfect example of what big data can do. By looking at the whole picture, companies can find patterns, trends and pain points across a wide section of customers, which can only ever be a good thing.

So what about small data? 

Small data is where unique gains can be made that boosts customer experience and satisfaction. Little data lets us spot opportunities and enables personalised customer interactions. It can be achieved with the data that a CSR should be able to readily access via their CRM.

The key is how easy it is for a customer service agent to access that information and how closely it is linked a 360 degree view of the customer. The customer service agent must be able to view recent customer interactions and all information needs to be clearly accessible, quickly.

Imagine a scenario where you don't have to re-tell the story you've already told to several people because the customer service agent already knows that last week your phone line conked out. The engineer was meant to turn up this morning, but canceled, and that no one has yet replied to your question via social media. It would be blissful, wouldn't it?

Or maybe recognising that a customer is routinely hitting data or download limits. Or that they've been late payers recently, but offering solutions, such as putting a hold on premium services, would be beneficial for the customer for a few months.

All these 'above and beyond' measures build customer loyalty. We know that loyal customers are worth up to 10x their first purchase. [source]

Companies have some, if not all this information available to them already. They have done for a long time. The key to Little Data is making sure you take advantage of it!

Big data and little data are both important strategic considerations for service providers. Ensure the network is performing to its optimum ability and build customer loyalty. Data, big or small, is the gold to each operators armour.

CoralTree’s off to TM Forum Live! – What do we expect?

In just two weeks time we'll be setting up in Nice for TM Forum Live! 2014. Anticipation builds, as it is the first time for CoralTree at TM Forum Live! In fact, the first time we have had a ‘proper’ stand at an exhibition. So what do we expect…?

Renowned for its sharing of best practice, networking and attracting some of the leading operators, I have high hopes for some interesting conversations. The conference agenda itself looks exciting. I am particularly looking forward to the revenue management focus on Thursday.

‘Better, faster, cheaper: How BSS/OSS consolidation can accelerate time to market, reduce costs and maximize revenue’ caught my eye. In my opinion BSS has to move with the times. With new technologies and services needing support from the BSS function, it is essential that next generation systems be adopted.

Convergence of billing and customer care systems into simple workflows is key to ensuring satisfied, loyal customers and agents. Come and see us on booth 52, to see how daVinci enables exactly that.

You can even have a beer with us whilst we discuss. And remember not to miss the ‘happy hour’ on Tuesday, 17:30-19:00 in the expo!

Better go and pack…see you in Nice!

Natasha Geldard

Marketing Consultant for CoralTree Systems ltd.

Creating Java Web Services Using JAX-WS, JAXB and Spring

I've recently been working a lot with Java web services, most of these were greenfield projects where we were able to choose the architecture. I decided to use JAX-WS to create the web services but was unsure initially of the best way to go about this. In general there are two approaches to writing web services (contract first or code first).

Contract first
Contract first requires a wsdl to be written first and then JAX-WS can be used to generate matching code. This approach has its place if you already have a wsdl but they're not the easiest of things to work with and maintenance quickly becomes messy.

Code first
Code first is much easier as you simply write the code using a handful of basic annotations and let JAX-WS generate the wsdl for you at run time. The downside to this approach is that you have to write the code before you have a wsdl or schema available. This may not be an issue but if you need to write a specification first then it's handy to have some kind of schema to define how the inputs and outputs are going to look.

Also, in some cases you may be able to express more in a schema than you can with just Java code. For instance you might want to set a restriction in the schema (like a string max length), or perhaps you want a particular nested structure of elements. You could do this yourself with JAXB annotations but it's easier to write a schema and generate the required classes.

Combined approach using JAXB
I asked this as a question on stackoverflow and one of the answers provided inspiration for a kind of best of both worlds approach. This has now been implemented for several different projects and overall it's been a pleasure to work with. The basic idea is that development follow something like the following process.

• Write a basic schema that defines the request and response types (this can be included in specifications and is easier to maintain than a full wsdl)
• Use JAXB/XJC to generate the request and response types
• Write a JAX-WS endpoint using the generated types as inputs and outputs
• Let JAX-WS generate the full wsdl at runtime

Spring integration
In addition to this I wanted to use spring for managing services, dependency injection and loading properties files. This requires setting up JAX-WS slightly differently so that spring can load the endpoints and inject dependencies. If you don't do this then you'll end up with a JAX-WS version of the endpoint with none of its dependencies injected while spring will have its own instance complete with injected dependencies but not handling any requests.

Maven build and dependencies
I'm using maven to manage the build and dependencies. You don't have to use maven but it really does make life much easier. These are the required dependencies you'll need in your pom.xml file.

<dependency>
         <groupId>com.sun.xml.ws</groupId>
         <artifactId>jaxws-rt</artifactId>
         <version>2.2.7</version>
       </dependency>

       <!-- Spring DI -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>${spring-version}</version>
            <exclusions>
            <exclusion>
             <groupId>commons-logging</groupId>
             <artifactId>commons-logging</artifactId>
            </exclusion>
         </exclusions>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>${spring-version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-beans</artifactId>
            <version>${spring-version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-web</artifactId>
            <version>${spring-version}</version>
        </dependency>

        <!-- JAX-WS/Spring integration -->
       <dependency>
   <groupId>org.jvnet.jax-ws-commons.spring</groupId>
   <artifactId>jaxws-spring</artifactId>
   <version>1.8</version>
            <exclusions>
            <exclusion>
             <groupId>org.springframework</groupId>
             <artifactId>spring</artifactId>
            </exclusion>
         </exclusions>
  </dependency>

In the build section of the pom you'll also need to configure the JAXB plugin to auto-generate code from your schemas. The way it's setup here it will look for any schema in the directory /src/main/resources/xsd and then generate code and put it in a source folder called /target/generated-sources/src/main/java. If you're using eclipse you'll want to right click this folder and take the option Build path > Use as source folder. If you don't do this you'll still be able to run a build using maven but you'll probably see compile errors in eclipse.

<build>
        <plugins>
            <!-- Generate JAXB Java source files from an XSD file -->
            <plugin>
             <groupId>org.codehaus.mojo</groupId>
                <artifactId>jaxb2-maven-plugin</artifactId>
                <version>1.5</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>xjc</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <!-- Don't set package name here as we want different packages for each schema.
                         Instead we set in each schema separately. -->
                    <!-- <packageName></packageName>  -->
                    <outputDirectory>${basedir}/target/generated-sources/src/main/java</outputDirectory>
                    <schemaDirectory>${basedir}/src/main/resources/xsd</schemaDirectory>
                </configuration>
            </plugin>
        </plugins>
  </build>

Web app config files
Next we need to add some configuration files to setup our web application. First is the web.xml deployment descriptor. Here we define the standard spring listener to load our spring configuration and we also setup a servlet to listen for our web service requests. Rather than use the JAX-WS servlet we've used a spring wrapper which will later allow us to use dependency injection in our endpoint classes.

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

  <display-name>TestServices</display-name>

  <!-- Load spring configuration -->
  <context-param>
 <param-name>contextConfigLocation</param-name>
 <param-value>/WEB-INF/application-context.xml</param-value>
  </context-param>
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>

  <!-- Servlet to handle all jax-ws requests -->
  <servlet>
    <servlet-name>jaxws-servlet</servlet-name>
    <servlet-class>com.sun.xml.ws.transport.http.servlet.WSSpringServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>jaxws-servlet</servlet-name>
    <url-pattern>/service/*</url-pattern>
  </servlet-mapping>

  <!-- There didn't ought to be any sessions created but it's good practice to define a
  timeout as it varies for different containers. -->
  <session-config>
    <session-timeout>40</session-timeout>
  </session-config>

</web-app>

The spring config is minimal in this basic example. It's just turning on classpath scanning for the package in our test project and enabling auto-wiring of scanned dependencies. We also need to setup which urls map to which endpoint classes but this has been moved to a separate file which we import at the bottom.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
       http://www.springframework.org/schema/context
       http://www.springframework.org/schema/context/spring-context-3.2.xsd
       " >

    <context:component-scan base-package="com.testservices"/>
    <context:annotation-config/>

  <!-- Define the jaxws endpoint -->
  <import resource="jaxws-context.xml"/>

</beans>

Usually with JAX-WS you need a config file called sun-jaxws.xml where you define which urls map to which endpoints. In this case we're using a spring JAX-WS servlet so instead we add our mappings here. This simple mapping is saying all web service requests to /service/test1 will go to the spring bean with an ID of test1Services. We shall see this bean shortly.

<?xml version="1.0" encoding="UTF-8"?>
<beans  xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:ws="http://jax-ws.dev.java.net/spring/core"
  xmlns:wss="http://jax-ws.dev.java.net/spring/servlet"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
   http://jax-ws.dev.java.net/spring/core
   http://jax-ws.dev.java.net/spring/core.xsd
   http://jax-ws.dev.java.net/spring/servlet
   http://jax-ws.dev.java.net/spring/servlet.xsd">  

  <!-- Define our jaxws endpoint (replaces sun-jaxws.xml) -->
    <wss:binding url="/service/test1">
        <wss:service>
            <ws:service bean="#test1Services" />
        </wss:service>
    </wss:binding>   

</beans>

Schema to define request/response types
In this simple example we could get away with one simple schema but in a real world example you'll probably end up with many. The way I've been organizing this is to have a base shared schema which defines common types. For example you might want all requests to include a username, password and environment and maybe the response should always have a boolean element to indicate success. Then you can write a schema for each endpoint defining the request and response types for all operations on that wsdl.

Here is the example base schema shared.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema  xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
   jaxb:version="2.0"
   targetNamespace="http://shared.testservices.com/"
   xmlns:tns="http://shared.testservices.com/"
   elementFormDefault="qualified">

  <!-- Settings for the JAXB code generation -->
  <xs:annotation>
    <xs:appinfo>
      <!-- Set the package name for the generated classes -->
      <jaxb:schemaBindings>
        <jaxb:package name="com.testservices.generated.shared" />
      </jaxb:schemaBindings>
    </xs:appinfo>
  </xs:annotation>   

  <!-- Begin Types/Classes to be generated -->
  <xs:group name="baseRequest">
    <xs:sequence>
      <xs:element name="user" type="xs:string"/>
      <xs:element name="apikey" type="xs:string"/>
    </xs:sequence>
  </xs:group>    

  <xs:group name="baseResponse">
    <xs:sequence>
      <xs:element name="success" type="xs:boolean"/>
    </xs:sequence>
  </xs:group>   

</xs:schema>

This schema then imports the shared types and defines a simple request and response type for our example web service. Note that we can define which package the generated code belongs to by using the jaxb namespace extensions. There are a number of other customizations you can do like mapping xml types to Java types.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema  xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:sh="http://shared.testservices.com/"
   xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
   jaxb:version="2.0"
   targetNamespace="http://test1.testservices.com/"
   xmlns:tns="http://test1.testservices.com/"
   elementFormDefault="qualified">

  <!-- Settings for the JAXB code generation -->
  <xs:annotation>
    <xs:appinfo>
      <!-- Set the package name for the generated classes -->
      <jaxb:schemaBindings>
        <jaxb:package name="com.testservices.generated.test1" />
      </jaxb:schemaBindings>
    </xs:appinfo>
  </xs:annotation>

  <xs:import namespace="http://shared.testservices.com/" schemaLocation="shared.xsd" />

  <xs:complexType name="test1Request">
    <xs:sequence>
      <xs:group ref="sh:baseRequest"/>
      <xs:element name="id" type="xs:int" />
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="test1Response">
    <xs:sequence>
      <xs:group ref="sh:baseResponse"/>
      <xs:element name="field1" type="xs:string" />
      <xs:element name="field2" type="xs:string" />
    </xs:sequence>
  </xs:complexType>

</xs:schema>

Finally add the endpoint interface/class
Having saved those schemas there should now be a generated class called Test1Request and another called Test1Response. We're now ready to start piecing things together. The final stage is to define the JAX-WS handler and add a web method that uses these classes as inputs and outputs.

@WebService
public interface Test1
{
 Test1Response test1(Test1Request request);
}

So we have a very simple interface which we annotate with the JAX-WS @WebService annotation. There is one method which uses our generated classes. When this code is deployed JAX-WS will do the legwork and generate the WSDL with this one method on it. We just need to implement this interface now.

@Component("test1Services")
@WebService(endpointInterface = "com.testservices.endpoint.Test1")
public class Test1Impl implements Test1
{

 ObjectFactory fact = new ObjectFactory();

 @Override
 public Test1Response test1(Test1Request request)
 {
  System.out.println("User: " + request.getUser());
  System.out.println("ID: " + request.getId());

  Test1Response response = fact.createTest1Response();

  response.setSuccess(true);
  response.setField1("Value 1");
  response.setField2("Value 2");

  return response;
 }

}

The implementation uses the JAXB object factory, which was generated for us, to create a response object. We then hardcode some values just to see if it works. In practice you'll be able to inject a spring service here and go off and do whatever business logic is required. The class has been annotated as a spring component called test1Services. It's important that this matches the bean name given in the spring config file for JAX-WS. The @WebService annotation names the interface that we've implemented.

You should now be able to fire up your test server and see this running. If you go to http://localhost:PORT/ProjectName/service/test1 you should see a page confirming the web service has been deployed with a link to the wsdl (just append ?wsdl).

Ben Thurley,
Senior Software Engineer at CoralTree Systems Ltd 

You can view Ben's wordpress blog, with more articles, here

Ben has worked for CoralTree for over 5 years. In that time, his expertise and knowledge in new coding techniques and methods have helped us develop even better solutions for our customers.

The views expressed in this article are not necessarily the views of CoralTree Systems Ltd.

Spitting in the Soup: Part Two - On the hook.

Spitting in the Soup - part 2 - On the Hook

As a small boy, growing up in rural Nottinghamshire, a highlight of my week would be a trip to the local newsagents to buy another six-penny pack of American Civil War cards. Each wax-papered pack would contain about five random cards from a series of maybe 200 in total, plus a nominal one inch square of bright pink bubble gum. 

Amongst our gang of local village boys, by far the most treasured card was one depicting a poor Confederate soldier helplessly impaled through his torso on a huge angled wooden stake. He had a ghastly agonised expression on his face and blood seeping from an enormous chest wound. By any standards it was a horrific sight, unless of course you were aged seven. Nowadays, I often think back to that picture when I encounter those CIOs of telecom operators who are struggling to come to terms with their own uncomfortable predicaments. Not so much "on the hook" as "on the spike".

To understand the CIO's predicament, I should explain that a telecom BSS solution plays a similar role within a large telecoms organisation to that of the vital organs in the human body - say the heart, liver, and lungs. So, unfortunately when dealing with some vendors, once that BSS solution has been installed and implemented (of itself a major challenge), the operator is effectively "on the hook" to that BSS vendor, and as helpless as that poor Confederate soldier. Up until final implementation and cut-over from any previous system, there may still be a small window of opportunity to escape from the vendor's clutches (see Spitting in the Soup part 1). 

Painful but true

Once the new system has "gone live", and the project celebration party bunting has been taken down, the operator gradually becomes aware of some pretty unsettling home truths:

• The vendor's A team, whose experience and skills were so valuable during the implementation project will gradually drift away to other higher priority (for the vendor) projects/clients, being replaced by inexperienced youngsters, whose industry training the operator seems to be unwittingly paying for.

• The exciting vendor strategic road-map that was so key in convincing the sceptics on the system selection committee to originally choose that particular path from the various available options, drops from sight as though it had never actually existed. Any attempt to engage the vendor in a discussion about it is met with either a blank expression or hysterical laughter.

• As the operator introduces new products and lines of business with corresponding new system requirements, the cost of such incremental system changes goes through the roof, and software is delivered late and with numerous bugs. Support levels deteriorate continuously. There is no other source for the software changes or software support, so the operator has literally nowhere to go. 

• The vendor acquires another BSS business, and announces that the newly acquired company's application software will form the centre-piece of its exciting (for them maybe) new roadmap. The solution that the operator has just spent millions implementing is effectively relegated to legacy status with massively reduced R&D funding.

Sadly for our industry, these kind of post-implementation disappointments have become the rule rather than the exception in recent years. In most "normal" economic market models, vendors delivering poor levels of software, service, and value for money would quickly be driven out and replaced by vendors with better offerings. 

We don't have much choice with who we pick... 

Unfortunately, in the BSS market two powerful forces combine to create a stifling inertia that prevents the development of an efficient market. Firstly there are the enormous barriers to entry that face potential entrants into the BSS industry. BSS applications have increased massively in their complexity as operators have launched new lines of business, with so-called triple-play and quad-play operators now offering complex bundles of telecoms services. 

The expertise required to design and develop such applications is such that there are probably no more than a handful of businesses worldwide attempting to create new applications for the industry, despite analysts estimating the annual market size as being in excess of 15 billion dollars. (Gartner 2011 IRCM Magic Quadrant)    

Secondly, the costs of switching BSS solution are so high, and the negative business impact of switching so great - requiring the business to freeze itself for a year or more, that operators generally have little option, but to grin and bear it.  

So what is our disillusioned and disappointed CIO to do in such circumstances? The real secret of survival for CIOs is to ensure that such scenarios simply do not arise in the first place, with the key issue being that of vendor selection. In fact I would go so far as to say the secret of success here is in not just finding the right vendor, but in finding a vendor with the right people. Ultimately it is the vendor's service delivery team that you will be hugely reliant on, not their corporate image, stock exchange listing, plush executive offices, or extravagant entertaining.

So what is a CIO to do?

So to finish, here are a couple of free tips for anyone thinking of entering the minefield that is buying a new BSS:

Make sure that you meet the vendor staff who will be responsible for implementing your system. Get hold of their CVs and get references from their previous client projects. Make a careful note of their names (the good ones), and ensure that the project staffing list forms part of your implementation contract. Make this a show-stopping contractual point, and do NOT back down.

Negotiate tough, but fair service levels that are clear and measurable. Insist on contract terms that will require the vendor to meet the estimated cost of you having to replace their system in the event that service levels are repeatedly breached, or as an alternative, that will trigger the automatic release of the application source code from escrow. You don't really want to have to exercise either of these options, but they should both help to keep the vendor in line. 

In my next article, I will explore why "small IS beautiful" as far as BSS vendors is concerned, and why there are so few of us around.

Cable Congress Q&A with one of the Sales and Marketing team.

Last week (11 - 13 March) CoralTree started its exhibition season with Cable Congress in Amsterdam. It is actually, the first time we have ever had an exhibition stand and it proved a very informative look into the industry. 

Our 'Pod'.

As it was our first time at Cable Congress and first shot at exhibiting, we thought we'd get a rundown of events, as well as some thoughts on the topics raised in the conference from a member of our Sales and Marketing Team, Craig Maxwell-Brown.

Q: Craig, seamless customer service was high on the agenda at the show, what do you think this means for operators and customers alike? 


Craig: It means that the customer has a consistent service with one operator, no matter what device or service they are using. For example, they watch TV on their mobile using their wifi, but carry on watching that show, with the same provider, when they leave the house, using their LTE service. 

For the customer all their needs are provided in a simple way and billed for by one provider. For the operator it provides greater customer stickiness and increased take-up of new services. This all helps to increase ARPU at a time when the industry is seeing it strained. In order to successfully monetise, operators must ensure they have the systems that can provide tailored and unique offerings.

Q: One of the key issues raised at the show was the need for cable operators to expand into mobile. What were highlighted as the main challenges for this transition?


Craig: Well, this was a very vocalised point at this year's conference. It very much links back to the previous point about providing customers with that seamless service. It is a must for operators, so they can remain competitive as the lines between telecommunications and cable becomes more blurred, but moving into this space certainly has its challenges.

A key IT consideration is the ability of their BSS systems to handle the complexities that mobile offerings bring. But investment is crucial. Providing quad-play bundles and packages will be vital for operators to differentiate themselves and to retain customers as telecomms operators look to compete in the video market.

Q: Are there any other topics/talks that really stood out for you at the show?

Craig: There was an excellent talk by Jordan Casey, a 14 year-old Irish lad who is running two companies. He has a great attitude towards work, and his studies, and it was inspiring to hear the unique challenges that he faces as a young entrepreneur.

Q: How would you summarise Cable Congress for both you and CoralTree?

Craig: It was useful insight for CoralTree. The issues raised in the conference confirmed that our development spend into our BSS portfolio daVinci is correct and will also help to shape where we focus our efforts on in the future. We were pleased to confirm that we have a competitive solution that can help operators combat issues and take advantage of market opportunities.

Q: Finally, a more light hearted question - what are your thoughts on Amsterdam as a city and a venue?

Craig: bikes, bikes, and more bikes! Amsterdam is a fantastic city, with great beer and that brilliant continental atmosphere - which really finds its way into the show. I'd have no qualms about going back there again!



CoralTree's next show will be TM Forum Live in June 2014. You can read more about CoralTree and CoralTree's daVinci BSS here: http://www.coraltreesystems.com/products