Service Assurance Initiative (CR 1068) Architecture Definition Document

Version 0.3

FairPoint Communications

Page I

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition

Table of Contents
1. 1.1 1.2 1.3 2. 3. 3.1 3.2 3.3 3.4 3.5 3.6 4. 4.1 4.2 4.3 4.4 4.5 4.6 5. 5.1 5.2 5.3 5.4 5.5 6. 6.1 6.2 6.3 6.4 6.5 6.6 7. 7.1 7.2 7.3 7.4 8. 8.1 8.2 9. 10. ARCHITECTURE DEFINITION DOCUMENT ....................................................... 3 DOCUMENT HISTORY ............................................................................................3 REFERENCES .....................................................................................................3 ACRONYMS .......................................................................................................3 INTRODUCTION ............................................................................................. 3 HIGH LEVEL BUSINESS CONTEXT DIAGRAM................................................... 3 USERS ............................................................................................................3 CHANNELS ........................................................................................................3 PRODUCT .........................................................................................................3 PERFORMANCE MONITORING AND REPORTING...............................................................3 SERVICEABILITY, ORDERING & TROUBLE TICKET MANAGEMENT ..........................................3 FOUNDATIONAL ELEMENTS .....................................................................................3 SOLUTION ANALYSIS ..................................................................................... 3 ACCEDIAN MICRO PORTAL AND EMS .........................................................................3 WHOLESALE SYSTEM (VFO FROM SYNCHRONOSS) .........................................................3 TROUBLE TICKETING ............................................................................................3 MONITORING AND REPORTING .................................................................................3 SOLUTION MATRIX ..............................................................................................3 PROPOSED SOLUTION ...........................................................................................3 SYSTEM CONTEXT DIAGRAM .......................................................................... 3 SOURCE SYSTEMS ...............................................................................................3 VFO...............................................................................................................3 DATA ..............................................................................................................3 SINGLE SIGN-ON ...............................................................................................3 PRESENTATION...................................................................................................3 SOLUTION ARCHITECTURE............................................................................. 3 AS-IS .............................................................................................................3 TO-BE ............................................................................................................3 SOLUTION DESIGN GOALS .....................................................................................3 DESIGN CONSTRAINTS .........................................................................................3 KNOWN DESIGN ASSUMPTIONS ...............................................................................3 DESIGN RISKS ...................................................................................................3 ENTERPRISE APPLICATION IMPACTS ............................................................ 3 NETCOOL/PROVISO .............................................................................................3 M6 (METASOLV) ................................................................................................3 REMEDY ...........................................................................................................3 ORACLE SSO ....................................................................................................3 INTEGRATION DESIGN................................................................................... 3 INTEGRATION OVERVIEW .......................................................................................3 INTEGRATION DETAILS .........................................................................................3 PHYSICAL ARCHITECTURE ............................................................................. 3 SOFTWARE STACK OVERVIEW ....................................................................... 3

FairPoint Communications

Page II

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition 10.1 11. 12. DEVELOPMENT TOOLS ........................................................................................3

OPEN QUESTIONS .......................................................................................... 3 APPENDIX...................................................................................................... 3 TECHNICAL AND IMPLEMENTATION STANDARDS ..........................................................3

12.1

FairPoint Communications

Page III

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition

1.
1.1

Architecture Definition Document

Document History
Date 10/15 10/19 11/09 11/17 11/29 12/02 Version 0.1 0.1a 0.2 0.2a 0.3 0.4 Description Template for review with Table of Content (TOC) Updated Business Context Updated System Context Updated functional architecture Updated system impacts Updates and addition of assumptions based on review. Author Fahad Baig Fahad Baig Fahad Baig Fahad Baig Fahad Baig Ryan Donovan

1.2

References
No. 1 2 3 Artifact Name FP_ServiceAssurance_InterfaceDesign.doc HW Architecture.pdf SA_HWSW_Requirements.xlsx Location <<fairshare>> <<fairshare>> <<fairshare>> Date 12/3/2010 12/3/2010 12/3/2010

1.3

Acronyms
No. 1 2 3 4 5 6 7 8 9 10 11 Acronym CDG SLA VFO NID M6 EMS VZW ATT Netcool/Proviso OAM EVC Description Wholesale billing solution Service Level Assurance Virtual Front office, wholesale ordering and trouble ticket solution Network ID Provisioning system Environment management system Verizon wireless customer AT&T customer Performance Management system for FairPoint network equipment Oracle Access Manager Ethernet Virtual Circuit

