Cost Estimate for the CCDE

Yesterday I received an interesting comment to one of my previous CCDE blog posts.  Jack asked:

My employer is asking for cost estimates for the whole process [CCDE]. I have seen that your estimate is 3000 dollars. Does this include the tests themselves or just the materials?

I contend that the real cost of this certification is in the time required to master the material.  That said, the actual out of pocket costs are very important too!  Here is a breakdown.

 

Costs

Fixed Costs

Cost	Item
$350 (each attempt)	Written Exam (352-001)
$1400 (each attempt)	Practical Exam (352-011)

Variable Costs

Cost	Item
Minimal	Travel to Written Exam
Potentially Expensive	Travel to Practical Exam
~$400	Books
Unknown	Formal Training

You almost must factor in the opportunity costs of your time, as many of aspiring candidates need to delay or avoid other time commitments.  At the very least, you’ll likely miss some family and friend events to concentrate on studying.

 

Travel to Written Exam

Hopefully this is minimal for everyone.  The exam is offered at all Vue testing centers, so this should be a short car or bus ride away.

 

Travel to Practical Exam

Currently, the practical exam is offered in Hong Kong, London, and Chicago.  Historically it’s been offered every six months, but that pace is expected to pick up to meet increased demand for the exam.  As of this writing, the exam was most recently offered in August, and the next scheduled offering is in December.  I expect the practical to be offered quarterly beginning in 2010.

Travel to/from these selected testing locations is not trivial.  My three day / two night trip to Chicago (from Delaware) cost approximately $1100.  That probably comes in at the low end of most candidates travel costs, as my airfare was only $350.  International travel can be considerably more expensive.  Of course, if you’re fortunate enough to be local to one of these cities, you’ll save a bundle!  Also keep in mind that it is probably wise to budget for two trips, to prepare for the possibility of failure on the first attempt.  This is an area where I wouldn’t cut corners.  For a big exam (or business meeting, etc), be sure to arrive in plenty of time (early afternoon on the prior day for me) and don’t be rushed to leave.  The exam is enough to think about, without adding travel concerns to the mix.

Books

I’ve given my book recommendations before, but I’ll repeat them here:

Optimal Routing Design – One of the authors (Russ White) is also author of most of the CCDE Practical content to date.  It helps to get into the mind of the test writer!  Besides that, this book is the best resource for Enterprise routing design, and specifically, IGP design.

Definitive MPLS Designs – This book covers MPLS Service Provider designs, as well as a bit of Internet Service Provider design.  More than any other resource, this book gives a great feel for the style of the CCDE practical exam.

BGP Design & Implementation – This book focuses almost exclusively on Internet Service Provider design.  It gives the “Why” behind route-reflectors and confederations.

End-to-End QoS Network Design – This book does for QoS what the above three books do for IP Routing & MPLS.  It uses great examples to describe class-based traffic-shaping and other QoS concepts.  For the purposes of this exam, you can disregard the configurations.

These four books cover the basics of network design.  In addition to these resources, candidates may also want to pick up Network Management Fundamentals.  This book gives an overview of Network Management design, and a few specifics on Network Management technologies.

Note that these books don’t necessarily cover the basic technology particularly well.  Each of these books has a primer section, but none of them go into the depth necessary to teach someone new to the respective technologies.  If you need more basic information on the technologies, I would suggest following the reading suggestions available from the appropriate CCIE track.  For example, if you need information on VPLS or AToM, read Layer 2 VPN Architectures.

Formal Training

 

I’ve noticed that there are now at least two formal training classes available for the CCDE.  One is being offered in Europe, and is taught by an actual CCDE certified instructor.  The second is offered in the US.  I suspect this is not being taught by a CCDE.  I’m not sure what to think of formal training for this exam.  It likely depends heavily on how the course is structured.  I do not believe that one or two weeks of classroom training can prepare a candidate for the broad range of technical topics covered in the blueprint.

