Thursday, March 05, 2015

SDN, NFV and Skill Development for Network Engineers

I came to Cisco Brussels 14 years ago to take my first CCIE lab. I didn’t pass that time. I went to Tokyo a month later and got my number there. Several years later I kept coming back to Brussels to pass my two other CCIEs.

Many people say there is no value anymore in taking CCIE these days. With SDN and NFV, everything will be done "auto-magically". We don’t even need network engineers anymore! Yeah, right. Last week I went back in Brussels to work on Network Control System, multi-vendor network device management tool from Tail-F that was acquired by Cisco June last year. NCS is the cornerstone of Cisco Network Service Orchestration framework for Cisco SDN and NFV solution offering. And I’m here to tell you that the world still need lots of network engineers, and CCIEs, or those who have CCIE-level skill set.

But first, let me talk more about NCS, a service orchestration for real-time service provisioning across multivendor networks.

Network devices were, and are still, configured using CLI. Then SNMP was created to help. Soon, we realized SNMP is great to monitor the network but it fails to become configuration management, as stated by RFC 3535. So more than 70% networks today are still managed by CLI. Arista Networks CEO Jayshree Ullal once said “it’s the way real men build real networks today.” And when we need automation, we create script to send sequential CLI command to devices.

When we use CLI, or Web interface, or SNMP, or send the command over REST API or Netconf to the device directly, this is called Stove Pipe approach. Tail-F NCS puts itself in the middle of the communication between all those protocols with the network devices or Managed Objects (MO). Think its function as mechanism to “normalize” devices configuration into one standard data model then push that configuration into devices using one standard protocol. NCS supports multiprotocol and multivendor by design.

NCS uses YANG, a data modeling language that represents data structures in Extensible Markup Language (XML) tree format. The data modeling language can be used to model both configuration data as well as state data of network devices. YANG can be used to define the format of event notifications emitted by network devices and it allows us to define the signature of remote procedure calls that can be invoked on network devices via the Netconf protocol. Network Configuration Protocol (Netconf) provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple remote procedure call (RPC) layer. YANG was published by IETF as RFC 6020, and Netconf was published as RFC 4741 and later revised and published as RFC 6241.

In short: The Netconf protocol allows a manager to set configuration, query configuration and state and execute actions on the device (much like SNMP). The YANG models describe everything there is to configure, monitor, admin actions, notifications for each device type and version (much like a MIB).

Many network management tools are misleading since they are actually only device management. What we really need is a service management. When we want to enable service, let’s say MPLS L3VPN, we may have to configure multiple devices. So it’s a network wide transactions based tool that we need. NCS acts as central repository to store network services logically using YANG data model for data structure. The structure represents service instance, and network configuration and state. It then maps between service operation to network configuration changes. NCS has transactional integrity. The service configuration is pushed using Netconf to all relevant network devices as one transaction. So it has to be successful in all, or nothing at all. If one device is failed to accept the configuration change, then all devices must be rolled back to its previous state. And there is no internal order inside a transaction, it is a set of changes, not a sequence. And any parallel transactions do not interfere with each other.

So what’s the relationship between NCS and SDN/NFV?

Cisco has been talking about Evolved Services Platform (ESP), that uses software-defined networking (SDN), Network Functions Virtualization (NFV), Open APIs, and advanced orchestration capabilities to forge a flexible and modular platform. With the Cisco ESP, and the physical and virtual infrastructure service delivery capabilities of the Cisco Evolved Programmable Network (EPN), service providers can quickly deploy new personalized offerings through integrated services modules. Imagine offering prepackaged tiers of enterprise services with default features, security, and service-level agreements (SLAs), that customers can select from an online portal and activate with a click of a mouse.

So the network operator can create a catalog of customized service offers that they make available through the active service catalog. The operator uses the business logic of the network service and resource orchestration modules to start up the virtual machines, activate the Virtualized Network Functions (VNFs), and dynamically create the specific service function chain, which creates appropriate linkages that support the service profile and steer the customer traffic through them. That is the idea behind Virtualized Managed Services solution, Cisco ESP services modules that may be deployed today.

And NCS plays important role as the Orchestration Engine in the solution.

Skill Development for Network Engineers

