Enabling New Services - All Comments

re: Summer Heat and Services Brokering

neha sehgal — Mon, 05 Sep 2011 08:56:27 GMT

can u pls share something about SCIM ie. service capability interaction manager...

re: Twitter: a Social Service Bus (~ESB)

Steve Harris — Mon, 15 Nov 2010 00:23:00 GMT

I've just been discussing this very subject with a friend of mine. It would seem to me that Twitter could have the possibility of becoming a global ESB. Imagine an interface to twitter to publish and subscribe to message - encryption, delivery assurance would have to be the responsibility of the applications - but that's what we have to do when using UDP.

Great observation Stephen.

re: A Spirit of Service

Tony Poulos — Tue, 02 Nov 2010 06:06:51 GMT

Stephen, you exemplify the 'Spirit of Service' and will be sorely missed by members and your colleagues, especially me.

Thanks from all of us!

re: Summer Heat and Services Brokering

Stephen Fleece — Mon, 23 Aug 2010 12:12:01 GMT

Thanks Alain for the comments. I agree with your highlight of Cloud Service Brokers as one of the major opportunities for Service Providers today. I blogged about Cloud Service Brokers in the week following this blog post (see http://bit.ly/9gfFCf ).

On the brokerage scenario for apps, there are several business models and TM Forum Frameworx architecture considerations. One question is "is the app being brokered" either "as a service" or as "software content"? Cloud often handles it as SaaS, where mobile devices often handle it as software content being distributed. Device apps use and rely on services from the cloud in general, but this type of brokerage is more than just brokering of service alone. The app constitutes what the TM Forum Frameworx view as commercial Product, involving both Services and Logical Resources (software binaries, metadata, etc.).

re: Summer Heat and Services Brokering

Alain Decartes — Mon, 23 Aug 2010 03:00:37 GMT

I see two types of services brokerage opportunities today: the first one is what the TM Forum Cloud Service Insight report calls Cloud Service Brokers. I also believe that communication service providers (CSPs) could serve as trusted intermediaries between end-users (I would say mainly enterprise), and cloud services providers. Please refer to a white paper explaining HP’s vision on this topic at www.hp.com/go/scalenow.

Then there is the consumer market, the explosion of applications for all types of devices, and the creation of App Store to expose them. During a visit to Barnes and Noble this week-end, I have just seen a demonstration of the Nook e-reader and the B&N application store. In this case, Barnes and Nobles, as Apple and Google successfully did before them, plays the role of service broker as they provide not only access to their millions of books, but also to all types of magazines, newspapers and other web sites through different “apps” (www.barnesandnoble.com/nook). The 3G connectivity, that AT&T provides, is an additional one time charge of $50. What is the revenue AT&T will make for providing their unlimited 3G access? Is it too late for the CSPs to play a services brokerage role for the apps store market? Should they take advantage of their network assets and subscribers knowledge to aggregate several application stores and make a business out of it? The possibility exists for them, based on the utilization of their Service Data Platform, Subscriber Data Management and… a Network Service Broker capability.

re: Summer Heat and Services Brokering

Stephen Fleece — Mon, 09 Aug 2010 12:46:50 GMT

Burhan ul Haq,

I've posted some illustrations here of the different Service Broker contexts...

www.tmforum.org/.../service-brokers.aspx

Stephen

re: Summer Heat and Services Brokering

Burhan ul Haq — Mon, 09 Aug 2010 06:29:21 GMT

I appreciate the classification which helps to distill the confusion regarding the subject. If possible, can you please share high-level diagrams regarding the two contexts.

re: Innovative distribution + enabling services…

Stephen Fleece — Mon, 02 Aug 2010 21:07:37 GMT

Tal, thanks for the comments. The external enablingment aspect is one reason the SDF project is prioritizing an initial "alpha" specification of the SDF SMI since this will be an external interface facing third-party developers of service apps (e.g., service enablers, SaaS/PaaS apps, etc.).

Stephen

re: Innovative distribution + enabling services…

Tal Givoly — Mon, 02 Aug 2010 20:57:27 GMT

Read both this post and Alan's.

I believe the critical aspects are indeed those that are being addressed by WAC right now. Will it be successful? Time will tell. Until then service providers will try different approaches (including the one cited by Alan as impressing him).

In either case, I believe the external interfaces are far more important than the internal structures to manage and run them. Each service provider's service delivery framework will differ quite dramatically, and that, perhaps, is by design. Standardization is useful when they are critical for adoption of a technology. When they are not critical, they are not only not helpful, they are unlikely to take footing. Examples of this are endless.

That's one of the reason internal interface standards, wholly within a service provider boundary, are of the lowest priority to service introduction. Unfortunately, much of the work TMF has been engaging in so far has been focused on this area - which is the least critical for service providers despite the difficulties it imposes upon them over time.

Once a technology is rolled out, fixing the management interfaces of it seems hardly the right thing to focus on.

A great example is IPTV - standardization way after the fact. On the other hand, IP, HTML, USB, BD, and WiFi are examples where standardization are critical for market creation.

Where do our current activities fall? Put this test to any standardization we work on to consider how effective it might become.

Tal

re: Innovative distribution + enabling services…

Stephen Fleece — Mon, 02 Aug 2010 14:37:09 GMT

Jenny, I think the potential of the SDF SMI is one part of a larger API management business landscape. I agree Alan's views on the business landscape and the architectural concept of SDF SMI are not entirely equal.

I think there's a big market strategy and "go to market" issue for CSPs to succeed in capturing business from third party developers (and the businesses that employ them) that Alan's views help emphasize.