There is no such thing as career path.
I’m talking about a career path for an engineer, or those who want to focus and stay technical in computer networking field, for example, for the rest of his work life.
In some organization this can be seen as crystal clear. There isn’t any path at all for technical person. It just doesn’t exist, especially in an organization where IT is considered as secondary team, formed just to support the mainstream of the company’s business. Once an engineer becomes senior and wants to go to higher level he needs to switch to a managerial level, let’s say by becoming a technical manager. And this means he needs to start dealing with other stuff outside the engineering scope: manage people, budget, P&L per head in his team and so on. In this type of organization if one is keen to stay with the current scope as engineer, then he’s going nowhere. It may be even worst since some organization prefers to “refresh” the engineering division aka removing the old timers and put the younger workforces in order to lowering the monthly pay slip.
How about the technology solution company? It has been said many times that the engineering division is the core key of such company. Technical solution by engineer leads to sales that brought the income to the company hence it must be a haven for engineers to work for such organization? Not necessarily. The key here is still the ‘sales that brought the income’. We need to understand that it’s difficult to quantify an engineering work and get promoted. For example, as sales person in the company one can be given a number of annual targets of sales and if he can achieve or even over achieve the number within several years in the row, the promotion certainly awaits. How can we measure how successful an engineer is using a similar measurement? By looking at the number of US patents he produces or IETF RFC’s he has been involved each year? I’m talking about the engineers who work in the field in general to support computer network systems, as many of us are not that lucky and able to sit in the lab to invent the new technology.
So is there a way for an engineer to have career path?
Yes, there is. Some technology innovation company perceives the importance of keeping good engineers to support the business by making higher technical position is always available. This is the company where an engineer can stay technical and yes he can always climb a higher level until he is called “Distinguished” engineer or even “Fellow”. But still in order to achieve such level in engineering one needs to take control and build his own path, and even may need to compromise.
And as far as I know, a good engineer never compromises :)
First of all, the engineer needs to compromise to accept the fact that the technical team is less likely to be involved in any business decision, like an organization changes. Suddenly the company decided to change the model of the way they do business, including restructuring the engineering team, and let’s just inform the engineers at a very late state. One may comeback from a nice weekend just to find out he now needs to work for another team or to report to another manager. And if it’s not enough with the difficulty of an engineer for being recognized for the works he has done, how about moving him to the new team or asking him to suddenly report to new manager, where he has to start over?
Second, the engineer may needs to compromise by manipulating a technical fact in order to support the business. A solution that may not fit the requirement is proposed due to some other reasons including the political and other non-technical stuff, and now it’s time for the technical person to make it works somehow. A young and fresh engineer may just say NO because he still likes to work with the plain truth, just as what being engineer is all about. But if one wants to climb the ladder in the organization, from an engineer moves to senior level, then to become architect, then to a position called as technical lead, or distinguished or whatever, the organization is certainly expecting him to support the business.
From the way I look at it, it’s just another compromise.
The third and the worst compromise of all, because it’s difficult to quantify and distinguish an engineer from the others, the engineer may choose the short cut by doing anything possible to stay on the spotlight. Some said, to climb the company’s ladder it’s all about making the big noise. But how if the engineer is busy making noise but not the real work? The competition among the engineers may become ugly and no real intellectual property really produced, only the noise or the efforts to be the first to announce a half-done work.
I hope the three above are just my imagination, and as the result of too much smoking Shisha while chatting with old friends last night. But unfortunately, some of them are too real.
So if I knew this all along, why bother even to write it down and discuss it? Life is a matter of preference, isn’t it?
It’s true.
The reason why I brought this up is so all of those like me who think and plan to spend the rest of our time focusing on technical, can set our expectation right. Once we choose to go down this path then we should know the consequences. That it won’t be easy and it will be full with obstacles even to move one grade higher. We have to be ready to see those who choose to be in other department, for example in sales, may climb the company ladder faster than we do.
And I also have a secret to share here. I noticed that to get the promotion as technical person, we don’t have to do great job in every task. But we have to do an extra ordinary job in only a single task. Superb work even in only a single project, in the right time and seen by the right people, can bring us much better result. Just like one great rock show can change the world, as Dewey Finn aka Jack Black said in the School of Rock. And obviously we don’t have to be on the spotlight by claiming someone’s work even if we really desperate to get the promotion.
Will it really work?
How the heck I know? I’m a kind of guy who keeps changing the organization everytime I want more. In the past, to get more salary I moved to another organization. To get a better job profile I moved to a different team. I built my own career path by keep moving from one organization to the others. I’ve never been in the same place long enough to see if my ‘secret career advice’ can really work.
So I will tell you all the result once I really get my promotion.
Disclaimer: the writing expresses my own opinion and it has no relation what so ever with the organization I currently work for. It’s based on my own experience moving from one IT organization to the others, as well as my short experience working as contractor.
And I’m not smoking anything while writing this.
Saturday, October 31, 2009
Wednesday, October 21, 2009
How the Lab Exam Should Be
I have just done one lab exam to complete the internal certification from my organization. I can’t disclose more information about it, but what I can share here is my thought of how the lab exam should be done based on my experience taking that exam.
I said it once that certification means nothing without experience. Passing even a very tough lab exam such as CCIE doesn’t turn us to become real expert directly. Certification can only offers the baseline set of skills, and we should build our expertise on top of these skills, not in lieu of them.
But have you ever wondered how far is the skills tested in the lab exam compare to the ones needed in real life? For example, once you pass the CCIE SP lab, do you think you can just jump into a large SP environment or there is still a huge gap to fill in first?
Let me share my thought of how the lab exam should be done. As usual, this is just my personal opinion. And you know what they say; opinions are like arseholes, everybody’s got one.
1. Lab exam should use the real gear
If you look at the equipments in CCIE SP lab, you will notice that they are not the real Service Provider gears. Cisco 7200 is good, but not as P router! As well as the 2800 and 2600 that are still being used in some lab.
SP lab exam should use high end routers such as CRS, ASR and 7600. As P node, if multiple CRS is considered too expensive, a single CRS with physical partition using Secure Domain Routing can do the job as well. And we all know most of the SP core networks use IOS XR, so at least GSR with IOS XR must be available if getting CRS is not an option. For PE node, if the latest ASR9K is still out of reach at least use 7600 with RSP and ES+ card!
Sound too ambitious? Perhaps. But those are the real equipments being used in most Service Provider networks nowadays.
It’s the same case with CCIE Routing & Switching lab. If this track is supposed to simulate a large Enterprise network, at least Cisco 6500 should be available in the lab.
2. Lab exam should simulate the real scenarios
Okay, you are done with the configuration of the device, and then what? Run a ping test? Verify the config? Run the show commands? It’s not enough!
The lab exam should use traffic generator to simulate the traffic. Once we have the traffic in the network we can verify, for example, if the Quality of Services features really work. The lab should ask the candidate to verify the failover scenario. How we can be sure if the fast convergence feature is already configured properly? By checking the BFD neighbors from show commands? By looking at the NSF and GR config only? Yeah, right.
Why can’t we just run the traffic generator and see the impact of the configuration, or failover scenarios, to the traffic? Even the skill to understand and set the traffic generator is necessary to do the job in real world later on.
3. Lab exam should test the knowledge in proper way
It’s not enough to ask the candidate to configure or troubleshoot something in the lab. Some guys can just get the lab questions from somewhere and memorize the configuration to answer them.
The best way to test the in-depth knowledge of the candidates is by asking them to do the verification and explain the output. For example, during fast convergence test, let’s ask the candidate to provide the convergence time for link failure and ask them to explain why the time can be different between link down and link up (restoration) state. Can they explain why the convergence time can be different if the PE router crashes compare to if the failure happens in P router?
Tricky questions like in current CCIE lab are still important. Troubleshooting skills are still required to be tested in the lab too. But the candidate is expected to be able to explain more ‘WHY’. Not only why it’s configured this way or that way, but as well as why the traffic behaves in certain way when some features are configured or when the failure occurs
I know most of the time it’s unfair to do the comparison between my “ideal” lab exam with the known certification like CCIE.
Take the lab equipments, for example. The real gears aren’t cheap. So a vendor may have only 1 or 2 complete labs that can replicate the real world’s equipment to serve all candidates around the globe. My view on this: that’s fine. Because nowadays we don’t have to fly to sit in the lab physically, we can just do the exam remotely. And the lab exam I described above is to test the skills in specific area. I mean, Cisco may create “Advanced CCIE lab” for specific technical focus with CCIE as the prerequisite, and there are so many tracks available (CCIE SP-NGN, CCIE SP-IPTV, CCIE SP-Wimax and so on). With many options of advanced track available, a candidate can choose which one is suitable to support his daily work so the number of candidates will be distributed to all the tracks.
If time permits, all the explanation should be done with short interview, not only in written. How if English is not the native language of the candidates? That’s fine. With remote lab, more locations can conduct the exam and the candidate can have the proctor who can speak the same language. And the lab exam can take 2-days format just like back there in 2001. Day 1 can be allocated to build the network, Day 2 morning can be used to run the traffic generator and verify the setup. Day 2 afternoon is for troubleshooting section. At the end of each section the candidate is expected to explain what have been done, and the behavior of the traffic in several different scenarios.
Obviously with this new and advanced CCIE track the main objective is to prepare the candidates to able to do the job the next day after they pass the lab, and not to chase the quantity of people to pass it.
Is it possible to have that kind of lab or can it be done only in our dream? Heck, who knows? One day a vendor like Cisco may really create a new certification track beyond CCIE, and they may take all the points above into their consideration.
Wednesday, September 30, 2009
Ode To The Contractors
"Himawan Nugroho spent his time between jobs last year as a contractor…and discovered it offered a level of control and empowerment that he’d never had before..."
The quote above is taken from an article in this site. It refers to my previous writing about Contractor Wannabe. Well, it's good to know that someone is actually reading that kind of stuff that I wrote :)
I was a contractor, even for only few months. It was during the time when I had resigned from my previous company and before I joined Cisco. Yes, indeed, the article describes exactly how I felt at that time. And I'm discussing again this topic because during the past few projects I've worked with many contractors, and some of them are really helpful.
In this part of the world it's not easy to hire a permanent employee. It takes time and lots of paper work at least for the visa process. And once the project is rewarded we have to start the work immediately, while the process to get someone on board won't be able to catch up. The solution? Hire contractors. They are skillful and available, almost, anytime. How about the working visa? They usually will be involved for short term so business visa should be fine. How about the skill? We can look at their previous experience and even call for quick interview. And once the work has started how if the guy has issue or we are not happy with him? Get the replacement. Easy and no headache. As long as we hire the guy with the right skill and we can allocate the proper work to him, the decision to use the contractors can be really rewarding.
Once I met a guy. He may be the right description of my answer if you'd ask: what do you want to be when you grow old? Single fighter, working for short term, keep moving from one place to another. Living from one hotel to another. His car is always from rental company. He carries his gadgets and magic luggage contains all the stuff he needs to live away from home for months. He got my respect because of the expertise. Got reputation and years of experience. Jason Bourne kind of guy. My kind of guy.
So will I go back to that kind of life style? Not now, at least. Currently I work in a place that I wanted to be. Working in the right team, surrounded by the most talented people. And I have something from my current work that I can't exchange even with a freestyler contractor life: deep level access to the product and technology.
Anyway, I was just trying to build a list of what it takes to become a successful contractor (in network engineering area or technical consulting). With my limited experience as contractor, here it is:
1. Build the reputation. The most important, I believe, are the integrity and responsibility
2. Result oriented. The work must be done successfully no matter what, within the agreed timeline
3. Adaptable, flexible, able to handle the pressure and sudden changes in the project
4. Possess extensive experience in different types of project with multiple roles
5. Able to work independently, but at the same time able to work as part of the team
6. Good communication skill and can easily blend with customers from any types, anywhere, in any circumstances
7. Specialize and focus in one technology area but know other stuff to certain level. For example, expert in Core IP/MPLS network but understand as well the access layer, security, physical layer, data center and so on
8. Able to work as multiple roles: engineer, consultant, architect, project manager etc
9. Always update the skills, fast and continuous learner. Willing to invest on skill update, lab, and any tools that can assist in delivering the work
10. Know how to market yourself: social networking, keep the contacts with previous customers, always update the CV, etc
When I look at the list above, I started to think that the list is a must not only to become a contractor, but as well as to stay competitive in the market even as permanent employee! It may be the one that keep our job during the financial crisis like today. I wouldn't know for sure, but it seems like I will bookmark this post to remind me that even a Triple CCIE can be replaced anytime. And the only ones that can save my job are those 10 points.
To all contractors, this post is for you.
The quote above is taken from an article in this site. It refers to my previous writing about Contractor Wannabe. Well, it's good to know that someone is actually reading that kind of stuff that I wrote :)
I was a contractor, even for only few months. It was during the time when I had resigned from my previous company and before I joined Cisco. Yes, indeed, the article describes exactly how I felt at that time. And I'm discussing again this topic because during the past few projects I've worked with many contractors, and some of them are really helpful.
In this part of the world it's not easy to hire a permanent employee. It takes time and lots of paper work at least for the visa process. And once the project is rewarded we have to start the work immediately, while the process to get someone on board won't be able to catch up. The solution? Hire contractors. They are skillful and available, almost, anytime. How about the working visa? They usually will be involved for short term so business visa should be fine. How about the skill? We can look at their previous experience and even call for quick interview. And once the work has started how if the guy has issue or we are not happy with him? Get the replacement. Easy and no headache. As long as we hire the guy with the right skill and we can allocate the proper work to him, the decision to use the contractors can be really rewarding.
Once I met a guy. He may be the right description of my answer if you'd ask: what do you want to be when you grow old? Single fighter, working for short term, keep moving from one place to another. Living from one hotel to another. His car is always from rental company. He carries his gadgets and magic luggage contains all the stuff he needs to live away from home for months. He got my respect because of the expertise. Got reputation and years of experience. Jason Bourne kind of guy. My kind of guy.
So will I go back to that kind of life style? Not now, at least. Currently I work in a place that I wanted to be. Working in the right team, surrounded by the most talented people. And I have something from my current work that I can't exchange even with a freestyler contractor life: deep level access to the product and technology.
Anyway, I was just trying to build a list of what it takes to become a successful contractor (in network engineering area or technical consulting). With my limited experience as contractor, here it is:
1. Build the reputation. The most important, I believe, are the integrity and responsibility
2. Result oriented. The work must be done successfully no matter what, within the agreed timeline
3. Adaptable, flexible, able to handle the pressure and sudden changes in the project
4. Possess extensive experience in different types of project with multiple roles
5. Able to work independently, but at the same time able to work as part of the team
6. Good communication skill and can easily blend with customers from any types, anywhere, in any circumstances
7. Specialize and focus in one technology area but know other stuff to certain level. For example, expert in Core IP/MPLS network but understand as well the access layer, security, physical layer, data center and so on
8. Able to work as multiple roles: engineer, consultant, architect, project manager etc
9. Always update the skills, fast and continuous learner. Willing to invest on skill update, lab, and any tools that can assist in delivering the work
10. Know how to market yourself: social networking, keep the contacts with previous customers, always update the CV, etc
When I look at the list above, I started to think that the list is a must not only to become a contractor, but as well as to stay competitive in the market even as permanent employee! It may be the one that keep our job during the financial crisis like today. I wouldn't know for sure, but it seems like I will bookmark this post to remind me that even a Triple CCIE can be replaced anytime. And the only ones that can save my job are those 10 points.
To all contractors, this post is for you.
Sunday, August 30, 2009
3 Types of Network Designer
The following writing is still related with the CCDE Practical exam that I took recently. IMHO, there are three types of designer for network infrastructure solution:
Designer for Solution: the one normally focuses on the high level solution, by considering customer business model, future growth and other non-technical stuff. The coverage of the design is usually broad, but not too deep, and the solution is for a complete infrastructure with all the supporting components, including the operational process and the operation management. Solution designer should be able to provide the high level topology network infrastructure with the technology to be used and the features need to be enabled, but neither is required to provide the details nor the exact hardware to be used. Characteristic and the features required from the hardware can be mentioned though, to make it easier for the hardware selection by later designer.
Designer for Pre-sales: similar with solution designer, but the coverage normally is less broad and more detail to support the sales activity. As example, while the solution designer may covers the whole infrastructure including the operational process, the pre-sales designer may cover only the data center but can provide the detailed topology for it. The pre-sales designer is the one who involves in the hardware selection, and she must ensure the hardware chosen can run the technology or features required in the solution. If there is capacity and future growth requirement in the design, it has to be considered as well during the hardware selection. The output expected from a pre-sales designer is high level design with the list of hardware required called Bill of Material.
Designer for Implementation: the one who focuses on the in-depth and bit level details of the design. Implementation designer must provide the low level design and make sure the solution can really be implemented using the hardware available. The list of hardware may have been decided by previous designer, so now it's time to make the solution really works. The coverage of the implementation designer can start from the physical topology and connection, module allocation in the hardware, IP addressing scheme, software to be used, up to the detailed configuration of each hardware. The technology and the features chosen may need to be adjusted accordingly based on the limitation from the hardware or the software architecture. And the configuration or the way to implement the technology or features is usually based on the best practices, lab testing or the previous experience in another networks.
One example when to use the different types of network designer is as follow: a solution designer is the one who builds the Request For Proposal (RFP) document for a complete solution including the operational support. So he stands on the customer side. A group of pre-sales designers, stand on the vendor side, can work to answer this RFP and each designer must provide the list of hardware for specific area that complies with the requirement. It is required for the pre-sales designer to submit the proposal explaining the high level design and how the proposed hardware can deliver the solution. And once the proposal is agreed, the hardware need to be ordered, and now it is time for the implementation designer to really make the solution works.
Which one of the designers is better? It depends.
As in the above example I mentioned, we can be the ones who set the direction of the new network infrastructure solution and technology to be used without having to know too much detail but instead must cover broader technology, we can be the ones who select the hardware and provide high level design to support the sales, or we can be the ones who work in low level design to implement the solution and configure the devices.
Sometimes a person must work as solution designer and pre-sales designer at the same time. And sometimes a person must even work as those three types!
Before I joined Cisco, I used to work as the solution designer, pre-sales and implementation designer role and my role may changed from one project to the other. Obviously at that time, as solution designer I gain benefit being outside Cisco because I was able to work even with the hardware from multiple vendors. But as implementation designer, I was not able to go deeper because I didn't have access to the detailed hardware and software architecture.
Since I joined Cisco Advanced Services about 3 years ago most of the time my focus has been in the implementation or after the list of hardware has been confirmed by the pre-sales designer. I must deal with the design limitation due to the hardware or software architecture. Most of my customers are Internet Service Provider or from Telecommunication industry. And in my last several projects I had to focus on the migration from the existing infrastructure to the new one, which means I have to deal more with the right methodology and the detailed procedures to transform the network without impacting the daily business of the customer.
The CCDE exam that I took few days ago covers the knowledge owned by the solution designer, and part of the pre-sales designer. It deals with the high level solution design. It is not required to know the limitation from the hardware, nor it is required to choose the hardware like what the pre-sales designer does. CCDE contents cover the different type of customer networks from different industry, from ISP to Retail, Financial, Media and so on. We don't need to know the in-depth and bit level details of the technology but we must know the reason why a particular technology is chosen in the solution.
So looking at the above facts, please allow me to make this statement even I haven't passed the exam to prove it: it is actually possible to just walk in to CCDE practical lab, without preparation, and pass it. As long as we have extensive experience with high level design for different type of networks. Plus we need the problem solving minded, the ability to capture only the related and important information, and a good stamina to stay focus with lots and lost of reading within 8 hours.
For me, if I really failed this attempt and need to take the exam again, at least now I know what to do. I need to get out from my current mindset that follows my current work where it is expected for me to focus in a very low level and detailed design, with a narrow technology area. I need to return back to my previous experience before I joined Cisco, when I used to support the pre-sales activities, and when I used to work with high level solution of multiple customer networks from different types of industry. Since my current work deals only with Service Provider networks, I may need to find some best practices documents, but not the in-depth implementation practices, but more like the high level design solution for different type of customer networks.
All of those will be necessary once I get the report 6-8 weeks from now, stating that I really fail. So let's just wait and see.
Designer for Solution: the one normally focuses on the high level solution, by considering customer business model, future growth and other non-technical stuff. The coverage of the design is usually broad, but not too deep, and the solution is for a complete infrastructure with all the supporting components, including the operational process and the operation management. Solution designer should be able to provide the high level topology network infrastructure with the technology to be used and the features need to be enabled, but neither is required to provide the details nor the exact hardware to be used. Characteristic and the features required from the hardware can be mentioned though, to make it easier for the hardware selection by later designer.
Designer for Pre-sales: similar with solution designer, but the coverage normally is less broad and more detail to support the sales activity. As example, while the solution designer may covers the whole infrastructure including the operational process, the pre-sales designer may cover only the data center but can provide the detailed topology for it. The pre-sales designer is the one who involves in the hardware selection, and she must ensure the hardware chosen can run the technology or features required in the solution. If there is capacity and future growth requirement in the design, it has to be considered as well during the hardware selection. The output expected from a pre-sales designer is high level design with the list of hardware required called Bill of Material.
Designer for Implementation: the one who focuses on the in-depth and bit level details of the design. Implementation designer must provide the low level design and make sure the solution can really be implemented using the hardware available. The list of hardware may have been decided by previous designer, so now it's time to make the solution really works. The coverage of the implementation designer can start from the physical topology and connection, module allocation in the hardware, IP addressing scheme, software to be used, up to the detailed configuration of each hardware. The technology and the features chosen may need to be adjusted accordingly based on the limitation from the hardware or the software architecture. And the configuration or the way to implement the technology or features is usually based on the best practices, lab testing or the previous experience in another networks.
One example when to use the different types of network designer is as follow: a solution designer is the one who builds the Request For Proposal (RFP) document for a complete solution including the operational support. So he stands on the customer side. A group of pre-sales designers, stand on the vendor side, can work to answer this RFP and each designer must provide the list of hardware for specific area that complies with the requirement. It is required for the pre-sales designer to submit the proposal explaining the high level design and how the proposed hardware can deliver the solution. And once the proposal is agreed, the hardware need to be ordered, and now it is time for the implementation designer to really make the solution works.
Which one of the designers is better? It depends.
As in the above example I mentioned, we can be the ones who set the direction of the new network infrastructure solution and technology to be used without having to know too much detail but instead must cover broader technology, we can be the ones who select the hardware and provide high level design to support the sales, or we can be the ones who work in low level design to implement the solution and configure the devices.
Sometimes a person must work as solution designer and pre-sales designer at the same time. And sometimes a person must even work as those three types!
Before I joined Cisco, I used to work as the solution designer, pre-sales and implementation designer role and my role may changed from one project to the other. Obviously at that time, as solution designer I gain benefit being outside Cisco because I was able to work even with the hardware from multiple vendors. But as implementation designer, I was not able to go deeper because I didn't have access to the detailed hardware and software architecture.
Since I joined Cisco Advanced Services about 3 years ago most of the time my focus has been in the implementation or after the list of hardware has been confirmed by the pre-sales designer. I must deal with the design limitation due to the hardware or software architecture. Most of my customers are Internet Service Provider or from Telecommunication industry. And in my last several projects I had to focus on the migration from the existing infrastructure to the new one, which means I have to deal more with the right methodology and the detailed procedures to transform the network without impacting the daily business of the customer.
The CCDE exam that I took few days ago covers the knowledge owned by the solution designer, and part of the pre-sales designer. It deals with the high level solution design. It is not required to know the limitation from the hardware, nor it is required to choose the hardware like what the pre-sales designer does. CCDE contents cover the different type of customer networks from different industry, from ISP to Retail, Financial, Media and so on. We don't need to know the in-depth and bit level details of the technology but we must know the reason why a particular technology is chosen in the solution.
So looking at the above facts, please allow me to make this statement even I haven't passed the exam to prove it: it is actually possible to just walk in to CCDE practical lab, without preparation, and pass it. As long as we have extensive experience with high level design for different type of networks. Plus we need the problem solving minded, the ability to capture only the related and important information, and a good stamina to stay focus with lots and lost of reading within 8 hours.
For me, if I really failed this attempt and need to take the exam again, at least now I know what to do. I need to get out from my current mindset that follows my current work where it is expected for me to focus in a very low level and detailed design, with a narrow technology area. I need to return back to my previous experience before I joined Cisco, when I used to support the pre-sales activities, and when I used to work with high level solution of multiple customer networks from different types of industry. Since my current work deals only with Service Provider networks, I may need to find some best practices documents, but not the in-depth implementation practices, but more like the high level design solution for different type of customer networks.
All of those will be necessary once I get the report 6-8 weeks from now, stating that I really fail. So let's just wait and see.
Wednesday, August 26, 2009
CCDE Practical, What (I Think) We Need To Pass It
I've just taken the CCDE Practical exam. The result will come only after 6-8 weeks, and frankly I don't know if I will pass or not due to the way the questions are presented. Mind you there are many questions require to drag-and-drop, fill in the table/matrix, re-ordering, and adding device/link into the existing network diagram, and in CCDE exam partial credit is possible.
For me, the content and coverage of the exam were a bit unexpected. So I wrote the following based on my own experience taking the exam today.
We Need a Very Good Stamina
- Surprisingly for the CCDE I found the time is not the main issue, 8 hours should be enough because we can't go back to the previous questions or re-check our work anyway. We just need to make sure to do each scenario within the average time allocated (if there are 10 scenarios, just divide 8 hours with 10 to get the average time we have per scenario)
- But what we really need is good stamina to be able to stay focus and concentrate after reading multiple different scenarios and hundreds of questions!
- Nice sleep and good dinner/breakfast is compulsory (in my case, lunch provided at testing center was horrible! And I was unlucky, I didn't have breakfast in the morning)
We Need to Have Broad "Design Experience"
- I believe there won't be any book or training to face this exam, the best practices design document or case studies may help
- We really need to have design experience and analytical skills, not as low level designer but more like as 'high level' solution designer
- Our experience and knowledge should cover the design for different type of customer network and industry, from ISP to Enterprise like Retail, Financial, Media etc in order to understand not only the challenges with the design of certain network type, but as well as type of the applications run and the network requirements of those applications that may affect the design decision
We Need to Understand What They Want
- Even we have extensive and broad design experience, our logic must sync with what the exam authors wanted
- Sometime there is more than one right way to solve the requirement, but we need to know which one is the expected answer based on the information provided
- Similarly, for re-ordering question, we need to make the order based on related information and which is the most correct (and for me it's still difficult to figure out the "right" order since I believe there is more than one possibility of the orders as the answer)
- CCDE Practical Exam Demo can show a brief example, the Networkers 2009 slides from Russ White can even provide closer view of the real practical exam
We Need to be Able to Relate Only the Important Information
- There are lots and lots of information provided, sometime half of the information is not important (but we still need to read and screen it at least during the first reading)
- But sometime the information can be very minimum, for example, for some application it's assumed that we know how it works
- This is the point where we need the good stamina so we can still focus especially in the last few hours, we also need the ability to capture only the important and the keywords from the overwhelmed information provided, and possess a broad and high level design experience in different type of network and industry to make us familiar with the challenges
We Need to Do "High Level" Troubleshooting Too
- It seems like the exam maker thought it was not enough with only the number of design decisions we must do, we also need to do some "high level" troubleshooting
- We may be asked to figure out what's wrong with the network or design flaw causing network issues, and instead of doing debug we must analyze it from series of information provided (sometime we need to choose which questions and further information to ask to the customer)
- Again, I believe for this part we have to rely on the experience with high level design, the logic and ability to capture only the necessary information, and possess the knowledge of technology overview instead of in depth/bit level details since we can't do any debug
And In the End, When We Fail
- Unfortunately even if we fail we may not able to be more prepared in the next attempt
- At least in CCIE lab if we can't ping definitely there is something wrong with our setup, and after we fail in CCIE we are presented with the break-down score for each technology section so we know which part is our weakness
- The CCDE exam contains multiple scenarios and bunch of questions for each scenario. From one scenario the questions may cover the routing, security, tunneling, management and Quality of Services technology areas and personally I'm not sure how I can figure out on which part is my weakness if I really fail (unless the score report can break it down per technology area for each scenario)
In summary, I fully support the statement of CCDE practical exam is as difficult as CCIE lab, even their coverage is not in the same context. And it may be more difficult if we consider the fact that we won't know for sure if we make mistakes. Even I feel like the design knowledge required to pass is more on the high level, but the most important things to have are the designer logic, broad knowledge of technology areas and the ability to capture only the necessary information before making any design decision.
So I think we need the above points I mentioned to pass this exam. But I can be sure only after I got my CCDE number, either in this attempt or the next.
Here is a link to CCDE practical tips from another test taker.
For me, the content and coverage of the exam were a bit unexpected. So I wrote the following based on my own experience taking the exam today.
We Need a Very Good Stamina
- Surprisingly for the CCDE I found the time is not the main issue, 8 hours should be enough because we can't go back to the previous questions or re-check our work anyway. We just need to make sure to do each scenario within the average time allocated (if there are 10 scenarios, just divide 8 hours with 10 to get the average time we have per scenario)
- But what we really need is good stamina to be able to stay focus and concentrate after reading multiple different scenarios and hundreds of questions!
- Nice sleep and good dinner/breakfast is compulsory (in my case, lunch provided at testing center was horrible! And I was unlucky, I didn't have breakfast in the morning)
We Need to Have Broad "Design Experience"
- I believe there won't be any book or training to face this exam, the best practices design document or case studies may help
- We really need to have design experience and analytical skills, not as low level designer but more like as 'high level' solution designer
- Our experience and knowledge should cover the design for different type of customer network and industry, from ISP to Enterprise like Retail, Financial, Media etc in order to understand not only the challenges with the design of certain network type, but as well as type of the applications run and the network requirements of those applications that may affect the design decision
We Need to Understand What They Want
- Even we have extensive and broad design experience, our logic must sync with what the exam authors wanted
- Sometime there is more than one right way to solve the requirement, but we need to know which one is the expected answer based on the information provided
- Similarly, for re-ordering question, we need to make the order based on related information and which is the most correct (and for me it's still difficult to figure out the "right" order since I believe there is more than one possibility of the orders as the answer)
- CCDE Practical Exam Demo can show a brief example, the Networkers 2009 slides from Russ White can even provide closer view of the real practical exam
We Need to be Able to Relate Only the Important Information
- There are lots and lots of information provided, sometime half of the information is not important (but we still need to read and screen it at least during the first reading)
- But sometime the information can be very minimum, for example, for some application it's assumed that we know how it works
- This is the point where we need the good stamina so we can still focus especially in the last few hours, we also need the ability to capture only the important and the keywords from the overwhelmed information provided, and possess a broad and high level design experience in different type of network and industry to make us familiar with the challenges
We Need to Do "High Level" Troubleshooting Too
- It seems like the exam maker thought it was not enough with only the number of design decisions we must do, we also need to do some "high level" troubleshooting
- We may be asked to figure out what's wrong with the network or design flaw causing network issues, and instead of doing debug we must analyze it from series of information provided (sometime we need to choose which questions and further information to ask to the customer)
- Again, I believe for this part we have to rely on the experience with high level design, the logic and ability to capture only the necessary information, and possess the knowledge of technology overview instead of in depth/bit level details since we can't do any debug
And In the End, When We Fail
- Unfortunately even if we fail we may not able to be more prepared in the next attempt
- At least in CCIE lab if we can't ping definitely there is something wrong with our setup, and after we fail in CCIE we are presented with the break-down score for each technology section so we know which part is our weakness
- The CCDE exam contains multiple scenarios and bunch of questions for each scenario. From one scenario the questions may cover the routing, security, tunneling, management and Quality of Services technology areas and personally I'm not sure how I can figure out on which part is my weakness if I really fail (unless the score report can break it down per technology area for each scenario)
In summary, I fully support the statement of CCDE practical exam is as difficult as CCIE lab, even their coverage is not in the same context. And it may be more difficult if we consider the fact that we won't know for sure if we make mistakes. Even I feel like the design knowledge required to pass is more on the high level, but the most important things to have are the designer logic, broad knowledge of technology areas and the ability to capture only the necessary information before making any design decision.
So I think we need the above points I mentioned to pass this exam. But I can be sure only after I got my CCDE number, either in this attempt or the next.
Here is a link to CCDE practical tips from another test taker.
Tuesday, August 25, 2009
Confession From London
I'm not ready.
I hate to admit but that's the fact.
I don't like to make excuse but let me try it once at least for this: after I got back from the previous project to Dubai last week I had only 6 days before the exam. And I used the first two days, obviously, to sleep and watch several HD movies, to compensate what I have missed during that hectic project.
So I had roughly only three days to review and read some books, and I was still managing the project remotely at the same time (it means lots of emails, webex meetings, phone calls, remote SSH session etc). Then this morning I took 8 hours flight to London.
As I said before, yes I'm really lack in my preparation but I'm not lack of confidence at all. But I guess I have to rely solely on my project experiences in the past and the knowledge I've gathered from the previous certifications.
Let's see how it goes.
I hate to admit but that's the fact.
I don't like to make excuse but let me try it once at least for this: after I got back from the previous project to Dubai last week I had only 6 days before the exam. And I used the first two days, obviously, to sleep and watch several HD movies, to compensate what I have missed during that hectic project.
So I had roughly only three days to review and read some books, and I was still managing the project remotely at the same time (it means lots of emails, webex meetings, phone calls, remote SSH session etc). Then this morning I took 8 hours flight to London.
As I said before, yes I'm really lack in my preparation but I'm not lack of confidence at all. But I guess I have to rely solely on my project experiences in the past and the knowledge I've gathered from the previous certifications.
Let's see how it goes.
Tuesday, August 18, 2009
Project Riyadh
- Vēnī, vīdī, vīcī. I came, I saw, I conquered.
This is my sixth week in Project Riyadh and hopefully the last. When I was told to be involved in the project the scope was: to lead the team to fix some design issues by migrating 15000 VPN customers in 3 weeks. My mind at that time was so focused to that number, and with a simple math considering the team can work continuously without a break it means we have to do 700 customers per night.
Once I arrived in Riyadh on the second week of July I realized the main challenge of the project is not to migrate the customers, no matter how many per night. There was lack of information and no documentation provided of the existing network and services. Network migration project relies on the information. Information of the existing network. Information of what the new network is going to be. Then we need to build a bridge between the existing and the new network. We need to build the methodology and procedure to ensure we can have a smooth transition period. The correct approach to make the migration process will not impact the daily business.
Without proper information, it's really difficult to come up with the right procedure. Without the right information, the methodology and the process can be misleading. No information, no bridge.
Fortunately I was and I am still surrounded by the best and talented engineers in the team. I remember Harry Stamper once said "I'm only the best because I work with the best". Like the Joe's, when all else fails, we don't. When any other team may refuse to continue working with a very less resource, lack of information and a very tight schedule, my team and I decided to continue the best we could.
We made mistakes in the first week but by making mistakes we learn more and more about the existing network. The customer environment is very unique so there is no way to finalize the migration process in the lab environment. We have to execute the migration and build the procedure at the same time. We are learning about how to migrate the network by doing it. Most of the team members worked more than 16 hours a day. And after few weeks, I was able to finalize the process, methodology and procedures, and I have all of those documented properly. Having a proper document of the migration process means anyone can continue my work even if I'm already out of the country.
This project may not make the top in my preferred projects list but I'm still happy because my team and I are able to accomplish something that was considered impossible. Yes I was not able to complete it in 3 weeks. Most probably it will be completed only by next week. But I communicated this frankly with the customer that due to the lack of information we have to share the risk. And one of the risks is we need more time to complete the project, especially I found there are many other services need to be migrated not only the VPN customers. I'm a kind of guy who doesn't like to make excuses. So to me what's important is to be clear and communicate all the challenges with the customer. And by working together as one team, anything is possible.
Yesterday was the independence day of my country. I hope my independence day from this project is coming soon too.
Those who have been following my blog should know that I have another important thing to do next week. Due to the high pressure from Project Riyadh, I didn't have time to prepare for it. But I will just try the best as usual.
Lack of preparation, yes. Lack of confidence, no no.
Project London, here I come.
This is my sixth week in Project Riyadh and hopefully the last. When I was told to be involved in the project the scope was: to lead the team to fix some design issues by migrating 15000 VPN customers in 3 weeks. My mind at that time was so focused to that number, and with a simple math considering the team can work continuously without a break it means we have to do 700 customers per night.
Once I arrived in Riyadh on the second week of July I realized the main challenge of the project is not to migrate the customers, no matter how many per night. There was lack of information and no documentation provided of the existing network and services. Network migration project relies on the information. Information of the existing network. Information of what the new network is going to be. Then we need to build a bridge between the existing and the new network. We need to build the methodology and procedure to ensure we can have a smooth transition period. The correct approach to make the migration process will not impact the daily business.
Without proper information, it's really difficult to come up with the right procedure. Without the right information, the methodology and the process can be misleading. No information, no bridge.
Fortunately I was and I am still surrounded by the best and talented engineers in the team. I remember Harry Stamper once said "I'm only the best because I work with the best". Like the Joe's, when all else fails, we don't. When any other team may refuse to continue working with a very less resource, lack of information and a very tight schedule, my team and I decided to continue the best we could.
We made mistakes in the first week but by making mistakes we learn more and more about the existing network. The customer environment is very unique so there is no way to finalize the migration process in the lab environment. We have to execute the migration and build the procedure at the same time. We are learning about how to migrate the network by doing it. Most of the team members worked more than 16 hours a day. And after few weeks, I was able to finalize the process, methodology and procedures, and I have all of those documented properly. Having a proper document of the migration process means anyone can continue my work even if I'm already out of the country.
This project may not make the top in my preferred projects list but I'm still happy because my team and I are able to accomplish something that was considered impossible. Yes I was not able to complete it in 3 weeks. Most probably it will be completed only by next week. But I communicated this frankly with the customer that due to the lack of information we have to share the risk. And one of the risks is we need more time to complete the project, especially I found there are many other services need to be migrated not only the VPN customers. I'm a kind of guy who doesn't like to make excuses. So to me what's important is to be clear and communicate all the challenges with the customer. And by working together as one team, anything is possible.
Yesterday was the independence day of my country. I hope my independence day from this project is coming soon too.
Those who have been following my blog should know that I have another important thing to do next week. Due to the high pressure from Project Riyadh, I didn't have time to prepare for it. But I will just try the best as usual.
Lack of preparation, yes. Lack of confidence, no no.
Project London, here I come.
Subscribe to:
Comments (Atom)