Some Thoughts on IT-Researcher Interactions Triggered by SDN Initiatives

GOAL of this document: This document attempts to outline timeline, processes, and tips on how tight interactions between IT departments and the research community may be effective. New network technologies, mash-ups of different technologies, evolving domain science workflows, a plethora of existing toolsets, etc. are enabling more rapid turnaround of research to prototypes to production explorations. For these explorations to be successful and timely enough for paper submissions, grant proposals, etc., the reseearch community often needs a close collaboration with the IT support organizations. Various operator-researcher meetings such as the GENI Engineering Conferences, Internet2’s Network Technical Advisory Committee (NTAC), Focused Technical Workshops, and Software Defined Network workgroup calls, have repeatedly noted the increasing need for these communities to interact at a more collaborative level.

For collaborations to be effective, respective groups need to understand some of the nuances of each respective entity’s processes. This document highlights some of these processes and potential best practices for such interactions between researchers and IT support groups at university campuses.

One of the strongest examples of the need for research and IT support collaborations is in the area of Network Science and Engineering (NSE) research.

Network science and engineering (NSE) requires extensive applied research through advanced testbeds. Initiatives such as the National Science Foundation’s GENI (Global Environment for Network Innovation), XSEDE (Extreme Science and Engineering Discovery Environment), and the recent NSF Cloud initiatives, such as CloudLab and Chameleon, have integrated many such research testbeds with campus network infrastructures. These integrations create a natural increased interaction between:

  • infrastructure personnel,
    1. university campus information technology departments,
    2. regional network operators including Internet2, and
  • researchers,
    1. educators who teach courses,
    2. academicians who advise graduate students,
    3. researchers who conduct Network Science and Engineering research, and
    4. any collaborators thereof being external and internal to the organization.

This document will use the term researchers to include educators, academicians, pure researchers, and collaborators of researchers. Similarly, the term infrastructure personnel includes the IT personnel as well as personnel in regional and national research and education networks (RENs).

Strong researcher and IT support interactions happen when each entity is willing to develop an understanding of the expectations, career aspirations, and motivations of the other. Each entity is responsible for expressing their interests as well as understanding the other party’s motivations. Each entity also needs to develop a sense of the timelines, deadline pressures, and constraints of the other party. The following table and lists suggest some of the general motivations, expectations, job requirements, constraints, etc. of each party in the context of Network Science and Engineering research and IT support. These are not exhaustive and only represent some of the observations of the authors in different scenarios on different campuses.


The list below is meant to be a general overview and not all items may be applicable and there may be more items to be included (please contribute!).

Researcher Perspectives:

Interests Opportunities/Need
Use infrastructure Learn features and capabilities of infrastructure
Raise research funding Help in deployment of research instruments
Build experiment test harness Help/support in setup of research testbeds
Teach courses with labs Stable infrastructure and testbed for laboratory/demos
Exchange data and methods Sharing policies of research data with collaborators
Student career development Internship and other positions at IT, regionals, etc.
Cross-pollination of ideas Applications of research/learn everyday problems in IT
Industry perspectives New products and features, test/investigate


Research instrument here is within the NSE context. Therefore, it is composed of one or more network equipment, virtualized resources, and other components connected to the campus production network. Even if these collection of server and network devices are connected to a campus production network (or a regional/national REN), the level of privacy and control over the research instrument should be analogous to how much control an infrastructure personnel in IT/REN may have over a microscope in a biology lab.

Although the above table covers some of the research perspectives, the researcher will always be in an investigative state of mind. Therefore, the expectations and perspectives change focus, and, priorities may move relatively quickly based on teaching load, research funding opportunities, collaborative opportunities, etc. Funding processes, documentation processes, and regulatory requirements through the individual institutions, funding agencies, and collaborators may also have an impact.

Requirements and Constraints of Infrastructure Support Personnel:

IT support requirements

  • Reliability and scalability of infrastructure
  • Integration of mobility platforms
  • Visibility into the infrastructure
  • Amortization of equipment
  • Rapid change of large breadth of technology
  • Training and certification
  • Long-term teams and general human resource constraints
  • Well-defined work processes for operational stability
  • Increasing regulatory compliance requirement


  • Reliable enterprise applications and network need to support large, disparate user groups
  • Standardization of equipment, backbone, distribution, access for operational efficiency
  • Integration of wireless and various mobile platforms
  • Ability to merge with instruments providing an overall visibility of infrastructure if responsible to monitor
  • Realization of return on investment and total cost of ownership
  • Vendor sales and influence on decisions with features and solutions
  • Vendor certification, focused skillsets on specific equipment
  • Specialized, focused, and well-defined skill sets within teams
  • Handle issues through escalation policies while linking to resources
  • Different mitigation strategies based on particular regulation, i.e. risk based, prescriptive, project-based, etc.

