Thursday, January 28, 2016

CCIE Skill Transformation to SDN Survey

I’m conducting “CCIE Skill Transformation to SDN” survey, to capture the perceived impact of SDN & NFV to CCIEs, as well as to understand how CCIEs think about their readiness to these new technologies. The result will be presented during my session at Cisco Live Berlin (BRKSDN-4005) on 16 February 2016. Only those who have passed CCIE lab can participate in the survey (regardless of your current CCIE status e.g. inactive or Emeritus). The information you provide is confidential and will not be disclosed as individual answer. No personal data will be exposed and shared to any parties. Thank you in advance for your support
https://www.surveymonkey.com/r/ccie-to-sdn

Friday, January 15, 2016

Hackathon and New Way of Hiring

I’ve been very busy the past 6 months. I was juggling between my work at Cisco, my personal activities in Indonesia, SDN warriors group, my MBA final semester, traveling, my SDN & NFV skill transformation, family issues, and all other tasks. I don’t believe in multi-tasking, so what I did was actually task-switching. Make priority list of all the tasks, keep switching from one task to another, re-prioritize the list, continue switching and so on. And unfortunately updating this blog was never the top priority in the list.


Anyway, during August 2015 I was leading my team to host SDN Hackathon event in Jakarta, Indonesia. It was 3-day event, started with 8-hour SDN Workshop to explain the technology from the architecture, SDN & NFV use cases in real world, up to the discussion about the skills we must develop to become Network Programmability Engineer and Network DevOps. The Hackathon happened after the workshop where we challenge group of students for 30 hours straight to develop SDN solution ground-up, from setting up physical network infrastructure, virtual infrastructure, all the way to workflow automation to provision network services using Web User Interface.


I won’t talk in detail about the event. It’s been a while so I don’t even remember many things that happened anymore. But I know for sure that it was the first SDN Hackathon ever in Indonesia. And I think it was the first SDN Hackathon in the world that asks to build SDN solution to perform end-to-end network services provisioning. So one magic button on the web interface can start the VM in OpenStack compute, configure the VM until it can provide Internet service, monitor the VM lifecycle, at the same time auto configure all the physical and virtual network, and deploy the network policy such as Access Control List and QoS. Fully automated and no human interaction during the process. It was an interesting experience and to my surprise the students were doing well, even they didn’t know much about SDN before the event, and half of the group was able to finish the challenge.


I did several presentations to explain about SDN solution during the workshop, then I watched the students closely during the 30 hours Hackathon. Most of them didn’t sleep. We provided all the food and drink for free, but no one seems to enjoy it. Everyone was busy. Busy discussing the technical solution. Busy coding. Busy modifying config files in Linux. Everyone was so focus to answer the list of challenges within the time limit.

Then it struck me. This kind of event is actually a perfect place to find good candidates to get hired by companies. And I will tell you why:

1. They have to work under pressure
To work on new and difficult task in 30 hours non-stop, obviously provide lots of pressure to every candidate. Only the strong survives

2. They have to solve non-familiar challenge
Almost all of them came to the event with a very little background about SDN. Yes we tried to help by explaining the solution during the workshop prior to the Hackathon, but it can still be considered an alien task

3. They have to work with strangers
We mixed the students to avoid one group with members from the same school. So they have to work with strangers to solve hard challenge within short time

4. Their communication skill is still crucial
It’s important for them to communicate within the team, and at the end of the event we also asked them to present their work, along with the thought process

5. Their unique ability will rise
We witnessed several candidates that show their leadership skill to lead the discussion or even to lead the team to tackle the challenge

Instead of taking CV and call the candidate one by one, by hosting one Hackathon event I would be able to get several good candidates at once. I would be able to see how they work under pressure, how they handle non-familiar task, how they work with people from different background, the way they communicate, to see if they are team player and even to judge their leadership skill.


If I was to hire someone to become SDN & NFV Consultant or Architect, beyond the skill and personality I would look at her experience, her reputation in the market, her network and contacts, and what others say about her. But if I want to hire fresh graduates or even someone with less experience, who most likely has not built reputation or network, so my focus is mainly on the skill, ability to deliver outcome and a team player, I believe this is the best way. I don’t need to create multiple hiring process, come up with long list of interview questions, and I don’t need to build simulated environment to analyze candidate’s ability.