FairPoint Communications

Page 1

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition

2.

Introduction

This document articulates the Technical Architecture for the Service Assurance Customer Portal (CR 1068) made available through FairPoint online business web presence. The goal of this solution is to provide an extensible portal to assure that FairPoint Carrier Ethernet is meeting is service level agreements with its business customers with data from Accedian equipment vendor systems with future goals of offering data from various equipment vendors in a centralized format and location. This document will be the guide for all technology and architecture related questions. This solution will allow service level transparency, increased customer confidence and centralized access to data and statistics from customers onsite Accedian equipment. It will be the primary resource for customers to analyze their service usage. The system should support monitoring of trouble ticketing progress and with future iterations - the portal should provide FairPoint with the opportunity to market additional products and services supporting revenue growth and product penetration. The service assurance aspect of the customer portal must be launched by March of 2011 and the service assurance requirements precede additional customer portal needs such as integration with billing systems, order management and serviceability during this initial phase of the initiative. The focus of this document is to provide the Architectural assumptions and decisions that lay the framework for this application to provide Service Assurance for carrier ethernet customers. This project is being driven by carrier ethernet service contracts with AT&T and VZW and FairPoint must meet the obligations of those contracts.

FairPoint Communications

Page 2

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition

3.

High Level Business Context Diagram

The Business context diagram provides an overview of the relationship of the various business level functions that are part of the solution. The intent of the diagram is to communicate the areas of scope that the architectural definition must touch upon to full encompass the solution. This diagram lives independent of the technologies used to build a solution to support the problem and simply guides the solution towards completeness.

Figure 3-1 Business Context Diagram 3.1 Users

3.1.1 Enterprise Business Customers This set of customers represents people that have already enrolled into the Carrier Ethernet product service from FairPoint communications. In the initial release the main purpose for them using this portal will be to get a status of the enrolled services and ensure SLAs are being met using various reports. 3.1.2 Admin Users This set of users represents internal FairPoint IT and Customer representatives trying to troubleshoot any customer portal related issues. These will be normal users with a higher level of privilege assigned to them. 3.2 Channels

3.2.1 Web Service Assurance Portal The site address (TBD1) website is the entry point for customers to view reports and status of the Carrier Ethernet service being provided by FairPoint communications. Customers will have secure access to the contents of this portal.

FairPoint Communications

Page 3

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition 3.2.2 Mobile Service Assurance Portal The (TBD1) mobile website will be similar in functionality to the website. This mobile website is not planned for the initial release and will be planned for a future release. The main purpose of a mobile enabled site is for customers to be able to check SLAs and reports using their mobile handsets. 3.3 Product

3.3.1 Carrier Ethernet Carrier Ethernet is the primary product to be supported by the Service Assurance portal. FairPoint may enhance its network with devices from multiple vendors (Accedian, OCCAM & AdTran); this portal will support SLA assurance reporting from all vendor equipment with an extensible architecture to support SLAs from any future vendor equipment. 3.4 Performance Monitoring and Reporting

3.4.1 Reporting The portal needs to provide extensive reporting functions which includes (but not limited to) dashboards, graphical reports and drillable reports which allow the customer to choose SLAs to include in the report. The reports should present the data that can be drilled down further to each device level and also roll up at a network level. These reports should be time-based and user should have the ability to retrieve these reports for a selected time period. All reports should be printable and support pdf, csv and excel formats.

3.4.2 Performance Monitoring The portal should provide a gateway for customers to monitor performance metrics of customers NIDs. The portal should display list of devices for each client with locations and detailed specifications. 3.4.3 Alerts The portal should provide users with service related alerts relating to meeting the contract determined SLAs.

3.5

Serviceability, Ordering & Trouble Ticket management

