• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Soa Oct 1 2009
 

Soa Oct 1 2009

on

  • 794 views

 

Statistics

Views

Total Views
794
Views on SlideShare
790
Embed Views
4

Actions

Likes
1
Downloads
0
Comments
1

2 Embeds 4

http://www.slideshare.net 3
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • A SOA service can be described as a way of packaging reusable software building blocks to provide functionality to users and to other services. A service is an independent self-sufficient functional unit of work that is discoverable, manageable, measurable, has the ability to be versioned, and offers functionality that is required by a set of users or consumers. A logical definition of a SOA service consists of three components: a Contract, its Interface and the Implementation.

Soa Oct 1 2009 Soa Oct 1 2009 Presentation Transcript

  • Core Network
    &
    Enterprise
    Nexus
    1
    Jack E. Brown
    9/29/2009
    SOA Reference Architecture
  • 9/29/2009
    Jack E. Brown
    2
    Cable Architecture Overview
    Headend
    Hub
    Internet
    gateway
    Core
    Router
    Xport
    HFC
    GR303
    gateway
    Xconnect
    Xport
    Hybrid Ckt/ VoIP
    D
    A
    T
    A
    Router
    GigE
    switch
    C
    O
    M
    B
    I
    N
    E
    R
    /
    S
    P
    L
    I
    T
    T
    E
    r
    Data, VoIP,
    Multimedia
    CMTS
    Servers
    Firewalls
    Analog satellite
    Native data,
    Analog video,
    Digital video
    Synchronous TDM
    CMTS
    rcvr
    analog
    mod
    Downstream
    Fiber
    Analog off-air
    ASI
    demod
    analog
    mod
    Coax
    QAM
    Fiber
    Node
    GigE
    Xport
    Local
    pgms
    analog
    mod
    Digital HDTV
    satellite
    Upstream
    Fiber
    V
    I
    D
    E
    O
    Local
    VOD Servers
    B
    R
    O
    A
    D
    C
    A
    S
    T
    Internet
    rcvr
    MPEG
    mux
    2-way
    Amps
    DWDM
    SONET/SDH
    ATM
    GigE
    RPR
    DVB-ASI
    DVT
    demod
    Digital HDTV
    off-air
    Tap
    WEB cache
    servers
    Local
    pgms
    Drop
    Broadcast Video
    Appliances
    • MTA (PacketCable)
    • NIU (Ckt Telephony)
    • Cable Modem (high speed data)
    • Set-top-box (video)
    O
    N
    D
    E
    M
    A
    N
    D
    V
    I
    D
    E
    O
    GigE
    switch
    HDT
    Xconnect
    VOD Servers
    PacketCable
    Ckt voice
    Xport
    Xport
    Router
    V
    o
    I
    P
    Signal
    gateway
    &
    V
    O
    I
    C
    E
    Broadband Multimedia
    CMS
    Media
    Gateway
    Xport
    OSSs*
    Application Servers
    Xconnect
    OSSs*
    • IP address mgmt
    • IP provisioning
    • DNS
    • DHCP
    • TOD
    • Billing
    Ckt
    Switch
    PSTN
    Circuit
  • 9/29/2009
    Jack E. Brown
    3
    PacketCable 1.5 Architecture Framework
  • 9/29/2009
    Jack E. Brown
    4
    PacketCable 2.0 Reference Architecture
  • 9/29/2009
    Jack E. Brown
    5
    Core PacketCable 2.0 Architecture
  • 9/29/2009
    Jack E. Brown
    6
    Cellular Integration
  • 9/29/2009
    Jack E. Brown
    7
    PacketCable MultiMedia and Converged Services
    3RD PARTY
    SERVICES
    PCP Web Portal
    SCP
    PARLAY
    Telephony Application Manager
    Supplemental Telephony Servers
    Non-Telephony Application Servers
    APPLICATION
    LAYER
    APPLICATION
    LAYER
    OSA-GW
    IM-SSF
    HSS
    (USER PROFILE)
    SIP
    Managed IP Network
    Service Broker
    ENUM
    CSCF
    SESSION
    CONTROL
    LAYER
    COPS or DAIMETER
    SIP
    Session / Border Controller
    BGCF
    PCMM Policy Server
    MGCF
    MRFC
    SG
    SIP
    SIP
    COPS
    CMTS
    DOCSIS Protocols
    (NCS/SIP)
    Media Server
    MG
    HFC Access
    Network
    Mobile
    Gateway
    ENDPOINT
    AND MEDIA GW
    LAYER
    MSO Relationship:
    Wireless Provider
    sMTA
    or
    eMTA
    Legacy Fixed and Mobile
    Networks
    Mobile Access Network
    802.11 AP
  • 9/29/2009
    Jack E. Brown
    8
    OpenCable
    The OpenCableproject is a concerted effort by cable operators to:
    • Create a common platform for interactive services, programming, and advertising on retail and cable devices;
    • Define next-generation interactive digital cable-ready retail devices (e.g., televisions, set-top boxes, DVRs);
    • Support home networking for cable content and services;
    Encourage supplier competition and innovation.
    • The OpenCable specifications describe an interactive digital cable platform comprising: Baseline core functional requirements for digital cable ready “host” devices;
    • A “middleware” comprising a set of common application programming interfaces (APIs);
    • The hardware interface between the host device and a removable security module (the “CableCARD™”);
    • Copy protection and security requirements; and
    • Optional extensions for host devices, including Home Networking, and DVR.
  • 9/29/2009
    Jack E. Brown
    9
    OpenCable
    Services and ApplicationsOpenCable Platform services may include:
    • Electronic program guides (EPGs);
    • Video-on-demand (VOD);
    • Interactive personal video recorders (DVR);
    • Interactive sports and game shows;
    • Impulse pay-per-view (IPPV);
    • Communications utilities such as e-mail, chat, and instant messaging;
    • Caller ID presented on the TV;
    • Interactive games; and
    • Interactive services such as voting and polling within a television show, shopping (television commerce, or “T-Commerce”), and home banking.
  • 9/29/2009
    Jack E. Brown
    10
    OpenCable
    Target Market
    • Content Developers: TV writers, directors and producers; ITV application developers; production houses; graphic designers.
    • Copyright holders: Studios; producers; programmers sports leagues; music labels; video game companies.
    • TV Networks: Cable services and broadcast networks.
    • Advertisers: Advertisers, agencies and marketers.
    • Cable Operators: MSOs and local cable systems.
    • Device makers & retailers: Digital TVs; HDTVs; DVRs; set-top boxes; portable TV players; mobile phones.
    • Consumers.
  • 9/29/2009
    Jack E. Brown
    11
  • Traffic
    Provisioning
    Billing
    Policy
    Broker
    BPM
    Service
    Registry
    Security
    Data
    VNO
    B2B - Enterprise
    Aggregator
    Billing
    Data
    Provisioning
    Orchestrated Applications
    Traffic
    Traffic
    Traffic
    Traffic
    Traffic
    Traffic
    Traffic
    Data
    Provisioning
    Data
    Provisioning
    Data
    Provisioning
    Data
    Provisioning
    Data
    Provisioning
    Data
    Provisioning
    Data
    Provisioning
    Billing
    Billing
    Billing
    Billing
    Billing
    Billing
    Billing
    Example High LevelSOA Reference Architecture
    Liberty
    Alliance
    Federation
    Service Bus
    WS
    IMS – Pkt
    Cable &
    Enablers
    3rd Party
    Apps
    Legacy
    Apps
    IMS-Pkt
    Cable
    Apps
    IN
    Apps
    Legacy
    Network
    Elements
    Wireline
    Wireless
    Jack E. Brown
    9/29/2009
    12
  • 9/29/2009
    Jack E. Brown
    13
    Definition of a “SOA Service”
    Service Definition
    Policy Engine
    SLA
    O/L
    Control
    Access
    Rights
    ResourceSharing
    Content
    Filtering
    • Service Contract
    • The service contract specifies the “rules of engagement”, i.e. the purpose, functionality, constraints and usage of a service
    • Service Interface
    • A Service interface provides an explicit means for the consumers of a service to access its functionality according to the contract it offers
    • Service Implementation
    • The implementation is the actual functionality produced by the service
    Parlay X
    Extended WS
    MutliParty Call Control WS
    Messaging WS
    PX MM Conference
    PX Audio Call
    PX Call Handling
    PX Term. Stat. Location
    PX Payment & Accnt Mgt.
    PX SMS & MMS
    PX Addr List Mngt.
    PX Presence
    Charging WS
    PX 3PCC & NICC
    Parlay Web Services Template
    Network Enablers
    Gateways
    Call Servers
    IVR
    Charging Gateway
    Media
    Servers
    BEA Confidential |13
  • 14
    Jack E. Brown
    9/29/2009
    Application Infrastructure
    • Application Development
    • Service Enablement
    • Execution Environment
    • Reliability
    Service Infrastructure
    • Composite Application Framework
    • Business Service Orchestration
    • Cross-platform management
    • Governance and control
    • Service discovery, publishing and security
    • Message routing and transformation
    • Resource allocation
    Application Infrastructure vs. Service Infrastructure
    Sharing Across Multiple Organizations
  • 15
    Jack E. Brown
    9/29/2009
    App2
    App 1
    Legacy
    App 1
    CSCF
    MMSC
    SMSC
    CDF
    Blended Services Approach
    • IMS – Pkt Cable/ VoIP/Circuit-Switched
    • IMS & Pkt Cable 2.0 is an access-agnostic standardized layered infrastructure which enables rapid deployment of new IP-based services across all networks, while maintaining a common policy management for service access
    • Service Oriented Architecture (SOA)
    • SOA is a technology strategy that organizes the discrete functions contained in internal or third-party applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs.
    • Blended Services
    • A federated services framework that leverages SOA across new and existing networks to dynamically deliver composite services across a heterogeneous IT and core network service application ecosystem
    Composite App
    Composite App
    Legacy
    App 2
    SOA
    Network Service Exposure
    Orchestration
    Facilities
    Northbound
    Resource Mgmt
    Manager
    Network I/f
    Southbound
    Policy Mgmt
    IVR
    MRF
    BMF
    IMS-Pkt Cable Core
    Existing Network Svcs
    Circuit Switch
    BEA Confidential |15
  • Layered SOA Reference Architecture Logical View
    16
    Jack E. Brown
    9/29/2009
    SOA reference architecture should account for processes, capabilities, services, data
    access, and network access
  • 9/29/2009
    Jack E. Brown
    17
    Layered SOA Reference Architecture Logical View
    Composite business services are typically created using high-level programming interfaces like workflow, business process management tools, and portal technology. These high-level programming techniques consist principally of configuration, and they are metadata driven.
    Presentation Services provide separation between the way content is transported and the way it is formatted for delivery to the user. In a SOA environment, content will generally be transported as XML. The content may be delivered in many different formats, depending on the device being used end user. These formats may include HTML, WML, cHTML, and others, with the capabilities of specific devices further complicating the ways that the content should be formatted. Presentation services may also entail personalization of content for specific users as well as for their devices.
    Architecturally, the shared business services layer begins the representation of two key paradigms, consolidation and rationalization. Consolidation refers to the ability to reduce or eliminate business functionality that is duplicated partly or wholly in different parts of an enterprise. Rationalization refers to the standardization of business functionality.
  • 9/29/2009
    Jack E. Brown
    18
    Layered SOA Reference Architecture Logical View
    The Data and Access Services layer will provide means to expose data from a diversity of software suites, custom applications, and data sources deployed throughout. In general most Service Providers, have embraced a long list of retrieval strategies such as Extract, Transform, and Load (ETL), message-oriented middleware (MOM), Object brokers, data integration, .NET, SOAP, etc. The intent of Data and Access services layer is to integrate these different access strategies into a single access technology
    The Network Access Services Layer offers features that guarantee the security, stability, and performance required by network carriers and demanded by subscribers. In other words it provides an abstracted network service development platform that hosts network based services that can be connected to the SOA, via the service bus, while providing connectivity into network related systems for telephony applications
  • 9/29/2009
    Jack E. Brown
    19
    DATA AND ACCESS SERVICES LAYER
  • 9/29/2009
    Jack E. Brown
    20
    Network Access Services Layer connecting
    the telecommunications network architectures to the SOA environment
  • 9/29/2009
    Jack E. Brown
    21
    HSS
    Packet
    CSCF
    Rating Engine
    Legacy
    SSP
    SMSC
    MMSC
    Policy
    Broker
    BPM
    Service
    Registry
    Security
    Content
    Mgmt
    OTAA/P
    Device
    Mgmt
    Client
    Mgmt
    ISC / SIP
    ISC / SIP
    LDAP/SQL
    TL1 / MML
    TL1 / MML
    CAP
    CAP
    AIN
    AIN
    LDAP
    XML
    XML
    Billing
    Billing
    External
    Gateway
    And other
    XoIP functions
    Reference Architecture – A Bit More Detailed
    xxxx
    Wlireline
    IN APPs
    Enterprise
    APPS
    IMS –OCAP
    Pkt Cable
    APPs
    Orchestrated
    Apps
    Billing
    ANSI-41
    LDAP/SQL
    Web Services
    Prepaid (CAP)
    Diameter Rf/Ro
    BAF AMATPS
    Web Services
    Web Services
    Web Services
    Sh
    Data Federation
    BILLING
    SCIM / IMSSF
    PROVISIONING
    WS
    WS
    Traffic
    Data
    ANSI-41
    Prepaid (CAP)
    Billing
    Diameter Rf/Ro
    BAF AMATPS
    LDAP
    Provisioning
    Sh
    HLR
    MPC
    Network 1
    Network 2
    Network 3
  • 22
    Jack E. Brown
    9/29/2009
    Federated ESB Deployment
  • 9/29/2009
    Jack E. Brown
    23
    Service Provider Perspective -- What is SDP?
    At the highest level, the Service Delivery Platform (SDP) is a set of enabling capabilities that allow new services to be rapidly and efficiently plugged into the carrier infrastructure.
    • SDP sits between the carrier’s network / IT infrastructure and the end user applications.
    • SDP exposes the capabilities of the IT and Network infrastructure to applications in a standard way.
    • SDP is not: a network element, an individual platform, an OSS/BSS solution, an access technology, or a competitor to IMS
    While some industry SDP implementations are IMS specific, SDP is broader than IMS. SDP allows applications to utilize capabilities of IMS (e.g. session setup), non IMS (e.g. get location), and IT (e.g. send a billing event) infrastructure.
  • 9/29/2009
    Jack E. Brown
    24
    Service Provider Perspective -- The SDP Concept
    The Service Delivery Platform Concept Is A Fundamental And Far-reaching One
    An SDP mediates between the network and the converged applications and services that leverage it
    • It is an exposure, integration, and execution framework
    • facilitates the connection of high-level services with core network functions in a reusable way
    • Consistently manages the execution of these services
    • Maximizes the access investment by provides an access-agnostic integration substrate for IP and non-IP services
    An SDP enables developers and content providers
    • It includes service creation tools to easily and efficiently create new services
    • It includes orchestration, brokering, and composition services to allow efficient recombination of existing Network and application capabilities into new, more flexible services
    An SDP puts additional structure on the service layer itself
    • It breaks the service layer into logical tiers
    • It partitions key capabilities, such as user identity, into these tiers and puts defined interfaces on them
    • It interfaces to OSS/BSS
    • It supports flexible workflow engines for new service development, and potentially also for provisioning, ordering, billing, and care
    • It can offer a tighter mapping onto device capabilities
    Publicly-exposed APIs
    Partner applications
    Third-party Web Services
    VoD
    Switched Video
    Music Downloads
    Applications & Services tier
    Well-defined, flexible, and reusable enabling infrastructure
    Service composition, orchestration, policy, routing, user profiling, identity, common data models, content management, and well-defined services interactions
    OSS/BSS
    Enabling function tier
    Subscriber Data
    Location
    Messaging
    Presence
    Core Network (IP, non-IP)
    Core network & enterprise capabilities
    Enterprise Network (IT)
    SMSC
    MMSC
    MSC
    EAI
    UBP
    Amdocs
  • 9/29/2009
    Jack E. Brown
    25
    An Example SDP Logical Framework View
    SDP Logical Framework composed of 3 key planes: Services Layer, Exposure Layer, Service Life Cycle
    • Exposure layerprovides a secure and managed access to the services by managing and enforcing 3rd party SLAs; it packages the underlying services for external consumption.
    • Service layerprovides an abstraction of network and IT capabilities using SOA principles in order to facilitate re-use and composition; it also provides a flexible execution environment to support multiple service delivery models.
    • Service Life Cycle Mgmtprovides an overarching end-to-end management of the various phases of the service. It refers to the governance and the business processes that drive the work flow management within the services layers
    • Network & IT Layer provides the actual underlying physical infrastructure.
    SDP
    Framework
    SOA dictates peering across services not layers
    25
    Restricted – Proprietary – Internal Use Only
  • 9/29/2009
    Jack E. Brown
    26
    Logical Framework – a more detailed view in 2D
  • A service is defined as an autonomous, self-contained logic that exposes a well defined interface that facilitates re-use and composition AND common communication infrastructure
    • This is different from end-user service; End User’s generally think about Caller ID, Conferencing, Voicemail, Family Tracking etc
    Rationale for decomposition
    Decomposed services
    • Helps in definition of service contracts
    • Helps in understanding impacts of business logic on service definitions for short-term and long-term
    • Allows evaluation of platforms and integration points
    • Allows evaluation of scalability, reliability requirements
    • Facilitates in distributing services across platforms to deliver optimal performance
    • Forms basis for composing coarse grained services
    • Allows a focused demarcation of the services with the organizational boundaries
    • Helps in focusing on the latency requirements of services. From Low latency (Network) to increasing response times (Business)
    • Network Services are network capabilities abstracted in form of repeatable logic, reusable by a wide spectrum of internal & external applications. For e.g. call control, sendSMS, etc.
    • Application Services are application logic abstracted in form of services, reusable by a wide spectrum of internal and external applications, in order to compose integrated applications. For example, conferencing, presence, group mgmt, etc.
    • Common Services provide service control and leverages capabilities across both IT and network domains. For example, policy mgmt, pre-paid charging, data access, etc.
    • Business Services implement the business processes (and functions) to enable a rapid service creation, deployment and monitoring environment.
    Segment Specific Apps
    Content Services includes specific services that facilitate life cycle management of content.
    Composite Services & Apps
    Composite & Segment specific servicesare composed using foundational network, application, common and business services (For e.g. – Messaging service that abstracts different messaging types to the 3rd parties, SMS, MMS, etc.)
    Business Services
    Content Services
    App Services
    Network Services
    Common Services
    Jack E. Brown
    9/29/2009
    27
    27
  • 9/29/2009
    Jack E. Brown
    28
    Service Creation is one of the key enabler for addressing time to market drivers and developer ecosystem
    • In order for 3rd party developers to create applications, three main artifacts are required:
    • Service Specification (Exposure)
    • Provide service API’s
    • WSDL,
    • Parlay X,
    • Web Services, etc.
    • Make available IDE’s, Simulation tools, device emulators
    • Service Catalogs (SLA based exposure of services)
    • Service Specifications and Documentation
    • Exposure mechanisms should be independent of any specific toolsets
    • Service Creation Tools (Environment):
    • Software development tools that use Graphical User Interfaces for creating, developing and testing telecommunication service applications, minimizing time to market for new services.
    • Support open source tool sets that developers can use to create services e.g. Eclipse, NetBeans, .NET, Ruby On Rails, IBM’s Websphere Rational® (BMF), etc
    • Service Testing
    • Provides an environment for Application Testing
    • Simulation tools, device emulators
    • Incubation Environment for product trials & testing.
    • Not all applications would require incubation testing or simulation tools
    Service Specification
    (Exposure)
    Service Creation
    Environment
    Service Testing
    (Execution / Simulation)
    Service Certification &
    Deployment
    Legend
    3P Environment
    Service Provider
  • 9/29/2009
    Jack E. Brown
    29
    SLA Mgmt.
    Location
    Movies
    Charging
    Performance
    Presence/Avail.
    Music
    BI
    Fault Monitoring
    Messaging
    Images
    Usage Mgmt.
    Other
    Other
    Other
    Other
    Services Mash-ups
    Services Testing & Certification
    End-User Services
    Consumer Services
    Business Services
    Access Management
    Policy Management
    Service Catalogue
    Service & Application Management
    Service Reporting
    Partner Management
    SOA Management
    Design-Time Governance
    Run-Time Governance
    Lifecycle Governance
    SOA Governance
    SOA Repository & Business Service Registry, Governance Interoperability Framework (GIF)
    Service Orchestration
    Service Adaptors
    Content Adaptors
    BSS Adaptors
    OSS Adaptors
    SOA Enablement
    Network Gateways
    Network & IT Service Elements
  • 30
    Service Delivery Platform (SDP)
    Services Mash-ups
    Services Testing & Certification
    Consumer Services
    Business Services
    A standards based architectural blueprint for development, deployment, integration and management of converged services
    User Equipment Plane
    Application Plane
    Service Delivery Plane
    Content Management & Delivery
    User Interaction & Presentation
    SDP Governance
    SDP Management
    Platform Support Functions
    Service Orchestration
    Subscriber Data Brokering
    Content
    IT Service Enablers
    Network Service Enablers
    Business Support Systems (BSS)
    Operation Support Systems (OSS)
    SIP
    OSA-Parlay
    SS7
    Web Services Access Gateway
    Other
    Service Control Plane
    IMS Network
    Cable Network
    Legacy Network
    Network Backbone
    Circuit Backbone
    IP Backbone
    Real-Time IP Backbone
    Jack E. Brown
    9/29/2009
    1 October 2009
    30
  • 9/29/2009
    Jack E. Brown
    31
    TM Forum NGOSS Framework
    31
  • 9/29/2009
    Jack E. Brown
    32
    Operations Level 2 Processes
    The above figure is shown with Level 2 processes visible. Note, in general, a Level 2 process is part of a vertical, and also a horizontal, Level 1 process. Hence level 2 processes can be reached in the process hierarchy by either path. However, whichever path is uses, a Level 2 process is “stretched” across several vertical levels. This is because the process concerned is need in several vertical levels
    32
  • 9/29/2009
    Jack E. Brown
    33
    ITU-IETF Business Architecture
  • 9/29/2009
    Jack E. Brown
    34
    Integration Framework
    When it comes to integration of a set of OSS products, where almost every
    component has to interact in several ways with most of the others, the number of point-to-point integration modules will become too many. And when including the often significant number of legacy applications in operation at a Network Operator the situation gets even worse. In the figure below a common type of OSS system map is visualized:
    A typical set of point-to-point integrations
    34
  • 9/29/2009
    Jack E. Brown
    35
    Integration Framework
    Due to the “mess” introduced by the large number of point-to-point integrations the concept of a message bus supporting the exchange of messages between components attaching to the bus was introduced. This significantly reduces the number of integrations, since the component only integrates with the bus itself (figure below):
    The message bus concept
    35
  • 9/29/2009
    Jack E. Brown
    36
    Integration Framework
    NGOSS and OSS/J
    NGOSS and OSS/J lay the foundation for OSS middleware components market by defining industry architecture and interfaces. TeleManagement Forum’s eTOM® model provides the processes outline for OSS/BSS systems. The model is widely deployed in the industry. J2EE, XML and Web Services are the main technologies suggested for use with OSS/J.
    Technology Choices.
  • 9/29/2009
    Jack E. Brown
    37
    OSS/J Architecture and APIs
    Functional API status in different verticals
    The above figure provides an overview of the OSS/J roadmap of APIs as defined through their corresponding JSRs and within a Fulfillment, Assurance and Billing context. It describes the current scope of work as well as the future one according to the color legend. The APIs highlighted in green have either had their corresponding JSR approved with final release, or are in maintenance mode.
    The APIs highlighted in yellow have their corresponding JSR approved by the Java Community and their specification as well as reference implementation and TCK are being developed through the Java Community Processes.
    37
  • 9/29/2009
    Jack E. Brown
    38
    OSS through Java™ list of core APIs
  • 9/29/2009
    Jack E. Brown
    39
    JSR-264, the Order Management API.
  • 9/29/2009
    Jack E. Brown
    40
    Integration Framework
    Example of a WEB Services Infrastructure Illustrating Service Provisioning
    Using A Business Process Engine
    40
  • An SOA Reference Architecture Should
    • Define the framework for the architecture and design efforts of all projects on the SOA roadmap.
    • Provide traceability from business objectives through architecture to
    implementation.
    • Provide a common vocabulary to communicate overarching SOA
    architecture principles and direction across multiple communities including Enterprise and Network Architecture teams, Domain teams, management, and business groups.
    • Provide the means against which to measure architectural compliance of the work product.
    41
    Jack E. Brown
    9/29/2009
  • An SOA Reference Architecture
    42
    A Reference Architecture may be related to and support the following
    Business Drivers And Objectives:
    • Achieve synergies & integrate Affiliates/Partners.
    • Seamless experience across sales and service touch-points.
    • Take cost out through process simplification.
    • Deliver IT solutions/services to meet business needs.
    • Manage business risk and government compliance.
    • Deliver a simplified and rationalized product portfolio on time.
    Strategic Objectives may be addressed through the implementation of a common set of Business Services that are exposed within the Enterprise and Network domains. In this way, 3rd party application developers and services providers, Affiliates/Partners, sales, and service may all access the same data, network, and business functions through these common
    Services.
    Jack E. Brown
    9/29/2009
  • An SOA Reference Architecture
    43
    • As a result, a consistent view of the customer and a consistent set of operations that may be performed on or for the customer will be presented to all parties.
    • Synergies are achieved through the reduction of redundancy and through increased re-use. With this reduction in redundancy comes agility to move more rapidly in changing environments, since the logic within the services only needs to be changed and tested in one place.
    • Business Service interfaces may also be used to hide the complexity of the back-end systems, workflows, and network capabilities from the 3rd party ecosystem and end user communities.
    Jack E. Brown
    9/29/2009
  • An SOA Reference Architecture
    44
    • When Services are created as coarse-grained interfaces that represent business level transactions, complexity is also reduced for the client applications, since one call to a service may replace many lower level API calls.
    • The complexity of workflows may be addressed through the use of Business Process Modeling and Execution tools that represent tasks at a level that is higher than that of raw code.
    • One of the goals of the Reference Architecture should be to define a flexible, agile SOA that will integrate the network and IT domains and will support rapid development of applications to meet business and customer needs.
    Jack E. Brown
    9/29/2009
  • 45
    An SOA Reference Architecture
    • A rich set of Business Services that are accessible throughout the Enterprise and Network domains using platform-independent technologies and standards will support the rapid assembly of applications with a reduction in the development of custom and redundant code required to do so.
    • By using existing Services, new applications and services will be able to eliminate the testing effort that would otherwise be needed if they had re-implemented those Services within the application.
    • Most applications currently contain some aspects of Security, Auditing, and Compliance internally. As a result, similar functionality is duplicated across many applications, and changes in rules or procedures for this functionality must be cascaded across all this custom code in each application.
    Jack E. Brown
    9/29/2009
  • 46
    An SOA Reference Architecture
    • SOA could introduce centralized Security, Auditing, and Compliance Services that would be implemented and maintained in one place.
    • In some cases, these Services may be called directly by applications. In other cases, these Services may be invoked implicitly as a request passes through an Enterprise Service Bus (ESB). The ESB approach provides ways to integrate these critical functions without introducing code into the applications.
    • A SOA based Reference Architecture can assist with application rationalization efforts. Rather than implementing the rationalization effort in large steps, a Services layer can introduce a level of abstraction to isolate the front end clients from the back end systems where rationalization and refactoring are taking place.
    Jack E. Brown
    9/29/2009
  • 47
    An SOA Reference Architecture
    A Reference Architecture may be related to and support the following
    IT Drivers And Objectives:
    • Keep systems up and running.
    • Deliver timely and accurate bills.
    • Meet business requirements, schedule, and cost.
    • Simplify and improve processes.
    • Mitigate security and compliance risks.
    • Deliver Strategic Business Capability Roadmaps.
    • Deliver Innovation.
    Jack E. Brown
    9/29/2009
  • 48
    An SOA Reference Architecture
    A Reference Architecture may be related to and support the following
    Product Development Drivers And Objectives:
    • Usable and Reliable Products and Services.
    • Deliver Products to Meet Channel Needs on Time.
    • Deliver a Simplified, Rationalized Product Portfolio on Time.
    • Grow Application and Content Usage.
    By exposing existing capabilities as Services, new products may be created by orchestrating the invocation of these existing capabilities to create new functionality.
    Exposure of core capabilities in a way that will facilitate and simplify reuse will greatly simplify the leveraging of existing capabilities. The ability to combine these existing capabilities through the use of orchestration tools without the need to write low-level code to accomplish the sequencing and integration of the capabilities will significantly reduce development time for new services
    Jack E. Brown
    9/29/2009
  • 49
    An SOA Reference Architecture
    A Reference Architecture may be related to and support the following
    Network Drivers And Objectives:
    • Offer Differentiated Products.
    • Meet and Deliver Innovation Commitments.
    • Deliver Targeted Network Performance.
    • Support NGN Integration and Deployment.
    Jack E. Brown
    9/29/2009