On the other hand, a week of classroom training could be great for learning design methodology.  Assuming the student already has a fundamental grasp of most of the technology, an instructor-led class that teaches by example could be a positive addition to a candidates preparation plan.  It may not even take a full week to prepare a qualified candidate for the style of the exam.

I will be interested to hear feedback and test results from the first wave of candidates who partake in these classroom training offerings.  Before I hear firsthand whether the candidates felt prepared, I won’t be able to recommend this strategy.

 

Conclusion

 

To sum this up (literally!), I spent about $3000 in actual dollars to achieve the CCDE certification (note, I took the written during the beta period, so my numbers don’t quite add up).  I am fortunate to have a supportive employer who covered most of these costs.  A candidate can spend far more than this in their quest for the CCDE certification.  If I were coming at this today, I would budget for two attempts for the written exam ($700), two attempts for the practical ($2800) + travel for the practical ($2200 for me, but varies wildly depending on your location).  I would also budget $400 for books, and depending on student feedback, I might budget for a formal class.  Without the class, my total budget would be $6100.

Thoughts on Fiber Channel over Ethernet (FCoE)

With all the recent Twitter chatter on the topic, I feel compelled to throw in my two cents on Fiber Channel over Ethernet.  Here goes!

FCoE Selling Point
Traditionally, data center designers built separate Ethernet-based Data Networks (LANs) and FC-based Storage Networks (SANs).  This was necessary because storage has a requirement for lossless operation, and Ethernet did not have the ability to meet this requirement.  This requirement cost IT departments considerable extra money in fiber cabling and FC adapters in servers.
Data Center Bridging (DCB) - which IBM calls Converged Enhanced Ethernet (CEE) and Cisco has referred to as Data Center Ethernet (DCE) - adds lossless operation to the Ethernet standard.  This allows us to multiplex storage traffic onto our data networks.  Voila, we can save a relative fortune in cabling costs and dedicated FC equipment, and to a lesser degree, we can save on server network adapters by using Converged Network Adapters (CNA).

Where Are Things Going?
This is great… Now we’re saving a bunch of money, and we still have the same basic network.  But is this the best we can do?  Of course not!  Why do we want the same basic network?  Why don’t we put our storage traffic into IP packets and zip it along like everything else?  Then we won’t need a separate network at all, virtual or otherwise.
If this story sounds familiar, that’s because it is.  At one time, SNA traffic had a dedicated network.  Then we decided to encapsulate it in a layer 2 protocol via RSRB, SR/TLB, etc.  Eventually, we tossed the traffic into IP packets via DLSW+.  Ultimately, we put IP-capable adapters in our mainframes and dispensed with the legacy technologies.
Or maybe you're thinking about voice… Who remembers the MC3810?  That was my first introduction to Voice over X technology.  We plugged PBX T1s into a router and encapsulated voice into Frame-Relay or ATM.  There’s even a parallel here with the FCoE multi-hop controversy.  Later we encapsulated the T1 traffic into IP packets on a router.  Eventually, we put IP-capable adapters into our PBXs and dispensed with the legacy technologies.
As far as storage goes, we’re still stuck on step 2, encapsulating storage into a layer 2 protocol.  Meanwhile, there are plenty of Storage over IP options available that don’t quite meet our performance needs.  Does anyone actually want to bet that NAS or iSCSI is never going to meet our performance needs?  Sure, there will always be specific high performance computer (HPC) needs that push the envelope, but the vast majority of corporate needs will eventually be met by IP-based storage.

So What Should We Do?
Does this mean we should ignore FCoE?  Definitely not.  I am in no hurry to swap out any existing FC-based SANs for FCoE.  I don’t see the financial justification for it, since I’ve already sunk my money into the cabling.  If I were to build a new data center, and I could demonstrate that IP-based storage would not meet my performance need, I would absolutely go for an FCoE solution.  But I would also spend a lot of time determining if I truly needed the extra performance offered by a SAN.  Any new DC build is going to be based on 10gbit Ethernet, so that should factor into the decision.
Ultimately, Fiber Channel will go away, just like every other dedicated network technology before it.  During the transition phase, which we’re currently in, it often makes financial sense to go with the interim technology.  I can’t come up with a scenario where it would make sense to replace an existing, working Fiber Channel network, but new builds should seriously consider going with FCoE.