3.5.1 Service Provisioning The portal should allow customers functions of activation of additional lines and increases in services on demand. This may include automatically triggered increases of services (and charges) to meet network traffic conditions. With knowledge of the customer equipment in place, service adjustments can be made and charged as needed. This functionality is highly dependent on the hardware equipment capabilities and is not immediately available for the FairPoint Carrier ethernet service. A workaround for this requirement is to allow escalated provisioning of services through orders for ethernet customers through the portal. Assumptions: - The escalated order process provides a suitable replacement for the need for real time service provisioning. - When real time provisioning and flow through to billing becomes possible, the FairPoint Communications Page 4 Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition service assurance portal shall be extended to lead people to the real time provisioning process. 3.5.2 Manage Trouble Tickets The customer should be able to raise trouble tickets for services offered by FairPoint. The portal should allow customers to view, escalate, cancel, edit tickets, and reports depicting trouble ticket history for a customer should be made available. In cases where a trouble ticket related to service outage, the qualifying trouble ticket can contribute to a billing credit which is sent to the billing system. Assumptions: - With customers eBonded to Remedy, the service assurance portal does not need to re-create the features of creating, viewing details and updating the trouble tickets. - The capability to work with Remedy trouble tickets also exists inside the VFO application. Since this capability exists, the service assurance portal does not need to re-create the capability. - The service assurance portal needs to support reporting on trouble tickets as this capability is not currently available to the customer via VFO. (eBonded customers may be able to report on Remedy tickets through their own processes, but FairPoint will not rely on them having that capability built.) The service assurance portal will need to report on both trouble ticket mean time to repair and circuit time to repair to provide customers with the transparency to contracted trouble ticket resolution times. 3.5.3 Manage Orders The portal should allow customers to place orders and edit existing orders. Customers should be able to incrementally edit their existing carrier Ethernet services. This action should trigger the correct set of events to ensure the order information ends up in the correct set of systems. Updates on status of order should also be made available to the customers. Assumptions: - With customers eBonded, the service assurance portal does not need to recreate the features of ordering. - The ordering capability also exists inside the VFO application. Since this capability exists, the service assurance portal does not need to re-create the capability. - The service assurance portal needs to support reporting on orders (Days over firm order commitment date) as this capability is not currently available to the customer via VFO. The service assurance portal will need to report on days over firm order commitment date on a circuit level to provide customers with the transparency to contracted trouble firm order delivery date obligations.

3.6

Foundational Elements

Foundational modules work across the different functional elements of the solution. These foundational elements will primarily include User management, single sign-on and

FairPoint Communications

Page 5

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition notifications functions. 3.6.1 Manage Profile The portal should allow customers to view and manage users. Customers should be able to manage contact information including mailing and email address. 3.6.2 Role based Access Control (RBAC) The portal should allow role based access to reports and systems. Functions in the portal should be accessible based on the roles to which a user belongs. 3.6.3 Hierarchical Profiles These go along with the RBAC system, where Admins for each customer are allowed to provision new users with restricted access and different roles. 3.6.4 Secure Access The portal should be accessible securely. The level of security will be determined at a later point but it needs to be an https connection at a minimum. All access to the portal reports should be secured using user id and passwords. 3.6.5 Single Sign-On In the scenario where the user will need to navigate to multiple systems, the system should enable seamless integration between the different systems. Single sign-on will allow users to navigate to different systems without having to re-authenticate themselves once they have been authenticated. This is a nice-to-have feature and should be implemented in a later phase. 3.6.6 Notifications This central service should manage all notifications being sent to the customers related to lapses in SLAs on various metrics. This service should also send out periodic SLA reports to the customers via email.

4.

Solution Analysis

As part of the Architecture definition exercise, various existing systems within the FairPoint landscape were analyzed and requirements validated. This was done with the sole purpose of avoiding re-inventing the wheel. The various systems analyzed by the team were 4.1 Accedian Micro Portal and EMS

This solution is being implemented as an immediate solution to display Y.1731 details in December 2010. The micro portal is a light weight portal solution that sits on top of the Accedian EMS and provides the necessary Y.1731 reports to the end customer. The Accedian EMS collects data and monitors Accedian device-enabled Carrier Ethernet network. The Accedian EMS is a potential source of data for the SLA data. Accedian EMS provides both SQL and XML based interfaces to the data. Accedian EMS as a data source was not an extensible solution, since it will only gather data from Accedian devices and if in the future other devices are introduced it will need integration between the different EMSs.

FairPoint Communications

Page 6

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition

4.2

Wholesale system (VFO from Synchronoss)

VFO (Virtual Front Office) is used by wholesale customers for ordering and trouble ticket management. VFO will be used by the Carrier ethernet customers to place orders and manage trouble tickets. This system does have the capability to fulfill the ordering and expedited ordering needs of the customer contracts driving this initiative. It also provides trouble ticketing access. 4.3 Trouble Ticketing

Remedy is used to manage trouble tickets. eBonding provides an electronic interface functionality to customers to manage trouble tickets through their own systems. Presently VZW is eBonded with FairPoint. There are longer term plans to eBond with ATT. VFO also provides trouble ticket management via a GUI. Users can create, update, view status of trouble tickets. 4.4 Monitoring and Reporting