The above list covers some of the high level requirements and constraints that IT support groups may face. IT personnel typically have a focus on projects with 1-5 year time horizon. Work requests and project requests from across the breadth of campus user groups drive the operational priorities. Infrastructure support personnel must support and balance the academic requirements, the performance driven researcher, the network researcher, the medical researcher and the day-to-day administrative campus functions, such as payroll, sport venue activities, special conferences, and other activities. Even in a relatively mature organization, personnel and financial resources have a limited scale that limits the amount of customization possible towards specific requirements.

Most work processes are part of the job definitions for the personnel’s work hours during the day. If large enough, IT organizations may allocate some work hours towards free-form learning and exploring technology and gaining new skills. However, most such time allocations end up within the context of a new feature set within an existing enterprise solution product. Training opportunities often are through a vendor-specific venue focused on operational considerations and upcoming vendor developments.

Interactions with Research Projects:

Research projects are similar in many ways to a start-up business approaching a financial institution/venture capitalist group with a new idea around which they want to start a company or obtain an additional round of funding. Researchers must bootstrap ideas just enough to write cohesive stories about how their technology or idea will be novel and change the field. The researcher must convince the reviewers (of papers, proposals, etc.) that they can deliver at least a prototype around their ideas and that this prototype will contribute intellectually to the field.


A research prototype might be an engineering model, code, thought model, medical derivative, etc. depending on the research field.

As part of the outreach to the broader community, the research project will potentially produce jobs, increase knowledge level, and create publications with students in the field and related areas, and possibly the greater community. The researcher might do preliminary “marketing” of ideas through invited talks, discussions within the community, and student publications. If awarded, the researcher has to provide annual reports and presentations to the funding agency. If the researcher is part of an actual contract, as opposed to a grant, the researcher typically has specific deliverables with rough timelines for those deliverables. Whether a grant or contract, a researcher must also publish paper results in journals and at relevant conferences.

Generally, three phases may exist in working with researchers on a somewhat well-defined project. The following prose in bullet points describe these phases in terms of a Network Science and Engineering (NSE) research infrastructure project:

  1. Pre-proposal stage: Gathering information on the idea and evaluating testbed connections and vendor options.
    • Bootstrapping ideas with no direct funding
    • Describe the early ideas with student publications
  2. Award: Obtain funding and go through some/all of the following sub-stages:
    • Build and deploy the proposed testbed
    • Run, operate, and maintain the testbed
    • Operate the testbed for longer terms with equipment refresh cycles
  3. Research stage: Orchestrate data collection, collaborator access to data, transfer of data to other entities, and long-term data management with preparations for further fund-raising. This phase of interaction refers to an infrastructure that is operationalized inside the university administration.


The first stage can last up to one or more years. In this respect, the nature of research - IT support personnel interaction has a slow progression, less about deliverables, and more about researcher learning from infrastructure personnel in vice versa. In some scenarios, the researcher and the infrastructure personnel collaboratively scope the project with specific expectations, and outline the processes for a long-term engagement. In other scenarios, the researcher and the infrastructure personnel organically or spontaneously grow the collaboration around a number of small or large opportunities.

IT personnel’s experience is valuable to student projects and feedback to student papers. The IT working experience helps broaden the student and faculty perspectives into some of the real-world issues that provide opportunities for additional research. Student projects, papers, and class papers can also help to broaden the exposure of new emerging ideas for the IT professional, beyond the specific vendor stories. There is also tremendous value in this exchange for the students’ preparation for the professional environment since they have to learn how to work around the “day-job” duties of IT personnel while pursuing their degrees.

During Pre-Proposal Stage:

As research ideas start to come to fruition, clarity also start to come to the shaping of a proposal to raise funding, and how collaborators might contribute to a specific proposal. Documenting a memorandum of understanding (MOU) at the proposal stage will remove potential misunderstandings on the mutual expectations when/if the proposal gets funded (or, funds are somehow raised to accomplish the project). Possible items to consider are:

  • equipment to be purchased,
  • location of deployment,
  • connectivity requirements (and, if there is any fiber deployment is needed with cost budgeted into some form of funding source)
  • infrastructure personnel who will be the point of contact to get the project accomplished with protected time committed to the project by their supervisors,
  • time allocation for vendor and equipment relations, purchasing processes, (and specific process information that corresponds to the particular university administration if capital purchases are involved),
  • administration and operational control of equipment during deployment and beyond.


Most researchers may not be aware of the purchasing processes involved in large infrastructure equipment including the option to evaluate, test, open bidding requirements, design phase that may include the vendor system engineers and outside consultants.

Although a fully executable and definite version may not be possible at the proposal stage, just the discussion of these items will help align expectations from each side. Notes on these discussions with contingency plans may also help in clarifying where each party’s interests lie in addition to how risk can be handled when less funding is secured, or the amount of existing resources may reduce for some reason.