With the long explanation above, if you are a network engineer, what should you do now? What should you learn? How to develop skills to be able to work with the new networking paradigm like SDN and NFV?

As I wrote in my last blog post, someone needs to translate business requirement into technical requirement. That someone needs to understand business language as well as the technical solutions. Then the same person or someone else needs to create end-to-end architecture just like Virtualized Managed Services. Another person needs to design the service profile and create service catalog. Tool like NCS still requires input from someone to make those services into YANG model. And even if all physical and virtual infrastructure will be provisioned and managed using tool, we still need people who are proficient with network, compute, storage as well as various virtualized network functions. There are still many network protocols today such as OSPF, ISIS, BGP, overlay like MPLS or IPSec tunnel, that will continue to be used in the solution. So you still need to know networking technology in details. We still need many network engineers.

Any SDN/NFV solution and implementation will have so many components connected to each other using different types of API. There are lots of moving parts. Lots of complexity. We still need CCIEs, or rather those who possess CCIE skill set to handle the complexity. Then they have to adapt and to learn something beyond networking.

We need those who want to go up, to get closer to the business, and those who want to have the wide and broad knowledge beyond networking: hypervisor, OS, programming logic, scripting, API and so on. Dave Tucker suggested the transition from NetOps to DevOps, and he would predict that the Network DevOps engineer will need:
  • Strong Networking Skills
  • Knowledge of Linux System Administration
  • Experience with Puppet/Chef/Ansible/CFEngine/SaltStack would be desirable
  • Scripting skills in Bash, PHP, Ruby or Python
  • Ability to work under Source Control (git)
  • Experience in consuming (REST) APIs
  • Experience with OpenStack and OpenStack Networking
  • Appreciation of Software Defined Networking (SDN)
  • Knowledge of Agile Methodologies
  • Knowledge of Test-Driven Development
  • Ability to write Unit and Integration Tests
With so many things to learn, where and how to start?

Introduce tree-traversal. It is a form of graph traversal and refers to the process of visiting each node in a tree data structure in a systematic way. Basically in the example above there are two ways to traverse a tree: 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.

Let’s look at my tree-traversal above. I used Depth-first approach. So I spent my time to learn Networking technology first, in Routing & Switching, then Service Provider and Security. Then I spent time to learn Compute with various Linux OS distributions. And these days I put my focus on SDN/NFV technology from Cloud, Virtualization and network programmability.

So which way is the best for you? It depends.

You may go with Depth-first like me: learn networking until CCIE level, then go deep with Linux, before moving to scripting, API, orchestration and so on. Or you may go with Breadth-first: learning networking to mid level, then switch to Linux, then try scripting a bit, then get some hands on with OpenStack, then coming back to learn networking in more detail, Linux in more detail, and so on. Both ways have pros and cons.

And you may use certification program to help you to learn. For networking, Cisco certification program is still the gold standard. For linux OS you may go with RedHat or Linux Foundation. Even OpenStack has certification program from company like Mirantis or RedHat.

If you do use certification program to learn, please remember one thing: in learning, process matters. At work, obviously outcome or result matters. But when you learn something, don’t focus on the outcome or to get the certification, but focus on the process to gain the knowledge. So you will always be ready to learn any new skills and technology.

And that, I believe, is the only way to become the next generation network engineers.

So stop reading now. And start planning for your skill development.
Good luck.

“Plans are nothing; planning is everything.”
-- Dwight D. Eisenhower

Tuesday, October 07, 2014

Go Up or Go Wide

You say, the world doesn't need CCIE anymore with the raise of SDN. I say, we still need CCIE, but those who can adapt. You say, my words are just futile last ditch effort to show the importance of CCIE certification. I say, even I still work for Cisco but I don't work for CCIE program, and I get paid not because of my certifications.

If we have data, let's look at data. If all we have are opinions, let's go with mine
(Jim Barksdale, former CEO of Netscape )

So let's look at the data to make the discussion more fruitful. If you look at Cisco revenue of each product line for the past 5 years, we see there is decline for NGN Routing and Switching business. And yes, Data Center business is growing in fast rate. And Data Center business includes unified computing, next generation fabric, cloud and most Cisco SDN solutions that are available today.

