IT management done right

How Babson College syncs its network, systems and software groups

Yes, it's plumbing, but you still need good plumbers. It is true that these services are now 'dismissed' as dial-tone, but the lack of a well-designed infrastructure hurts. The approach we take to network design is to define the business problem to solve

Network World Editor Bob Brown recently conducted separate interviews with three members of the 38-person IT team at Babson College, a business school for 3,300 students based in Wellesley, Mass., to gain insight into the perspectives of members from different departments and to learn how they are coordinating their efforts to manage a 9,000-port network (plus 300 wireless access points) across roughly 60 buildings.

The school is pushing hard on three big projects: Digital Babson, an initiative to get Babson content and thought leadership online; next-generation application infrastructure; and network/server architecture enhancements.

To read an interview, click on a name:

Kuljit Dharni, director of architecture & development

Steve Thurlow, manager of enterprise services

Andy Lymburner, manager of software services

Kuljit Dharni, director of architecture and developmentHow do you coordinate interaction among your network, applications and systems teams?

On the formal end we have a full team meeting on a biweekly basis, and a full list of all current projects are published prior to this meeting. Additionally, I hold one-on-one's with my direct reports on a biweekly basis. On an informal basis, I talk with pretty much every team member daily -- this may be just a hello or a quick chat about a current project of theirs.

Where is the interaction most natural, and where do you need to work hardest to make it happen?

The informal talks are the most natural. I love to talk tech, and people are happy to talk about their current projects to demonstrate "cool" things. The formal group meetings are a 50-50 affair: Half the people like them, and half can't stand them. Additionally, not everything that comes out of a casual meeting gets documented -- many times there is no need, but some projects need my input, and if I approach someone out of the formal project context, good discussions/solutions tend to get forgotten 'til sometime in the future (i.e., at app review/testing time).

How do you see the roles of your network, applications and systems teams changing in the light of new technologies and business requirements?

The biggest issue we face is that of our customers demanding more-complex software in a short time horizon -- both in terms of the notice given to us as well as the time to complete the projects. Since the teams (server, app, network) manage all aspects of the life cycle (definition, creation, testing, implementation and support), we often feel rushed and overwhelmed. To manage this, the teams are approaching the projects in a more flexible manner -- i.e., through an iterative process vs. let's define everything and build it in one go. We are also attempting to layer more formal processes for support and project request. This is tough in a college environment, since people do not toe to the bottom line.

Industry pundits increasingly tend to dismiss core network technologies, such as switching and routing , as mere plumbing. But is designing a network really a no-brainer these days?

Yes, it's plumbing, but you still need good plumbers. It is true that these services are now "dismissed" as dial-tone, but the lack of a well-designed infrastructure hurts. The approach we take to network design is to define the business problem to solve and then through an iterative process come up with potentials. These potentials are fleshed out, and I make the pick based on a few criteria -- namely, how well does it serve the initial purpose, how complex is it (i.e., how will we support it) and what will it cost (initial and ongoing). The other thing we do is to continually keep reviewing technologies to make sure we have the best solution for us -- sometimes this is based on feature and functions, sometimes purely on cost.

You've mentioned that you want to emphasize a certain QoS for users that goes beyond the sort of Layer 2 and 3 QoS that we sometimes hear network-product companies discuss. What do you mean?

The QoS that I find relevant is not at the bits and bytes level, it is all about the "perceived performance" from the users' perspective. This is not to say we take all user comments of "the network/application is slow" at face value, but we do try to find patterns in these comments and investigate the causes that lead to the comments. If there is one standard measurement in computing, it is that happy users don't complain. Therefore, we take all complaints seriously. Setting arbitrary performance levels at the network layer is not useful to me, the entire experience of the user has to be taken into account. This usually means we look at the application on down when researching performance/quality of service issues.

In short, the line between the network vs. servers vs. application is so fuzzy you have to take a macro view toward QoS, no matter what your job role is. I expect everyone within my organization to look at the user experience first and then their statistics to support/refute the claim.

You have a background in disaster recovery and continuity services with Comdisco. How do you exploit that experience?

I have a healthy paranoia of things going wrong. I try to bring my experience to bear in terms of balancing the need/cost of recovery solutions. I.e., anyone can throw money at a problem (especially recovery), but how do you do it cost effectively and how do you prioritize?

How do you cope with the budget constraints of running a college IT department?

