{"id":205486,"date":"2017-02-07T00:30:15","date_gmt":"2017-02-07T05:30:15","guid":{"rendered":"http:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/uncategorized\/new-telecom-transformation-goals-require-service-automation-techtarget.php"},"modified":"2017-02-07T00:30:15","modified_gmt":"2017-02-07T05:30:15","slug":"new-telecom-transformation-goals-require-service-automation-techtarget","status":"publish","type":"post","link":"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/automation\/new-telecom-transformation-goals-require-service-automation-techtarget.php","title":{"rendered":"New telecom transformation goals require service automation &#8211; TechTarget"},"content":{"rendered":"<p><p>    The notion that telecom providers had to transform their    business models is more than a decade old, and for most of that    time, specific initiatives targeted the telecom transformation    goal. Positions for chief transformation officers have even    been created to get it done. Yet, here we are, watching telecom    capital expenditure decline as, unfortunately, profit and cost    per bit converge.     Software-defined networking was supposed to fix this    decline, as was     network functions virtualization and even cloud computing.    But declining     Capex remains unfixed in 2017.  <\/p>\n<p>        Gain best practices for optical network design  including        access, metro and core network issues affecting fiber        deployment  as well as 3-part overview of DWDM optical        network transport.      <\/p>\n<p>            By submitting your personal information, you agree that            TechTarget and its partners may contact you regarding            relevant content, products and special offers.          <\/p>\n<p>                You also agree that your personal information may                be transferred and processed in the United States,                and that you have read and agree to the Terms of Use and the Privacy Policy.              <\/p>\n<p>    What will fix it now? Since everything old is new again,    operators now think the answer is to go back to transformation.  <\/p>\n<p>    The idea of fixing an old problem by returning to an old    strategy may seem crazy, but there's method behind this choice.    Telecommunications is a $2 billion global market, with the    greatest financial depreciation inertia of any tech industry.    While it's likely that every CFO in the industry looks back at    the decades-old transformation strategy concepts taught in    business schools, they now realize a strategy that approaches a    telecom transformation by replacing legacy gear with something    virtualized -- or gear that could be virtualized in the future    -- is going to take a long time. They also realize that    attacking a systemic problem like revenue or cost per bit with    selective technology changes is probably not going to be    effective. That's why only about 25% of operators that were    confident about     network functions virtualization (NFV) strategies at the    end of 2015 were confident a year later.  <\/p>\n<p>    The back-to-transformation movement isn't about repeating the    past; it's about starting with the business-school    approaches of the past and developing them with principles    learned from cloud computing,     software-defined networking (SDN) and NFV. It's about being    goal-driven first and technology-centric second. If you want to    stop the frightening convergence of operator revenue-per-bit    and cost-per-bit curves, you have to either reduce costs or    increase revenues. These goals were apparent in the beginning,    but early transformation planners couldn't get past the    abstract goals, and no technical path presented itself.  <\/p>\n<p>    In the technology-driven SDN and NFV period of telecom    transformation, the problem was the opposite. People worked out    a new way of building networks using     virtual functions and software-defined connectivity. Most    everyone agreed this was a better and more flexible approach,    but it was also totally different, complicated and didn't seem    to have any accepted business-value propositions to drive it.    The specific benefits were unclear, as was the path to them.    Nobody had a good answer, so the technology-driven model didn't    work, either.  <\/p>\n<p>    The big lesson operators have learned is telecom transformation    can't be about changing technology; it has to be about    improving operational efficiency. The cost of deploying,    selling and sustaining services accounts for almost one-third    of every revenue dollar, and capital costs are about 19 cents    per revenue dollar. The quickest change operators could make to    improve their return on infrastructure would be to make this    whole operational process cheaper through service    automation. The same automation could also reduce service    provisioning times and make it possible to introduce new    services faster -- both of which would increase revenue. Lower    cost, higher revenue: What's not to like?  <\/p>\n<p>    The key to obtaining operations efficiency turns out to be one    thing from NFV and another from SDN. NFV offers orchestration,    while SDN provides the idea of device independence.     Orchestration is the term now used to describe    modeling of the entire service lifecycle and using software to    drive all lifecycle processes, including responses to changes    or failures in the service resources.  <\/p>\n<p>      The quickest change operators could make to improve their      return on infrastructure would be to make this whole      operational process cheaper through service automation.    <\/p>\n<p>    In NFV, orchestration is essential because     virtual network functions replace traditional devices, and    that deployment process has to be coordinated for every single    function in a service if the service is to work. Automated    software lifecycle management is possible with end-to-end    orchestration, and it brings great efficiency and agility.  <\/p>\n<p>    The big problem with     NFV orchestration is that current infrastructure doesn't    use virtual functions, so you can't apply the NFV model. SDN    stepped in to help with a specific idea that came out of the    project work on the     OpenDaylight SDN controller -- the idea of device    independence. Yes, an ODL controller can control SDN switches,    but with the proper plug-ins, it can also control almost any    legacy device or even a system of devices accessed through a    common network management system.  <\/p>\n<p>    Operators and vendors have also provided varying support for    legacy devices by exposing the management systems of current    network hardware directly to the orchestration layer. In some    ways, this is a better approach because it doesn't need the    intermediate SDN controller. But not all NFV implementations    have this kind of capability. Even where a controller is    present, it may require custom coding to interface with some    network devices.  <\/p>\n<p>    If you can use SDN ODL or a customized orchestration interface,    then NFV orchestration can drive even legacy devices through    software-orchestrated service lifecycles. You can then phase in    SDN switches or NFV's virtual functions where they make sense,    at a pace that makes sense, while getting the operations    benefit right away. In fact, you could get enough benefit from    doing model-driven software-orchestrated service lifecycle    management to fix the problem of profit per bit, without    changing out technology at all. If you then added in SDN and    NFV in an optimal way, you could save as much as two-thirds of    the     Opex costs.  <\/p>\n<p>    We're not quite to the point where this transformational    goodness can be achieved, but we're closing in -- largely from    the NFV side. The OPEN-Orchestrator NFV open source project is    extending NFV automation concepts to     operational support system\/business support system elements    to capture more operations savings. Network giant     AT&T has defined its own open source implementation of    SDN and NFV-centric infrastructure. Both its projects include    the device-independence model from SDN and OpenDaylight.  <\/p>\n<p>    SDN and NFV have so many different changes and additions that    it's hard to make sense of them as a whole. But there's a    single driver behind all of them -- the new-model    transformation theme. We need benefits to match our challenges,    and operators are realizing they have to look at everything    through the service lifecycle -- from service design to    operations and fault management. They also have to address both    new virtualized elements and legacy devices. If they can do all    of that, they stand to gain as much as 12 cents of each revenue    dollar in overall transformation return. That's more than    enough to interest everyone at the C level, and to drive new    and exciting projects, even under the old transformation label.  <\/p>\n<p>    Find out what's     driving NFV to be better for the business  <\/p>\n<p>        SDN and NFV could change telecom  <\/p>\n<p>        Automating OSS\/BSS can kick-start network changes  <\/p>\n<p><!-- Auto Generated --><\/p>\n<p>The rest is here: <\/p>\n<p><a target=\"_blank\" rel=\"nofollow\" href=\"http:\/\/searchtelecom.techtarget.com\/tip\/New-telecom-transformation-goals-require-service-automation\" title=\"New telecom transformation goals require service automation - TechTarget\">New telecom transformation goals require service automation - TechTarget<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p> The notion that telecom providers had to transform their business models is more than a decade old, and for most of that time, specific initiatives targeted the telecom transformation goal. Positions for chief transformation officers have even been created to get it done. Yet, here we are, watching telecom capital expenditure decline as, unfortunately, profit and cost per bit converge <a href=\"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/automation\/new-telecom-transformation-goals-require-service-automation-techtarget.php\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"limit_modified_date":"","last_modified_date":"","_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[431581],"tags":[],"class_list":["post-205486","post","type-post","status-publish","format-standard","hentry","category-automation"],"modified_by":null,"_links":{"self":[{"href":"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/wp-json\/wp\/v2\/posts\/205486"}],"collection":[{"href":"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/wp-json\/wp\/v2\/comments?post=205486"}],"version-history":[{"count":0,"href":"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/wp-json\/wp\/v2\/posts\/205486\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/wp-json\/wp\/v2\/media?parent=205486"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/wp-json\/wp\/v2\/categories?post=205486"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.euvolution.com\/futurist-transhuman-news-blog\/wp-json\/wp\/v2\/tags?post=205486"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}