Took the CCDE Written Beta Test Today

No info on the practical yet. They are waiting to finish the written beta, then will release more info on the practical.

You won't be actually configuring anything on the practical, but you might have to dig into a network to get specific information you're after to make decisions. In that case, you would run in to the actual configurations and information pulled from the device, which wouldn't be interpreted or given to you in any way--you'd just be expected to be able to make sense of the output off the device.

I think this is a pretty realistic concept of what folks at this level should be able to do--or at least I hope it is. I know I can't configure things without the books any longer, but making sense of a config is something I have to do for a lot of different devices on a fairly regular basis.

:-)

Russ

I'll try and provide a couple of perspectives on this question, to give everyone a better feel for where this exam is going.

When we first began developing this certification, we started with a long list of what we wanted to test, or what we thought was important. The first thing we realized was: "Oh my, we can't test all of this stuff in the number of hours we have!" There is a practical level to what you can actually cover on a test of a given number of questions with any sort of depth. If you have 100 topics to cover on a 100 question test, then you have 1 question per topic--and, based on the professional testing folks we've been working with, this probably isn't a good idea. So, we needed to cut a lot of stuff out of the list, and focus.

Once we had built this list, we had to spend some time sorting out how we wanted to test for specific things. A lot of the technologies we wanted to deal with we wanted to test in relation to other things. IE, we didn't want to test 'where do you place VOIP gateways in your network,' but we did want to test 'what's the impact of placing VOIP gateways in your network on the network design?' We classified everything based on the way in which we believed we could test each thing--a simple multiple choice question, a practical, interactive question of some sort, or only on some form of truly person-to-person test.

Needless to say, this took a long time (in fact, this took longer than actually writing any questions).

What you find on the written beta is that set of topics we believed we could reasonably cover on a one hour test using multiple choice questions--so, it doesn't represent everything covered by the certification.

For a second perspective--consider that we didn't want the test to be Cisco centric. This pretty much lets out any sorts of questions on what sort of equipment to use where, what equipment capacities are, and that sort of thing. While we think this is all really important stuff, putting it in causes us to lose focus on other things (the breadth becomes to large), and it also dates the test--the test isn't useful after a year or two. This makes the usefulness of the certification in the field questionable--it becomes a question of what version of the test you took, rather than "do you have this certification."

For a third perspective: I will admit we're a little layer 3 infrastructure centric. :-) You'll find voice on the practical exam, as an application that challenges the network design, though, rather than as something to be designed independent of the network design. I think you can look at network design two ways:

o The network is a black box on which you are putting applications. You don't care how the network works, so long as it provides the services you need when you need them.

o Applications are placed on top of a network, so the network needs to be designed around those application requirements. This treats applications somewhat as "black boxes," and focuses on the network design.

There are folks on both sides of this design, and both sets claim the titles "designers" and "architects." One of the problems we've faced throughout is how to differentiate between these two. It's intentional that this test falls in the second camp, not the first, however. :-)

In the end, what you'll find is there is a lot broader set of technologies on the practical. The focus there will be on the interaction of various technologies--QoS, routing, various layer 2 technologies, and applications, like VOIP, web services, etc. The focus won't be on designing a VOIP deployment, but rather how a VOIP deployment impacts the overall network design, and how it will interact with existing services, or existing design elements.

So, it's a looking at network design from a slightly different angle than some folks might see it, but, we believe, in a more realistic way. VOIP will eventually rule the world, then there will be some other killer app that must be rolled out. The real test of a network design isn't whether it supports VOIP well, but whether it enables new services we've not yet thought of without disturbing the existing services. Does it work well when you add intelligence to the network in the future, or pull intelligence out? These are the hard questions we think are at the root of the network design problems we face.

HTH

:-)

Russ

I was doing something else, and a perfect example occurred to me that might help explain this a little. Virtualization, for instance, is something we've used in networks for years--X.25, frame relay, DWDM, and others, are all virtualized networking technologies. All virtualized technologies share some common characteristics--for instance, any time you introduce virtualization, you introduce fate sharing.

So, while you might not completely understand some new layer 3 virtualization technology that someone might come up with tomorrow, and a good network designer, you should always know to ask--you're virtualizing, which means there's fate sharing here someplace, and I need to go find it, and account for it.

Again, I hope this gives you some insight into the types of thinking going into the test development cycle.

:-)

Russ