However, if you do a simple math you can see the combined revenue of Routing & Switching business is still close to half Cisco revenue as of today. We are talking about more than 20 billion USD business. It's declining indeed, but it will take number of years for Data Center business with the same growth rate to reach the same size of revenue.

And below is the revenue comparison between product vs. service.

It shows that the hardware business is declining, but the service business is increasing in size. It can be interpreted freely as there is still demand for those who are able to deliver service. It means as long as you the network engineers don't lock yourself in to particular product, you should be fine. Don't become a product admin but try to really understand the technology. Learn deep about how protocols work not only how to enable the feature.

So I say, if you are still interested to work in computer networking, you can continue pursuing CCIE to gain the skillset. Long gone those days when CCIE gets paid only just because of being certified. You need to be in the right company, you need to be in the right position. You need to be relevant to company's business.

But the requirement for network programmability, virtualization and overlay is real. Those are what SDN has promised even though we are still yet to see the mass implementation of it. Company like Cisco has released its own SDN solution with Application Centric Infrastructure (ACI) and it requires different type of skillset to understand and implement it.

We, as network engineers, must evolve. We, as CCIE, must adapt.

So my message to all CCIE out there: the time has come for you to choose.
Either to go "up" or to go "wide".

We are all here in this field to support company's business. The promise of SDN model is to create abstraction layer to hide the complexity. There is a growing need for customers to put main focus to their core business activities, and let the SDN solution to deal with how to provision and to run the networking infrastructure. There is a dream in the future where customers can just describe their business requirement and what they need from the infrastructure, and let the SDN controller to automatically re-program all the network elements to answer the requirement.

But someone must translate that business requirement into technical requirement. That someone needs to understand business language as well as the technical solutions. That someone has to show the tangible outcome like Capex and Opex reduction that any SDN solution can offer to the business. That someone must be familiar with PERL - performance, efficiency, risk, liquidity of the company, at the same time at least understand the position of PERL language within SDN big picture.

That's go up.

These days I work with several "Cisco" Solutions Architects who posses different type of skillset. Some of them are not even certified in CCNA. They know very little about IGP, BGP and MPLS, but very proficient with hypervisor, OS, scripting, API and SDK. They speak Scrum. They are object oriented type of persons. They always see the overlay and virtual layer while most people still see the physical infrastructure.

Their type of skillset is still incomplete. CCIE type of skillset is far from complete either. Don't expect one type of skillset to dominate the workforce of the future. But imagine the next generation network engineers who possess both types of skillset.

That's go wide.

Possess CCIE skillset only is indeed no longer sufficient. Know only how to pass CCIE exam is even very less useful these days.

Go up or go wide is not similar with red pill - blue pill options. Both options are red pill. Both options are real.

Welcome to the new reality in computer networking.

Disclaimer: Cisco revenue is being used here due to its position as the market leader in computer networking industry. And all the information to make the graphs above is available publicly in Cisco annual financial report. You are more than welcome to analyze other vendor's revenue if you wish.

Friday, September 19, 2014

Some New Old Books

The Lean Startup approach is for companies that want to be more capital efficient and that leverage human creativity more effectively.  It relies on “validated learning,” rapid scientific experimentation, as well as a number of counter-intuitive practices that shorten product development cycles, measure actual progress without resorting to vanity metrics, and learn what customers really want. It enables a company to shift directions with agility, altering plans inch by inch, minute by minute.

The products lean startup builds are really experiments: the learning about how to build a sustainable business is the outcome of those experiments. That information is much more important, because it can influence and reshape the next set of ideas. And it uses the Build-Measure-Learn feedback loop at the core of Lean Startup model.

In short: build Minimum Viable Product (MVP) or Minimum Viable Service (MVS), launch, collect data to learn in order to perfect the ideas. Or if it doesn't work, fail fast, and pivot to another ideas.

Rather than wasting time creating elaborate plans for new product, it's better to launch quickly and find a way to test the idea continuously, to adapt and adjust before it’s too late.

How to decide which ideas to develop first?

In Four Steps to the Epiphany, Steven Blank offers the practical and proven four-step Customer Development process for search and offers insight into what makes some startups successful.

