How Wedge Approaches Existing OSS/BSS
Wedge Greene is frequently described as the "go to guy for OSS reinvention" or "a technical genius always inventing the next step for companies and products." This simple “marketing” characterization has some truth and Wedge routinely accomplished these goals while a chief architect and as an executive consultant. However, this does not address the fact that the penetration of new approaches and new technology into today’s telecom is really quite shallow – as little as 5% and possibly, in some of the most far along, perhaps 25%. Some of the most important activity of a chief architect is building the broad strategic view and a pattern for technical realization of that strategy. But much of the work is addressing the adaptation of existing legacy systems (often doing a fine job at what they were designed for) to the changing market conditions, new product offerings, and updated network and systems platforms. This activity is not so romantic and does not get the press of bold new concepts. But it is important for business continuity. Quite often the right business decision is to update what exists and integrate in new functionality. Most of the day to day activity of a chief architect at a service provider is doing just this work.
NGOSS was originally designed as an integration platform and most of the success stories of NGOSS involve integration approaches as the principle return on value. When NGOSS was conceived, there were some 200 separate OSS/BSS systems doing overlapping jobs at MCI. When WorldCom and MCI merged the number jumped to over 600 systems. No matter who you are, it is not feasible to effectively run a business with this degree of fractionalization in IT support structures. So some systems must be consolidated and others replaced. But as often as not there is gold in there with the straw and this must be discovered through audits and interviews of the existing support staff. When gold is found, it might pay to expand its scope and enhance its role to become a service used by other systems. NGOSS is a platform architecture that can facilitate this service component structure. Most of the attached services in real-world NGOSS integration are legacy systems or commercial products.
Often the best way to build new functionality is to “buy” an existing OSS/BSS product. This was not true as little as six years ago, but today it is possible to actually choose between competing OSS/BSS service component products that will effectively bind into NGOSS architecture. Part of this is because vendors have “wised up” to the expressed needs of service providers as captured in NGOSS, ITIL, and other enterprise architectures. Yet better, many of the new products are designed for functional service zones, such as Enterprise Product Catalogues, or use the new TMForum and ITU standards, such as with Universal Element Management systems. All these work well as components in NGOSS architectures; returning multiplied value as they are accessed and reused by other services.
But there are still vendors who claim to support NGOSS and are just not there. It is important to review all potential products: in the context of NGOSS principles, by getting examples of successful NGOSS integration, and for applicability to your existing environment. Claims of NGOSS/ITIL support are not evidence of support. Not all integrators and consulting houses are working for you; some are working for themselves.
The future does belong to "cloud computing" and “autonomic network management” or yet some other advanced approach. But it typically takes 10 years to bring a concept into common penetration and another 10 years before it is the predominate technology. In the mean time service providers must adapt to stringent new market conditions. “Re-use, adapt, buy” is often the correct choice and having “a good feeling for corporate politics” is how this gets acomplished. Analysis, decision, implementation... should be done with the support of an architect “with one foot in the past and another in the future”. One does not keep a product because it has always been there, but because it still has value and can be economically hooked into today’s enterprise service architectures.
