Enabling New Services

A Spirit of Service

Stephen Fleece — Fri, 29 Oct 2010 11:48:00 GMT

This is my last blog post as employed staff with the TM Forum. I look forward to continue supporting the work of the TM Forum as a member again. I write a next chapter in my career as I return to the realm of communications industry consulting for Service Provider clients.

For the most part, TM Forum frameworks are often called “service agnostic.” In other words, the frameworks represent abstract models that support the common aspects of communications services—for the most part, any service—at least from a management perspective. This generic aspect of Frameworx continues to serve the expanding scope of the industry well. The models are intended to be frameworks, which are—by design–missing custom aspects that are often needed to make an implementable solution by full reference.

Times are changing, and Service Providers today need both agility and lean interoperability in the right places, but not all integration points. Common architecture continues to play a vitally important role in both cost effectiveness and agility, but I believe that architecture can easily be overused for changes that are innovative, experimental, or in an early stage of development. These changes include things like new product, services, processes, etc. Until such changes become proven from a business and financial perspective, it easy for the engineer in us to overdo architectural alignment and conformance. Sure, it sometime costs more to align things later, but it also often costs more, in both effort and invaluable time to market, to apply a heavy dose of architecture at the formation of change. There are always exceptions, but I believe this pattern and balancing opportunity is generally true in the majority of cases of significant transformation and change.

Today, different TM Forum members need different solutions for many different challenges and opportunities. A common approach in Frameworx is an important core, but we need service-specific business and management solutions for things—examples include defense network services, cloud services, and emerging new services like open APIs and advertising-based business models.

I encourage the best of my fellow brave, contributing members among us to deeply believe and commit to “the spirit of service.” It’s time for us to use, simplify, complement, and extend the “agnostic” aspects of Frameworx with the more “spiritual” aspects of specific new types of services. This means contributing to new best practices and standards as reference solutions for specific types of services that matter for your business environment.

It has been my pleasure to serve you all, wishing you my best in spirit.

‘Checking In’ and ‘Being In’ places

Stephen Fleece — Fri, 20 Aug 2010 15:29:00 GMT

Facebook fully launched its “Places” location-based service (LBS) this week for its 500 million and growing downstream base of users. What does this news mean to CSP LBS in terms of new services business growth potential? First, it uses a product design pattern that should be considered in CSP’s LBS products. Second, it is yet another web-based over-the-top (OTT) service bypassing potential CSP value beyond internet pipe connectivity. Third, it’s got a cool API for developers that CSP IT architects should note.

Facebook Places is similar to the recently successful ‘foursquare’ service, where users initiate a “check in” to a place, typically using their mobile device and internet data service. I see why this product design and user experience pattern is successful with downstream users. First, it gives simple and private control to the user on when and what location is published. Second, it builds naturally off of user status updates and tweeting style of user-initiated updates. However, this user-initiated product design pattern does require sustained will and mindshare from the user to publish.

I personally would prefer a few folks to have my real-time location by default, with features to limit real-time location data to a trusted circle of people. Continual GPS use zaps my device battery faster too. I think of that always on (mostly to trusted people), real-time, network-initiated pattern as the “being in” places pattern, as opposed to the “checking in.” Maybe I’m just a little lazy in that regard. I still like check-in style too for my wider circle of acquaintances.

I still see a market need for mobile carrier network LBS products. But, CSPs need to get more aggressive in investing in the upstream market and exposing this network capability for free. Yes, I said “free”--at least for the next few years. Unless the magnetic polarity of the earth reverses sometime soon (a dark scenario for bigger reasons), device-based GPS is only going to get more and more adopted as a free alternative LBS source for apps to consume, instead of getting it from a cloud service like GSMA’s OneAPI LBS. So, I suggest CSPs give away this specific value of the network before the market forgets about "greedy" clouds. There are other enabling services CSPs can better monetize if they can get market and mind share with upstream developers and businesses.

On a more technical note, Facebook Places uses a new, even more simplified third-party developer API called “Graph API.” Graph API provides a very simple pattern for third-party developers and apps to read and write data between the Facebook platform. The API uses username or object numeric identifiers in simple web addresses, depending on whether the object is a person, organization, or page of the person/org (username cases); or some other thing (number cases). So, every entity in the platform information model has a unique ID for hash functions. Many web service providers are diversifying away from relational information and data technologies towards semantic web and “NoSQL” approaches. Dynamic information relationships in less structured content, along with implementation performance and scale in cloud computing infrastructure, are two key reasons. These trends have me thinking about the TM Forum’s Information Framework (SID) futures.

