More
CALL To Action
To Know
-
Piece of change
A DIP dive into integration
CALL To Action
—
Jan 2018
In the technological world where the only constant thing is change, CSPs are facing one of their biggest challenges to date: how will they continuously address new customer needs and new ways to interact with customers and users?
Pushed by the never-ending stream of apps and OTTs, today’s customers want to consume all services the way they subscribe to Netflix or Spotify, i.e., clicking a button and with no need for interaction with a CSR.
The core of a CSP’s system architecture is not ready for such diversity and change in concepts, and it is also not able to effectuate change so quickly. So, how will an operator deal with this need of reinventing itself while not hurting its core business?
We have looked at the vectors of change on an operator today, and depicted the main ones below:
For these dimensions, organizations are dwelling on questions such as:
Now we have set the baseline, let us understand how Celfocus is addressing this challenge…
But… before jumping right into the solution to what was described above, let’s first acknowledge that every one of us has, at a given time, thought something along the line of “Do we still need integration layers? Why? Isn’t this just more complexity and costs on our projects?”
Guess what? Integration is alive and kicking! And why?
Let us pick up on what integration does and what it does best: it deals with heterogeneity, and it minimises dependencies from one system to the next (anyone hearing the classic “loosely-coupled architecture” tune?). Well, if the new era is comprised of more and more channels, more and more offers and the need for agile delivery - how could this “enabler of change” be out of the loop?!
It is not. Changes are natural, even in SOA. And that means a new integration concept arises…
The Foundations - SOAF
For the past 12 years, Celfocus has been building, evolving and extensively delivering a SOA Framework (SOAF) with every project where integration was included. Its value as an enabler of high development speed, out-of-the-box cross-cutting features, and governance enablers allows us to deliver faster and be more consistent on our approach to integration design. It has been a cornerstone of the BSS architectures we have put in place everywhere.
Going Digital - DIP
Even though our legacy makes us proud, we do know that not every need of today and tomorrow is supported by SOAF or any other SOA architecture/ESB. As such, we have evolved our core integration architecture to a multi-layered approach with well-defined concepts and responsibilities, where different components are joined to provide a complete solution to tomorrow’s integration needs.
Main pillars for the Digital Integration Platform are:
ESB
We acknowledge that a classic ESB is not ready for decommissioning, as it will still massively mask and standardise functions on the core BSS and OSS. Therefore, it is still present and of the utmost importance on current transformation and migration programmes.
Microservices
Fast-paced delivery of features requires these not to be implemented in their typical systems of record; instead, a new layer is born, where capabilities are availed on the best technology fit for a given scenario, and domain-driven design ensures a correct split of entities and functions, minimising entropy and collateral damage on changes along the road. The first example here is the migration of SOAF’s features themselves to a microservice approach!
API Management
Companies used their ESB to standardise systems and provide a single bus for service catalogue, service governance and functionality composition. Now we have moved out of our CSP and embraced the world, a new kind of abstraction is required; this API abstraction provides us with full authentication/authorization control, monitoring and service execution safeguards (throttling, caching, etc.) – allowing us to expose functionalities to every single end-customer while still ensuring security and our core systems’ availability, and potentiating new “pay-per-use” revenue models.
Cloud-Native Integration
Every single one of these pieces can be deployed under one or more cloud service models, and both microservices and the ESB can be containerized. This yields that the new platform is readily available and scalable, optimizing costs and providing solutions for any given load.
Agile Delivery
Solutions as the ones above play well with Agile, DevOps and CI/CD. This implies that we embrace a change that is bigger than technology: we need to adapt to new ways of doing things, and then assist our customer on the same journey. As you all have thought by now, this cannot be underestimated …and may easily be the biggest concern raised here!
Now we have explained our solution to support the digital world’s integration needs, what benefits are we delivering to the CSPs that cross the digital chasm with us? Well, feel free to add the ones you believe to be missing from this set:
On an ending note, if you have understood what we wished to achieve and how we did it, you might find yourself wondering how are we presenting DIP to our customers, and what their reaction has been. The good news is that we did share it on a fair number of accounts and prospects, and we got a chance to explore it (i.e., building services or PoC’s on top of one or more components of DIP). Customers’ focus now seems to be on how to add microservices capabilities and provide API management, while leveraging on the existing SOA – and we have been happily providing answers on this!
For more information reach out to us and we will gladly get in touch!
Demand for new domestic telephone service during the war was huge. Most of that growth happened during the following decade. What's changed and what hasn't?
In the technological world where the only constant thing is change, CSPs are facing one of their biggest challenges to date: how will they continuously address new customer needs and new ways to interact with customers and users?
Pushed by the never-ending stream of apps and OTTs, today’s customers want to consume all services the way they subscribe to Netflix or Spotify, i.e., clicking a button and with no need for interaction with a CSR.
The core of a CSP’s system architecture is not ready for such diversity and change in concepts, and it is also not able to effectuate change so quickly. So, how will an operator deal with this need of reinventing itself while not hurting its core business?
We have looked at the vectors of change on an operator today, and depicted the main ones below:
For these dimensions, organizations are dwelling on questions such as:
Now we have set the baseline, let us understand how Celfocus is addressing this challenge…
But… before jumping right into the solution to what was described above, let’s first acknowledge that every one of us has, at a given time, thought something along the line of “Do we still need integration layers? Why? Isn’t this just more complexity and costs on our projects?”
Guess what? Integration is alive and kicking! And why?
Let us pick up on what integration does and what it does best: it deals with heterogeneity, and it minimises dependencies from one system to the next (anyone hearing the classic “loosely-coupled architecture” tune?). Well, if the new era is comprised of more and more channels, more and more offers and the need for agile delivery - how could this “enabler of change” be out of the loop?!
It is not. Changes are natural, even in SOA. And that means a new integration concept arises…
The Foundations - SOAF
For the past 12 years, Celfocus has been building, evolving and extensively delivering a SOA Framework (SOAF) with every project where integration was included. Its value as an enabler of high development speed, out-of-the-box cross-cutting features, and governance enablers allows us to deliver faster and be more consistent on our approach to integration design. It has been a cornerstone of the BSS architectures we have put in place everywhere.
Going Digital - DIP
Even though our legacy makes us proud, we do know that not every need of today and tomorrow is supported by SOAF or any other SOA architecture/ESB. As such, we have evolved our core integration architecture to a multi-layered approach with well-defined concepts and responsibilities, where different components are joined to provide a complete solution to tomorrow’s integration needs.
Main pillars for the Digital Integration Platform are:
ESB
We acknowledge that a classic ESB is not ready for decommissioning, as it will still massively mask and standardise functions on the core BSS and OSS. Therefore, it is still present and of the utmost importance on current transformation and migration programmes.
Microservices
Fast-paced delivery of features requires these not to be implemented in their typical systems of record; instead, a new layer is born, where capabilities are availed on the best technology fit for a given scenario, and domain-driven design ensures a correct split of entities and functions, minimising entropy and collateral damage on changes along the road. The first example here is the migration of SOAF’s features themselves to a microservice approach!
API Management
Companies used their ESB to standardise systems and provide a single bus for service catalogue, service governance and functionality composition. Now we have moved out of our CSP and embraced the world, a new kind of abstraction is required; this API abstraction provides us with full authentication/authorization control, monitoring and service execution safeguards (throttling, caching, etc.) – allowing us to expose functionalities to every single end-customer while still ensuring security and our core systems’ availability, and potentiating new “pay-per-use” revenue models.
Cloud-Native Integration
Every single one of these pieces can be deployed under one or more cloud service models, and both microservices and the ESB can be containerized. This yields that the new platform is readily available and scalable, optimizing costs and providing solutions for any given load.
Agile Delivery
Solutions as the ones above play well with Agile, DevOps and CI/CD. This implies that we embrace a change that is bigger than technology: we need to adapt to new ways of doing things, and then assist our customer on the same journey. As you all have thought by now, this cannot be underestimated …and may easily be the biggest concern raised here!
Now we have explained our solution to support the digital world’s integration needs, what benefits are we delivering to the CSPs that cross the digital chasm with us? Well, feel free to add the ones you believe to be missing from this set:
On an ending note, if you have understood what we wished to achieve and how we did it, you might find yourself wondering how are we presenting DIP to our customers, and what their reaction has been. The good news is that we did share it on a fair number of accounts and prospects, and we got a chance to explore it (i.e., building services or PoC’s on top of one or more components of DIP). Customers’ focus now seems to be on how to add microservices capabilities and provide API management, while leveraging on the existing SOA – and we have been happily providing answers on this!
For more information reach out to us and we will gladly get in touch!
Demand for new domestic telephone service during the war was huge. Most of that growth happened during the following decade. What's changed and what hasn't?
In the technological world where the only constant thing is change, CSPs are facing one of their biggest challenges to date: how will they continuously address new customer needs and new ways to interact with customers and users?
Pushed by the never-ending stream of apps and OTTs, today’s customers want to consume all services the way they subscribe to Netflix or Spotify, i.e., clicking a button and with no need for interaction with a CSR.
The core of a CSP’s system architecture is not ready for such diversity and change in concepts, and it is also not able to effectuate change so quickly. So, how will an operator deal with this need of reinventing itself while not hurting its core business?
We have looked at the vectors of change on an operator today, and depicted the main ones below:
For these dimensions, organizations are dwelling on questions such as:
Now we have set the baseline, let us understand how Celfocus is addressing this challenge…
But… before jumping right into the solution to what was described above, let’s first acknowledge that every one of us has, at a given time, thought something along the line of “Do we still need integration layers? Why? Isn’t this just more complexity and costs on our projects?”
Guess what? Integration is alive and kicking! And why?
Let us pick up on what integration does and what it does best: it deals with heterogeneity, and it minimises dependencies from one system to the next (anyone hearing the classic “loosely-coupled architecture” tune?). Well, if the new era is comprised of more and more channels, more and more offers and the need for agile delivery - how could this “enabler of change” be out of the loop?!
It is not. Changes are natural, even in SOA. And that means a new integration concept arises…
The Foundations - SOAF
For the past 12 years, Celfocus has been building, evolving and extensively delivering a SOA Framework (SOAF) with every project where integration was included. Its value as an enabler of high development speed, out-of-the-box cross-cutting features, and governance enablers allows us to deliver faster and be more consistent on our approach to integration design. It has been a cornerstone of the BSS architectures we have put in place everywhere.
Going Digital - DIP
Even though our legacy makes us proud, we do know that not every need of today and tomorrow is supported by SOAF or any other SOA architecture/ESB. As such, we have evolved our core integration architecture to a multi-layered approach with well-defined concepts and responsibilities, where different components are joined to provide a complete solution to tomorrow’s integration needs.
Main pillars for the Digital Integration Platform are:
ESB
We acknowledge that a classic ESB is not ready for decommissioning, as it will still massively mask and standardise functions on the core BSS and OSS. Therefore, it is still present and of the utmost importance on current transformation and migration programmes.
Microservices
Fast-paced delivery of features requires these not to be implemented in their typical systems of record; instead, a new layer is born, where capabilities are availed on the best technology fit for a given scenario, and domain-driven design ensures a correct split of entities and functions, minimising entropy and collateral damage on changes along the road. The first example here is the migration of SOAF’s features themselves to a microservice approach!
API Management
Companies used their ESB to standardise systems and provide a single bus for service catalogue, service governance and functionality composition. Now we have moved out of our CSP and embraced the world, a new kind of abstraction is required; this API abstraction provides us with full authentication/authorization control, monitoring and service execution safeguards (throttling, caching, etc.) – allowing us to expose functionalities to every single end-customer while still ensuring security and our core systems’ availability, and potentiating new “pay-per-use” revenue models.
Cloud-Native Integration
Every single one of these pieces can be deployed under one or more cloud service models, and both microservices and the ESB can be containerized. This yields that the new platform is readily available and scalable, optimizing costs and providing solutions for any given load.
Agile Delivery
Solutions as the ones above play well with Agile, DevOps and CI/CD. This implies that we embrace a change that is bigger than technology: we need to adapt to new ways of doing things, and then assist our customer on the same journey. As you all have thought by now, this cannot be underestimated …and may easily be the biggest concern raised here!
Now we have explained our solution to support the digital world’s integration needs, what benefits are we delivering to the CSPs that cross the digital chasm with us? Well, feel free to add the ones you believe to be missing from this set:
On an ending note, if you have understood what we wished to achieve and how we did it, you might find yourself wondering how are we presenting DIP to our customers, and what their reaction has been. The good news is that we did share it on a fair number of accounts and prospects, and we got a chance to explore it (i.e., building services or PoC’s on top of one or more components of DIP). Customers’ focus now seems to be on how to add microservices capabilities and provide API management, while leveraging on the existing SOA – and we have been happily providing answers on this!
For more information reach out to us and we will gladly get in touch!
Demand for new domestic telephone service during the war was huge. Most of that growth happened during the following decade. What's changed and what hasn't?
.png)
n.jpg)