Next time I was going to hire someone, I would rather host a Hackathon event.

Thursday, November 05, 2015

Journey to Become SDN Warrior!


We have just released the Journey to become SDN Warrior v1! Designed with end in mind. Based on today's SDN and NFV real use cases. Clear milestone in every learning step. Transforming Network Engineers' skill while still maintain relevancy with the networking industry that is transforming as well. First Dojo to open in Dubai early 2016. Join us https://www.facebook.com/groups/sdnwarriors/

Saturday, October 10, 2015

SDN Warriors



SDN Warriors Facebook Group is an open group for any Network Engineer who wants to transform to become SDN & NFV Architect, Network Programmability Engineer and Network DevOps. The group is run by mentors who are currently transforming ourselves and willing to help others to do the same. We have the skills and experiences with various SDN solutions, we have done SDN & NFV projects, we have hosted SDN Hackathon event, we have even created our own SDN products.
Non-SDN related topics will be banned, and please use English only
https://www.facebook.com/groups/sdnwarriors/

Monday, August 31, 2015

How to Bring SDN/NFV into Reality


Unless you've been living inside a cave, or on top of a mountain without any Internet connection, you must have heard or read the news about Software-Defined Networking (SDN). In fact, SDN news pops up too often these days it makes some skeptics start thinking whether it is really real or just another hype in networking industry.

The challenge is it seems like everybody comes with their own definition of SDN. Each networking vendor displays its solution based on each own interpretation of SDN implementation. IETF group called the Interface to the Routing System (I2RS) is still trying to standardize southbound programming protocols and network-wide, multilayer topologies that include both virtual and real elements, network overlays and underlays. Open Networking Foundation (ONF), as a user-driven organization dedicated to the promotion and adoption of SDN, until today is mainly focusing on standardization of OpenFlow protocol. And the rise of new SDN startups, no doubt have created lots of excitement with many innovations within SDN spaces, contributes to the confusion at the same time.


The questions from today's business leaders in companies that consume networking technologies: if we want to embrace SDN, are we on the right track? Which way to go? For some, the question is even more basic: What to do to get to SDN? How to start?

To try to find the answers to those questions, perhaps we should refresh our memory how it was all started. Everybody has heard the story how some smart people at Stanford University initiated Project Clean Slate, to explore what kind of Internet we would design if we were to start with a clean slate and 20-30 years of hindsight. Project Clean Slate led the development of OpenFlow.

According to Wikipedia, OpenFlow is a Layer 2 communication protocol that gives access to the forwarding plane of a network switch or router over the network. In "traditional" network paradigm, control and data (forwarding) plane reside within the physical device such as router or switch. In SDN paradigm, not all processing happens inside the same device. Control plane is separated from the physical device that will run only as forwarding plane.


OpenFlow has four parts:

Controller - resides on a server and provides control plane function for the network
OpenFlow Agent - resides on a network devices and fulfill requests from the Controller
Northbound APIs - enable applications to interface with the Controller
OpenFlow Protocol - the Layer 2 protocol that the Controller and Agents use to communicate

Open Networking Foundation (ONF) was formed to accelerate the delivery and use of SDN by standardizing OpenFlow. Deutsche Telekom, Facebook, Goldman Sachs, Yahoo, Google, Microsoft, NTT, Verizon are the board members, while almost all known vendors in networking industry like Cisco, HP, Juniper, Intel etc. sit as ONF members. That shows how important OpenFlow is.

However, the important point to keep in mind that OpenFlow does not equal to SDN. OpenFlow is just one protocol within SDN paradigm. Cisco once shared sample of new protocols for SDN along with their place in multiple layers: from device API layer, to forwarding, control plane, network services, orchestration and management.


Now, you have read this far and may have the One Most Important Question in mind: who cares? What should I care with all this? Who cares about new protocols in the network? How can it help me with my business? Exactly.