Clouds forming for Services Brokerage

Stephen Fleece — Fri, 13 Aug 2010 21:23:00 GMT

In last week’s blog, we looked at the term “Service Broker” for the communications industry. Two contexts were highlighted: 1) the network service broker, and 2) services brokerage business models. Today, we examine the same term in an emerging context of cloud computing. Similar to the defined network service broker, the cloud service broker is beginning to take an early form.

In Gartner’s recent press release and report last month, Gartner identified three forms of cloud service brokers.
- Intermediation
- Aggregation
- Arbitrage

These forms map to similar business model examples that communications service providers (CSPs) face for services brokerage (we headlined last week). The aggregation angle for more product offerings was expected, as cloud computing services are a natural product to buy alongside communications products.

However, Gartner points out some interesting additional things to me. First, they go beyond business models to talk about specific intermediary management capabilities of a service broker component in a provider’s architecture. They name pricing, identity, access, and billing capabilities as examples.

Second, Gartner introduces the services brokerage role of arbitrage, which is something most communications service providers have yet to widely do at any dynamic scale. Arbitrage is similar to the exchange models or roles I headlined last week, but is different. Arbitrage works on dynamically buying low and selling high as pricing differences arise for the same things, whereas exchanges take a share of a transaction fee or revenue between two parties. For either exchange or arbitrage roles to work well, a standard taxonomy for cloud services product and feature definitions are needed in a federated catalog.

In any case, these types of cloud service brokers will bring important patterns of functional and operational capabilities for CSPs and suppliers to monitor and assess directional impacts. We already see signs they are impacting solution patterns for new communication services. These patterns include both enablement and the management fabric across the product and service lifecycle. In the TM Forum’s collaboration work on enabling new communication services, we are already seeing strong synergies between cloud and communications services like enablers. These impacts arise from cloud’s Platform as a Service (PaaS) model and its need for new management paradigms (and standards!) for many mashed up application services that software apps depend on from the cloud. These web-based communications services include open APIs to functional network and OSS/BSS capabilities, but much more as well.

Another useful reading resource about cloud services in the communications industry is our recent TM Forum Quick Insights Research publication, available for TM Forum members at no cost.

Summer Heat and Services Brokering

Stephen Fleece — Fri, 06 Aug 2010 22:41:00 GMT

Summer has come to the northern hemisphere. The term Service Broker is hot. Within the TM Forum membership, discussion about the term is growing. It reminds me a bit of the SDP and Telco 2.0 movements that started some years back. The hype got really loud and expectations grew significant. Both SDPs and Service Broker applications have found their place in the Next Generation Network architecture and the integrated business architecture. But, the industry lacks clarity on use of the term.

What strikes me is that there are two very important contexts for the term Service Broker:

1) Network Service Broker as part of a NGN architecture, typically focused on abstraction and mediation functions across IP Multimedia System (IMS) SCIM and Intelligent Network (IN) functions. It’s a complementary service control point (SCP) to complement SOA and SDPs northbound with IMS and traditional IN networks (2G/3G mobile, PSTN, etc.) southbound.

2) Services Brokerage as a category of business models typically focused on market making transactions between two sides, like roles in the Telco 2.0 model. This is sometimes called B2B2B or B2B2C, the B in the middle serves as a Business, such as a Service Provider, in a two-sided brokerage role. The first B is the upstream Business supplier or partner, and the B or C at the end is a downstream Business or Consumer customers.

So, when we in the industry say “Service Broker,” it may be helpful to clearly state (or ask the question of those using the term), are we talking “in the network” (NGN architecture) or “between markets” (business model)?

For more on the Network Service Broker, one of many good resources in the TM Forum is an on-demand webinar from Accenture and Oracle, available for replay during 2010 to TM Forum members at no cost here.

Services Brokerage represents a category of web-centric, retail focused business models that are growing in importance for CSPs, especially in the apps (mobile, IPTV, and SaaS) and IT business services areas such as cloud computing. Several value-adding, informally-defined example brokerage models include:
• Search & Discovery Agency
• Aggregation & Distribution (content, apps, services, etc.)
• Access (identity, access controls, subscriptions/usage, etc.)
• Marketplace Exchanges - includes transaction clearing and settlements
• Auction
• Delivery
• Marketplace Portals

