|
|
article page | 1 | 2 | 3 | 4|
In a very large way Dave set the tone and the high bar for the TMW Catalyst program. In recent years Dave was one of the few “leader-visionaries” who headed the NGOSS Red Team which had the task of hammering out the central architecture of NGOSS. For years, Dave led a dual life, for he also kept the OSS/J project teams firmly grounded in reality. With the merger of the OSS/J organization into the TMF earlier this year – which resulted in PrOSSpero, the choice of Dave as this fall’s inductee was obvious. Of all, Dave most represents the fusion of NGOSS and OSS/J.
PrOSSpero vs. NGOSS
PrOSSpero (as Martin Creaner letters it) is a merger of OSS/J and the TMF. This was a big organizational initiative for the TMF, announced last spring at the TMW Europe. For years OSS/J members have worked inside TMF groups and Catalyst projects while under the organizational charter of the Java User Community. So in some ways, this was an insider merger; however, there were reasons OSS/J was separate for so many years. TMF products used to be about architecture and collaborative standards. OSS/J was about producing software under standardized interfaces. OSS/J directly rejected NGOSS style component architecture and eTOM/TAM re-engineering of components, to favor mainstream ‘link up existing products design’ using established product feature boundaries. (Truthful disclosure: a position the author argued was anti-architectural and pseudo progress.)
The board is seems mostly behind this merger but the advisory board still expresses doubt and may withhold full support. There are many who worry the TMF should stay in standards and cooperative agreements and not become a software shop; a task to which it may be ill suited and in which there is no embedded TMF staff expertise. The working team membership is also mixed about this. Some vendors like Valaran, itself an architecturally driven, small service-based infrastructure company, have openly joined PrOSSpero, singing its praises – I expect this is because of the Java connection. Other companies like AutoMagic are concerned that architecture and rigorous adherence to design principles are being sacrificed for expediency. Greg Fiedler wants more discipline in developing sound business process design and analyzing component processes in the PrOSSpero program (here, here!). In some ways this debate on ‘should the TMF be in the software business’ is a “shutting the barn door after the cows are out” discussion. The merger occurred; now how will TMF make it work and not marginalize NGOSS?
AutoMagic is another rising star. I felt this consulting group with a canned UML NGOSS/eTOM model was the outstanding new development at last year’s TMW Americas. This last year they have enriched their offering. They have built a formal software engineering model of the decomposition of NGOSS, SID, eTOM, and TAM - perhaps the only rigorous treatment of core NGOSS in existence. This may be the second place to go first for any company considering using NGOSS in operational and product transformation.
NGOSS Catalyst’s - Re-engineering OSS & BSS in the Lab
In its current state of implantation, NGOSS is still about connecting large applications through messages. The standard approach is to use an Enterprise Service Bus (basically a pub/sub messaging system orchestrated by workflow) as the connector. But the services themselves still tend to be existing (heritage/legacy) applications and COTS (Commercial Off The Shelf) products. SOA (Service Oriented Architecture) is making inroads at replacing the ESB product with a web services connector; more because of the reduced cost and the awkwardness of implementing with the ESB COTS products. However, the applications being connected are still big, multi-function applications, each with their own data stores. So, while new, re-engineered architectural models, following NGOSS and eTOM, describe single function services, the power of this decomposition is lost during implementation when the architecture is mapped onto larger composite applications.
The Telecommunications Applications Map (TAM) was developed to provide a high-level decomposition of applications into functional groups, so that similar, reusable functions would be grouped together and reside in well known service boundaries. The actual TAM has an epistemological history antedating NGOSS. Now TAM is the composite service model of the business applications layer of NGOSS. It does not address the common infrastructure services which are described in the NGOSS “red team” architecture documents. Some progress is occurring in Catalyst teams understanding of NGOSS, because the vendor-driven approach of mapping existing COTS onto the eTOM functional service map is now replaced with the mapping of COTS onto the TAM. This is good because the TAM describes the composite architecture while the eTOM describes the functional actions. However, in practice, the eTOM delivers a much more decomposed, fine-grained design than the TAM.
Catalyst projects are among the most successful products that the TMF offers the OSS/BSS community. This year Catalysts were surging back into prominence with six major project efforts – but as always the results were mixed. But that is the point of a Catalyst; some should fail or fail to demonstrate their goals. After all, Catalysts are the laboratory in which the design ideas of the TMF working groups are applied to real world practice. A team is created to attempt to solve an important service provider problem. Members form in “birds of a feather” sessions and must have at least one Service Provider. Vendors with products that can be applied to solve the problem join in, as does usually a Systems Integrator.
The object is to push from concept at one TMW to live demonstration of a viable solution by the next – just six months later. Working in successive six month chunks, the teams push the concept to a logical end. A good Catalyst project might for example show delivery of an existing service (re-engineering) and delivery of a future service (rapid service support design.) Today it is expected that every Catalyst team must be successful and all have praises to sell – this just is not true. We, who learn, also learn from failure.
Returning to NGOSS implementation approaches, the “decomposition failure” is evident in the Catalyst Showcase “Realizing SOA-based NGOSS”.
|
|
"In some ways this debate on ‘should the TMF be in the software business’ is a “shutting the barn door after the cows are out” |
|
This group took a strong model-driven architectural approach concentrating on a data-centric integration of the composite services. That is, design followed the SID data model and implementation consisted of mapping this shared service model onto consolidated databases. IMHO, this catalyst still fell into the ongoing problem of mapping a larger pre-existing application onto the TAM (telecom Applications Map), aggregating these smaller services within some larger applications. (This is much like the American political process of voting area redistricting. The borders are drawn to conform to the desired outcome – here a legacy system or COTS.) In this catalyst the actual messaging occurs in an ESB layer not over SOA. The SOA of the title is limited to a web service wrapping for the human interface services. This is far from state-of-the-art design thinking in the use of SOA.
IMS Everywhere
This year the TMF took a page from the organization of other commercial conferences and provided a strong model of grouping presentations into tracks of similar function and business goals. (This was also done in the spring TMW Europe in Nice.) I had the honor to chair the Wednesday morning sessions for the Converged Operations Summit.
Last year IMS was hardly featured at the TMF, but got one of the strongest responses from the audience. This year IMS themes dominated and were scattered throughout the program. The community is waking up to the challenges and opportunities of this new approach. Every track had IMS related presentations, many of which overlapped each other in competing groups. Next TMW, I recommend the staff consider tracking by target services and technologies. I cannot report on all of the IMS talks, including some very good tutorials, but I will single out one example presentation and the IMS catalyst.
In the track I chaired (among the ever-present vendor pitches thinly masquerading as field studies), IMHO the outstanding presentation came from Laurie Harvey of Appium concerning IMS and SDP/SDF creation. She argued that IMS and classical SDP can coexist under a new component SDF framework. This framework is being designed, or at least consolidated, in the TMF Landscape Project. This is an approach that resonates with us. Incidentally, while I have not used it, I hear good things about the specialized Appium applications server – according to Sun benchmarks. If you are planning a service creation and service management project in the IMS area, you should put them on your potential vendor list.
For me the most exciting Catalyst this year was Accelerating VoIP and IMS Services (AVIS)”. This group demonstrated-live the development and use of IMS services, together with user feature control interactions via a customer portal. And these were services you would love to have right now on your mobile phone. The architecture was very clean and defined; although they also settled for macro-size components of COTS products. Nevertheless, there was a clear, rational delineation of network service, operational service, service delivery, and service management. The demo followed a life-cycle approach of showing service build, service activation, service modification, and management of service QoS. This is the 2nd year for this catalyst and shows that, like my old FineGrain NGOSS Catalyst, cohesive groups that start with a clear vision, have ambitious goals of supporting real time service demos, and stick with this over the long haul in a coherent catalyst team can achieve remarkable and significant results.
The Executive Master Class
For me, the high point of the entire TMW meeting was this session lead by Keith Willets and Rob Rich on transformation. The good news is that they intend to repeat it at Nice next spring, so you still have a chance to hear this. If idealism exists in Service Provider Transformation, this is the heart of that perspective This session was actually set up as a roundtable with all the seats, including the presenters arranged at tables (alas, no drink or food). This was a marathon session of tag teaming between Keith Willets and Rob Rich (ex of Yankee Group and now an independent consultant) coordinated by Jim Warner. It is a shame that Colin Orviss was ill and missed participating in this session, but Keith stepped in and handled the technology slides with aplomb (they were all trends and no software). It is an open rumor that this group is working on a joint book – about time that the Lean, Mean Service Provider got updated.
I have not the space or the right to steal their thunder by repeating these sizable presentations. Simply put, the gist was the relationship of many trendy business paradigms (like web 2.0, long tail products, and the New World Order) to Service Provider transformation projects. They have produced a seven part transformation life-cycle, fully animated, which includes stages such as commit, rationalize portfolio, remove barriers, transform processes, transform systems, etc.
Rob Rich sums it up like this: “it is becoming clear to virtually all carriers that:
1. They are operating in a complex dynamic ecosystem
2. There are a number of opportunities where they are well suited to provide significant customer and partner value and differentiation.
3. In order to provide leadership in one or more of these roles, they will need to focus their strategic intent and execution (to quote marketing guru Al Reis, "When you try to be all things to all people, you end up being nothing").
4. In order to cope with complexity and remain agile in the ecosystem, they will need to develop/ evolve world class processes in key areas, monitor progress through KPI measurement, adopt standards based architectures, and take advantage of the risk avoidance and time to market benefits of COTS.”
While none of these is radically new news, it is presented in a package that may help service providers identify some logical starting points for their transformation programs. All I can add to this is ‘remember to keep a balanced focus between what your customers would find truly relevant and a disciplined, architecture driven design.’ |
|
|
|
article page | 1 | 2 | 3 | 4|
|
|
|