Let's first quickly review who were the first ones making noise about SDN in real network: James Hamilton from Amazon released a famous white paper in 2010 saying "Datacenter Networks Are In My Way". As network engineers we have to admit that auto provisioning technique in networking space is way behind the server space. Automation and orchestration in provisioning new Virtual Machine in Data Center can take only minutes to build, to configure the system and even to install service packages (e.g. Apache, DNS etc) in order to make it ready to provide services to the users. While to provision the new VLANs and subnets, to inject the new prefix into Routing Protocol, to create or re-configure Security policy and QoS... well, most networks today are still using manual provisioning method that require at least days or even weeks to complete those tasks.

Urs Holzle, Senior Vice President of Technology Infrastructure at Google, gave keynote speech at the
second annual Open Networking Summit (April 2012) and mentioned that Google has been using OpenFlow as the protocol for their WAN. That was a pretty big statement and somewhat validated OpenFlow as a viable technology in the SDN space.


You may argue that you are not Amazon nor Google. You don't run Massive Scale Data Center that requires multi-tenancy and very fast auto provisioning for services. And you are still happy with your current WAN since the traditional networking protocols that you use can provide predictable behavior, "self healing" the network will find alternate path when the primary path is down, and your network can provide sub-second convergence time during failure. You don't want to even consider new protocol, or new paradigm, that is not proven yet to replace the current one you've been using for years.

And you are absolutely right. For us mere mortals, nothing has changed in networking since Cisco built their first router about 30 years ago. The "traditional" network paradigm has remained mostly intact, until mid-2012. That was the time when VMWare bought a startup company called Nicira, that created Network Virtualization Platform as overlay network, for around $1.2 billion in total. Rumor has it that Cisco was trying to acquire Nicira too, but outbid by VMWare at that time.

What does it mean?

When major networking players such as VMWare and Cisco are willing to spend more than a billion dollar to acquire a startup in SDN, that's a market validation. That gives a strong signal to confirm that SDN business is real. And obviously that acquisition was able to boost lots of investors to started investing in many other SDN startups.

Software defined networking (SDN), as per Wikipedia, is an approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality. To understand this abstraction concept, let's see the different types of Network Programmability.


The traditional network device we know, shown as the most left in the picture, can be managed by the applications using well known protocol from device CLI to SNMP or Netflow. Picture (1) shows how several network vendors have created vendor specific API to access their devices to allow some degree of programmability by the applications, even though we have to follow what is defined in the API. When SDN with OpenFlow comes to the picture (2a) it separates the control plane and data/forwarding plane. This "Pure SDN" approach lets the controller to provide Northbound API for the applications, and to use Southbound API to communicate with network device. Northbound API can be open/standard based or vendor specific, and the Southbound API can be OpenFlow, PCEP, I2RS and other types of open API, or vendor specific API. The result is an abstraction where the application does not need to deal directly with lower level functionality within network device.

Some people argue that all networking technologies that have been built for the past three decades can't be thrown away and replaced by new SDN protocols. Hence they say it's better to keep the network as it is, but have the controller ready to program the network when it's required. "Preserve what works, program when needed". This is the idea behind Hybrid SDN (2b) approach, where the network can continue with its predictable behavior, self healing, and fast convergence, but can be re-program based on the input from the applications. Just like pure SDN, controller can sit between applications and network device to provide the abstraction.


What is overlay networks (3)? When we have physical network built using physical devices and links, called the underlay, then on top of it we create new virtual network topology that can be different with the physical network, then we get an overlay network. It is not a new concept in networking. GRE tunnels or MPLS VPN are some example of overlay network we've been using for years. That idea is being sold by the vendors who sell overlay networks as SDN solution: leave the underlay network as it is, and build completely new virtual network on top of it.

Before we start looking for the answer of which network programmability is the best, let's discuss NFV quickly. Network Functions Virtualization (NFV) is a network architecture concept that proposes using IT virtualization related technologies to virtualize entire classes of network node functions into building blocks that may be connected, or chained, to create communication services. So instead of having dedicated hardware for router, switch, firewall, cache engine, DPI, BRAS, NAT etc. we can run those network functions as software on top of common x86 hardware.