Troubleshooting an Application Problem

I grew up knowing I would be a computer programmer… then I reached my University years and realized I had no passion for it.  I still pursued and attained my Computer Science degree, but I gravitated towards non-programming courses like Computer Networks, System Architecture and Telecommunication Systems.  Prior to losing my interest, I was quite good at it, and I believe my familiarity with the subject helps me to understand why Cisco IOS and other network OSs work the way they do.  My programming background also leads me to offer opinions on application development.

My first consulting project for RPM Consulting was for Philadelphia Newspapers, the owner of the Philadelphia Inquirer and Daily News papers.  Most of my efforts were focused on a new LAN design for their downtown office, which faced the familiar constraints of old, big city office buildings, like limited conduit space and union labor for all physical cable moves.  While this was interesting, I was drawn to the secondary project:  troubleshooting a new Unisys-provided newswire service application.

This custom-built application was intended to provide a centralized, searchable database of all news wire stories.  In the Unisys lab, and then again in the Inquirer lab, it worked perfectly.  Users could access story titles and abstracts, and if they were intrigued, a single click would retrieve the content.  When the system was deployed to the first batch of users, it failed miserably.  Downloading the story list was quick, but it took several minutes to download each individual story.  The application developer blamed the network (big surprise).  A colleague and I were able to borrow RPM’s Network General lunchbox sniffer for a day to get the data I needed to troubleshoot.  Our packet traces revealed that the application was built using UDP, not TCP, as I was expecting.

As our studies have taught us, TCP has built-in reliability, in the form of sequence numbers, acknowledgements and retransmissions.  UDP provides none of these features.  Application programmers who choose to use UDP must provide their own reliability mechanisms.  In this case, the developer coded the client application to send an acknowledgement once the full story was received.  If the story was not received in a predetermined time period (approximately two minutes), the client application repeated its request.  If a single UDP packet was dropped,this timeout value was the only mechanism for detecting the event.  This was fine for a lossless lab network, but in a production network, packets are sometimes dropped.  Especially in this particular network, which was in the midst of a Token-Ring to Ethernet conversion.

Due to the ongoing conversion project, there was very little I could do to mitigate the packet loss in the short term.  Our recommendation was for the application developer to rewrite the application to use TCP.  Fortunately, my colleague was a former Unisys employee, so that task fell to him.  The interim solution was to dial down the timeout value from two minutes to a few seconds.  I’m not certain either solution was accepted, as my participation in that consulting assignment ended before a solution to the application problem was implemented.

Defining a Quality of Service Policy

Let’s get this out of the way in the beginning.  Quality of Service is my favorite part of network design.  The fact that we now have enough power within our network devices to inspect packets and make on-the-fly DSCP value changes is amazing.  It doesn’t seem that long since we had to optimize our ACLs to keep the router CPU under 99%.  But remember:  With power comes responsibility.

Quality of service often gets a bad reputation for a pair of reasons:

1. It requires micromanagement of applications
2. It allows (or forces) network administrators to play favorites

Some would say it also gets a bad rep because it is often poorly implemented, but that wouldn’t happen to us, right? :)

Both of these are certainly possibilities, but a well-designed QoS policy doesn’t require either to be true.

 

My Current QoS Policy

I designed and led the implementation of a ten-class QoS policy for my organization.  Ten classes?!  I’m sure this seems like overkill, but there is a good reason for each class.  Here are the classes, plus the DSCP values associated with them:

Class Name	DSCP Value(s)	Traffic Type / Example
Internetwork-Control	CS6	Routing Protocols
Telephony	EF, CS3	VoIP, VoIP Signaling
Video-Conference	AF41, AF42, AF43	Realtime Video Conferencing
Video-Live-Streaming	AF31, AF32, AF33	Live Webcast
Video-Backbone	CS4	Realtime Video Transfers
Transactional-Data	AF21, AF22, AF23	Interactive Data
OAM	CS2	Network Mgmt (SNMP, TACACS)
Bulk-Data	AF11, AF12, AF13	Data Transfer Apps (FTP, CIFS)
Standard	Default (DSCP=0)	Uncategorized Traffic
Scavenger	CS1	Undesired / Out of Spec Traffic

