Posted on

What’s all the fuss about Orchestration for NFV?

Originally posted on 6Jun17 to IBM Developerworks (11,950 Views)

Think about it – orchestration is everywhere in a Telco – the Order to Cash process, The Ticket to Resolution process, the service and resource  fulfilment process and even the NFV MANO processes.  Orchestration is everywhere…

There is a hierarchy to processes in a Telco – just as the TMF recognises that there is a hierarchy in business services (within the eTOM Process Framework). At the highest level, the Order to Cash process might look like this:

Each task in this swimlane diagram will have multiple sub-processes. If we delve down into the provision resources task for instance, a CSP will need processes that will interrogate the resource catalog and network inventory to determine where in the network that resource can be put and what characteristics need to be set, then tell the resource manager to provision that resource. If it’s a physical resource, that may involve allocating a technician to install the physical resource. If it’s a virtual resource such as a Virtual Network Function (VNF) then the Network Function Virtualisation (NFV) orchestration engine will need to be told to provision that VNF.  If we go one level deeper, the NFV Orchestration engine will need to tell the NFV Manager to provision that VNF and then update the network inventory.

Perhaps the diagram below will help you to understand what i mean:

This diagram is a very simplified hierarchical process model designed to show the layers of process. As you can see, there are many layers of orchestration required in a CSP and as long as the orchestration engine is flexible enough and can handle the integration points with the many systems it needs to interact with, there is no real reason why the same orchestration engine couldn’t be used by all levels of process.

Over the past couple of years as NFV has risen significantly in popularity and interest, I’ve seen many players in the market talk about orchestration engines that just handle NFV orchestration and nothing else.  To me, that seems like a waste. Why put in an orchestration engine that is just used for NFV when you also still need orchestration engines for the higher process layers as well? I’d suggest that a common orchestration and common integration capability makes the most sense delivering:

  • High levels of reuse
  • Maximising utilisation of software capabilities
  • Common Admin and Development skills for all levels of process (be they business focussed or service or resource focussed)
  • Common tooling
  • Common Integration patterns (enabling developers and management staff to work across all layers of the business)
  • Greater Business Agility – able to react to changing business and technical conditions faster

There are a number of Integration platforms – typically marketed as Enterprise Service Buses (ESB) that can handle integration through Web Services, XML/HTTP, File, CORBA/IIOP  even Socket/RPC connections for those legacy systems that many telcos still have hanging around.  An ESB can work well in a MicroServices environment too – so don’t think that just because you have a ESB, you’re fighting against MicroServices – you are not.  MicroServices can make use of the ESB for connectivity to conventional Web Services (SOA) as well as legacy systems.

A common Orchestration layer would drive consistency in processes at all layers of a Telco – and there are a number of Business Process Management orchestration engines out there that have the flexibility to work with the Integration layer to orchestrate processes from the lowest level (such as within a Network Function Virtualisation (NFV) environment) all the way up to the highest levels of business process – the orchestrations should be defined in an standard language such as Business Process Execution Language (BPEL) or Business Process Model Notation (BPMN).

To me, it makes no sense to re-invent the wheel and have orchestration engines just for the NFV environment, different orchestration engines for the Service Order Management, the Resource Order Management, the Customer Order Management, the Service Assurance, the Billing, the Partner/Supplier management etc etc – all of these orchestration requirements could be handled by a single orchestration engine. Additionally, this would make disaster recovery simpler and faster and cheaper as well (fewer software components to be restored in a disaster situation).

Posted on

Blockchain in Telcos?

Originally posted on 23may17 to IBM Developerworks (16,554 Views)

If you like me are hearing ‘Blockchain this, blockchain that‘, it almost seems like blockchain will solve world peace, global hunger and feed your pets for you!  We’re obviously at the ‘peak of inflated expectations’ of the Gartner hype cycle.

I saw a tweet yesterday from an ex-colleague at IBM yesterday that spoke about using blockchain to combat fraud in a Telco.   While I can see that as a possible use case, I was thinking about other opportunities for blockchain.

Perhaps I need to explain blockchain briefly so that those that don’t understand it can also understand the Telecom use cases for blockchain. Wikipedia defines it like this:

“A blockchain… is a distributed database that maintains a continuously growing list of records, called blocks, secured from tampering and revision. Each block contains a timestamp and a link to a previous block.By design, blockchains are inherently resistant to modification of the data — once recorded, the data in a block cannot be altered retroactively. Through the use of a  peer-to-peer network and a distributed timestamping server, a blockchain database is managed autonomously. Blockchains are “an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. The ledger itself can also be programmed to trigger transactions automatically.”

