Table of Contents 1 Executive Summary... 2 2. SOA Overview... 3 2.1 Technology... 4 2.2 Processes and Governance... 8 3 SOA in Verizon The IT Workbench Platform... 10 3.1 Technology... 10 3.2 Processes and Governance... 15 3.3 Return on Investment... 16 4 Verizon SOA Professional Services Offerings... 17 5 Conclusion... 18 Copyright 2006 Verizon ALL RIGHTS RESERVED
1 Executive Summary The Verizon Service Oriented Architecture (SOA) platform, also known as IT Workbench, is an agent based infrastructure for deployment and publication of services. Created a few years ago as a tool primarily for developers to create and publish Web services, the platform has evolved into a comprehensive SOA solution for Verizon where thousands of services are published and millions of service invocations are made on a daily basis. Some of these services are available to external customers and partners, resulting in operational efficiencies for all parties. This paper provides an overview of this platform and discusses how Verizon has been using and benefitting from the platform so far. The paper s initial section provides a high level overview of Service Oriented Architecture approach, introducing areas ranging from service creation to service management and security. This introduction to SOA is followed by a detailed overview of the IT Workbench platform. To illustrate how the SOA platform helps with practical applications, the paper references real life examples to trace the evolution of a service in the Verizon environment. Case study examples are located in each section. Finally, the paper concludes with a discussion of the Return On Investment (ROI) for Verizon as well as potential areas of future evolution of this platform. Case Study : Background The trouble ticketing function will be used as an example to illustrate the use of SOA within Verizon. For the purposes of this example, the trouble ticketing function is composed of two major services: the create service invoked by the caller to create a ticket when a network trouble is reported and the get ticket status service used to obtain status of a ticket. On the create call, the network on which the trouble is reported is identified by a circuit identifier. It returns a ticket number in response. The get ticket status service is passed a ticket number and returns its status. After the formation of Verizon Business in 2006, the company had two major trouble ticketing systems one for access networks and the other for transport networks. The access network interface was based on the Common Object Request Broker Architecture (CORBA) specification, a forerunner of Web services and SOA, whereas the transport network interface was already based on the Web services standard. For Verizon Business, it was clear that a common interface for trouble ticketing based on web services standards was needed. It was also clear that a highly secure version of this interface was needed for the Business to Business (B2B) channel. Page 2
2. SOA Overview Service Oriented Architecture (SOA) is a design approach that treats discrete pieces of business logic or data as services delivered through software. A service is described by a contract which explains its functionality, intended usage, and service level agreements. Services have their own development lifecycle with design, run, and change time viewpoints. Automation tools, joined with certain design approaches and disciplines, define the overall approach to SOA design. The motivation for SOA is largely around reuse of existing softwarebased system assets in a more flexible way. At a minimum, the design objectives of SOA include the following tenets: Strong encapsulation Services are defined with specific functionality and well understood boundaries. They are packaged as discrete components that are reusable in other designs, yet do not depend on the particular state of any other component. Construction by composition Services are designed to be components in other (possibly unknown) applications. Loose coupling Services are able to interact without creating brittle dependencies, using well known protocols and within industry standard deployment platforms. In more sophisticated SOA environments, additional designs may be applied to increase the dynamic nature of service interactions: Discoverability Services are recorded in some form of directory that may be consulted programmatically by the developers of other systems in order to locate and reuse services at run time without prior configuration. Real time monitoring Services may participate in overlay networks of monitoring systems which observe, record, and report on their use and health. Reactive service level management Additional functions may provide reactive control based on the run time operation and usage of services. Changes in service levels may result, based on scaling, performance, security, or other concerns. Migration In the most sophisticated environments, services may be mobile across a range of physical infrastructure with support for ondemand provisioning and de provisioning. Page 3
2.1 Technology Reference Architecture and Deployment Model The SOA reference model (Figure 1) provides a foundation for understanding the functional placement of components in the overall architecture during development and deployment. The SOA infrastructure facilitates the deployment of services, their discovery and use by other applications, and the necessary security and other service level commitments needed for the proper functioning of these applications. Figure 1: SOA Reference Architecture There are four key areas an SOA platform needs to enable: 1. Service creation and deployment refers to the native services created by new applications, as well as services created through service enablement, via transformation and protocol conversions, of legacy systems. The functional elements of the Enterprise Service Bus play a key role in this area. 2. Service coordination refers to service composition and orchestration the ability to create sophisticated services from basic services and to orchestrate them via business processes. 3. Service management facilitates the publication and discovery of services, service monitoring and reporting, and management of any service level agreements. Page 4
4. Security management refers to providing secure access to the services, authenticating service use, and preserving the confidentiality and integrity of the data associated with services. Service creation and deployment The creation and deployment of native services by new applications are typically enabled via some kind of a portal that allows developers to specify the service interfaces and locations and ties them to a service registry. More sophisticated implementations might use an Enterprise Service Bus (ESB) that provides for protocol transformation and mediation. Enterprise Service Bus An ESB is the design pattern for integration and middleware implementation that facilitates the interoperation of multiple protocols among many applications. Components of the ESB are distributed throughout an application ecosystem, with some pieces collocated within application containers (e.g., Java application servers, Web servers, etc.) and others functioning independently as standalone resources (e.g., business process automation environments). While many products implement some or most of the ESB pattern, products vary in approach and completeness. Any given organization will implement multiple products and/or in house development functions to complete their ESB. Larger organizations will likely run multiple ESBs and interconnect them to cross business units or geographic boundaries. An ESB may have many components, including the following: Service invocation Data routing Data transformation Protocol adapters and transformations Service naming mapping Message processing Transaction management Coordination of implementation services (ʺservices orchestrationʺ) Coordination of business processes (ʺprocesses choreographyʺ) Security management Availability, performance, and scaling management Many of these functions reside on the bus as independent framework services and are shared across multiple applications. Page 5
Service Enabling Legacy Systems A critical component of most SOA initiatives is the liberation of functionality trapped within existing legacy systems. Legacy functions are wrapped using adapters from an ESB or other middleware. Integration servers may be applied to tap beyond the normal interfaces of existing systems. Modern SOA deployments implement or reuse existing integration servers to facilitate legacy integration. Such integration tools and servers include implementation of the following general patterns: Enterprise application integration (EAI) Extract, transform, and load (ETL) Enterprise information integration (EII) Semantic mapping engines Mashups and UI aggregation servers Business process management (BPM) and workflow automation Stream or complex event processing Service Coordination Service coordination is essentially the construction of business applications through reuse of existing services. A number of tools exist to make the job of constructing composite applications easier. Business Process Management (BPM) and workflow automation tools operate at the coordination layer of the SOA reference architecture. Existing systems may be orchestrated through calls to their native or Web service enabled interfaces to implement a cross system process. Interfaces of multiple systems may be aggregated with additional functionality to create new applications. Finally, systems which exist as peers may agree on common protocols or rules of engagement that Choreograph their interactions. This commonly occurs across business units or among customers, suppliers, and partners, where no single organization controls the entire coordinated system. Regardless of the methods and tools, the coordination layer is where much of the active development activity occurs in a SOA to create new business value visible to end users and customers. Page 6
Service Management Service Management functions within the SOA are responsible for areas such as monitoring, reporting, maintaining registries/repositories of services, and controlling service levels. Monitoring may be accomplished within the implementation of services or via framework services, that is, services that do not perform any application business logic but enable other services. These services are in turn consumed by tools that provide reports and summary information. The use of a service registry (a directory of services) and repository (implementation code and documentation) forms the backbone of functionality needed for management service lifecycles, from the initial justification of requirements through the eventual deployment. The entire portfolio of services should be describable within the registry/repository making it easier for new development to find and reuse existing assets. The final function of the service management framework is to provide the ability to both describe as well as enforce service level agreements between service providers and customers. In more sophisticated deployments, this single tiered approach will extend to define the entire value chain across many services that are interdependent. When a call to a service initiates calls to several more layers, these dependencies can be aggregated into an overall service level that is reliable for the top level service consumer. This capability is especially important when the service chain includes external service providers (e.g., suppliers and customers). Case Study: Publishing Common Ticketing Interface via SOA Registry The first step towards ticketing system consolidation was to create a common set of ticketing services using Web services standards and publish them on the Verizon SOA registry. To this end, a common Web services based interface for ticketing was defined, accommodating both the access and transport networks. An Enterprise Service Bus (ESB) was used to transform the CORBA based access network interface to the new Web services based interface. The final set of common ticketing services was then published on the registry for use inside Verizon. Developers could now find these services readily on the registry and start using them. Within a few months of the publishing of these services, the get ticket status service was one of the most widely used services across Verizon Business. Security Management The W3C (World Wide Web Consortium) Web Services Architecture Requirements outline the following six important security considerations for a comprehensive security framework. Authentication: verifies identity of anyone accessing the service. Authorization: verifies that the authenticated person has the right to access the service or data. Page 7
Confidentiality: protects the data passed between the requester and provider. Integrity: prevents the message from being modified in its path from requestor to provider. Non repudiation: prevents the sender of the message from claiming he/she sent the message at a later time. Accessibility: maintains service accessibility and protects against attacks, such as Denial of Service (DoS), from outside or inside the system hosting the service. In an SOA environment, a popular way to achieve authentication and authorization is via Simple Object Access Protocol (SOAP) message monitoring. The SOAP message associated with the Web service being invoked is intercepted and examined for user authentication and authorization. Security Assertion Markup Language (SAML) is an OASIS XML standard that provides credible assertions of the authenticated and authorized messages that can be passed around. Message confidentiality, integrity and non repudiation are typically achieved via certificates, keys and encryption. XML security standards exist that allow SOAP messages to be encrypted while retaining the XML formatting that provides standards based secure messaging. Finally, accessibility is generally backed by some form of a service level agreement (SLA). 2.2 Processes and Governance The previous section discussed the technological foundation of SOA. For an organization to effectively implement SOA, technology needs to be combined with processes that govern the architecture of services, their design and lifecycle, their effective operational management, and any changes required to align the organizational structure and processes to be consistent with the service model. We now discuss these areas in turn. Architecture Management The architecture management of the SOA may fall to groups named IT Architecture, Enterprise Architecture, or some other title. Regardless of their name, some organization must take on the role of defining both the reference architecture as well as the framework for a service catalog. Successful service catalogs use the business model of the organization or a more general framework model from the organization s industry overall. Page 8
Example industry specific models include the Tele Management Forum s enhanced Telecom Operations Model (etom) for telecommunications, the Supply Chain Operations Reference (SCOR) model for supply chain management, and the insurance industry s Insurance Application Architecture (IAA). Each can provide a foundation for service architecture. Having such a model helps to show where gaps and overlaps exist in the available services and creates a shared understanding of how to classify services across the complex application portfolios of most large organizations. Leveraging a managed architecture framework builds up two key views of process. It frames the conversation about which services to reuse, which to build, and which to buy. Thus, the prioritization of the use of resources is clearer and makes for an easier path to strategic change. Second, a framework based view allows for analysis of key business processes which span many services. Those processes may now be classified in the framework and, if it is industry based, benchmarked against peers. Lifecycle Management Services are software components and their design process is similar to a typical IT Software Development Life Cycle (SDLC). SOA services, being integration pathways, involve multiple participants and need information sharing of various artifacts among these participants from conception to the realization of service. A realized service evolves in its lifetime (e.g., using versioning control). Service lifecycle is the definition of these activities and milestones that all involved parties can easily understand and be aware of. Service lifecycle with governance provides a coherent way to evolve SOA in an organization that provides agility and focused service definition. Operational Management The operational management of an SOA involves business and technical policies governing the production, consumption, and distribution of SOA services. One operational aspect deals with which services are consumed by whom and what throughput and performance attributes need to be satisfied by a particular service. Business policies governing access restrictions are realized by means of security management. Technical policies regarding throughput and other performance requirements might be addressed by means of a comprehensive Service Level Agreement (SLA). Page 9
Organizational Management The first and foremost impact services might have in an organization is on the structure of the organization itself. Most existing IT organizations are organized around applications or projects. Services, by providing an opportunity to break these application silos, might provide a fundamentally different way for these organizations to structure themselves around services. The second area where services might have an impact in an organization is in its budgetary process. Given the importance of the budget in influencing organizational behavior, it is best for the organizational budgeting process to be service aware. This will allow for service creation and usage to grow without budget impediments. For an organization getting started with SOA, it is important that the SOA creation and usage targets are clearly articulated in the organizational goals and objectives. 3 SOA in Verizon The IT Workbench Platform When Verizon s SOA platform, called IT Workbench, was created in 2002 and was conceived with a focus on the service creation and deployment capabilities to turn existing application functionality into Web services, promoting visibility and reuse. While the platform has surpassed its original expectations with phenomenal growth in adoption and use across Verizon, it also has evolved over the years into a robust SOA platform with solid service coordination, management, and security features. The next few sections provide an overview of this platform. 3.1 Technology Reference architecture that closely matches what is shown in Figure 2.1 has been adopted as the model for Verizon. IT Workbench Service Creation and Deployment IT Workbench provides development and service lifecycle management functions within the portal environment for developers as well as a dashboard for service administrators. Figure 2 depicts this scenario. Page 10
Design Time ITW Service Administration Portal Provision - or Subscribe Service ITW Service Management Dashboard Run Time Manage Define Service Name Bus. Functions Taxonomy Owners Interfaces SLAs Subscriber Access Control Metrics Standard / Ad Hoc Reporting Health Monitor Service Registry & Repository Log Records Logging Security Develop and Test Service or Subscriber Deploy Production Figure 2: Workbench Portal Lifecycle The IT Workbench portal and dashboard components provide complementary functions. At design time, services are specified by their interfaces and location and assigned a service owner who controls modifications and subscriptions to the service. The service owner may control an entire portfolio of services across a complete business function or process. At run time, the same service definitions recorded in the IT Workbench repository are used as templates for service management. The IT Workbench dashboard provides reports and service health monitoring via SLA tracking. IT Workbench supports two different but complementary paradigms for service instrumentation. In the agent based approach, services are instrumented via the IT Workbench agent to provide security access control and monitoring of service usage events (Figure 3). In this approach, the IT Workbench infrastructure is highly distributed, with agents collocated within application containers (the Java or.net application engines on which the application services run within Verizon s infrastructure). This arrangement allows IT Workbench to scale out horizontally in conjunction with the application infrastructure. Agents are added only when new services are added. Page 11
Figure 3: IT Workbench Agent The other approach for service instrumentation is the broker based model (Figure 4) where a centralized service broker provides the instrumentation necessary for security and monitoring. The centralized broker model does not require agents, and therefore is not intrusive to the actual application. Each of the models, agents, and brokers serve specific design needs. In an environment as complex and dynamic as Verizon, both options are necessary to allow for maximum flexibility in meeting business needs. The Verizon SOA platform uses the ESB primarily for protocol transformations for legacy systems. The ESB itself can have the agent instrumented in it or can use the centralized broker for service deployment. Both approaches are in use today. Page 12
Figure 4: IT Workbench Broker IT Workbench Service Coordination The main tasks of service coordination and reuse are service composition and orchestration. Here Verizon departed from the early thinking in SOA design that required service coordination be part of the ESB. Instead Verizon took a more flexible approach that admitted the complexities of Verizon s environments, culture, and development practices. Verizon s approach to the company s complexities is to allow multiple implementations of service coordination technologies to be managed across a federated ESB environment and Web Services Management (WSM) platform. These infrastructures come together in a development plan for IT Workbench services that is shared across Verizon. This approach expects development portfolios to follow their own path for service coordination and development environments, with pockets of expertise arising around major vendor offerings. Initially, the technology mapping of the SOA reference architecture followed existing assets in Verizon. Given the dynamic nature of the IT infrastructure market, Verizon expects to support migrations from tool to tool over time and to maintain a competitive vendor offering capability wherever possible. At this stage, the SOA market is not expected to remain entirely vendor agnostic. Page 13
Case Study: Adding business logic to ticketing interface via service composition SOA Service Composition allows for the creation of composite services based on a basic set of services. As Verizon Business was preparing to make the ticketing services available to customers via the B2B channel, it was apparent that there needed to be a translation between the network inventory stored by the customers and those stored inside Verizon Business on behalf of the customers, which are often not the same. The customer systems use the customer identifier whereas the ticketing service expects a Verizon Business identifier. It is inefficient to make the changes in the ticketing service itself as it would require the change to be made in multiple systems (network and transport ticketing systems). Instead, the SOA platform allows this to be achieved by means of Service Composition without changing the underlying ticketing systems. In this case, the ticketing service was replaced by a new composite service that invokes another service which does the inventory translation before invoking the ticketing function. This is just one example of how the SOA platform provides for the graceful evolution of services. IT Workbench Security Management IT Workbench uses username tokens (based on Web services WS Security model) to provide authentication and authorization. Depending on how the service is instrumented, these are performed at run time by the IT Workbench agent or by the centralized broker. IT Workbench agents and the broker have the ability to cache the credentials and authentication information to improve performance. The security service itself is deployed as a framework service that is accessed by the agents and the broker. For services that are used across business units, two way Secure Sockets Layer (SSL) at the transport layer is usually added to provide a second layer of security. Services that are exposed to external customers and partners are accessed via public network facing gateways. These gateways use username tokens for authentication and authorization and also require digital signature based encryption for privacy protection and data integrity. Case Study: Securing common ticketing interface for B2B channel The B2B channel requires additional authentication and encryption due to stringent security requirements for dealing with external entities like customers and partners. For example, besides doing the encryption at the transport layer via Secure Sockets Layer (SSL) Verizon s security policy mandated that the so called two factor authentication be applied to the B2B ticketing interface. The two factors referred to here are: 1. User ID & Password to authenticate the message 2. Use of Digital Signature to confirm the integrity of the message This was implemented by intercepting the Simple Object Access Protocol (SOAP) message at the SOA layer and using the WS Security header in the message. Again, an example of a SOA facility that allows for an enhancement to occur without any changes to systems down stream Page 14
3.2 Processes and Governance When SOA was first introduced at Verizon, adoption and usage growth was driven primarily by executive level goals set for creation and consumption of services. These goals were translated into the targets for individual organizations. The bottom up creation of services by these organizations, combined with the distribution of these services across the company by the IT Workbench platform allowed the organizations to usually exceed their creation and consumption targets. The other aspects of service management and governance have evolved over time. A discussion of the current state of these aspects appear in the following sections. Architecture Management The Verizon Enterprise Architecture (EA) team maintains the service catalog for each business unit and works in close co ordination with the infrastructure team on technological aspects of the platform and with the development teams on the service definitions. The EA team is currently working on rationalizing the service catalog based on the enhanced Telecom Operations Model (etom), a telecommunications framework from the Tele Management Forum. We expect this to be an ongoing activity where the EA team continues to keep the Verizon service repository and definitions synchronized with industry standards as they evolve. Lifecycle Management The IT Workbench platform provides several functions supporting service lifecycle management. It allows service providers to start the lifecycle process at the beginning of the design/analysis phase and keep track of the service through a set of administrative and development portals in IT Workbench. The registry store within IT Workbench monitors changes as the service evolves through the lifecycle and includes version management for the service. IT Workbench also offers various reports on service transactions that can be targeted for distribution across the entire company. Operational Management As we discussed in the previous section, IT Workbench offers various levels of security and service level management for service providers to enforce. One business unit, Verizon Business, for example, enforces security (authentication and authorization) at runtime through agents, service level agreements based on load, performance and availability, and even requires adherence to standards on interface specification for any service (via the WS I Basic Profile). Organizations typically start with a limited number of security and service criteria and add more as demand grows or as new requirements arise. Page 15
Organizational Management Services at Verizon have evolved to reflect the organizational structures of business units. Service adoption and growth was driven during the initial stages by setting organizational goals for service consumption and creation. As the platform has matured, services have now become part of usual business processes. In general, the Verizon implementation of internal processes and service lifecycle management within IT Workbench reflects the needs and culture of Verizon s development and operations approach. Given the need to provide an environment across many, semi autonomous organizations, IT Workbench maintains flexible forms of governance where possible and constrains work where required by corporate policy. For example, security standards are strongly enforced. However, the standard for any given service endpoint for performance and scaling features is dependent on business requirements and agreements between service providers and consumers. 3.3 Return on Investment The benefits and returns on investment for an SOA platform can be broadly classified into three categories: The cost and speed to market benefits associated with reuse of services The cost benefits associated with system consolidation and legacy system decommissioning The cost and efficiency benefits associated with the direct exposure of these services to external customers and partners (Business to Business (B2B)) The cost and speed to market benefits associated with service reuse is obvious as it is usually significantly faster to reuse a service compared to writing it from scratch. The benefit comes not only from the saved code development time, but also from the testing and business validation that goes with any new service that is created. Of course, for any of these benefits to be realized, there has got to be a significant level of adoption of services and SOA across the company. Verizon believes that the simplicity of the IT Workbench distributed agent model and the associated Portal environment helped considerably with its service adoption in general. Within a year of the launch of the platform, Verizon saw the emergence of hundreds of services. Also, the comprehensive and easy to use service registry led to a lower reuse cost (compared to creating a new service) which resulted in an explosion of service usage (about 200 million transactions per month at of the end of 2007). Page 16
At Verizon Business, which immediately adopted IT Workbench after its formation in 2006, in the first year alone, the company saw a net savings of approximately $5M just from service reuse. This was achieved by both encouraging the creation of services as well as the distribution of the services via the IT Workbench repository. An organizational target for service creation was set and was translated into targets for individual development portfolios depending on their size and the nature of their development work. SOA has also enabled the retirement of legacy systems as part of infrastructure consolidation. Verizon Business retired over 75 systems in 2007 and is on track to retiring over 100 systems in 2008, thanks in part to the SOA initiative. Finally, in addition to service reuse benefits, Verizon Business has found that exposing these services in a B2B environment (with additional security provisions) to external enterprise customers can yield further benefits. For example, allowing the customer and partner applications to directly invoke services might result in lower calls into the operations centers as these communications would have otherwise been made via calls. Verizon Business observed a tremendous growth in the use of B2B trouble reporting services when they were made available to customers and partners. 4 Verizon SOA Professional Services Offerings With its simple agent based infrastructure that has been used for years at Verizon, IT Workbench is being packaged as a product and can be leveraged by enterprises planning to adopt SOA. Verizon s in house SOA expertise will also be offered as part of its professional services portfolio. An enterprise wanting to adopt this approach can start with an evaluation of its SOA needs by a Verizon professional services team and proceed towards a much broader engagement which tapers off as the enterprise learns the platform and becomes less dependent on the professional services. To facilitate this, Verizon will offer the following suite of Professional Services providing a progression of customer engagements allowing the customer to decide which option, if any, is a fit for their enterprise: Verizon SOA Basics: Customers can start with an overview of SOA and the Verizon SOA platform by requesting a half day briefing session where documentation and white paper material will be provided. Page 17
Verizon SOA Advanced: Interested customers can follow up the briefing session with a 5 day, on site evaluation of SOA in their environment. This evaluation will be conducted by a trained Verizon SOA Professional Services team. It will generally include a thorough analysis of the customer SOA environment including the organizations and processes, and provide a comprehensive set of recommendations covering all of these areas. A written evaluation and recommendations document will be delivered to the customer at the end of the engagement. A long term advisory role for Verizon Business can also be arranged where Verizon SOA Professional Services team will monitor and advise the customer on their SOA evolution. Verizon SOA Professional: If the Verizon SOA platform is determined to be a good fit for the customer environment, the platform can be sold as a licensed product to the customer. Verizon on site professional services, typically lasting from one to six months, will be available during installation and set up time. Continued support for the product will also be available at various service levels. Verizon SOA Managed: The Verizon SOA platform can also be offered as a managed service with Verizon owning complete operational responsibility for the platform. In this case, the platform itself will be hosted by Verizon and managed by the Verizon team. The Verizon SOA Professional Services team will advise the customer on the use of the platform and on SOA adoption. 5 Conclusion IT Workbench today is a widely adopted SOA platform within Verizon supporting service creation and management. While the internal adoption and usage growth have been phenomenal, the platform has also enabled cross business unit communication within Verizon and B2B communication with customers and partners. As the platform grows, Verizon expects it to evolve in three ways: Continued evolution of the platform via framework services expanding IT Workbench framework services beyond just security and logging, and creating new framework services for SLA contract management, service discovery, and even dynamic provisioning of services Evolving from service standardization to information standardization integrating IT Workbench with an enterprise data services platform to unlock information from legacy data sources and expose them as data services Page 18
Moving towards full business automation total integration of service composition and business orchestration tooling into the platform to automate entire business processes from contract definition to service creation Verizon is currently working on creating a standards based, serviceoriented, common product catalog, enabled by the Verizon SOA platform and leveraging data services and federation among legacy product catalogs. Verizon is a member of the Tele Management Forum (TMF) and is working to leverage the SOA platform to achieve full business process automation based on TMF standards. Case Study: Standardizing Common Ticketing Interface using NGOSS OSS/J Specifications At this point, Verizon Business has a standard set of ticketing services that are used both internally (using the SOA registry) and by our customers (via the B2B channel). The Tele Management Forum s standards bodies (OSS/J and NGOSS) have recently published a web services based, industry standard interface for trouble ticketing. Verizon Business is working with a few other service providers to consider adopting this interface in the future. This standardization is also being done via Service Composition at the SOA layer by creating transformation logic between Industry Standard Specification and Verizon Business Proprietary Specification. Page 19