Rather than blindly execute a plan, The Four Steps helps uncover flaws in product and business plans and correct them before they become costly. Rapid iteration, customer feedback, testing your assumptions are all explained in this book.

What will be the next step if we want to use lean principle to launch new product/service?
We still need to create a plan. But don't waste time in creating plan.

Business Model Generation explains the most common Business Model patterns, based on concepts from leading business thinkers, and can help us reinterpret them for our own context. We can learn how to systematically understand, design, and implement a game-changing business model--or analyze and renovate an old one. Along the way, it will make us understand at a much deeper level our customers, distribution channels, partners, revenue streams, costs, and our core value proposition.

Business Model Generation advises us to use "Business Model Canvas" to analyze quickly any product/service we want to build. We can even use a modified model which is the "Lean Canvas" that is closer to the lean startup principle.

Each of us just need to spend few minutes to learn about the Lean Canvas model in order to use it.

Ideas are cheap. Execution is everything.
Think, build, launch. Get feedback, iterate, update. Repeat.

Tuesday, July 22, 2014

Six Phases of Network Evolution

Last month I was asked to speak about Next Generation Networks at Indonesian Network Operators Group (IDNOG) forum. Whenever I speak about this subject with my customers, I usually use top down approach: started by talking about the business drivers and requirements, NGN architecture, to high level and low level design, before going deep into details to each supporting technology.

This time I decided to take a different approach. Instead, I tried to demonstrate how to build a new SP network from bottom to up. The objective is to show how the network can be transitioned from the simple one that offers a single service, to the one that carry multiple services and become resilient Next Generation Networks. I don't know if the message was received by the attendees, but I run out my 30 minutes time so I continued that effort by conducting the webex session few weeks ago.

The presentation I made for that session inspires me to write down about the six phases of network evolution below. And the phase will end up with the one thing that has become hot topic these days: Software Defined Network (SDN).

Phase 1: It begins with connectivity
When we build the network from ground up, the first and most important thing to focus is all about connectivity. Site A can connect to site B. User can access the server. This means we need to build the physical topology, enable layer 2 and L3 routing protocols (IGP, BGP) to provide connectivity. And it is common to deliver only single service (Internet/data) on global routing table.

Phase 2: Converged network and multi-services
Then comes the next requirement to use the same network to deliver multiple services. MPLS is definitely the protocol of choice by industry to provide overlay in the network, even other tunneling protocols can still be used as long as the objective is achieved. The network now must be able to provide L3VPN and L2VPN services over MPLS, High speed Internet, voice over IP, IPTV for both multicast stream and unicast video on demand, even mobile services and multimedia. Convergence happens in access layer too: one IP MPLS network to carry different types of last-mile access networks technology.

Phase 3: Scalability
When we have big number of users accessing multiple services, especially for Service Provider, scalability factor becomes important. Nowadays we use IGP routing protocol only to connect between SP routers while the customer networks are carried using BGP. IGP must be fine tuned and link-state protocol area design must be done properly to make it scalable. BGP RR design becomes crucial when the number of BGP speakers is high. Multiple BGP AS must be able to work between each other to carry the services seamlessly. Even the design of every part of the network need to be unified and consistent in order to make it easier to scale up.

Phase 4: Services level differentiation
QoS will kick in when there is congestion in the network. When there is no congestion, QoS is applied to limit the service in order to differentiate service level provided to end user. QoS implementation in Service Provider network is obviously different with Enterprise network. In SP it's common to share network infrastructure that spread across the nation connected with WAN links, with potential of network congestion, to serve big number of users trying to access multiple services. QoS makes sense to be applied to prioritize certain type of traffic, or to charge the customer differently depending on the agreed service level. In Enterprise network such as LAN campus network or data center, it is already considered low latency network with sufficient bandwidth pipe hence the QoS implementation focus is most likely on the WAN link.