A corporate ability of a CSP to rapidly develop, compete, and grow businesses and new services over the web in these types of brokerage business models requires not only an agile network, but an agile and integrated business architecture along with an organization that is adept at market making and merchandising. Services Brokerage in this broader business and technical context is where many see TM Forum Frameworx offering tremendous business benefits for the well-architected CSP business platform.

Innovative distribution + enabling services…

Stephen Fleece — Fri, 30 Jul 2010 13:59:00 GMT

With the June 24 TM Forum webinar and Team Action Week sessions (interest groups, SDF next phase), we’ve announced a direction and priority scope for the TM Forum’s Enabling New Services Initiative. Work remains to be done in tuning it and our execution plans, but it feels great to me to now be started. The initiative includes a dual focus: product trading between businesses (e.g., part of B2B space), and management of new enabling services.

On July 13, industry visionary Alan Quayle blogged about some of the same themes that lead the TM Forum Enabling New Services Initiative's focus. I was delighted to read Alan’s insights and strongly agree with his views in this post. Such resonating agreement includes most views found in other posts he links back to (e.g., developer needs). I especially support the point that Service Providers cannot effectively monetize enabling services by nickel and diming businesses and developers using the atomic enabling services ("dips"/usage). That's true now especially in a market phase of investing in market share/goodwill, developer relationships, and fostering third party innovation.

Digital product distribution solutions are also essential for getting apps and third-party services wired to--and hosted by--Service Provider’s enabling services in the cloud. Amazon and eBay-like distribution business models (like portals & app stores) are an important two-sided value-add for providers to win share of monetized business. IT customer buying decisions, from sole proprietor developers to the largest business corporations like banks, will be made during both build-time and run-time (across the lifecycle) of apps, content, and top-level services that rely on SP enabling services from hopefully interoperable platforms in the cloud.

I encourage everyone to read Alan’s blog post and most links in it. Alan has said very important things much better than I can again.

However, in adding to Alan’s closing example in his blog, many TM Forum member companies supply solid commercial parts of the enabling platform solution space. However, CSP executive leaders and all of us in the industry have collaborative and procurement work to do on realizing qualities of web-facing interoperability, simplicity, and unity. Reducing fragmentation facing third party developers on the web is absolutely critical for CSPs and their supply ecosystem to grow new industry share. I applaud the efforts of the Wholesale Apps Community (WAC) in this area. We must go further in the distribution and enabling services areas to address fragmentation for upstream businesses and tech developers. If we do not, new types of Service Providers doing distribution may get most of the new enabling services business share. These new SPs have advantages by having over 500,000,000 downstream users (including valuable user information) today on their proprietary platform.

New services upstream need user scale downstream

Stephen Fleece — Mon, 26 Jul 2010 13:48:00 GMT

This week Facebook crossed the 500 million registered users for the social network. I’m personally spending more time communicating with friends on this network, and less time communicating by voice and addressed messaging. The number of third-party apps and content providers on Facebook’s web platform are growing rapidly. The platform delivers over 500,000 third-party apps from the cloud, with over 1 million external websites integrated with Facebook’s own web services. An important linkage connects these two sides of Facebook’s growth. This linkage illustrates a relationship between enabling services for upstream customers and partners, and strategic scale of downstream users.

Speaking of two sides, TM Forum keynoted Management World 2009 conference in Nice on the topic of two-sided business models. This event last year began our member’s active collaboration to close a gap between strategies, new business models, and TM Forum Frameworx. We still have a long way to go as an industry and membership to fill this space in between strategy and operational practice. The industry still needs real best practices that can be implemented as business processes and technology, at least without using a “bus load” of high priced consultants.

Market scale and operational efficiency in a downstream “retail” business are becoming essential, in one way or another. Before the Internet, large CSPs have had unusual scale and competitor barriers in that they had “assets in the ground and air” to reach many physical end points (premises and mobile devices) and the users of voice and early data services. But today, the open Internet (and data access to it) has created a global marketplace for web and application level. Global Internet services brands like Facebook, Google, Apple, and even CNN reach the same users across many “ground and air” access territories. Scale advantages have moved from the individual CSP to these Internet brands and this type of digital service provider.

With the challenge of diminishing relative scale on their own assets, leading CSPs are adopting more partnerships and platform-centric approaches to develop web-facing and enabling services of the future. Regardless of the estimates, evidence like Facebook's success is proving that upstream businesses and developers are the growing, monetizeable customer market of tomorrow. These customers are interested in simple enabling services as “raw materials” for their own digital goods (products) and the ability to distribute product to downstream customers. This requires a whole new front, style, and portfolio of operational capabilities facing the upstream side of developers, partners, and business customers in the two-sided business model. Operators who try to contain them as suppliers or suppressed partners will eventually lose out significantly on market share and the financial value of enablement.

