Transcript BT Wholesale CIO - CRM B2B Options

Consult21 Systems Work Package
BT Architecture and eBusiness
Derrick Evans
21CN Systems
Overview
• Discussion of Systems Architecture from an external
perspective
– How the architecture behaves externally from a customer/partner
perspective
• Summary of the current situation
• Ideas for the future
• Principles and Issues for Syndicate Discussions
BT’s legacy
credit vetting1
wholesale products
retail products
technical checks1
decomposition1
retail billing1
network1
progress events1
KCI1
Note 1: illustrative functions
• BT’s legacy is built on large integrated national systems
• Designed to maximise customer satisfaction
–
Place as much information as possible in the hands of customer services
–
Support flow through provisioning
Re-engineering
Today’s architecture
credit vetting1
wholesale products
retail billing1
network1
progress
events1
KCI1
CRM Services
decomposition1
Retailers
credit vetting
service
management decompose
retail products
Integration Framework
technical checks1
21C Target
Non-SMP
Service
Management
billing
KCI
SMP Product tech checks
Service
Management network
progress
Note 1: illustrative functions
•
The current architecture creates issues for the introduction of next generation services and new
market structures
•
An approach is to refactor the OSS stack by layering and segmenting the architecture into a set of
applications that provide services or capabilities to each other
•
This is not possible/desirable in a single step so a “leave and layer” approach is required for the
evolution from one stack to the other
“It’s not the components it’s the
interfaces”
Today's integration framework
•
Selected functions from our legacy systems have been exposed for eBusiness integration over
the past fifteen years
•
To achieve this
CRM applications have been built as a layer on CSS and COSMOSS
–
Portal and gateway front ends are a layer on the CRM applications and/or CSS/COSMOSS
Internet HTTPS XML
Internet HTTPS XML
Internet HTTPS XML
Internet HTTPS XML
Internet HTTPS XML
Internet ebXML XML
?
Each has been built to address a product family or market segment and been built using
differing architectures and technologies
ISDN FTP
Fixed Length
•
–
DEDS
(NP,CPS, +)
SPG
(C&A,WLR
Ordering)
FSPG
(LLU SMPF)
Broadband XML
Gateway
(Broadband
Ordering)
LLU MPF XML
Gateway
(LLU MPF)
ECO X API Gateway
(Private Circuits,
PSTN, ISDN)
BEA B2B
(Broadband
Assurance)
Other interfaces –
either Fastrack one
offs or email
(including Ripple)
NPIC
SPG
Automation
CPS
Gateway
Large File Output
Generating
Systems
Via
Hub
Lisa
eCo Broadband
SOS (SDSL)
eCo LLU
eCo X
GTC/WOOSH
GPMS
Manual or Robot
(including Ripple)
Proposed integration framework
•
Messaging used to synchronise
processes (Choreography and
Orchestration)
•
Single messaging platform
(single security regime and
single platform to manage)
•
A version of this technology is
already deployed for broadband
fault reporting and diagnostics
email
(SMTP)
Web services
(http,ftp, SOAP)
binary
The core of this is XML and http
(in the form of SOAP and other
web service technologies)
CSV, Tab
delimited
•
Transport
Management
Partner B2B
Profile
Format
&
Translation
Bt Internal XML
(XSD schema)
A “loosely coupled” messaging
capability based on Internet
technologies
Process
Management
Bt Internal XML
(XSD schema)
•
XML
(SOX schema)
A Gateway to host a variety of
services and functions
XML
(XSD schema)
•
B2B protocols
(ebXML, Resonate)
Partners
OSS
Gateway
Proposed Syndicate Sessions
 Systems management, commercial,etc
 IPR
 Documentation & change control
 Enablement & service support
 Consult21 project planning, issues management, housekeeping
 Systems principles, standards and capabilities:
 Architecture principles
 Technical and business standards
 Services and capabilities
Service management, commercial, etc
 Intellectual Property Rights
–
Use and re-use
–
Fair usage
–
“Selling-on” to end users
–
Right to change and ownership of “value added” features
• “Enablement” & Service Support
–
Specifications,
–
Test Environments,
–
Technical Support,
–
Change Management,
–
Service Management.
• Documentation & change control

What should be documented, how, when & change control
 Consult21 project planning, issues, housekeeping

Future meetings, agendas etc

Documentation, distribution lists, timing

Issue management
Systems principles, standards and capabilities:
• Architecture Principles
– The “Loosely Coupled” architecture
– Transactions versus ETL/MIS Reports
– Simple versus Complex Business Services
• Technical and Business Standards
– Technologies
– Document and Process Description Languages
– Document Content and Business Process standards
• Services and Capabilities
– Which services (fulfilment, assurance and billing)?
– Granularity (simple transactions or end to end processes)?
Further Details
Intellectual Property Rights
• The current and proposed interfaces are derived from BT designs for various
products and processes
• Questions arise as to what rights partners and customers have when
implementing these in their systems
• As an example in the US some carriers are implementing variations of TMF
trouble ticketing standards and publishing parts of their solutions as open
source
–
Open source is provided without a guarantee of technical support
–
Open source is free for others to adopt, reengineer and use but the origin must be
acknowledged
–
Adopters must respect the terms in any service they sell on (you can sell support for open
source but not the code)
–
Any contribution to an application is also deemed to be open source and cannot be derived
from incorporating work which is not yours to give
Enablement and Service Support
•
A word specification or an XML schema is not sufficient documentation to implement
an interface
So what is?
• A complete specification of all such an interfaces behaviour is not practicable
–
•
An interfaces behaviour is down to complex interaction of product type, order type, current service state, ….
Anyway our experience is
–
–
the more you write down the more people pick holes and question which results in more being written down…
most developers do not read documentation and programme from examples anyway
• Change management is important
But
• There are unintended consequences of change (“Who told you that it could be used
for that?”)
–
•
The impact of change depends more on how an interface is used than how it is provided and we don’t know
how people are exploiting “features”
So for example
–
–
What is interface and what is content?
Is the inclusion of a new valid product code or order type for a product a change to an interface?
• The order format is the same.
• If one corrects the spelling of the text of a message is that a change to an interface?
– If the text was not designed to be automatically parsed then the answer is no
Architecture Principles
• We cannot afford to tightly link partner processes and
technologies
Tightly Coupled
Loosely Coupled
Interaction
Synchronous
Asynchronous
Message Style
Remote Procedure Call Messaging
Message Paths
Hardcoded
Routed
Technology
Homogeneous
Heterogeneous
Objective
Re-use
Broadly useful
Usage
Anticipated
Unexpected
Technical and Business Standards
Services and Capabilities
• Services are realised by the exchange of messages as part of a
transaction/process
• Problem is which services and how are they combined?