Netcool/ Proviso is used to monitor and gather data from Accedian devices used by the NOC and DSC teams. Netcool also provides reports for the internal team. The structure of SLA metrics data stored in Netcool/Proviso was analyzed and it was concluded that Netcool/Proviso will need further development on top of the existing data structure to gather data from Accedian at a circuit level. Netcool/Proviso was chosen as the data source for SLA metrics data since it will provide the extensibility to the solution and make the solution independent of the network devices being used to provide the Carrier ethernet service. 4.5 Customer Order information and Circuit Information (M6)

The M6 provisioning system was reviewed for its data on both the carrier ethernet circuit identifiers and service firm order commitment and service delivery dates. Based on conversations with Brian Hardy and the M6 team, the system does have details on the circuit identifiers, the mapping of circuits to customers as well as details of the firm order commitment and service delivery dates required by the service assurance portal. The service assurance portal requires these pieces of information in order to relate customers to particular ethernet virtual circuits as well as report on On-Time Performance. During the design period, requested details on the data structures were not be provided. The service assurance portal design will have to make assumptions about the available data.

FairPoint Communications

Page 7

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition 4.6 Solution Matrix

4.7

Proposed Solution

FairPoint Communications

Page 8

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition Based upon the system analysis and the Solution matrix developed, the proposed solution for Service Assurance portal will include the following Configure reports to view SLA and metric information o Use of existing reporting package to reduce the level of effort (OBIEE) o Dashboard view of SLAs Link users to Out of the box functionality from VFO o UI level integration with VFO Extend Netcool/Proviso to collect data from Accedian EMS system and relate circuit information to customers with data from M6 Implement SLA notification alerts and scheduled reporting Implement user and account access control Implement missing functionality o Aggregation of time to repair and MTTR data from Remedy o Aggregation of the service delivery data from M6

5.

System Context Diagram

The System context diagram provides an overview of the relationship of the various systems that are part of the solution. The intent of the diagram is to communicate the areas of scope, the data elements that the architectural definition must touch upon to full encompass the solution. This diagram provides the flow of data from source to the presentation and the various data elements involved during that life cycle.

Figure 5-1 System Context Diagram

FairPoint Communications

Page 9

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition 5.1 Source Systems

This section describes the various systems that will be used to collect data. These systems will provide data to the Service Assurance portal. Data from these systems might be used as-is or processed to make it conform to the final data structure. 5.1.1 Netcool/Proviso The main function of the Service assurance portal is to provide assurance to FairPoints clients using Carrier Ethernet service. Netcool/Proviso will be used to provide the SLA metrics data to be displayed to the end users through the portal. Netcool/Proviso will collect data from Accedian devices and aggregate them at a circuit level. Data will be available in Netcool/Proviso at a 5min interval period. 5.1.2 Remedy Trouble Ticket Remedy is used as the Trouble ticket management system in FairPoint. Service assurance portal should provide logged in customers, to view details and status about their service trouble tickets online and Time to Repair (TTR) reports for trouble tickets will be provided using information from Remedy. 5.1.3 M6 (MetaSolv) M6 is the provisioning system for Carrier ethernet services. Service assurance portal needs to provide reports based on the Firm Order Commitment (FOC) date and the SLAs based on it. This date will be sourced from M6, and relevant reports will be generated. M6 will also be the source for customer to circuit relationship information. 5.2 VFO

VFO is FairPoints Wholesale Gateway which allows wholesale customers to submit orders and trouble tickets. It also provides a status of the orders and trouble tickets to customers. All ordering and trouble ticket management requirements will be fulfilled by functionality provided by VFO. Single Sign-on with VFO is possible, for the phase 1 of this project; it will implemented during a later phase. Users will have to log into VFO to access ordering and trouble ticket management. Verizon is eBonded with FairPoint systems, hence ordering and trouble ticket management can be performed using the electronic eBonding interface already in place. 5.3 Data

This section describes the various data elements that will form the database for service assurance portal to report on. These are data elements, the actual data structure of these elements will be designed during detailed design phase. 5.3.1 Network Performance and Availability These data elements are representing the SLAs that the reports will be based upon. These elements can be broadly classified into the following categories, Latency, Jitter, Packet Loss/ Frame Loss, Availability. The primary source of this data will be Accedian. In addition to the network performance and availability related data, some master data like the SLA thresholds, equipment information will be sourced from Accedian.

FairPoint Communications