A bit of clarification around the three video classes is necessary.  We have two important video-based applications.  We have deployed a video-conferencing solution to a significant number of our locations.  This traffic is marked as AF41.  We also have scheduled live webcasts that consist of two traffic types.  The obvious one is the actual live video stream, which is delivered via multicast over our WAN to all remote locations.  This traffic is marked AF31.  The second type is the source material that creates the webcast.  These events often require remote camera feeds from other internal locations.  Originally, we would ‘roll a truck’ and use a satellite uplink to get the feed back to our HQ office.  Now, we attach the camera(s) to an encoder and convert the audio/video into a UDP packet stream.  This is then sent to our HQ site for A/V mixing to create the live stream.  It’s a great solution, and it has paid for itself many times over already (satellite trucks are expensive!).  The pre-work is significant on the network side, as we need to temporarily modify our QoS policy to accommodate the new stream, but it is worth the effort.

Let’s dedicate a paragraph to each of the classes to give an idea of why they exist.  These are loosely ordered based on importance, but as you will see, everything gets a bandwidth guarantee:

Internetwork Control

This class includes all of our routing protocol traffic, as well as the Lightweight Access Point (LWAPP) to Wireless LAN Controller (WLC) signaling traffic.  These are generally light traffic loads, so the queuing allocation can be small.

Telephony

We have chosen to combine voice and voice signaling traffic into a single traffic class.  I’ve even instructed our voice team to mark signaling traffic as EF.  We then overprovision the priority queue by 15% or so to allow for the extra traffic.

Video-Conference

Our video-conference equipment marks all stream traffic as AF41.  This traffic is RTP, and the application is very sensitive to dropped packets.  Because this application is real-time, it is also sensitive to delay and jitter.  While Cisco advises network admins to use a priority queue for their Telepresence system, I’ve been able to get by with standard Bandwidth allocation, which preserves our priority-queuing capabilities for the Telephony traffic.

Video-Live-Streaming

As mentioned above, the live video stream is delivered via multicast, using RTP packets.  Much like our Video-Conference traffic, this is highly sensitive to dropped packets.  Jitter and delay are less of a concern, due to the one-way nature of this stream.  It’s like watching TV… As long as the signal is solid, you don’t really care if it is delayed by a second or two.

Video-Backbone

This is very much like Video-Live-Streaming, except it flows in the opposite direction.  It is also a much higher-bandwidth stream.  We gave some thought to combining this with the Video-Live-Streaming class, but in the end we decided it was much clearer to give it a unique identifier.

Transactional-Data

This is the first of three end user application classes.  We mark all interactive applications with AF21.  I define interactive as a command/response relationship, like Telnet or Remote Desktop.  The user types or clicks something, then waits for a response before entering the next command.  Most (but not all) of these applications are low bandwidth.  They are generally delay sensitive, as the user is constantly monitoring the application.  This is where we place some of our internally-developed applications.

OAM

This queue is used for network management traffic.  Applications such as Netflow, SNMP and TACACS+ are placed in this queue.  Historically it has been difficult to get this traffic properly marked, as it usually sources from a router/switch, but this has gotten better with Cisco’s movement towards dedicated management ports on equipment.

Bulk-Data

This is the second end user application class.  All data transfer applications go into this queue.  These applications will often take as much bandwidth as is available.  They are not terribly sensitive to delay or jitter.  We further characterize these apps as time sensitive (AF11) and time insensitive (AF13).  This allows us to use a WRED policy to selectively drop packets from less critical transfers.  The time-insensitive category is great for NetApp SnapMirror, Windows background updates, patch deployments, etc.  This gives priority to user-based apps like Windows File Sharing.

