From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

CCDE Bootcamp with Jeremy Filliben, Day Two

525 Words. Plan about 3 minute(s) to read this.

Today’s classroom revealed a couple of key study strategies for the CCDE. One is understanding why a particular technology exists. In other words, it’s one thing to know what a technology does. It’s something else entirely to know what it’s good for. While this might seem like an obvious point (this is a *design* certification, after all), I found that a lot of the natural side conversations that came up devolved into detail that was beyond the point. It seemed like we kept getting into mechanics of technology implementation that, for the most part, is too much information when talking about CCDE. I think that’s part of the temptation we network engineers fall prey to. Almost all of us in the class are CCIEs and/or have come from a heavy implementation background. The nitty gritty details are fascinating to us; we sort of can’t help talking about them. However, when we’d snap back to the larger point, I’d be reminded from the context of the slides Jeremy was taking us through that we really need to know is what the technology is good for – much more than the implementation specifics. Getting hung up on details is a time suck, and considering how many technologies there are to comprehend, time is something not to be wasted.

The second strategy is that of going through sample CCDE scenarios, as that proves you can apply a technology to a business situation & its peculiar constraints. Now, it’s not like there’s tons of CCDE scenarios out there to choose from. But what I think is going to be valuable as a practice exercise is to create scenarios with questions and answers, and then work through them with others. My thought is to take a knowledge domain I’m particularly competent with, then build a scenario that tests design elements that could be impacted when using tools within that knowledge domain. I have an advantage in that I’ve got an entire CCDE test scenario that’s a part of the boot camp. In that sense, I have a model to follow that shows the format of the exam, the kinds of questions to ask, etc. I know that many of the folks in the CCDE program have attempted the practical already at least once, and have that same sort of insight. The kicker here is actually building test scenarios. You need to construct a situation, generate network designs, create problems to be solved, then understand the best design solutions to those problems. Hard work to build scenarios like that. That said, I have a number of scenario ideas based on projects I’ve been a part of over the years. I’d just have to divorce myself from what might have happened in those specific projects and adapt them to a CCDE test scenario. I’m hoping others from all areas of networking have similar ideas. In this way, those of us stronger in enterprise technologies could challenge those stronger on the service provider side. And vice-versa. That would be an excellent basis for a study group. Do the scenario, get together, and diagnose it. Heck of way to reveal your weak spots.