So, it’s an immutable record of changes to something.  I was thinking about that yesterday and there were a number of use cases in Telecom that I could think of that could use blockchain.  I’m not suggesting that they should use blockchain or that it’s needed, just that they could. These are the Use cases I came up with:

  • Fraud prevention : being immutable makes it harder to ‘slip one by’ the normal accounting checks and balances that any large company has.  I suppose the real question is ‘exactly which records need to be stored in a blockchain to enable that fraud prevention?’ The obvious one is the billing records.
  • Billing – maintaining state of post-paid billing accounts, who is making payments, billing amounts and other biulling events (such as rate changes, grace periods etc)
  • Tracking changes to the network. At the moment, many of the changes being made in a Telco’s network may be made by staff, but increasingly, maintenance and management of the network is being outsourced to external companies and you want to keep en eye on them to ensure they’re doing what they say they’re doing.  In the new world of Software Defined Networks (SDN) utilising Network Function Virtualisation (NFV) to build and change the network architecture at a rate that we’ve not seen before, it becomes important for a Telco to be able to track changes to the network to diagnose faults and customer complaints. Over a 24 hour period, a path on a network that supports enterprise customer X may change tens of times – much higher frequency than would be possible if the network elements were physical. 
  • Tracking changes to accounts by customers and telco staff – I could imagine a situation where a customer claims that they didn’t request a configuration change, but a blockchain based record of changes could be used to track beck through all the changes in a customer’s account to determine what happened and when – potentially enabling a Telco to limit the liability to the customer… or vice versa…
  • Tracking purchases – A blockchain record of purchases would allow a CSP to rebuild a customer’s liability from base information; provided there was an immutable record of the data records as well…
  • xDRs – any type of Data Record (CDRs, EDRs…) could be stored in a blockchain to facilittate rebuilding of a client’s history and billing records from base data. The problem with using a blockchain to store xDRs is the size requirements.  I know that large CSPs in India for example produce between five and ten BILLION records per day. It wouldn’t take long for that to build up to a very large storage requirement – even if you store the mediated data records, it’s going to be very large. I guess the question is : ‘what is the return on investment?’ – it is worth while doing. I can’t think of a business case to justify such an investment, but there may be one out there.
  • Assurance events – Recording records associated with trouble tickets and problem resolution.

I don’t for a second think that all of these can be justified in terms of cost/benefit analysis, but I could see blockchain being used in these scenarios. 

Do you have any ideas? Please leave a comment below.

<edit>

I realise I missed the usual business case that blockchain is used for – a financial ledger. Obviously storing a CSP’s financial data in a blockchain would work (and make sense) as it would in ANY other enterprise. I really wanted to illustrate the CSP specific use cases for blockchain.

</edit>

Posted on

Impact 2010 – AT&T, Using SOA & BPM to accelerate business value

Originally poster on 05May10 to IBM Developerworks (16,501 Views)

AT&T are part way through a major SOA/BPM project which if you know a little about their history* must be an enormous task. They are introducing modelling tools and reverse modelling their existing systems as well as using a tool from iRise to prototype the user interfaces and reduce the risk of not hitting the business requirements.

They have deployed Rational Requisite Pro to capture requirements without the need to get users away from their beloved MS Word. In the last five months, their requirements have gone from 15,000 requirements registered in January to over 30,000 now. Certainly illustrates the traction that they are achieving with their business people. Users access Req Pro via Citrix sessions and the tools are available to thousands of business users.

AT&T are also exposing WebSphere Business Modeler and iRise to a smaller set of subject matter expert users – building a Centre of Excellence in UI design and Process Modelling. So far, they have modelled over 800 process flows base on eTOM models which have been extended to meet their specific requirements. All of these are stored within a common Rational Asset Manager instance which helps their business analysts to improve asst use and reuse.

Those process models feed directly into the model driven development method which is aligned with the requirements and process models. That MDD method uses WebSphere Integration Developer(WID), Rational Software Architect (RSA) for development and WebSphere Process Server (WPS) runtime. WebShere Business Modeler and WebShere Services Registry and Repository (WSRR) in support of the runtime. IBM GBS have put in place processes to support AT&T’s development life cycle and governance requirements.

Key success factors that AT&T see include:

  • Solve Critical Business Problems
  • Win over senior Exec support
  • Achieve Business Partner Alignment
  • Integrated Tools Approach
  • Organisational transformation
  • Infrastructure investment
  • Communicate, communicate, communicate!

* AT&T have been through multiple de-mergers and mergers and acquisitions over the past 10 years resulting in a hugely complex IT environment.