The ability to rapidly assemble new shorter-life services will be the key differentiator for telecommunications service providers (SPs) striving to beat out cable, entertainment, and Internet companies as they encroach on each other's customer base.

SOA and BPM offer potential solutions to this critical issue by bringing levels of business agility and responsiveness hitherto unseen in the IT environs of SPs.

As the lines blurred among telecom, entertainment, retail, and Internet domains, SPs were forced to seriously consider the state of their networks. Now with the network in place, SPs are instead considering how they can increase operational speed and responsiveness to customer demands.

The realization in hotly contested triple- and quad-play markets is that SPs must in fact become customer service providers (CSPs). They must make the transition from me-too services to truly converged, on-demand services that differ from those offered by MSOs and non-traditional competitors.

Services On-Demand
To achieve that end, CSPs will have to work with third-party developers to create scores, if not hundreds, of niche services that leverage their substantial investments in IP networks. After all, they laid the fiber to enable voice, video, and data to come together over the same connection in very short time frames. In theory, that unique ability will enable CSPs to create prodigious catalogs of converged services without disrupting the underlying architecture.

Carriers must shift from the staid and stodgy belief that services must take months, if not years, to roll out to a paradigm that enables services and products to be rolled out in hours, if not minutes. The only way to effect that mindset change is to drive the reuse of common data models, formats, naming conventions, interfaces, and design processes across the organization.

That need for reuse will drive carriers to break back-office silos down into components. Such components will represent operational elements of network and IT systems, as well as product, service, and resource specifications. These components can ultimately be turned into "building blocks" that are loosely coupled so that they can be used interchangeably among different services and products.

The ability to use building blocks interchangeably among applications requires a common framework in which carriers can segment operations and couple services in the spirit of Service Oriented Architecture (SOA). SOA requires an execution environment in which services are decoupled from networks for integration with business processes.

Once this type of integration is achieved, the environment can be used as a true service delivery platform (SDP) from which new functionality can be driven (i.e., SIP capabilities around presence, location, and more advanced voice mail services that can be used in creative product bundles). By implementing common SIP servers for applications needing connectivity over IP networks, carriers can procure data from disparate sources so that billing authorization and billing detail are consistent across the organization.

As new services are created through increasingly agile SDPs and execution environments, CSPs will have to orchestrate changes simultaneously within OSS/BSS applications. The complexity of orchestration for dynamic services will require full automation of activation, ordering, and billing processes so that fulfillment and assurance processes can seamlessly work for new service rollouts.

Too Many 'Moving Parts'
In today's marketplace, the bottleneck for product management and design is usually the sheer volume of paper documentation and ambiguous hierarchies with which engineers, architects, and marketers have to grapple.

Rather than invest in software, companies tend to throw people at the problem. These people usually fail to resolve issues expediently because they continue to look at problems at the granular level. A granular approach requires intimate knowledge of the "nuts and bolts" of an organization. That is a major impediment to rapid service deployment.

Larry Goldman at OSS Observer believes that CSPs are now willing to "generalize" parameters in exchange for speed to market.
For example, CSPs today possess as many as 30 or 40 pieces for their fulfillment system. As a result, dozens of applications have to be strung together to handle and track orders and interface to networks.

More often than not, distinct inventory systems are purchased for each technology type in the carrier environments - such as one instance for copper wires, one instance for DSL, and another for basic switching systems. On top of that, more systems are layered to track and manage services riding over those technologies.

Rather than manage so much complexity, carriers should strive to possess fewer "moving parts." The ability to handle a large range of services in a tight manner is more important now than disrupting the business with custom-made solutions running in isolation.

Thinking "Inside the Box"
To reduce the number of small pieces they must manage, CSPs must first ask, "What size box is the right size?"
Carriers are wary of the smaller boxes that must be strung together with enormous integration projects, but they are also wary of monoliths that take care of all aspects of fulfillment, assurance, billing, and customer care.

Most CSPs don't want to be held hostage, or surrender control to a vendor that can take its time with upgrades to accommodate the desired feature sets. Carriers would rather possess more capabilities for self-care and control of feature sets and services.

While IT and engineering grapple with the hierarchies and dependencies necessary for new products or services, it's the product managers that must ultimately introduce new services into commercial environments.

The main issue facing product managers is that whenever they suggest a new product innovation they have to wait months, or even years, for IT departments to assemble technical committees that try to embrace the business need. They gather details and slide presentations that attempt to detail for marketing the reasons why a new service either is or isn't possible.

Rather than endure such a lengthy process, product managers need tools that abstract the IT complexity for them by creating "objects" representing components of the IT and network domains of which they know little.

Such objects would be a foundation for an ecosystem built around common descriptions about pieces of fulfillment, assurance, and billing.

As consistency in terminology and protocols is established around how services are defined and what components are necessary to make services work, IT could better understand how components should be deployed and discrepancies easier to identify (i.e., multiple elements deployed to do the same function).