Keeping these interactions informal is key to building relationships. However, written minutes of meetings is also the only way such interactions can turn into reality with tangible goals and deliverables. Professional decision processes should be followed to reduce misunderstandings in the long term.

During the pre-proposal stage, the researcher and IT support collaborators might also look at the different options for funding. Multiple national government and industry mechanisms for funding are available for funding. Most common infrastructure funding for Network Science and Engineering have been through the National Science Foundation’s Advanced Cyberinfrastructure initiatives ( For infrastructure specific to the support of the life Sciences or medical areas, the National Institute of Health has solicitations as well. The Department of Energy also has solicitations that cover a large area of research fields such as carbon sequestration, clean energy, etc. Industry partners, such as those in the oil and gas and other fields of research, are also viable partners.


Each funding entity has its own unique requirements for proposals, i.e. formatting, type of support documentation, proposal lengths, etc.

Project Proposal Stage:

This stage involves a lot of writing. Not all IT personnel are comfortable in writing prose and typically have not written many (if any) research style proposals. However, if researchers can provide a framework for writing, or at least have specific question/answer sessions with the IT personnel, the researcher can gather valuable information and experience to add to a proposal. IT personnel also have the vendor contacts to obtain competitive quotes for infrastructure projects. IT personnel are also usually good at providing some critical feedback on whether the proposal sounds credible and able to realize a prototype within a reasonable time-frame.

Post Proposal Waiting Period:

This period is potentially a downtime during the interactions. Unless other ongoing projects exist, this time period is good for engaging in discussions to exchange ideas and to build mutually beneficial smaller scale projects through various activities such as:

  • Student internships at the IT support department which engage the students on real-life applicable projects while conducting research,
  • Invite network engineers to serve in master’s and PhD committee as external reviewers and collect their thoughts on applications and any applicable performance criteria,
  • Define an everyday problem (or a set of them) to be addressed as class projects and involve infrastructure personnel in advising, grading, and evaluation of projects (however it may be feasible - can be as little as attending the final presentation day of the class/lab),
  • Assign researchers to the service positions such as the Technical Advisory Group (TAG) of regional Research and Education Networks (REN) along with university network engineers as representatives of the university,


Usually such TAGs have only network engineers with no researcher voice. However, they need to support the research environments. REN goals are to support research and education and therefore need the researcher voice represented as well.

  • Hold seminar style presentations by researchers to be attended by the infrastructure personnel to familiarize with the research directions and exchange ideas on real-life applicability,
  • Jointly attend relevant conferences for each side such as: researcher may attend an Interop with his/her infrastructure personnel and students, similar options such as TridentCom, GEC, Internet2 TechExchange (or, similar) are also possible.


The above list comprises activities that turn this relationship into a long-term engagement without mandating time/effort on either of the parties. In general, the underlying assumption and the goal is to create, nurture, and maintain an environment where both parties are always gaining knowledge towards their own specific interests and goals.

After Securing the Funding:

First things first: CONGRATULATIONS!!! Now, it is time to shop for goodies!

The researchers and IT support professionals now obtain new refreshed quotes and start to work tightly to describe the current operational requirements from each party. This discussion temporarily foregoes future or current interests in research directions and focuses on the immediate implementation and how to manage it over the lifetime of the grant/contract.

Example discussion points in a Network Science and Engineering project might be a working/evolving spreadsheet to be shared between the parties with the following tabs and columns:

  1. Research infrastructure initiatives:
    • Researcher deliverable timeline: various and with somewhat vague deadline schedules
    • Collaborations: current, possible in the future, internal, external, etc.
  2. Communication workflow - change management:
    • Researcher making changes
    • IT making changes
    • Tracking of and response to outages
  3. Maintenance:
    • Firmware upgrades
    • Testing of new network equipment
    • Addition of new equipment
    • Overlap with general production maintenance
  4. General communication flow:
    • IT operational case submissions through some form of a work order system
    • Create a listserv (researchIT listserv)
    • Expectations on turn-around time
  5. After a research infrastructure operational process has been laid out with the points above, a tracking mechanism can be formed for all equipment and virtual resources with the following ownership identification for clear-cut expectations from each party:
    • Equipment
    • Location
    • Administrator
    • Project and purpose
    • Account holders
    • Operational administration
    • Notes and future considerations


This document has been made possible through the authors’ experiences while building research infrastructure and experimenting on such infrastructure and through many discussions that happened between the authors and Nicholas Bastin, the GENI community, the CIO of University of Houston Dr. Dennis Fouty, researchers, LEARN’s CTO Akbar Kara and CEO Mike Phillips, SETG’s technical advisory group (TAG) including Scott Mace and Jeff Early from the Baylor College of Medicine, William Deiggard and Jason Bothe of Rice University, and the Internet2 personnel.


Indices and tables