Page 10

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition 5.3.2 Customer Information Service Assurance portal reports need to have relevant customer information. This information will be primarily sourced from M6. In addition to customers contact information, data related to unique circuit attributes such as site addresses, locations etc will also be sourced from M6. The relationship between customer and circuits will also be gathered from M6. 5.3.3 Trouble Ticket Information All trouble ticket related information, like description, status etc will be sourced from the Remedy System. This will be needed to provide a view to the customer into the latest status of their remedy tickets through Service Assurance portal. 5.3.4 Cross Reference With common information like customer related data, circuit related data, service order data and trouble ticket information being sourced for service assurance portal; this set of data elements will primarily provide the link between records from different systems. 5.4 Single Sign-On

Oracle Access Manager (OAM) is used to provide authentication service for the portal. 5.5 Presentation

This section describes the various elements that will form the presentation tier for service assurance portal. 5.5.1 Processes These are ancillary modules that complete the desired service assurance portal functionality. Scheduling will be used to run and deliver reports via email as per the customers convenience. Notification service will be used to provide messages to customers for lapsed SLAs upon receipt of alert from monitoring systems. 5.5.2 Reports These consist of all the reports that customers will use to confirm the service assurance for Carrier Ethernet product. These reports will be based on various SLA parameters identified like latency, jitter, frame/ packet loss, availability and time to repair. These reports will be available in various formats (pdf, excel, csv) and will be in printer friendly format. In addition to tabular representation, these reports will also provide graphs and charts for a pleasing visual experience to the customers.

6.
6.1

Solution Architecture
As-Is

There is no existing solution in place to support the business functionality being planned. This is new business system. However, the application will integrate with some existing applications with these integrations called out below.

FairPoint Communications

Page 11

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition 6.2 To-Be

6.2.1 To-Be Functional Architecture

Figure 5-1 Functional Architecture Diagram 6.2.1.1 Service Assurance Web Application

This is primarily the web application being accessed by the end customers of Carrier Ethernet service. The main responsibilities of this application will be to display reports for SLA metrics, trouble tickets, charts and graphs, account information and provide alerts to users. The detailed technical architecture of this application is described the section xx.xx. Most of the functionality required to fulfill contractual requirements from carrier ethernet customers will be provided by this application. 6.2.1.2 Service Assurance Engine

The Service Assurance engine is a module that will be the processing engine of the portal. The engine will be tasked with interfacing with multiple data sources, using multiple interfacing technologies, aggregating the data into a format that can be presented on the web application using simple views. The engine will also subscribe to system alerts and send email notifications when alerts are reported. This engine will work as the gateway to the custom datastore for all other systems. 6.2.1.3 Custom DataStore

This custom designed schema will contain tables designed specifically to provide functionalities such as alerts, scheduled reports, aggregations, mapping of customers in different systems and mapping them to equipment being used for reporting SLAs. This will FairPoint Communications Page 12 Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition be an Oracle 10G database, and will primarily contain user preference related data along with any metrics that needs to be aggregated to present as dashboards. 6.3 Solution Design Goals

The following solution design goals were considered with this architecture. 6.3.1 Keep it simple Dont over complicate the system for the purpose of adding technology. Rather utilize frameworks and software already developed. 6.3.2 Ensure Extensibility for Future The likelihood of using non-Accedian network equipment to provide Carrier ethernet service is high; hence the system should be extensible to provide SLA reporting from multiple device vendors. The solution should ensure a device independent design. 6.4 Design Constraints

6.4.1 Fixed Timeline This project is scheduled for release during the March 2011 cycle. Because of this, some aspects of the design may need to be pared down and not as extensible to support any and all configurations. With this consideration - the foundational architecture needs to be modular and extensible enough to support equipment from new vendors. 6.4.2 Impacts to Existing Systems As part of the design, the amount of impact and change to existing systems needs to be considered as part of the trade off on any approach to integrate. The less impact to the existing systems still accomplishing the same outcome is desired. 6.5 Known Design Assumptions Netcool/Proviso will be the source system for all SLA metrics related data JDBC access will be provided to views exposed by Netcool/Proviso Remedy will provide a batch file feed for trouble ticket information M6 will provide a batch file feed for Customer and Circuit related information

6.6

Design Risks

6.6.1 Netcool/Proviso Integration Provisos ability to collect SLA metrics data at a device level is known, but the functionality to collect data from Accedian EMS and at a circuit level will need to be constructed. Design assumption has been made that the data provided by Proviso will be of similar quality as Accedian EMS, at a 5min interval and aggregated at each circuit (EVC) level.

7.

Enterprise Application Impacts