Phase 5: High availability and resiliency
The target for HA and resiliency in the network depends on how much we can tolerate services unavailability. Some customers can afford network downtime for days while others can only tolerate fraction of seconds. Some applications can continue to work, or to resume immediately, when it gets disconnected for more than few seconds while some others can show serious disruption when the network is down within miliseconds. So we need to look at high availability and resiliency from end to end perspective. Physical topology redundancy is good but may not be enough. Link down or network node down detection becomes crucial. IGP can be fined tune to react below 500 ms. Hardware availability combined with NSF, NSR and GR may be able to provide 0 packet drop during route-processor failover. BGP fast convergence is done in forwarding plane, even in control plane it still relies on IGP convergence. Multicast streams can be active-active and in parallel using path diversity to provide always-on IPTV service. MPLS TE and IP FRR may be used to achieve sub-50 ms while waiting for the IGP to fully converged, in exchange of more complexity in the network. And infrastructure security is another factor to consider to ensure network availability.

Phase 6: Manageability, agility and efficiency
"Simplicity is the prerequisite for reliability". In order to provide reliable services it should be simple enough to run the network. Some believe if network management works as expected we won't even talk much about SDN. The fact that the network today has become very complex to manage, even with various management tools available in the market, makes many of us are looking for the solution that seems to be promised by SDN. We still need to run lots of management protocol like SNMP and RMON. We still need to secure management channel through SSH or other encrypted channel. But now we want the network to be agile to adopt to the changes that come from lots of new applications. We need to be able to provision new services quicker. We are talking more and more about automation and network programmability. We want the network to be efficient. We want to hide all the complexity that happens in the network to make it efficient for the operator to run and manage it. And SDN may be able to do so by providing the abstraction to provide the simplicity to run the network.

In the end, with the amount of complexity built up when the network transforms from one phase to the other as above, it's clear why SDN looks promising. It's easier now to understand why people believe SDN is the answer.
Because it's simply the part of the network evolution.

Friday, May 02, 2014

The New Cool

I thought it was cool to be an MCSE.

The year was 1999. I didn't have any background in IT. I had just graduated and got my degree in Mechanical Engineering, and was struggling to get a job in that field. That's why I switched to IT, and the first thing I learned (FYI my previous computer skills were Warcraft and Doom) was Windows NT server and workstation. For someone without any IT background, Windows NT looked very interesting at that time! So I thought it was cool to be an MCSE, until I attended a CCNA course.

I thought it was cool to be a Network Engineer.

I felt in love to computer networking since the first day of CCNA training. I loved every moment during the 10-day course and in the last day I passed the CCNA exam. There were not many CCNA around during that time, so the certification landed me my first real job as network engineer early 2000. I thought OSPF was so cool, IGP redistribution was amazing, and BGP policy between different AS was an art. And I thought it was cool to be the guy who managed and monitored the corporate network, received customer calls and performed troubleshooting tasks almost every day, until I heard something about CCIE.

I thought it was cool to be a CCIE.

The company was crazy about CCIE. They spent lots of money to get the engineers certified. They sent several senior network engineers abroad just to take a complete CCIE training package. CCIE was the target for everyone. At that time I couldn't even imagine how difficult it is to pass CCIE, but I wanted to be one. I thought it was cool to be among the first who pass CCIE. Even I didn't get any training. Even I had to sleep at office and spent my nights studying. So then I passed one certification at a time, from CCDA to CCNP and CCDP. Until I passed the written test. I went for my first CCIE lab attempt in Brussels on August 2001. I failed. Then I passed in Tokyo a month later.

At that time, having CCIE made me the special one in the company. And it's eventually landed me a job with Cisco gold partner in Dubai early 2002. Without any interview. Not even a phone interview. The company sent the offering letter over email, and asked me to come immediately once I got my working permit. How cool was that?

I thought it was cool to be a security expert.

Working in system integration company made me realize CCIE skill set is not enough. Even the company was a Cisco partner but we used to have projects where we have to deliver end-to-end system from network, servers, desktops, security, wireless and telephony. So I learned Unix/Linux and took Sun Solaris certification. I went deep with wireless using Planet3 certification and I used to perform wardriving on Dubai streets. I got more and more interested with network security. Not only I took several certifications like CCSP, CEH, CISSP and the one from Checkpoint and SANS, I also set up a home lab with all security tools and honeypots. I did lots of security projects, and I even helped customers to response for security incidents. It felt cool to know something most people don't know. It felt cool to be called a security expert by customers. Until the day I found out some students I caught hacking their university server, were expelled. I thought it was just a curiosity game, for someone like me or for those students. When things got serious and impacted people's life and future, I felt that it was not the right game for me. So I stopped pursuing career in security.