Pretty much all of my comments mentioned the need to be cost effective. I continually try to challenge my team to present solutions that do more than one thing -- i.e., how do we maximize our investment? E.g., we purchased a product from Acronis for making DR images of critical servers (that was issue No. 1 -- identify critical servers, not all servers). Using it in the mode it was intended for is great (i.e., server recovery), but how about using it as an image tool to create server replicas for testing, or how about using it to do a P to V move? Another example is that we tested HBAs, accelerator cards and built-in NICs for use with iSCSI vs. just taking the HBA route (per everyone's suggestion). The result: We use the built-in NIC, our testing (and now experience) shows no loss in performance (I/O or CPU) using the server NIC's from Intel.

What one technology has you most excited these days?

In my position, I find it difficult to be excited by any one technology, but will limit my answer to two:

* Virtualization, in conjunction with iSCSI. We adopted this dual architecture over the summer of '06 and have been thrilled with the performance, flexibility and relative low cost. This environment has allowed us to scale our operations while cutting back on the number of physical hardware. As of February, we're running 29 virtual servers on four physical dual-processor machines. The conservative estimate is to scale to 80 virtual machines on the same hardware. With the redundant iSCSI array from EqualLogic, we are able to have all hard disk for the virtuals on the SAN (including boot volumes). Therefore, we fully leverage our VMware ESX environment with automatic failover and load balancing.

* On the application side, I am excited about the ready availability of enterprise applications that are "user focused," i.e., social-networking capabilities, wikis and blogs, etc. While these technologies are not exactly new, they are underutilized on the enterprise level, including at colleges and universities. The interest I have is not to replicate MySpace, but to truly create a useful and engaging experience for our students and faculty.

Name a technology you think is overhyped or underrated?

I would count SOA as an overhyped technology. Don't get me wrong, I believe in the intent of SOA, it's just that it's the latest in a long list of terms for an obvious application architecture. Anyone trained in computing science in the last 20 years should have been thinking about and building applications that were loosely coupled and supported the business rather than IT. However, if it finally has people thinking about architecting scalable solutions it will have been worth the pain.

What one technology do you wish never existed or that you could have back?

The administrative side of me wishes P2P had never been invented. From a technology viewpoint I love it, so simple, so clever. From the administrative side, especially in a college setting, it has been frustrating to keep P2P under control, i.e., managing use of our bandwidth, complying with intellectual-property issues, etc. Basically, it makes us in IT into the bad guys in the eyes of the students, when all we're trying to do is a) preserve a good computing experience for all of our clients and b) stay within the confines of the legal system as well as the rules of the college.


Return to introduction

Steve Thurlow, manager of enterprise servicesHow do you interact with your peers in software services?

On all levels. For starters the network and systems groups are managed by me, so we have a great deal of interaction where otherwise we might not.

We also have integrated weekly operational and project meetings in which staff from applications/systems and networks work together in delivering our services. Typically, in IT this kind of interaction only happens on projects. The problem with that scenario for us is that we do both operations and project work. I have found that including everyone in the operational meetings as well as project meetings has produced a balance from all groups that truly understand we are not just project-focused and point fingers at each other when we have issues with project deadlines. The other aspect is that it becomes harder to separate the pieces when you have applications running on virtual servers connecting to an IP SAN with VLAN trunking on backup and production networks. All these technologies are merging to a point that it becomes difficult to function well if we are not working together.

What are the keys to successfully working with the other groups?

360-degree communication is critical. Since we are technical groups, we often listen to one scenario while thinking of something totally different. This means we walk away thinking we have consensus that we don't actually have. This happens all the time, and the only way to effectively deal with it is clearly stating after the fact what we talked about. This will identify areas that need more discussion prior to getting knee-deep doing something that you find out later was not what everyone agreed to in their own minds.

Give me a thumbnail sketch of a project where your groups worked with software services.

The deployment of virtual servers has pulled everyone together in a way that required the trusting of each other's disciplines in the delivery of services to our customers. Combining applications on underutilized servers to a common virtual server is an area where the application experts needed to trust the system experts in providing a platform that would perform for the applications that couldn't be physically touched. The system admins needed to work with the network admins in delivering VLAN trunks and lag ports to the virtual servers as well as connectivity to disk delivered over an Ethernet network.

Can you think of any examples where you should have worked more closely with these other groups?

The most important lesson learned is don't be afraid to both ask for help understanding something and also don't hold back in the giving of information to others. The biggest mistake is to assume that because someone works in another group that they either wouldn't understand or don't care about the expertise that you provide.

How do you see the role/priorities of the network team changing in the light of such new technologies as VoIP and wireless?

Over the next five to 10 years, we will continue to see a blurring of service providers for voice, video and data. As this trend continues, companies will struggle with how they can morph their separate groups for these services into a combined force that will be able to really utilize the emerging technologies in ways that will improve their service offerings.

Babson emphasizes QoS beyond Layers 2 and 3. How does your group contribute to optimizing the user experience?

By simply looking at it as an experience and not just a narrow view of how fast the packets get from one part of the network to another. Everyone feels a responsibility to making sure that the user's experience is the best that we can offer. Sometimes that may mean that a system admin helps a user troubleshoot their networking connectivity when the call that came in was related to server performance. Our user community sees IT as one face. We try to make sure the face they see does not have multiple personalities.

What one technology has you most excited these days?

1 2 Page 1
Page 1 of 2
SD-WAN buyers guide: Key questions to ask vendors (and yourself)