Tuesday, 3 January 2012
Mobile Market and Network Planning - Part 4
1.4
Shift in Focus from Quality of Networks to Quality of
Service
Monday, 19 December 2011
Mobile Market and Network Planning - Part 3
1.1 Lagging Revenue Growth
1.2 Rising Operator Margin Pressure
Monday, 12 December 2011
Mobile Market and Network Planning - Part 2
1
Key
Market Trends
1.1
Exponential Growth in Wireless Data
Figure 1: Mobile Content and Applications revenue by service category and forecast data traffic,
2009–2015, (source: Analysys Mason, 2010)
Monday, 5 December 2011
Mobile Market and Network Planning - Part 1
This is part 1 of a multi-part tutorial on the state of the mobile industry and of mobile network planning.
Sunday, 10 July 2011
Decreasing BSS/OSS “integration tax": Part 3 - SOA and data models complete the current picture

This BLOG post is the third, and last, in a series of short articles on the changes in BSS and OSS architectures arising from the changing underlying data communications, middleware, and data modeling software technology. In the last posting, I described how IP and middleware dropped the cost and complexity of integration by an order of magnitude.
These innovations of the past three decades have brought the cost of interfacing modern software systems from large fractions of a million dollars to a few tens of thousands of dollars and enabled multi-system architectures and automatic flow-through of information, orders, and network control unheard of when I first began my career.
Monday, 16 August 2010
Decreasing BSS/OSS “integration tax": Part 2 – IP and middleware make things better