That's not a new idea either, is it? Before network devices use dedicated hardware with either "merchant silicon" off-the-shelf chip or vendor's designed-specific ASIC, we used to have Linux firewall or Linux router. So we used to have network functions running as software on x86. What's new? NFV brings the idea to not only virtualized the network functions but to connect them as well, known as "Service Chaining", in order to provide benefits to the business such as time reduction for service provisioning, and dynamic and elastic scale for network services.


Obviously not all network functions make sense to be virtualized. For Network Forwarding function with high throughput, high bandwidth, stateless and predictable, using designated hardware or custom Network Processing Unit (NPU) is a better way. But for many Network Services function with low to medium throughput, stateful and unpredictable, this is the area where virtualization on x86 can shine. In short, when you need more muscle functions, it's better to use special designed hardware. When you need more brain functions, it's better to virtualized the functions.

Now we reach the $1 million question:
How to bring SDN, NFV, Overlay, Programmability etc into reality?

Based on my experience working in this space the past few years, to make any SDN/NFV solutions successful in real world:

1. It must solve Real business problem

Different customers have different business problem to solve. Separation of control plane and data plane as offered by OpenFlow may not be interesting to others outside research or academic institution.


For Massive Scaled Data Center or SP Data Center or Cloud provider, what matter is the automation of new services to scale the multi-tenancy environment. Deep programmability or network overlay may be interesting to support application mobility. For Service Providers that have invested heavily on the WAN infrastructure, what important is to have deep network programmability to monetize the current infrastructure. WAN optimization is another requirement, as well as providing SLAs to their customers. For Enterprise customers, especially the ones that only use network infrastructure to support their core business, the requirement is to have auto provisioning and device config management to provide services.

2. It should be orchestrated to deliver business outcome

SDN to separate the control plane and data plane, and NFV to have network functions and software running on any open standards-based hardware, mean nothing if they don't deliver business outcome. A new component called Services Orchestration should be used to provide automation, provisioning and interworking of physical and virtual resources in order to enable new service offering.


The industry agrees that the combination of these capabilities offer business a path to agility and dynamic networks. To optimally benefit from virtualization, the intersection of all three must be addressed – and on a carrier grade level which means services can be scaled up as well as down easily with complete reliability and security. The confluence of SDN, NFV, and orchestration takes advantage of cloud economics and provides service automation so we can nimbly address new market opportunities and dynamically modify existing services to best benefit the business. With this approach service innovation dramatically changes from weeks and months to minutes and days.

3. It has to follow industry standard and open architecture reference

We don't have industry standard yet for SDN architecture reference. However, ETSI - European Telecommunications Standards Institute has already published NFV Reference Architectural Framework as shown below.


The three main components of the reference architecture:

- VNF is the actual Network Function application, for example virtual router, virtual switch, virtual firewall, virtual load balancer, virtual web filter and so on, along with the Element Management System (EMS)
- NVF Infrastructure consists of virtualization layer that provides abstraction between the physical resources (compute, storage, network hardware) and virtual resources, where we can run the VNFs
- NVF MANO includes Virtualized Infrastructure Manager as resource manager to manage NFVI, VNF Manager to manage the life cycle of the VNFs, and the Orchestrator manager to orchestrate the overall solution

ETSI even defines formalized NFV use cases with potentially virtualized functions.


4. It should be modular, loosely coupled and extensible

Any SDN/NFV solutions will be built using various components. Modular architecture provides benefits since it can be scaled and extended when it's needed. One important note here is: every component should be connected as loosely coupled, and not "locked". It means the solution is expected to run in multi-vendor environment and will have lots of integration to build the whole system.


The picture above shows an example of SDN solution architecture. All physical and virtual resources are managed by Management and Orchestration box, that consists of network control, compute and storage control and service control, with cross-domain orchestration to manage all of them. Customer facing service portal is common to provide self service to the users. Management and Orchestration box provides northbound API for the application, and use various southbound API from all the control layer to the resources. Many other boxes like billing system, trouble management, inventory and service assurance can be attached to have the end-to-end solution.

5. It has to use Open API

In order to make sure all components can interconnect without any vendor locked-in, the solution must use Open API between each component. The Northbound API between Management/Orchestration and Applications, for example, can use REST API, NetConf, SOAP or even XML RPC with standard data format like XML and JSON. The Southbound API from Management/Orchestration toward compute, network and storage resources can use NetConf, OpenFlow, SNMP, Telnet/SSH or even device specific API as long as it is open.

