There is a real shift going on in IT as we try to be more open in our discussions of systems. The most difficult question to answer is how much information is too much to release. I won't post passwords (duh), code versions (gives away security holes), or details such as IP addresses and sub-netting. I will however talk about issues that occur from deliberate choices that we make in our systems. I am also very happy to discuss why we do these things as well. The other day, I read an interesting post on Bill Simon's PSU VoIP Blog. Bill was attempting to answer the age-old question that anyone working for Penn State IT has to answer. "Why do you do it that way?" I will attempt to add to the answer, because I don't think anyone has the entire answer. In the interest of full disclosure, I work directly with Bill on most of our VoIP systems. Since I technically work in systems design and Bill works in operations, we can and do have differing opinions at times. I really value the opinions of our operations team, because they are the ones who ultimately get stuck making things go and talking to the cranky customers with broken stuff. Our department, TNS has been going through a number of what could be described as therapy sessions in an attempt to better our service to Penn State. We are well aware that our current organizational structure is not agile. We need to change that from within, and so we want to begin by sharing our information with our customers.
Bill's post talks about how at the University we have many autonomous groups who may or may not rely upon TNS for their network management. Some departments are very independent and others like spending their time not worrying about LAN/WAN maintenance. There are pros and cons to each approach, and personally I would choose either one accordingly depending upon which approach is most responsible for the organization being served. At University Park, we have approximately 300 building connected to the VoIP network. If we followed a vendor recommended approach to the letter, we would potentially be housing some form of telephone system in each building on campus. The total cost of ownership for equipment and the people to manage it would be enormous. We do share physical infrastructure between buildings such as fiber-optic cabling, and we share the core routers but separate the traffic. To maintain reliable telephone services, a long time ago, the decision was made to manage VoIP LANs more like the controlled network of the PSTN than the trusted confederation model of the Integrated Backbone.
There is a constant debate about why we do the things we do. I fully believe in supporting open standards (not necessarily open-source) among our systems so that we protect Penn State's interests by not getting ourselves trapped by a vendor. As a University, we do not reports to shareholders, but we do have many stake holders. It is our responsibly to be good stewards of their trust and resources. Vendors very often report to shareholders, so it is their job to sell us as many things as possible. It would be very easy to just open the Penn State cost-recovered coffers and pay for an all-in-one service provider whether it is Cisco, Microsoft, Apple, Nortel, etc. Easy, yes...but not ultimately beneficial to us. What happens if a monster company implodes like Enron, or more realistically declares an utterly useful product dead to bolster stock prices? Putting the students, faculty, staff, alumni, and even the communities that Penn State serves as part of its mission at the mercy of large IT companies is not in our best interests. The fun part of my job is to figure out how we can provide useful services that are not proprietary and can for the most part be independent of their vendors. I use proprietary tools all the time (such as the MacBook Pro I am typing on right now), and I will definitely use proprietary tools to bridge gaps that standards haven't yet addressed. I won't however, use them indiscriminately and without study.
The traditional telephone is slowly on its way out. I will probably not see its departure during my career, but it is headed that way nonetheless. Software based communications tools are definitely the future. Soft Phones give us flexibility to use telecommunications wherever we may be. VoIP from an iPhone, or cross-referencing a database with a desktop contact center client are two examples of the superiority of software clients. There is an experimental service now that uses the communications standard SIP to allow person to person voice, video, and instant messaging for Penn State. It will connect to the PSTN in the future, and yes it does resemble proprietary services like Skype. This service is a Penn State effort to build a solution that doesn't rely upon any one vendor to deliver the service. It also works on desktops and laptops regardless of their operating systems. This VoIP offering takes advantage of the Integrated Backbone rather than hiding from it in a walled garden. It can do this because it is not the same thing as a 12,000 customer PBX that is held to the same standards as the Local Exchange Carrier for delivery of 911 calls and 99.999% availability. These systems have different purposes, but they will eventually work together to provide better, faster, and cheaper communications for our customers.
