|
|
article
page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
-
Extends services across networks and devices
-
Provides an operating environment and development tools for third-party software developers
-
Improves the profitability of niche services
But getting an SDF will not be easy. Issues to be overcome include:
-
Managing end-to-end application performance
-
Modular, standards-based SDPs are still relatively immature
-
Integration
-
Service provider’s are not yet organized to take advantage of SDPs
-
Lack of a compelling business case
-
Lack of standards creating confusion and trepidation
-
Marketing challenges
All of this is rather familiar stuff. Indeed some of these were cited eight years ago as business drivers for NGOSS, and probably have been used to justify (or shoot down) most IT initiatives funded by service providers in the last five years. What is new is that the technical piece-parts are becoming available and perhaps the will of the service providers is stronger. And this time the vision just resonates. It is elegant.
|
|
[Incompatibility] greatly increases the expenses of deployment and in particular the management costs. Increasingly, service providers want a managed service from SDPs. |
|
positioning of appropriate contributions from other Industry Groups and market sectors will also be an essential facet of this project. However, the proposal contained a cartoon architecture drawing laying out architecture for an SDF and this was further elaborated upon in the last year. This SDF “model” was fresh - now we see it replicated in the SDP product description documents of major vendor contributors like Nokia. So, de facto, despite expressed contrary wishes, the TMF is at it again - inventing architectures of broad significance, because after all, this is what the membership wants.
The opportunities and potential of this program are quite exciting. The SDF Team work-plan promises to deliver on some of these expectations. What actually got charted, as stated in the current final draft of TR139, as the work of the TMF SDF program is the definition of these elements:
|
|
|
|
It is not expected that the TMF will progress this work alone, or even take the lead in designing the actual architecture of the SDF. It expects to liaison with other industry groups to achieve this, but those groups do not seem to have formal SDF programs. Just as with NGOSS, the needs of the service provider seem to demand architectures and programs earlier than other industry groups – most of which only concern themselves with specific business enablers.
Formally, the TMF SDF group is not inventing the SDF. “Present work involves defining the Requirements to fill ‘Gaps’ in existing NGOSS Frameworks and associated specifications (eg eTOM, SID, TAM etc). In addition, the
|
|
must comply in order to perform the lifecycle management;
-
The lifecycle management interface of SDF service components;
-
Impact on OSS/BSS and lifecycle management support infrastructure with for example interfaces, meta-data, and flows needed by inventories, Catalogs, and Registry.
But SDF contains the promise, the potential to include even more exciting implications - potential work products which have not, as yet formally, made it into the managed work plans of the team. Specifically, Keith Miller’s larger vision includes:
article
page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | |
|
|