6. It must have continuous development and support, and embrace FOSS

There are many components from SDN solution that can embrace Free and Open Source Software (FOSS). The operating system for the Compute resource, for example, can use Linux. Virtual Infrastructure Manager can use OpenStack. Network controller can use OpenDaylight. All programming languages used like Python or Java are free to use. The main benefit to embrace FOSS components in the solution is we can get continuous development and support from the community, and we don't need to create all the components in the solution only some focused components that we think matter the most.


Do you think there is SDN/NFV solution today following the points above?

I can give you one example of SDN/NFV solution that complies with all the six points above. And you may be surprised when I tell you that kind of solution comes from a network vendor that is known to be closed source: Cisco. Yes, Cisco with its Virtualized Managed Services (VMS) actually follow all the points in the list as explained below:

1. VMS solves SP's real business problem in managed services

SPs that offer VPN solution have seen the strong adoption by large and medium enterprises, however the aggregate growth rate is pretty much stable (around 5-7% in many countries). This requires them to find the blue ocean, a new market with expansion opportunity such as Small and Medium Business. However, SMB is very price sensitive and has adopted public cloud services to shift the workload. Huge number of SMBs provides indeed big opportunity, however the solution must be attractive from pricing perspective, time to market/provision the service, and integrated or bundled with other service offering.

2. VMS is orchestrated to cut down time to provision

VMS uses the idea of cloud-based managed service by moving the network functions from CPE to SP cloud.


The CPE is moving to be less and less intelligent, to a point where it becomes L2 network insertion device only. Virtualized Network Functions in SP Cloud are service chained to provide new service offering to the customer. All initiation and configuration of the VNFs and CPE are done automatically to provide agile service provisioning to the end customer. The CPE even uses zero touch deployment mechanism to reduce the requirements to have a technician sent to the location only to fix the device. Once the CPE is powered up, it will call home to register itself to the system and start building encrypted tunnel to its assigned service chained VNFs.

3. VMS follows ETSI architecture reference

I can only provide the following diagram to show Cisco VMS architecture.


However, I can mention that Cisco VMS follows ETSI architecture reference:

- Cisco has extensive list of VNFs from virtual router to virtual web filter, and there is nothing can stop the solution to use third party VNFs
- NVF Infrastructure uses Linux KVM as virtualization layer, running on top of physical hardware resources for compute, network and storage. Again, even though the solution is built using Cisco UCS and networking products, it can accommodate third party hardware as well
- NVF MANO includes OpenStack as Virtualized Infrastructure Manager, Cisco ESC as VNF life cycle manager, and Cisco NSO (previously known as Tail-f NCS) as the Cross Domain Orchestrator

4. VMS is modular, loosely coupled between components, extensible

VMS solution uses modular architecture. There is no locked-in between components. The solution can be integrated with customer existing setup. It can also be extended beyond the main functionality when needed.

5. Yes, all APIs between VMS components are open

The self-service portal can send the service request to orchestrator using Netconf. NSO as orchestrator can use NetConf or REST API to instruct Cisco ESC to initiate the VNFs, which requires ESC to tell OpenStack either with REST or Nova Client API to spin up the VMs. Cisco NSO can provision the configuration of network devices either using NetConf, SSH, REST or device specific API.

6. VMS embraces FOSS

As you can see above, Cisco VMS embraces FOSS like OpenStack, Linux, KVM along with open API to connect them to Cisco specific components. By doing that, Cisco can focus on the component that matters the most like the orchestrator. And innovation with life cycle manager or end-to-end system integration is the competitive advantage from Cisco compare to the other vendors.


Before you accuse me as Cisco fanboy, let me make a statement first: I'm not trying to sell Cisco solution here. Cisco has the best sales force in the market to do that. I just want to give example that even a market leader like Cisco is willing to adapt; to change from closed source to be more open as shown in its VMS solution. This is a big shift in networking industry. And I believe we will see more and more solutions that are inline with the six points above.