Default

Anything that isn’t specifically marked into another queue falls into the Default queue.  Most HTTP-based apps are here.  The majority of my organization’s traffic falls into this queue.  It receives a healthy allocation of interface bandwidth as a result.

Scavenger

The Scavenger class is reserved for traffic that either exceeds normal network patterns or is known to be unnecessary.  We have defined a simple end user port policy of allowing any user to send up to 5mb/s of traffic into the network.  Any traffic which exceeds this value is marked as CS1.  This promotes a level of fairness between users.  This queue is given a 1% bandwidth allocation at all network chokepoints, so it is the first to go when there is congestion.  As for the ‘known unnecessary’ category, I’d prefer get rid of the application, rather than penalize the traffic.

 

What’s Missing?

Notice there isn’t a ‘Priority Applications’ queue in this model.  We purposely defined our queues based on traffic characteristics, not application priorities.  This has served us well, and has prevented the cajoling many experience when they ask their users to define ‘important’ applications.

Will this model work for everyone?  Probably not.  Every organization has a unique set of applications.  If you have already agreed to prioritize something, it can be difficult to back out of that promise.  If you haven’t done so, I suggest you avoid heading down that path.  Think hard about the characteristics of you traffic, and attempt to

In a future blog post I will show how this policy translates to a packet marking configuration, and later, an interface queuing policy.  I am a proponent of MPLS networks, which introduce another wrinkle to the equation.  None of my incumbent providers offers a ten class QoS scheme.  I will show what we’ve done to adapt our policy to those constraints.

Time for IPv6?

It is Fiscal Year 2010 budget time at my company.  We have just completed a rather expensive three-year cycle of hardware upgrades, so it is refreshing to look at the modest capital costs I am requesting for 2010.  Of course, depreciation is eating up a significant portion of our budget for the next couple of years, so I would be hesitant to ask for a large allocation this year anyway.

Every year since I started with my current employer, my potential project list begins with “Implement IPv6”.  And every year, I quickly move it to the following year’s potential project list.  While I pondered it a split-second longer this time around, I still moved it to the 2011 list.  I see no compelling reason to foist a new protocol on my employer over the next 12 – 16 months.

Please understand, I’m not dense when it comes to the need for IPv6 in the world.  I am able to comprehend IPv4 address exhaustion (I read Geoff Huston’s excellent blog at potaroo.net), and I see the benefits to IPv6.  In 2000, I successfully argued that it was in my (then) employer’s best interest to pay for my purchase of an IPv6 book, so I could digest the information and teach my consulting co-workers how to plan for the protocol.  “It can be a differentiator!” I explained.  Is there a more perfect project for the PDIM cycle? (Plan, Design, Implement, Manage, or feel free to substitute your own consulting methodology)  Much of the information in that book became obsolete, and I’m fairly certain I recycled it years ago.

So why not this year?  In brief, one of the following things must happen for me to push forward with an IPv6 project:

- A compelling application is released that requires or would benefit from IPv6.  Definitely not a reality yet.  I’m holding out hope that VMWare will realize that VMotion and IPv6 Mobile IP are a nice match.  So far, I haven’t heard anything.  (I really want to spend some time developing my thoughts on this into a coherent blog post)

- Our customers start clamoring for it.  We expect this to happen in our ASPAC businesses eventually, but nothing yet.  Maybe I’m naive, but I am confident that IPv6 users will have gateways into the IPv4 world.  After all, who would be willing to sign up with an ISP that can’t reach the ‘real’ Internet?  Even the then-mighty AOL had to abandon that business model is the 90s.

- Our business partners require it.  We’re in a regulated industry, so there is a fair amount of government and quasi-government involvement.  I assume they will be the first business partners to move to IPv6, but I have even heard of any inquiries about out IPv6 status.