During the 1980s and 1990s, while the technical world was focusing on the X.25 standard for system interoperability (and good old Bell Labs, never an organization to go with ‘good enough’ created its own improved version, BX.25), the TCP/IP protocol was coming into its own. It was not endorsed by any standards organization. It wasn’t owned by anyone. The group that agreed to it documented the agreements by something they call RFCs – ‘Request for Comments.’ But it was simple. It was open. And it could be easily implemented on a wide variety of hardware. It became the de facto worldwide standard, essentially solving the problem of system interoperability at the lower levels of the protocol stack.
At the same time, ‘middleware’ raised its head in the BSS/OSS industry. Vendors such as TIBCO had their software ‘busses’ that could be implemented to bind together software systems. All you had to do was to build to their API (and have an agreed-to mapping of the internal data models of the various systems to an intermediate language, with interfaces to the API implemented in every system) for systems to ‘talk’ together. The TMF created its NGOSS architecture around this ‘bus’ concept, and many modern systems were built around one of the busses available in the market. This made integration MUCH easier and cheaper, as seen below. For a mere half to one million dollars you could have a systems integrator interface two systems together.
The effect was that systems that were formerly ‘islands’ of automated systems started to be hooked into each other, creating ‘flow-through provisioning’ and an end-to-end ‘trouble process,’ among other work flows. So, if you wanted a good multi-OSS or BSS system, you would go to a systems integrator (SI), choose a bus, choose the new OSSs you wanted to implement, decide which legacy systems needed to be hooked into, and sit back and wait a couple of years for the SI to do its magic.
Mark H Mortensen
Monday, 19 July 2010
Decreasing “integration tax" has radically changed BSS and OSS architectures and business – and will change them more in the future [Part 1]
This BLOG post starts a series of short articles on the changes in BSS and OSS architectures arising from the changing underlying data communications, middleware, and data modeling software technology. Today we look back on the early days of OSS and BSS in the 1970s and early 1980s.
During my 30 years in the telecoms industry, I have seen a radical change in the cost of developing interfaces among BSSs and OSSs. Before the wide adoption of standard data communications protocols such as X.25, the development costs of interfaces between systems was easily $500,000 or more. Then multiply that by the old magic 2.7 to get the cost to the customer, and it meant well over a million dollars. The adoption of data communications interfaces such as X.25 and the old IBM FCIF (used in TIRKS and other IBM 3270-era systems) dropped the costs somewhat. But it only really attacked part of the problem. I recall once in my testing systems days (SARTS, for the old-timers out there) one US RBOC customer who wanted us to implement an X.25 interface on the system. When quizzed as to why they wanted it, they replied that they wanted to ‘plug it into’ another system and exchange data in real time. They were quite disappointed when they were informed that implementing a data communications protocol in two different systems did not mean that they could ‘talk’ together – you needed to actually do some more work. We also had another problem in those days – the X.25 protocol stack implementation was different in every different computer hardware system. So every time you offered the software on a different hardware platform, even from the same manufacturer, you had to re-implement the protocol stack.
The effect on the architecture was that only huge systems, architected by the same group, and implemented and tested by a single vendor, could hope to work together. Interfaces between disparate systems were few – and very expensive to build and maintain.
Next time – IP and middleware make things better.
(As usual, comments welcomed.)
Wednesday, 24 February 2010
Intelliden - Evangelism to White-Shirt-Button-Down IBM
This kind of crossing of the boundaries of IT and telecoms is going to be happening more and more, as the equipment and software that provides telecom services evolves to be just like that in a data center - optical transport equipment with Ethernet interfaces, routers, computers, SANs and specialized software for voice, data, video - and OSS/BSS functions!
Monday, 18 January 2010
Evangelistic OSS Products - An Introduction
(i.e. there is not an established market with a set of vendors providing somewhat the same thing to a defined set of customers). But a few brave customers (usually ones who love technology, in the case of OSSs and BSSs) are willing to take the gamble - these Moore called the 'innovators.' Then there is a gap (or 'chasm') as the 'early adopter' customers, usually looking for competitive advantage, begin to implement the product and see if it lives up to its potential.Many products fall into that chasm, never to be seen again - but those who cross the chasm usually begin to experience that heady 'hockey-stick' sales curve that companies crave.
In a series of BLOGS this year, I'm going to take on the task of describing some of whom I see as the companies and products in the BSS/OSS space who are crossing the chasm, or aspiring to.
I'll be covering companies like:
- Aria, attempting to change the way CSPs plan networks
- Celona, with new techniques for data migration
- Intelliden, tackling configuration management of CSP equipment
- Tribold, with a master catalog that seeks to dramatically decrease the time for new services to be introduced in BSSs
- Ontology, looking to bring the benefits of new bottoms-up patterning technology from biology to telecom to make database interfaces easier
- RateIntegration, bringing real-time marketing information to CSPs
Others have been suggested, such as Irdeto, GreenPlum, OSSTree, RiverMuse, and Quantellia, which I'll take a look at.
Comments and suggestions welcomed.
Tuesday, 25 August 2009
Mobile app stores - nice, but where's the money?

Saturday, 22 August 2009
BSS/OSS Sales vs. Revenue During a Recession – A Simple Model and Explanation
CFOs and product managers in software (and all other) companies spend a lot of time worrying about revenue, which is related to sales, but is not at all the same. Sales are “booked” when the customer signs a contract. Revenue is “recognized” in a way that is much more complicated – especially for software sales. During times of relatively smooth growth, yearly revenue (roughly, from sales of products this year + sales of products contracted for some time in the past, and now fully delivered + maintenance for that year + other professional services contracts completed this year) lags yearly sales (of new products, maintenance, and services) by some time – perhaps by a few months (for simple product sales that are delivered and accepted quickly) or perhaps by a few years (if it is a large, complex contract with multi-stage delivery, none of the revenue can be booked until ALL of the items have been delivered and accepted, and the customer has signed off on all services – in other words, everything in the contract has to be completed and signed off on before any of the revenue can be recognized).

