In the Beginning, There Was... Definition - NaaS and CaaS explained
MEF recently announced the release of the first version of the "Industry Blueprint for Network-as-a-Service (NaaS)," a development that piqued my interest, as any attempt to align approaches and visions in the telecommunications industry tends to do. In this blog post, my goal is to help you understand the concepts behind NaaS (Network-as-a-Service) and CaaS (Connectivity-as-a-Service) and to analyze the industry drivers propelling us toward this vision. This article is the first in a series that will explore how we can achieve automated networks where global services are easily attainable and quickly provisioned. I intend to delve into both the vertical and horizontal aspects of realizing this vision, taking a top-to-bottom approach anchored in the business context. Emphasizing the business aspect is crucial because, as I once explained to my children regarding Product Management, "even if you have the best product idea, if no one wants to pay for it, it will never materialize."
First and foremost, we must establish clear and concise definitions for CaaS and NaaS.
When I began working on defining NaaS (as the announced MEF blueprint centers around NaaS), I realized that it's essential to first explain CaaS. CaaS is a business-enabling concept that is relatively straightforward to grasp and comprehend. But what is it, precisely?
Numerous definitions and vision statements exist, but the one that resonates most with me comes from TMF:
First and foremost, we must establish clear and concise definitions for CaaS and NaaS.
When I began working on defining NaaS (as the announced MEF blueprint centers around NaaS), I realized that it's essential to first explain CaaS. CaaS is a business-enabling concept that is relatively straightforward to grasp and comprehend. But what is it, precisely?
Numerous definitions and vision statements exist, but the one that resonates most with me comes from TMF:
“Connectivity-as-a-Service (CaaS) as intent driven dynamic realization of connectivity solution based on customer expectations.”
In other words, Connectivity as a Service (CaaS) delivers fast ("dynamic realization") and simple ("intent-driven") connectivity solutions. To better understand this vision, let's trace its origins back to TMF IG1271, which states:
"The objective of connectivity-as-a-service as a concept is to gain the characteristics and behavior that have made the cloud so successful, such as flexibility, scalability, and consumability."
In simpler terms, telecommunications companies aspire to offer their services in a dynamic and flexible, hyperscaler-like fashion. It's worth noting that all of this is essential for sustaining their business. Furthermore, automation, leading to "dynamic realization," becomes a margin-saving necessity in an industry with increasingly razor-thin margins. The use of intents makes these services more accessible to consumers. In summary, CaaS is not just an innovative business concept but a shift motivated by the need to retain business relevance. Perhaps not as glamorous, but it's a critical evolution.
Now, let's dive into how CaaS will function through a futuristic scenario. Imagine it's the 2030s, or even later. You open an AI-backed application provided by your Service Provider. You tap the microphone icon and say, "I need a private connectivity link between my site at <your specified address> and <your specified second address>, with a reliable private connection offering a throughput of <your desired bandwidth>. Can you make that happen, and what's the cost?" Shortly after, you receive a positive response, and if you approve, you say, "I'll take it." It's up and running seamlessly.
One of the most remarkable aspects is that the addresses you provided could point to any location worldwide. You won't see how your Service Provider determines if its network can fulfill your request. They do this by identifying relevant Customer Facing Services (CFS) within their own or partner's inventory, making them work for you.
(Don't worry; I'll delve deeper into the CFS concept in upcoming blogs, covering information models, reference architectures, and business processes. For now, understand that CFS is a service derived from underlying network capabilities, commercially offered to customers. In other words, if I've built the highway, I can offer it as a CFS to you. If you need to get from A to Z, I'll take you from A to B [my CFS], and my partner will handle B to Z [his CFS]. It's seamless, and you won't even notice.)
Now, let's get a bit technical and make a statement: "Think of CaaS as something that leverages network capabilities in the form of CFSs, making them easily accessible to you on commercial terms you can evaluate." For me, this concept conjures the idea of a Product Catalog, and it's okay if it does the same for you.
"Okay," you might say, "I grasp the concept of CaaS, but you promised to explain NaaS. What is it?"
Defining NaaS isn't straightforward, but I'm looking forward to MEF's NaaS Blueprint to help clarify it. For now, let's go with this definition from TMF1170:
"NaaS defines a structured approach to separating the commercial systems' concerns from Technology Capabilities used to produce solutions so that Service Providers can increase their business agility."
In essence, while CaaS focuses on making efficient use of existing CFSs, NaaS revolves around managing these CFSs by controlling the underlying network capabilities.
Consider another example: If I own a car, I can offer the following CFSs commercially:
CFS1: Transport a person.
CFS2: Deliver a small package.
I can package these services and add them to my catalog, making them accessible through intents, just like in the CaaS space. However, if I want to offer a CFS for transporting large and heavy items, I must modify my underlying capabilities (in this case, the car I'm using) to enable such a CFS. This mirrors the challenges in the NaaS space.
I became more confident in this perspective after listing TMF open APIs constituting NaaS:
TMF640 - Service Activation and Configuration
TMF633 - Service Catalog Management
TMF638 - Service Inventory Management
TMF641 - Service Ordering Management
TMF645 - Service Qualification
TMF677 - Usage Consumption
TMF656 - Service Problem
TMF653 - Service Test
Today, when I think of CaaS, I envision a Product Catalog, while NaaS brings to mind a Service Catalog.
When I think of NaaS, I see computer networks and their capabilities represented by CFSs. When I think of CaaS, I see people happily using these CFSs in a way that benefits our world.
Thank you for joining me on this journey so far. My intention was to outline the concepts of CaaS and NaaS. I hope I've provided a clear explanation, and I'm open to any questions or comments. In my next installment, I'll explore fascinating aspects of reference architectures, so stay tuned. In the meantime, feel free to reach out for further discussion.
Cheers!
"The objective of connectivity-as-a-service as a concept is to gain the characteristics and behavior that have made the cloud so successful, such as flexibility, scalability, and consumability."
In simpler terms, telecommunications companies aspire to offer their services in a dynamic and flexible, hyperscaler-like fashion. It's worth noting that all of this is essential for sustaining their business. Furthermore, automation, leading to "dynamic realization," becomes a margin-saving necessity in an industry with increasingly razor-thin margins. The use of intents makes these services more accessible to consumers. In summary, CaaS is not just an innovative business concept but a shift motivated by the need to retain business relevance. Perhaps not as glamorous, but it's a critical evolution.
Now, let's dive into how CaaS will function through a futuristic scenario. Imagine it's the 2030s, or even later. You open an AI-backed application provided by your Service Provider. You tap the microphone icon and say, "I need a private connectivity link between my site at <your specified address> and <your specified second address>, with a reliable private connection offering a throughput of <your desired bandwidth>. Can you make that happen, and what's the cost?" Shortly after, you receive a positive response, and if you approve, you say, "I'll take it." It's up and running seamlessly.
One of the most remarkable aspects is that the addresses you provided could point to any location worldwide. You won't see how your Service Provider determines if its network can fulfill your request. They do this by identifying relevant Customer Facing Services (CFS) within their own or partner's inventory, making them work for you.
(Don't worry; I'll delve deeper into the CFS concept in upcoming blogs, covering information models, reference architectures, and business processes. For now, understand that CFS is a service derived from underlying network capabilities, commercially offered to customers. In other words, if I've built the highway, I can offer it as a CFS to you. If you need to get from A to Z, I'll take you from A to B [my CFS], and my partner will handle B to Z [his CFS]. It's seamless, and you won't even notice.)
Now, let's get a bit technical and make a statement: "Think of CaaS as something that leverages network capabilities in the form of CFSs, making them easily accessible to you on commercial terms you can evaluate." For me, this concept conjures the idea of a Product Catalog, and it's okay if it does the same for you.
"Okay," you might say, "I grasp the concept of CaaS, but you promised to explain NaaS. What is it?"
Defining NaaS isn't straightforward, but I'm looking forward to MEF's NaaS Blueprint to help clarify it. For now, let's go with this definition from TMF1170:
"NaaS defines a structured approach to separating the commercial systems' concerns from Technology Capabilities used to produce solutions so that Service Providers can increase their business agility."
In essence, while CaaS focuses on making efficient use of existing CFSs, NaaS revolves around managing these CFSs by controlling the underlying network capabilities.
Consider another example: If I own a car, I can offer the following CFSs commercially:
CFS1: Transport a person.
CFS2: Deliver a small package.
I can package these services and add them to my catalog, making them accessible through intents, just like in the CaaS space. However, if I want to offer a CFS for transporting large and heavy items, I must modify my underlying capabilities (in this case, the car I'm using) to enable such a CFS. This mirrors the challenges in the NaaS space.
I became more confident in this perspective after listing TMF open APIs constituting NaaS:
TMF640 - Service Activation and Configuration
TMF633 - Service Catalog Management
TMF638 - Service Inventory Management
TMF641 - Service Ordering Management
TMF645 - Service Qualification
TMF677 - Usage Consumption
TMF656 - Service Problem
TMF653 - Service Test
Today, when I think of CaaS, I envision a Product Catalog, while NaaS brings to mind a Service Catalog.
When I think of NaaS, I see computer networks and their capabilities represented by CFSs. When I think of CaaS, I see people happily using these CFSs in a way that benefits our world.
Thank you for joining me on this journey so far. My intention was to outline the concepts of CaaS and NaaS. I hope I've provided a clear explanation, and I'm open to any questions or comments. In my next installment, I'll explore fascinating aspects of reference architectures, so stay tuned. In the meantime, feel free to reach out for further discussion.
Cheers!
Komentarze
Prześlij komentarz