For an interesting interview with one of the masters of this model at Facebook, a good video interview with Facebook’s new CTO is available at this link. Enjoy and enable!

Often better late than never

Stephen Fleece — Mon, 12 Jul 2010 12:03:00 GMT

“Often better late than never,” I’m told. After a week’s vacation, a US holiday, and a trans-Atlantic round trip for the forum, I confess I’m late on this blog post by a business day. The post being late got me thinking about how most CSPs are late on something important too… seriously competing in the business models of the web. But, I assert again, often better late than never.

While I was on vacation, one of our contributing members Alcatel-Lucent acquired the online dwelling place of many western web developers “The ProgrammableWeb.” I’ve read a lot of questions about this move, and had a few interesting conversations with members and advisors about this strategy, but I’m quite encouraged about it as an important data point about a strategic trend in the communications industry. To me, it’s symbolic of major incumbent supplier/partner's moves to support the new ventures of several pioneering CSPs like BT (Ribbit), Vodafone, Orange, Telenor, and others to expose platform APIs to web developers on simple and commercially reasonable terms, to enable a “long tail” and large number of third-party customers.

Sure, many CSPs have had platform APIs for many institutional partners, but let’s face it as communications industry sectors, we are late "to the party" time for getting simple APIs (for more than SMS and location) opened up and offered on attractive terms to tens of thousands of SMB-like developer customers to innovate with, as serious products of the future. That’s where many CSPs who have a mission to build a customer-centric business need to go, regardless of retail versus wholesale orientation. Both need to be enablers at different layers or roles in the digital economy value chain. The party event of the digital economy is located at the corner “over the top” (OTT) to devices and web-based cloud services, so CSPs need to get ready to compete with, partner with, and offer to customers all the assets they’ve got facing the web. These assets include much more than the mobile network too. It includes an appropriate view of customer insight and real-time data beyond location, billing and settlements as a service, premium end-to-end QoE capabilities to the edge device, and much more.

Unless CSPs are set on being the best commodity bit pipe in the their part of the world, it’s indeed better late than never to start collaborating on and smartly competing for web business models. These models involve new products to enable a “long tail” of innovative parties on the web to better reach, engage, and deliver apps and cloud services to their customers and end users (and devices)—many of which are the CSP’s customers too.

Worst Competition in New Business Models

Stephen Fleece — Fri, 25 Jun 2010 19:38:00 GMT

A recent article about innovation at BusinessWeek notes two success factor questions regarding an innovation: 1) fit within an organization, and 2) readiness of management to support it. One of the worst competitors in CSP innovation exists inside the same CSP organization itself, as being "not a good fit" (usually technically or by competency) or a perceived threats to traditional business models or its operations.

Humanity is truly just in the beginning decades of learning to disruptively use our incredible inventions of the Internet and distributed computing for more than just business support systems, emails, and web 1.0. Yet, telecom innovation seems to have slowed down terribly, with exception of the world of optics and faster Internet pipes. Since the birth of UNIX and DARPA in the 1970s and roles that AT&T and Bell Labs (now Alcatel-Lucent) had in these disruptive technologies, the leaders of today’s digital economy--most outside telecom--are operating far above Layer 7 in the OSI Network Management stack. Maybe we need a new model north of the OSI host layer in our industry that will cover new services and business models.

A lot of CSPs are worried about declines in their traditional revenue stream. They should be. But many CSPs are very slowly (or not yet) moving services portfolio to Layer 7+ and the web (like GoogleVoice). This takes facing risks with market experimentation at the expense of traditional cash cows. Those cows are dying, so not taking product development risks is a bigger risk to shareholders.

As industry professionals at many levels in our companies, we all--myself included!--have a job to do in developing new competencies and showing our executive leaders the way forward in the digital economy. We can do this more effectively by increasing customer orientation, business proposition focus, management readiness, and architecture flexibly to make a fit for new ideas, new products, new services, and hopefully new revenues and profits. Progress is even more important today than perfection. It will take some contained failures to get to big success. Collaboration can help share the investment for experimenting at a business level with solid building blocks.