I thought it was cool to have multiple CCIEs.

It was 2005 and those who have multiple CCIEs lived like kings. People hailed them in Internet forum. Their profiles were shown everywhere. They were called the geek in computer networking industry. I wanted to be one. I thought if having multiple CCIEs was special, it may even land me a job in Cisco. So I spent my personal saving to build CCIE Security lab. I didn't want to continue working in security, but looking at my background that track was the closest. At the same time I grew interest in MPLS so I learned it with CCIP. It took me about 6 months and two lab attempts to become a Double CCIE. I was happy and confident my future would be bright. I was one of 600 multiple CCIEs out there. Joining Cisco would be like walking to the main door and getting the offering letter from the reception.

But, I didn't even get a chance for a job interview with Cisco.
I learned that skills and experience alone was not enough. Nor the reputation built over the years and track records of successful project. I left my job in Cisco partner, to comply with Cisco policy not to hire from the partners, but I didn't manage to get even a phone interview. I still needed the network. The human network. The connection. At the end one of my connections in Cisco put my CV through internal reference system. And after years of waiting finally I got in. In 2006 I joined Cisco Advanced Services APAC in Singapore. I still had to use my skills and experience to pass tough interview process, but the first fight was to get noticed.

I thought it was cool to be Cisco Consulting Engineer. I thought it was cool to work anytime, anywhere. I thought it was cool to travel the world.

When I was in partner, I had a chance to work with Cisco AS Consulting Engineers in several projects. I was impressed with the way they delivered the work. I was amazed with the depth of their knowledge. Not only they know how to configure and troubleshoot the network like a CCIE, they also went very deep with the design, the protocols and hardware architecture. And some of them were not even CCIE. So becoming part of Cisco AS was the new cool for me. And I think it's still cool. Who doesn't want to work from the cafe, airport or even the side of hotel swimming pool? Who doesn't want to travel the globe to work with Cisco's large SP and enterprise customers? I like the feeling when I was leading complex migration projects in Malaysia, Vietnam and KSA. I felt accomplished when I was able to help the customers to transform their network. But other Consulting Engineers around me did pretty much the same. As much as I like to work anytime, anywhere, and to travel the world, these are no longer cool to me. They have become a norm. Daily activity.

Once again I used my connections, skills and reputations to try to move to a global team. I felt that I wanted more exposure. More challenges. I wanted to feel cool again. And after a tough interview process (yes, there is interview process even to move internally within Cisco), I managed to get into an NGN global team in 2008. I moved back to Dubai. The team filled up with senior Solutions Architects, they made me feel like the least experience in the team even I had my third CCIE in SP. We did many large scale and complex projects across EMEA together.

I thought it was cool to be a Cisco Solutions Architect. I thought it was cool to be a global consultant. I thought it was cool to provide solution architecture and technical design to answer customer's requirements and problems.

I still like to be a Cisco Solutions Architect. I still like to be a global consultant. I still like to meet the customers to provide solution architecture and technical design to answer their requirements and problems. But I've been doing that for many years.

I like to redesign the whole network architecture for customer in Middle East. I like to design and transform the MPLS backbone for mobile operator in Africa. I like to create architecture blueprint, or build IPv6 strategy for customer in Europe. I like to discuss more about the new SDN, virtualization, network programming and Internet of Everything. But these days I want to have more business-oriented discussion. I like to understand more about customer's business challenges. I like to have more meeting with business leaders from the customer. And this is inline with my MBA study.

I think it's still cool to continue presenting at Cisco Live. 

I still like to meet customers and present a technical session at Cisco Live. I still like to talk about CCIE and CCDE during the event.

I think it's still cool see my name on Ciscopress book someday.
I would like to spend some time to write technical book, but it looks like the time has come for me to make a choice.

I think it's still cool if someday I can become a distinguished engineer in Cisco. I think it's still cool to get Cisco Certified Architect certification.

But at the same time I think it's cool to try to make impact. It's cool to try to transform Indonesian students and young professionals to become globally competitive professionals. Even if I can only transform one person at a time.