So what does this mean? In the case where there is a recession, there is a flywheel effect on the revenue (or hysteresis, for the engineers and physicists out there) that smooths it out. Take a simple case of a company whose sales are growing by about 14% per year, before and after a two year recession. As seen below, the revenue is rising yearly, along with the product revenue and the total revenue. (I’ve assumed a simple model here where half the projects are completed within the year they are sold, and half the next year. Maintenance is assumed at 20% of purchase price.). Then along comes a recession, where sales drop to only 85% of the previous year’s sales and stay there for two years. Of course, the new sales curve drops. But the total revenue still continues to climb, although at a much smaller rate due to the smoothing effect of revenue recognition and the increasing maintenance base.
The smoothing effect is larger for larger companies, in general, since they tend to take on large, multi-year projects whose revenue is often deferred for some time. The effect is especially large for companies whose revenue includes a large fraction of services or custom work, like Amdocs and Telcordia (such companies also have the ability, during a sales downturn, to focus their development and delivery resources on completing contracts that may be lingering, boosting revenue) For smaller, very product-focused companies, who may be deriving 80% or more of their revenue in-year, a recession can be devastating to their “top line.” But, when times get good, their numbers recover more quickly, while the smoothing effect for the larger companies mean a longer recovery time for their numbers.
Why this complex relationship? Why does a company have to deliver it ALL to recognize ANY revenue? Because regulations were put into effect after the excesses of the dot-com era where some software firms were recognizing revenue when very little of the work had been done on the contract, then something would happen, and the contract was not completed. So now, a company may find itself in the strange situation of having delivered almost all of the components of a contract, perhaps even having been paid most of the money, but unable to “recognize” any of the revenue. Of course, revenue recognition is much, much more complicated than I’ve described here, and varies among the countries of the world, so if you are further interested, talk to your product manager or CFO.
If you want to play with this simple model of sales and revenue before, during, and after a recession, please e-mail me at mark.mortensen@analysysmason.com and request a copy of the spreadsheet that generated the chart above.
Tuesday, 28 July 2009
A new telecom analyst and the process of forcasting
Sunday, 19 July 2009
Customer Self-Care Done Right!
Thursday, 16 July 2009
Customer Self-Care - "You're on Your Own" or "You Asked for It!"?
Wednesday, 1 July 2009
Mortensen's Law of Maximum Ambiguity
MORTENSEN'S LAW OF MAXIMUM AMBIGUITY
In any situation, what will happen next is whatever will leave you maximally confused as to what the best course of action is.
Simple example:
You know that if "A" happens, you know you should do "Z." If "B" happens, then "Y."
What will happen will be a strange admixture of "A," "B," and "C" (maybe something you did not even think of) in precisely the combination that leaves you the most confused as to what is best to do next.
Try this out and see if you agree - many have reported that its predictive powers are amazing!
Friday, 26 June 2009
The TMF Certification Program – It Does What, Exactly?

Now I understand why that’s a good thing for the TMF – revenue for the organization, more “oomph” behind their very good work on projects like MTOSI, OSS/J, their NGOSS framework, and the SID, just to name a few. These quasi-standards have been more successful (although not nearly as successful as they should be – but more on that in another BLOG later) than any other set of telecommunications industry-created standards I have seen in my 30 years in the industry. But what, exactly, will the certification mean for the buyers and users of the systems that will be conforming? Ensuring interoperability with other that meet the standard? Certainly not without rigorous testing and integration work - there’s no such thing as blind plug-and-play in interfaces as complex as they are. For the ISVs, another hurdle to get over, and another cost (and become the 21st Century equivalent of Telcordia’s old hated OSMINE program? Hmmm.).
Let’s remember that the most successful standards have been set as de facto standards in the competitive marketplace, and then “standardized” later. And, somehow, the IETF doesn’t have a certification program and seems to be getting along just fine.
Friday, 19 June 2009
Machine to Machine Mobile Interfaces - Coming faster than you think
(Short version - dispenser with water and flavor, mixes the requested drink in real time, giving over 100 possibilities. RFID-tagged flavor cartridges. Software built on Microsoft CE, communicates daily via Verizon Wireless network with dedicated IP range to a Microsoft System Center Configuration Manager for Mobile Devices. Info on sales and re-order of supplies directly to Coke's SAP CRM system.)
Of course, as most of us believe, M2M interfaces over mobile networks are going to be a big thing in the future, representing, I believe, a great growth opportunity for the mobile operators (or maybe new, specialized operators?) over the next decade.