To generalize, we’re not a bleeding edge infrastructure company.  We would not derive any benefit from being a first mover.  I like new technology as much as the next guy, but I have a responsibility to make logical, defensible recommendations to my business leaders.  That’s why “Implement IPv6” is moving to the 2011 project list.  Of course, I’m hedging my bet by including a “Verify IPv6 Compatibility” project on the 2010 list, just like last year, and the year before that, etc.  It’s a low-cost project, and if the need for IPv6 comes on suddenly, we’ll be prepared to meet it with code upgrades, not hardware purchases.

If you are planning your own 2010 projects, I encourage you to think through your own situation.  It may be different than mine, or you may have more work to do to prepare for IPv6.

Jeremy

Technical Writing.. Books or Blogs?

I’ve been thinking lately about whether it still makes sense to write technical books.  Years ago, I had a contract to write a book for Cisco Press.  Due to a job change, I was only able to complete a few chapters, and after handing it off to another author, it seemed to die a quiet death.  I used to be able to find a reference to it on one of the Amazon websites, but a recent search turned up nothing.

About six months ago, the writing bug bit me again, and I created a proposal for “Enterprise Network Designs” and sent it off to Cisco Press for feedback.  In the (long) time between sending that email and receiving a meaningful response, I chose instead to begin writing this blog.  Blogging fits my schedule better, and it provides a more interactive communication platform.  IIRC, I felt a good deal of deadline pressure and a bit of nervousness about making mistakes.  Once information is committed to paper, it’s difficult to fix it.

As a result of these events, I’ve been trying to determine if we’ve reached the end of the technical book publishing industry.  I don’t recall the Cisco Press contract being especially lucrative.. something like 10 – 15 percent of gross revenues go to the author, minus some expenses.  As several technical authors have mentioned, you don’t get into the field for the money.  Maybe they’re just trying to keep the competition out, but for some reason I doubt that’s the case.

Why wouldn’t technical authors go the blog route, and cut out the publishing middleman?  This would eliminate much of the overhead of publishing, as well as free the author from official deadlines.  Revenue can be generated by monetizing the blog, as well as follow-on contract work.  If the content is well-written and relevant, the professional prestige gained from the effort should be comparable to being a published author.  Technical book readers are by definition technical, so reading a blog should be well within their comfort zone.

 

What would the author be missing?  A few items are:

Deadlines - Is that good or bad?  Depends on the author, I suppose

Copy Editor – Go with a freelance editor?

Book Signings – Not sure a substitute is available for the blogger

Seeing Name in Print – Ditto.. no obvious substitute available

Copyright Protection – There must be a good solution to this, right?

Publisher Credibility – Cisco-related books from Cisco Press probably significantly outsell books from Pearson Publishing, even though they’re the same publishing house.  The lack of a well-known imprint could make it difficult to build an audience.

 

What are the advantages?

Full control over content

Easier publishing process (arguable, I suppose)

Infinite ability to revise content after publishing

Better interaction with readers

Better for the environment, if that is meaningful

 

I would think it would be relatively easy to monetize the content through eBooks, like the Kindle.  Some technical blogs are already syndicated on that platform, such as Jeremy Stretch’s Packet Life blog.  Thirty cents per month per user probably isn’t terribly lucrative, but for hassle-free revenue, why not?

Monetization Strategy

Google Adwords

eBook syndication

Professional consulting

Partnership with training vendor (depending on blog content)

 

 

I’d love to get some feedback, especially from authors (books and blogs).  Have you considered something like this, or are you already do it?  What are the challenges you’ve faced?

Recap of Cisco Certified Architect Update

On Thursday I attended a Cisco meeting on the CCDE and Architect certification programs.  There was not a lot of new information offered, so some of this has already been discussed on the blog.

 

Timeline

October 2009:  Blueprint available on Cisco Learning Network

November 2009: Application process open on CLN

January 2010: First board review availability

Candidate Application Process

To apply, you need to be an active CCDE.  The next step is to submit a resume, which should demonstrate 10 years of networking experience and some architect/design responsibilities (not necessarily 10 years of these responsibilities).  The candidate also needs to submit a Project Summary for an architect or design project that he/she led.  During Q & A, I asked if there would be a specific format for this.  That hasn’t been determined yet, but I don’t see how the application review team could handle this without a specific format, since we all use unique project documentation.  The resume and project summary will be reviewed, and questions will be developed to be asked during a short (15 minutes?) phone interview.  This will allow the application review team to be certain the candidate is qualified to take the exam.

 