And if you are in a company that consumes networking technology, next time any networking vendor comes to offer their SDN solution, you can ask them questions if the solution offered really solves your business problem, how the solution is orchestrated to deliver business outcome, whether the solution follow industry standard and open architecture reference, ask if the solution is modular so can be extended easily without any locked-in to specific vendor, check if it supports open API, and if they have plan to embrace FOSS to ensure continuous development and support.

That, I believe, is the only way to bring SDN/NFV into reality.

Friday, May 01, 2015

Skill Development Planning by the Dozen


I’ve been going to Cisco Live as one of the speakers for several years now. As Cisco employee, you can go to Cisco Live (for free) only if you are a speaker, or part of the World of Solutions exhibition, or if you come for the customers, or to support the network infrastructure for the event.

For the past three years at Cisco Live I’ve been sharing strategy and tips and tricks of how to become CCIE based on my own experience. My part of the session is focusing on skill development planning to achieve the objective, which is to pass CCIE lab exam. There are many technical sessions available during the event, but only very few talk about how to build learning plan and walk you through step by step of sample plan created by someone who has done it. I believe the session material can be applied outside CCIE context, and it’s relevant with my previous post, so I’m going to share it here with some updates.



Robert Grant mentioned that strategy is the means by which individuals achieve their objectives. In short, successful strategy can be achieved by having clear and consistent goal, understanding the environment or the industry as well as our capabilities, and executing with effective structure and system.

You must have a strategy for your skill development. And here are a dozen steps you can follow to build one:

1. Begin with End in Mind

What do you see at the end of the road? What is your objective? What are you planning to accomplish? Having a clear goal can help you to plan on how to achieve it. Your goal can be your one thing. Whatever it is, you must have a goal or objective. If you don’t have it yet, go find one.

To make it easier to digest, I will use an example here. Let’s say today you are a network engineer who puts a goal to become Network Function Virtualization (NFV) Solutions Architect someday.

2. Break It Down

How to eat an elephant? Cut it into pieces and eat one piece at a time. Big goal must be dismantled into pieces so we can understand it well.

What is NFV? What does Solutions Architect do?

As per Wikipedia, NFV is a network architecture concept that proposes using IT virtualization related technologies to virtualize entire classes of network node functions into building blocks that may be connected, or chained, to create communication services. As described by ETSI NFV whitepaper, Virtualization eliminates the dependency between a network function (NF) and its hardware, as seen in typical physical network appliances, by creating a standardized execution environment and management interfaces for the Virtualized Network Functions (VNFs). ETSI defined NFV framework into three main components: Virtualized Network Function (VNF), NFV Infrastructure, and NFV Management and Orchestration (MANO).


If we break down each NFV component, we can see sample of a product or solution that we have to learn:

- VNF is the actual Network Function application, could be run as Virtual Machine (VM). Sample of this are virtual router, virtual switch, virtual firewall, virtual load balancer, virtual web filter and so on
- NVF Infrastructure consists of virtualization layer, that can be server hypervisor such as VMware ESXi or Linux KVM, and physical hardware resources for compute, network and storage. This includes the server host operating system (e.g. Linux), physical server, networking devices and underlying protocols (routing, switching), and storage disk, SAN as well as protocols such as iSCSI, NFS and FCoE
- NVF MANO includes Virtualized Infrastructure Manager like OpenStack, VMware, SDN controller such as Open Daylight, VNF Life cycle manager and Cross Domain Orchestrator such as Tail-f NCS

Don’t forget the northbound/southbound and interface to connect between the components: Rest API, OpenFlow, NetConf, data format with Json and XML, and if you are into data modeling: YANG. And some of the components require customization and module expansion using programming language such as Python and Java.

Solutions Architect is someone who can articulate problem statements, solution capabilities and the gaps between the two. He or she must correlate business issues around technology and processes, and able to create an architectural solution specific to a given customer or segment. Solutions Architect needs to interpret business requirements and strategies, and mapping them to solution capabilities, and driving the integration of the solution into an existing infrastructure, which would drive systems integration and implementation approaches.

Solutions Architect skill requirements go beyond the end-to-end technical architecture:

