In my first SDN blog, I asserted that "Services" -that is technical support, professional and consultancy services -are the missing "S" in the SDN debate.  I'd now like to apply our Cisco Domain Ten^SM framework "in anger" to examine in more detail the impacts that SDN may have on your IT services and operations.  While come of our competitors will only talk about the network switches and new device protocols,  l'll show how it's not just the network switches that you should be concerned with: your SDN and Cisco ONE journey could involve impacts across multiple "domains".

As I bogged about Cisco Domain Ten this past year, I've positioned it as a mechanism to help you on your data center journey.  Let me now extend that use -SDN after all is more than just a data center technology play.  My experience with Cisco Domain Ten over the past year has helped me realize that it is, in fact, an excellent framework for considering impacts to more general IT services, and not just to  the data center .  I'll also illustrate my case with both service provider and enterprise/business/public sector examples.

The following diagram summarizes the areas impacted -let's discuss each one.

In Domains 1 and 2 is where most of the SDN technology debate is focused -namely the network devices, protocols and abstractions (APIs) required to drive network behaviour -in essence, programmability and control.  In my opinion, it's the "domains" above this that are all too often forgotten in the technology debate.  So let's shine some light on these impacts.

Domain 3 -Automation and Orchestration -is the area of potentially biggest impact -in my opinion.  With more network APIs being made available, via say an OpenFlow Controller or via Cisco's onePK API, there is significant opportunity to integrate your management and orchestration tools with the network.   This may involve you working with your OSS (Operational Support System) and NMS (Network Management System) vendors to have them update their applications to use the new SDN APIs, and going through an application upgrade process in your Network Operations Center (NOC).  It may involve you upgrading your custom-developed apps and provisioning scripts.  Software development is not cheap and it can unfortunately be the source of project delays so please don't underestimate the costs of such an exercise.  Such costs and risks are usually noticeable by their absence when our competitors describe the "nirvana" of their SDN products: re-engineering or even just upgrading an OSS  or Systems Management suite of tools is never a straightforward exercise  (15 years working in NMS and OSS taught me that! -call me a cynic :-)).

 You may even envisage new network services and behaviors -that you may expose via your end user interface or User Portal (Domain 4) and IT Services Catalog (Domain 5).  For me, this is where the real opportunity of SDN arises.  Sure, some will argue that you may save some money on potentially cheaper network switches.  However, you may find that you spend significantly to upgrade your NMS and OSS, which may make for a positive (or negative!!!) RoI for your SDN project.  What the smart companies will do in my opinion is to generate new network services, delivering flexibility, agility and business value add that out-flanks their competitors focused only on cost reduction.  You may devise new classes of software applications (Domain 8) that solve some of today's networking challenges.  Application development may be an area you need to upskill your staff for, providing excellent career development opportunities as well as new business opportunities. Time will tell here.  In my mind this is where the exciting opportunities of SDN lie.

With SDN being a relatively new technology, there will undoubtedly be challenges that arise as it matures.  Security in SDN is one such area of concern.  Security vulnerabilities in new architectures (e.g. the centralised SDN controller, or in multi-layer virtualized networks) have still to be fully understood.  The services we provide in Domain 9 "Security and Compliance", I am sure, will be in demand as customers evaluate SDN technologies.  In fact, I was at a customer meeting just last week, and "security vulnerabilities" [in SDN] was one of the 2 biggest customer concerns (the other being the need for a concrete business case in order to justify their transition.

Finally, last but by no means least, what are the Operations Management (Process and Governance -Domain 10) implications?   There may be operational process changes and new procedures required for device and software controller certification.  You may need to upgrade fault management OSS tools to versions that can communicate to new SDN devices.  Of course if you make use of Cisco's onePK API, to existing devices, your current fault management systems won't be impacted -a key advantage of the Cisco ONE strategy.  And as you introduce new SDN devices, consider overlay networks and investigate OpenFlow controllers, make sure you evaluate the available troubleshooting tools and techniques for each of these, and make sure that, in the rush to SDN, such tools have actually been developed.  Your operations team will thank you for your due diligence here!

As you can see, Cisco Domain Ten provides a useful analysis to help you understand the challenges of new IT services and technologies, including SDN.  It's helped me illustrate a range of challenges that are all to often missing from the SDN discussions across the industry.  Cisco Domain Ten can help you generate focus on the key changes you need to make in order to really exploit SDN and Cisco ONE.  Finally please do remember that Cisco Services and our Cisco Domain Ten, SDN and Cisco ONE experts are ready to help you on this journey with our portfolio of Cisco ONE services!