I think it's cool to be a 50preneur while still working for Cisco. I think it's cool to build my own organization. To set the vision and goals. To hire people to execute them. Until one day I become a full-time entrepreneur.

And I also think it's cool to be able to spend more time with family. I think it's cool to be able to play snowboarding together with my daughter. It's cool to teach math to my other kids. I think it's cool to drop the kids to school every morning, then to have breakfast with my wife at beachfront cafe, before I start working from home.

So those are my new cool. What's yours?

Tuesday, April 29, 2014

How Much Are You Worth?

"I have a CCIE. But why my salary is not as high as expected?"
"I've just passed CCIE. Why don't I get salary increase?"
"Why my salary as CCIE is far below the market's salary survey?"

Have you heard such questions before?
It's 2014 and I'm surprised I still get emails from time to time asking either one of those questions. I thought the answers are straight forward. But in case you are one of them who sent the email, please allow me to enlighten you.

Most companies pay you based on "perceived value". It's based on opinion of your value to the company. It may have little or nothing to do with the salary range in the market. And it depends on the your ability to satisfy company's requirements.

The opinion can be shaped based on the certification that you have. It may use the market's rate as guideline. It may include your experience into consideration. And usually the opinion is associated to the internal company's rank and salary range.

Now let's go through the following questions:

Do you think you deserve your CCIE?
Do you really have the skill set of a CCIE, or you just know how to pass the exam? Don't bother to answer or throw nasty comments here. If you don't deserve your CCIE, your employer will find it out. Either earlier during the interview process or eventually after you have to perform daily work. And honestly I have no further advice for you.

Are you in the right company?
Obviously if you are a CCIE but you work in company that does not require skill set defined by CCIE certification program, you should not expect much. Sample of companies that still require employees with CCIE skill set are: Cisco partners, Service Provider/Telecommunication companies, Large enterprise, training companies etc.

Are you in the right position?
Let's assume you are in the right company. You have multiple CCIE certifications. But you take a role in Network Operation Center to monitor daily operation. There is nothing wrong with the role, but such task can be performed even by someone who has lower skill set than a CCIE. Obviously to get raise or higher salary you have to move to more senior position in the NOC, or switch to another role like consultant for integration project that requires you to use your multiple CCIE skills.

Are you relevant?
Relevant can mean your skill set is updated with the latest industry's requirement. Relevant can also mean your skill set contributes directly to your company's business. For example: even if you work in large enterprise with complex network, even if your job is crucial to maintain the daily operation, but your company, while it indeed runs on top of the network infrastructure, it does not make money immediately from the network infrastructure but from other product or services, then unfortunately you may be considered as 'overhead' or 'cost center'. You may disagree, but compare the situation with a consulting company that sells your skill set to its customer and they charge based on the number of man days your perform the work. You get the idea.

In summary, if you can see direct link of your expertise and CCIE skill set with the business your company is doing, you should expect to get a better pay. Or you can simply move to another company that will value you more.

And my opinion about salary survey report?
"There are three kinds of lies: lies, damned lies, and statistics."

Sunday, March 02, 2014

DEW Testimony

Thanks to God !! Finally all the effort to be Design Expert is paid off!
I really appreciate to Himawan for his knowledge and passion about CCDE mindset, insight and learning strategy to help my CCDE journey.
They are really enlightening and accelerating.
“Learn from the best to be the best” really works for me.
Thanks Him, great to have you as my mentor!!
All the best, brother :
(Hinwoto – CCDE #2014::4 / CCIE #15026 RS & SP)

Thanks, Hinwoto, for the kind words.
And congratulations once again for your CCDE.

I can't make anyone to pass CCDE. And I don't think anyone can give promise that he or she can make you pass CCDE exam. The only person who can make you become CCDE is yourself. I, and all other CCDE study groups, training vendors, or individuals who spend time to help others to pass CCDE, can only help with knowledge and tips to prepare for the exam. You are the one who has to push yourself to continue learning. You have to gain experience and real design skills. You are the one who will make decision to get certified or not.

I can only show you the door, Neo. You're the one that has to walk through it.

And as much as I like to see people who can pass CCDE after taking my advices or attending DEW, I would like to see more real Design Expert Warriors like Hinwoto.
Not only more certified people.

Are you ready to take the red pill?