- deep expertise in several technology domains (network/infrastructure, data, applications/middleware)
- fluency in network technologies and related advanced technologies
- expertise in several soundness disciplines (availability, security) as well as operational disciplines (systems management, change management)
- fluency in key IT business architecture areas including business process design and governance

To become Solutions Architect one must possess customer skill, business oriented mindset, communication, ability to collaborate, planning skill, leadership, and problem solving skill. Above all, it is important for a Solutions Architect to be able to solve the puzzle, put all the pieces together, and to connect the dots.

3. Self Assessment

Now you have a better picture of your goal, it is important to understand where you are standing today and see the gaps. Bruno, CCIE program manager and my co-speaker at Cisco Live, is very famous with his mantra: "Know what you don’t know".

If you know what you don’t know, then you can build the plan to acquire the knowledge. My advise is to build some kind like checklist, let’s say listing both the NFV components and the Solution Architect skillset from the above point. Then make self assessment about your current situation with scale between 1 to 5 with level 1 as the lowest (no knowledge at all) and level 5 as the highest (posses the expertise to design, implement and advise others, being the “go-to guy”):


- how good are you with linux OS? (1-5)
- how good are you with hypervisor e.g. ESXi, KVM? (1-5)
- how good are you with OpenStack? (1-5)
- how fluent are you in Java? (1-5)
And so on.

You can do the same with non-technical skills:

- how is your communication skill? (1-5)
- how is your ability to articulate solution? (1-5)
- how good is your problem solving skill? (1-5)
- how good is your understanding of customer business? (1-5)
And so on.

4. Define Target Performance Level

This is the question I always ask from time to time: How do you define success?
If you have the list of required skills to become NFV Solutions Architect from both technical and non-technical, and you have done self assessment to understand your current situation, what level should you target for each skill?

In a perfect world, we need to be 5 in everything. But we don’t live in a perfect world.

The challenge will be the time. Our time is limited so we have to prioritize. We need to define which skills we have to develop to reach level 5 and which skills we can develop only to reach level 2 or 3, at least for time being.

To pass CCIE Routing & Switching lab, for example, you must possess level 5 of core knowledge such as IGP Routing, BGP, MPLS. They are defined as core knowledge due to the amount of exam questions about the topic, and in the lab that technology is the foundation that put everything together. You can’t build a working solution if you are unable to make the core technology works. You may reach only level 3 for QoS or security, and still able to pass the exam since they are not the core knowledge.

But how we define target performance level for NFV Solutions Architect?
My advise is to start from the top. NFV solution comes from the business (top) to the physical implementation (bottom).

Solutions Architect must be proficient with the top level: business requirement and strategy, and end to end solution architecture. You should target for level 5 on that. Then going down to the translation of the requirement into the technical solutions. Then going down to how the orchestration can manage multiple domains. Once you are good with all those, you can go down to virtualized infrastructure manager such as OpenStack. If you still have time, build capabilities on VNFs, hypervisor and host operating system. Then all the APIs and interfaces between components. Then programming language, and so on. Try to target the highest level on the top, and moderate level as you go down.

Nothing stopping you to pursue and master physical network knowledge first. But if you are really good in individual technical component, but can’t understand the business driver as well as the overall solution, then you are still at engineer level. A very good engineer perhaps, but not a Solutions Architect.

5. Use Tree Traversal for Development Planning

To give point 4 more concrete example, you may want to use Tree Traversal as I wrote in my previous post. It offers two different approach in visiting each node in a tree data structure:  Depth-first, go down first e.g. first child, then grandchild before second child, and Breadth-first, go across first e.g. first child, then second child before grandchildren.


Your decision to pick which approach, depends on your current situation. Perhaps you are in a work environment where everyone is expected to become a domain expert first, hence you may choose Depth-first. Or perhaps you are being supported to become a Solutions Architect and it is better to start by knowing the whole picture to begin with, then go with Breadth-first approach.

6.  Build Learning Path

How to build learning path for non-technical skills?
Indeed certain skills such as communication, leadership or connecting the dots usually comes with experience. But you can still equip yourself with some books or courses that teach foundation knowledge of those topics. And you don’t have to take MBA to understand the business, but it may help to look at the program curriculum and pursue the knowledge defined in it.