FairPoint Communications

Page 13

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition 7.1 Netcool/Proviso

7.1.1 Provide Metrics data for reporting There will need to be some enhancements done for Proviso to provide SLA metrics data for reporting from the Accedian network devices. This data will need to be available at a 5min interval and has to be aggregated at a circuit level. 7.1.2 Provide Alerts for notification Proviso will have to raise alerts for SLA lapsed for Carrier Ethernet products. These alerts will need to be placed on a queue for the notification engine to pick up and send out the relevant notifications. Proviso will also need to provide alerts when these SLA lapses have been resolved, so that an appropriate message is sent back to the customer. 7.2 M6 (MetaSolv)

7.2.1 Provide Service Order data for reporting M6 will provide a nightly batch file feed containing the orders placed by customers for Carrier Ethernet service. Reports will be generated based upon the FOC (Firm Order Commitment) date and the actual go-live date for the orders being placed. 7.2.2 Provide Circuit Information M6 will need to include details on the ethernet virtual circuits that exist on the FairPoint network. With this information, the related customer to each ethernet virtual circuit needs to be provided. 7.3 Remedy

7.3.1 Provide Trouble Ticket data for reporting Remedy will provide a nightly batch file feed containing trouble tickets status for the past 60 days against carrier ethernet service. This file will also contain the TTR (time to repair) for each trouble ticket. Reports will be generated based upon TTR and MTTR will be calculated accordingly for customer display.

7.4

Oracle SSO

7.4.1 Login Access The configuration of Oracle will need to be updated to include Service Assurance application resources as part of access control.

FairPoint Communications

Page 14

Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition

8.
8.1

Integration Design
Integration Overview

Reference: FP_ServiceAssurance_InterfaceDesign.doc <<fairshare link>> 8.2 Integration Details

Reference: FP_ServiceAssurance_InterfaceDesign.doc <<fairshare link>>

9.

Physical Architecture

<<to be completed>>

10.

Service Assurance Design by Use Case

<<to be completed>> 10.1 Circuit and Customer Knowledge

Design Decisions - The system will need Assumptions 10.2 10.3 10.4 Alerting Reporting User Management

Design Decisions - Each user in the system will need to be directly mapped to a customer identifier. - Each user in the system will currently be mapped to the following roles: o Account Administrator Access to all EVCs for that customer. Able to create new users and control access to EVCs per user. Able to indicate whether a user can see the dashboards with SLA data or not. o Regular User with SLA Access Able to see the EVCs assigned to them. Also able to see dashboards and reports with SLA lapse / warning data. o Regular User with No SLA Access Able to see the EVCs assigned to them. Not able to see dashboards and reports with SLA lapse / warning data. Only able to see detailed values on specific EVCs and time periods. o Regular User with access to all SLAs and EVCs Able to see all the EVCs assigned to the customer as well as SLA information. o Regular User with access to all EVCs with No SLA Access Able to see all the EVCS assigned to the customer but not the SLA lapse or warning data. FairPoint Communications Page 15 Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition Account Administrators will be able to see all EVCs assigned to a particular customer. All modifications to user account information shall be made in real time

Assumptions Open Questions - Should we consider synchronizing with Fairpoint Customer Wholesale Portal for usernames, domains and passwords?

11.
11.1

Software Stack Overview

Development Tools
Software Version Purpose

During the course of development the following tools will be used.

System

12.
S.NO TBD1

Open Questions
Revise Date 10/20/2010 Description Domain name for Service assurance portal needs to be finalized Resolution Status Open Owner Fahad B.

13.
13.1

APPENDIX
Technical and Implementation Standards

13.1.1 Java Coding Standards All coding will follow the standards as defined by FairPoint and where lacking any detail, as further set forth by Sun in the Java Code Conventions document. http://java.sun.com/docs/codeconv/CodeConventions.pdf 13.1.2 Design Considerations All class implementations will utilize an interface driven design approach or class convention design. The benefit of interface drive design allows for separation of the implementation from the interface. This allows an implementation to be swapped with another implementation as needed. In practice, it is rare that in an operating system there is the need to swap out 90% of the classes implemented. Rather the interface design approach allows for swapping out the implementation during unit testing and separating out the testing of different layers from one another. FairPoint Communications Page 16 Architecture Definition 12/3/2010

Service Assurance Initiative Architecture Definition

The use of class convention design comes more into play when using frameworks that can inspect a class and translate object details into the function calls of the convention class.

FairPoint Communications

Page 17

Architecture Definition 12/3/2010