Test Pre-Work

Assuming the candidate has passed these checkpoints, he/she will submit payment and receive the project documentation / test materials.  The candidate will have a few weeks to develop an RFP-style response, which will consist of a Functional Specification, High-Level Architecture Diagram, an outline of the Board Meeting presentation and a few other documents that I failed to note.   The presentation used during the meeting is not yet available for download, so I can’t look up the missing documents at this time.  This documentation will be submitted in advance of the board review, to allow the board to develop questions based on its contents.

 

Board Review

The board review is scheduled for six hours.  No mention was made of where it will be, or if Telepresence will be used for the reviews.  There seemed to be a hint or two of using technology during this process, and I believe the initial board is physically located in separate offices, so I’m expecting a Telepresence presence, so to speak.  The timeline for the review is:

1 hour – Present design solution to Executive Team

1 hour – Respond to questions from Design Team

15 minutes – Presented with “What If” change to original architecture challenge

2 hours, 45 minutes – Create solution based on new “What If” requirements

1 hour – Present and defend new solution

Out of the six hours, three hours are spent presenting or defending solutions.

 

Other Notes

- I don’t believe anyone mentioned when the candidate will receive a pass/fail result, or what sort of feedback is expected.  As a potential candidate, I’d like feedback with either result.  Even successful candidates have room for improvement.  That’s one of the negatives to receiving only a “Pass” result to the CCIE/CCDE exams.

- Someone from Cisco on the call suggested that there would be around 100 successful Cisco Certified Architects in year one.  I’m sure most of the call attendees (and a few of the presenters!) did a double-take at that news.  One of the Q & A questions bluntly asked “If there are 7 current CCDEs, how can you get 100 Architects?”  The response was that the CCDE program is expected to pick up steam over the next year, and many CCDEs are expected to immediately pursue the Architect certification.  I have my doubts.. my guess is 15 in 2010.  I don’t think there have been 100 unique CCDE candidates to date.

- There will be a recertification process, and it will likely consist of contributing to the program via content development or serving on future review boards.  It’s a good strategy, as developing this content will be highly time intensive.  It will not be possible to ramp up this certification program to hundreds of candidates without significantly expanding the certification team.  This should be a cost effective method of accomplishing that.

- I was a bit surprised at the lack of questions from the meeting participants.  Perhaps everything is too new at this point.  I was going to also ask about the expected pass rate, but I doubt they have a target, so it didn’t seem worth the time to me.  The only notable question was about the cost, which I don’t believe was addressed in the presentation.  The $15,000 price tag was confirmed, with some mention of it being comparable to Microsoft’s top-level certification.  I have no knowledge of their programs, so I’ll take the Cisco team at their word on it.

- The presentation is supposed to go up on CLN soon.  It went into nice detail on the Candidate Objectives, so it will be nice to see it on my own time.  That part of the presentation went a bit too fast for me to absorb all the info.  If I had known in advance, I would have taken some screenshots!

- The presentation team went into a bit of detail on the differences between Network Designers and Architects.  Most people I know (including me!) use the terms interchangeably.  The basic point being made was that Network Architects take business requirements and turn them into functional network specifications.  Network Designers take the specifications and create a network.  I don’t know of anyone who functions as an architect without also creating the network design.  I certainly know of engineers who only perform the second step.  So who creates the functional network specifications for them?  In most cases, it isn’t really created.  I have been guilty of this.  I’m told of a business problem that needs to be solved, and almost immediately I fire up dynamips and configure a solution.  I would like to think that intuitively I’ve thought through the architecture and concluded that my solution is the best one, but without explicitly going through the process, I can’t truly know that I am correct.  Over the last year, I have made a point of incorporating architecture/design reviews into my project planning, and asking for more input from project team members.