Consult21 Systems Work PackageBT 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

• 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

credit vetting1

technical checks1

decomposition1

retail billing1

network1

progress events1

KCI1

wholesale products retail products

Note 1: illustrative functions

Re-engineering

credit vetting1

technical checks1

decomposition1

retail billing1

network1

progress events1

KCI1

Non-SMPServiceManagement

Retailersservicemanagement

SMP ProductServiceManagement

Inte

gra

tion

Fra

me

wo

rk

wholesale products retail products credit vetting

tech checks

decompose

billing

network

progress

KCI

CR

M S

ervice

s

Today’s architecture 21C Target

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

DEDS (NP,CPS, +)

SPG(C&A,WLR Ordering)

FSPG(LLU SMPF)

LisaSPG

AutomationNPIC

CPS Gateway

Large File Output Generating

Systems

ISD

N F

TP

F

ixed

Len

gth

Inte

rnet

HT

TP

S X

ML

Inte

rnet

HT

TP

S X

ML

Broadband XML Gateway

(Broadband Ordering)

LLU MPF XML Gateway

(LLU MPF)

eCo LLU

ECO X API Gateway(Private Circuits,

PSTN, ISDN)

eCo XeCo Broadband

Inte

rnet

HT

TP

S X

ML

SOS (SDSL)

Inte

rnet

HT

TP

S X

ML

Inte

rnet

HT

TP

S X

ML

BEA B2B(Broadband Assurance)

GTC/WOOSH

GPMS

ViaHub

Inte

rnet

ebX

ML

XM

L

Other interfaces – either Fastrack one

offs or email (including Ripple)

Manual or Robot (including Ripple)

?

• 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

• Each has been built to address a product family or market segment and been built using differing architectures and technologies

Proposed integration framework

• A Gateway to host a variety of services and functions

• A “loosely coupled” messaging capability based on Internet technologies

• The core of this is XML and http (in the form of SOAP and other web service technologies)

• 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

Gateway

Partner B2B Profile

Process Management

Format &

Translation

Transport Management

Web

ser

vice

s(h

ttp,ft

p, S

OA

P)

emai

l (S

MT

P)

B2B

pro

toco

ls

(ebX

ML,

Res

onat

e)

XM

L(S

OX

sch

ema)

XM

L (X

SD

sch

ema)

CS

V, T

ab

delim

ited

bina

ry

Bt I

nter

nal X

ML

(XS

D s

chem

a)B

t Int

erna

l XM

L (X

SD

sch

ema)

OSS

Partners

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?