Speaking of business models, I’m taking a week off to go lay in the sun, so there’ll be no blog next week, but I’ll resume in 2 weeks time. While on vacation, I have ambitions to read a great new hard-copy book called Business Model Generation by Alexander Osterwalder and Yves Pigneur. I encourage you to get and finish it before me.

Monetizing App Services with PaaS

Stephen Fleece — Fri, 18 Jun 2010 15:05:00 GMT

The worlds of consumer apps and cloud computing will converge for service providers. Most consumers “downstream” in the apps value network care less about techno cloud talk, they just want a personalized, reliable, inexpensive, and simple experience on their various screens and devices. Yet, on the upstream side of the service provider's business model, app providers (and the technical developers that make them) are increasingly needing services from the cloud. It's at this point that app development people and making important “wiring” and purchasing decisions, as customers (not supplier/partners). The cloud computing sector’s “SPI model” includes an important model concept called PaaS, or Platform as a Service (PaaS) that has vital implications to capturing demand for new communications services on the web.

Today’s article from the Economist on mobile apps on their own raises again an important question about the business and shareholder value of retail apps distribution. As reinforced by TM Forum’s Insights Research done earlier this year, the key retail business benefit of apps distribution is improved end user experience and loyalty benefits compared to not having a branded and integrated app store at all. But, apps very well may be a loss leader product (possibly profitable, but margin diluting) from a retail distribution perspective.

Cloud computing providers realize that getting apps development into their clouds and tools (SDKs) is a synergistic strategy to sell operational services to support and run the apps functionality. That’s not just for app hosting, but includes the micro-services that apps consume like cloud storage, ad placements, and mashups (network-based location, charging, etc.). Many of these web-based micro services are not generally free either, and have real demand and revenue potential. PaaS models go further to attract the actual app software development and service consumption into an integrated app software development, deployment, and operational environment. It’s in this full cycle approach that open API services demand and monetized market share will be built. The TM Forum’s Service Delivery Framework (SDF) takes a full lifecycle approach in its reference architecture and identified interfaces to support both development and management new services and seems well suited for PaaS environments.

I’m pleased to announce the TM Forum’s kickoff of an interest group for collaborating on best practices for app stores and distribution. Our first call will be on Tuesday, July 13th at 9:00AM ET. Any member of the TM Forum can join. More details are found in our online community for Content & Apps Value Chains (member log-in needed).

Mitigating Risk of a Derivative Services Disaster

Stephen Fleece — Sat, 12 Jun 2010 00:59:00 GMT

Prophets of gloom seldom get a warm reception. But they can stimulate proactive and positive mitigation of reasonable risks. The communications industry can learn from other industry’s technology failures and resulting crises and catastrophes, such as two recently caused in financial services and energy production. As we build architectures to enable new digital services, communications industry leaders are increasingly challenged to balance the need for new competitive speed and traditional operational diligence. Collaboration helps.

I’ve been thinking about the role of technology management in gloomy scenarios, after witnessing two catastrophic disasters with devastating impacts on society. The first is the financial crisis, largely caused by enabling--but not managing--the complexity of derivative debt securities. These financial “mash ups” of multiple securities were largely processed by technology. There are some fundamental human, non-technical reasons for this crisis, but the lack of monitoring and management controls around these complex assemblies made them appear safely diversified to many, but actually very difficult to track and monitor underlying quality by the issuers. Most investors didn’t know the true nature of the complexities and interdependencies inherent in the products. When parts of the industry crashed (mortgages, derivative debt), it almost brought the whole global financial system down, including basic banking liquidity. The second disaster is the environment and social devastation caused by what is most likely now to be largest crude oil spill the world has ever seen. Both historical events were caused, in part, by the failure of human engineering around technology, together with lack of reliable management controls for failure scenarios. These events have destroyed many families way of life.

In the evolving Internet economy, human communications have begun a paradigm shift towards many parties weaving together mashups of apps and services between computing and communications clouds. Yet, there are none or limited management control standards adopted between service providers to help humans monitor and manage these interdependencies, and the risk of failure they bring. Will we be next to cause an unforeseen disaster?

My pondering about gloomy scenarios has become another reason I see great potential for the TM Forum’s Service Delivery Framework (SDF). That potential goes beyond risk mitigation, and includes potential for new revenues too in “sunny day” scenarios, by monetizing service distribution and the value of assurance as a service. There’s much work to be done. I want my MTV mashup, but we need to mash it with interoperable management too. There very well could be much more at stake than just merrily sharing music videos with friends on Facebook.