For technical skills, the path can be set by following certification program. Not everyone is a big fan of certification, but the program creator usually spent quite amount of time to define the level of expertise as well as the scope of each level, why not leveraging this instead of reinventing the wheel? And you don’t have to take the exam if you don’t want to, just follow the learning blueprint of the program. You can use Cisco certification for networking, RedHat or Linux Foundation for Linux OS, VMware for virtualization and hypervisor, Mirantis or RedHat for OpenStack and so on.

7. Get Feedback

When you are in process of learning something, it is important to get a feedback to measure your progress. The exam in certification program can be a feedback: if you pass it means you have reached the knowledge level as defined by its creator. Or you may want to get a feedback by getting involved into the discussion. Find out who is the domain expert and try to discuss with him or her to validate your assumption of what you think you already know. Or provide assistance for those who have just started to learn. Seek a feedback by teach the knowledge to others. It was Albert Einstein who said "If you can't explain it simply, you don't understand it well enough."

8. Remove Barriers to Knowledge

I’m just stating the obvious here, but please make sure you have all the access to learn the knowledge. From a simple Internet connection, training material, online library, whitepaper, books, to lab equipment to practice and allocated time and place to study, make sure you don’t have anything to stop you in learning.

9. Make Learning as Habit


In The Power of Habit, Charles Duhigg takes us to the thrilling edge of scientific discoveries that explain why habits exist, and how the right habits were crucial to the success of Olympic swimmer to CEO. There are many examples in the book of how implementing so-called keystone habits can earn billions and mean the difference between failure and success, life and death.

You have to make learning as your habit. And you can do that by starting it slowly, but be consistent. If you plan to spend at minimum an hour a day to learn something new, then do that and stick with it. Later you can increase the amount of time you want to allocate. Later, once it has become your habit, you will find that it is part of your daily routine and something you can’t skip.

10. Take Classroom Training

If you asked me 15 years ago if classroom training is necessary, my answer would be no. Why would you waste your time sitting inside the class, listening to someone who may know only how to teach, instead of doing the reading yourself and trying to apply the knowledge directly? I passed all my CCIE and CCDE exams with a very minimum number of trainings.

But if you ask me again now, my answer is: you may want to consider to go to classroom training. Not because you can’t learn by yourself, but the training can accelerate your learning and shorten the time required to understand the new knowledge. We are all busy so it is good to have someone helping in explaining complex subject to us. Just make sure the instructor is someone who has experience in applying the knowledge in real world, so you will get the knowledge not only the one from the training material.

Another reason is classroom training gives us break from our daily work. You are excused not to reply to your email immediately or to pick up the phone since it is in silence mode: you are inside the classroom listening to the instructor! Your boss or colleague or even customer can be informed in advance and usually they respect your training time and give some space.

11. Exploit Strengths, Manage Weaknesses

By now I believe you have already know what are your strengths and weaknesses. If communication is your strength point, exploit it. Put yourself as the key person to discuss with the customer to get the requirement. So even if technical skills are your weaknesses, you can manage them by delegating the technical tasks to the engineers.

It is important to emphasize that as Solutions Architect your strength point should be the one that is closer to the business on the top. This can cover your weakness at the bottom such as technical implementation, at least for the time being while you are developing the skills. So if you feel that technical detail is your only strength, while you really have to develop your business mindset and communication skills, exploit it by becoming Subject Matter Expert in some technical domains. You are not a Solutions Architect yet, not from the business people perspective, but at least you have a good value to contribute to the team and slowly you can develop the required skills to become one.

12. Believe That It Can Be Done

Last but not least, you have to believe you can achieve your goal. Your mind can play trick with you. Many have not even tried to pursue their goal because they don’t believe it can be done. Skill development plan is important, but what more important is the process in planning it. Start developing the plan and follow it. Achieve small success at a time. Believe it is possible as long as you continue to execute your plan.

Only by believing that he is the one, Neo is able to stop the bullet.



So start building your career strategy now using the points above as guidance. Then implement it with commitment, consistency and determination. Don’t forget to have fun during the process.

Good luck.

“We must learn how to be the CEO of our own careers"
-- Peter Drucker