�ݺ�ߣ

Editor's Notes

1. My wife Brenda and I surprised her best friend Tricia in Oklahoma for her 40 th Birthday party Brenda & Tricia left to go attend one of her son’s football games The family was new in the house and many things were not yet unpacked I was left in change of some of the meal preparations I had the recipe but no mixer, so I had to come up with something
2. I searched the kitchen which didn’t help too much, though I did find the beaters to some mixer The broader search didn’t turn up a mixer I had a finite amount of time to get this done
3. There were no electrical appliances except for a coffee grinder, toaster, and espresso machine The drill was a variable speed device and worked FABULOUSLY in mixing the egg, cheese, and other ingredients
4. I scooped the egg mixture into the cooked egg halves using a melon ball scoop, dipping it in water to allow the mixture to come out easily This part of the process only took a few minutes, and the eggs turned out perfect; keep in mind I am NOT a cook nor do I consider it a strong suit The guests at the party loved the eggs, more for the flavor than anything else, but I was pretty jazzed about coming up with the whole solution
5. Creative Solutions do not happen in a vacuum but require the right conditions and begin with EXPANDED THINKING, requires a little bit of wild eyed optimism Actually creating the solution also requires management of ideas In the final analysis if all you do is dream then be a writer, solutions require that you put feet to your ideas
6. First and foremost, you have to be willing to fail, made fun of, or called all kinds of interesting names Understand that no one bats a thousand, expect a minimum of 50% fall out rate on ideas No wasted solutions, you may find parts of what you think was a bad idea to be core in another solution later Experimentation is really key here, good ideas grow out of “what if” questions The story of Cisco Systems is actually key to this, Len Bosack, Sandy Lerner, and Kurt Lougheed developed the first Cisco routers on the campus of Stanford Their home was the location of the first “assembly line” and when Stanford said NO to commercial production, they did it anyway; not everything they tried worked either but look at the state of the industry and business NOW Famous examples include the Beatles who were refused by Decca, Fred Smith, etc.
7. Fed Ex as a concept got a C grade when submitted The phone was regarded as a useless toy by Western Union, and now its current forms dominate the modern communications landscape Having a thick hide is REQUIRED to pull off creative solution designs Knowing how to NOT quit is also important
8. I spent a lot of my early years without the right resources or tools to get things done so it forced me to use creative workarounds to compensate Not every idea worked, I tried to create a steam pump to pull heat to my room in college and that was a huge failure In my CCIE studies I depended on very old equipment that often could not completely serve the exam, for instance I could not afford $3000 3550 switches at the time so I used a router and L2 switch to mimic most of what I needed to use At AT&T I had a couple interesting crazy solutions, one was for a large retail company who wanted certain parts of the network be restricted to certain servers in the data center. AT&T refused to do VLANs in the data center (one wonders why), so instead I created access lists and null routing to accomplish the same thing over the VPN tunnels. Ironically they liked that solution better One customer migrating from frame-relay to an IPSec VPN service never mentioned Novell IPX until the solution was going in; I suggested using the legacy Cisco routers to use GRE tunneling to transport the traffic until it was phased out. It was also a solution that was inelegant but helped in its own way Coffee Partners Hawaii owned Starbucks and Jamba Juice stores and wanted to have one DSL connection support Internet access and dual IPSec tunnels to Starbucks and Jamba Juice HQ’s for card processing. Using propietary security devices requires some unusual subnetting and ACL’s to provide that VPN backup to the AT&T MPLS service was required and used a combination of HSRP, BGP, and EIGRP for correct failover and local Internet access Because I changed configurations in my lab environments often I wanted to create a program that would access the routers and switches in the lab via console access through terminal servers, open telnet/SSH, log in, write configurations to the NVRAM and then drop the connection. After fighting with the concept for a while I later learned that others had already accomplished that Many many of the crazy things I come up with do not work as intended or do not address the issues enough to be considered viable, I give these examples simply to give an idea of how willing you have to be to come up short Some ideas may qualify as nothing more than novelty items but can still be fun – call it a “mad scientist” inclination
9. Another CRITICAL element is understanding HOW the technology works from a technical standpoint. On one of my first UC installs, CUCM paging was not working correctly and the customer was facing about $3000 to upgrade the switch software from SMI to EMI so it would support multicast. The link between the 2811 and 3560 switch was a L3 routed port, but if it was made a trunk instead, then the EMI was not necessary to support paging. GREAT example of knowing how the technology actually works. Sometimes in the rush to get certified it is easy to lose the importance of how everything actually functions As kids we had unlimited imagination and creativity and no shame about using it. As adults we seem to forget how to “play” so to speak, to say nothing of creativity. Innovators are in a sense in touch with their “inner child” One of the reasons that hackers continue to create issues, viruses, and other challenges is because they are willing to ask “what if…” or “what does this do” questions instead of trying to always color inside the lines CHALLENGE assumptions, you will be surprised at the avenues it can open up
10. Once you have the right mindset for coming up with creative, off the wall ideas, you have to actually CREATE them. It starts not with wanting to come up with weird ideas but rather on addressing an actual need: KNOWING the issues marks the first step. Frequently, if not always, it is a business need rather than a technical need that you find yourself addressing, and requires peeling back the layers. CLARITY IS KEY HERE: Beware of assuming you understand the issue, it’s amazing how often you can find yourself answering questions that no one is asking The second step is the one where a lot of folks understandably go awry. List out EVERY POSSIBLE SOLUTION; don’t get caught up in how wild, impractical, or mildly insane it may sound. Don’t put a fence around things just yet, all in good time. What you often find is that this stimulates the creative juices in ways that just going for the solution first just cannot do. It’s not the destination that matters at this point, it is the journey. Take the time to consider every angle, possibility, or idea FIRST ! Roughly describe the potential solutions with as much detail as you can without getting too caught up in them; sketch it out, don’t draw a Mona Lisa! Think of this as the “Flood and Prune” methodology of PIM-DM!
11. After compiling as complete a list as you can, start narrowing the field a little bit by pruning things based on a series of questions The first is TECHNICAL in nature: Will it work? In the final analysis, no matter how cool or fun an idea may seem, if it does NOT function then it is worthless. Knowing why it may not work as needed from a technical standpoint is key here as well. This is the first and most important consideration to take a look at or there is no point. The second and equally important consideration is whether the solution(s) actually solve the problem and/or address the need. It may make a GREAT white paper, but at the end of the day of it doesn’t actually do what it is supposed to do then it is just as useless as a solution that does not work technically. Practicality is a major issue as well; if the intended solution cannot scale, costs too much or creates security holes, for example, then toss that one out as well. This one can be painful! The question of long vs. short term solutions is a big one. I have seen many many “I’ll just do this to get by for now” quick-fixes stay in place literally for years, well past the point that anyone who put it in place or remembers what it was for is even still around. If you DO use something as a short term fix make certain you go back to it and actually fix it at some point, the next person doing your job will THANK YOU! Supportability is a big deal as well, the whole question of TOTAL COST OF OWNERSHIP or operating a solution is groslly underestimated many times. CFO’s may like how cheap a solution is from a capital standpoint, but if it costs three times as many man hours to operate it, then it may be a poor solution Best Practices are helpful and save a lot of headache but this can be a place that good ideas are cast aside in the name of best practices; take care that it does not become an empty mantra that just thrown out every new idea just because it is different PAY ATTENTION to dependencies and potential drawbacks of certain solutions. If you can mitigate the issues without too much trouble, so be it, but if you create solutions that require constant babysitting or workarounds “keep fixing” then beware of going down that path. At the end of the questions you should have a couple viable ideas to work with, otherwise just go back to the drawing board a little bit
12. Once you have a direction, start trying it out…you may need to think things through a little more, and if so, this is the time to do it. The devil is in the details, so know what those details are and work with them As with new technologies and such, a pilot is always a great idea. If you do not have a lab, now would be the time to create one. Unless the solution(s) require it, use older, decommissioned, or surplus equipment works well for purposes of experimentation. Try to mimic the production environment in some form so that the test setup is close enough to the real thing sto be valuable I think actually writing out the equipment configuration is valuable, use notepad or a text editor. First of all, this helps spot typos, errors, transposed numbers or other obvious problems up front. It also gives you a great place to search if something is not working or having issues. It also has the effect of keeping the configuration fresh in your mind When you have the set-up functioning and working end to end, stress the systems to push the limits a little bit. If there are cracks in the ideas involved, this will be a way to find that out in a controlled environment, and also help prove out what you are after. Use show and debug commands as needed to measure what you are doing Have a test plan already thought out and follow it to a T; do not rely on a single set of data, but run it at least twice to make sure that it does actually work within certain parameters Document everything in detail; use that for later analysis and for use in crafting a broader solution on the production network
13. Go back and review everything; read your documentation thoroughly, and try to look at it objectively One of the greatest favors you can do for yourself is to have relationships with other great engineers, but make certain that you can share things with a level of trust; the last thing you want when you have come up with a cool solution to a problem is someone running off claiming it was their idea, or worse yet, to show up at a conference listening to someone do that Ask hard questions about the results; it’s better to scrap an idea than stubbornly hold on to it like it’s a first born child and find out later its not what you thought Create an action plan to apply the solution to the larger production network; even in this regard it might be a good idea to start out with a smaller pilot and see how things go: MEASURE TWICE, CUT ONCE!
14. The title of this presentation is the focus of the rest of our talk today, and the reason we are all here My wife is the Director of Medical Imaging at a Hospital in Bellevue, Washington, and she allowed me the opportunity to submit a Unified Communications Solution for a business issue in her department The TRANSPORTERS are a group within the department that move patients to and from exams and often on the move; coordinating t his aspect of patient care is highly critical and they were looking for ways to communicate with them and also empower communication with one another The hospital had a large installed base of Cisco switching infrastructure as well as 802.11a/b/g wireless access points running multiple SSID’s The end solution had to allow for 2-way radio type communication between the central dispatcher and the transporters as well as between themselves
15. Several possible solutions had already been contemplated by the Operations Manager, Mike Wade, with whom I was dealing A couple of the alternatives were expensive and could create additional support issues Using the process we discussed previously I thought about a way to use the UC520 platform with wireless phones to create a Push to Talk type of solution
16. The UC520 would ideally use a trunk to the access layer of the switching infrastructure but could also just use a single VLAN for voice (no data) The VLAN would ideally also map to a new BSSID using WPA2 for data protection The UC500 would act as DHCP server and no communication would be allowed to/from any device outside the VLAN Separate Ephone/Ephone DN’s could be used for each of the stations One 7942 phone would serve as the “base station” for the 7921 phones The paging-dn (IP address 239.1.1.1) would map to the PTT button on the 7921 phones When pressed, the transporter or dispatcher would speak into the microphone and be broadcast out to all stations, much as a 2 way radio Configuration details for this feature is available on www.uc500.com
17. Headsets would be used for transporters to use to listen/speak (VOX would not be possible but button would be pressed just as with 2 way radios) Channel would be simulated but mimic the functionality closely This was to be deployed in an all-Avaya environment and serve as a beach head for further Cisco UC solutions
18. This is the actual bill of materials for the proposed solution Installation costs would also be required since programming and staging would be required
19. None of these issues would be show stoppers but must be considered
20. This compares our previous paradigm to the solution In the final analysis the budget was set artificially low, I considered donating my time but was overruled by management