Session 263


The Importance of Synergy:  Integrating Curricular Components in IT


John A. Biles,

Information Technology Department, RIT





Most IT educators would agree that IT is a new academic discipline whose roots lie in several established fields but whose graduates possess a different mix of skills from that produced by traditional computing majors. The mix of technical skills that IT graduates must command is part of the IT story, but what really defines IT as a new and distinct academic discipline is the synergy enabled by that mix of skills.  To foster that synergy, an IT curriculum must successfully integrate curricular components and provide a unified vision of IT that is greater than the sum of its parts.


This paper presents a unifying vision of IT curricula, using RIT’s 10-year-old BS IT program as a model.  After presenting a brief overview of the curricular components in RIT's program, I’ll focus on curricular lessons learned from students’ experiences in industry while completing their cooperative education requirements.  These lessons point to the importance of integrating programming, networking and Web skills in virtually every IT co-op position and stress the importance of user-centered design and deployment as the key to enabling the synergy among the technical areas that defines an IT professional.  Finally, the paper will discuss implications for emerging IT accreditation guidelines and stress the importance of defining outcomes-based curricula that address societal needs.



As anyone attending this conference must know, Information Technology (IT) is a rapidly emerging discipline.  The formal establishment of the Society of IT Educators (SITE), which this conference heralds, is an important step in establishing IT as a recognized academic and professional discipline.  As the IT movement solidifies and spreads, model curricula are beginning to emerge as potential guidelines for formal accreditation of BS IT programs.


This paper presents a somewhat personal view of IT curricula, from the perspective of RIT’s BS IT program, which is currently beginning its 11th year of existence.  The author has been the undergraduate program coordinator of that program since 1996 and has, among other things, shaken hands with a few thousand IT graduates at RIT’s commencement ceremony, read several thousand work reports written by IT students returning from cooperative educational experiences in industry, and cut countless deals in the form of course substitutions and other accommodations, as RIT’s IT curriculum has evolved over the last 10 years.  I’ve also attended annual industrial advisory board meetings at RIT, served as a member on industrial advisory boards at area community colleges, and met with employers who hire IT students from RIT.


Hopefully, the perspective on the IT field gained from these experiences will be a useful lens through which to view IT curricula in general.  The author feels strongly that IT is a new discipline that is fundamentally different from traditional disciplines like computer science, management information systems, software engineering, library science, professional communications, engineering technology and a host of other academic fields that might touch IT territory but are clearly not IT.  One goal of this paper, then, is to help define what IT is, beyond a statement of what it is not.  I’ll try to do that by using RIT’s IT curriculum as an example and focus on aspects of our curriculum that are central to a definition of IT.  In doing so, I won’t discuss every course, in the interest of space.  Further details on RIT’s IT program are best obtained from the department’s Web site1.


The RIT Experience

RIT’s BS IT program is currently marketed as a four-year program that requires 180 quarter credits (equivalent to 120 semester credits) and three quarters of cooperative education experience (or co-op blocks, as we call them).  Chronologically, the curriculum is structured in two two-year chunks separated by the first co-op block, which is normally done in the summer after the second year of classes.  The goals of the first two years are to provide a solid technical foundation in three of the fundamental areas of IT and to prepare students for their first co-op block.  The goal of the final two years, which includes two more co-op blocks, is to provide solid career preparation in one or more IT specialty areas, along with opportunities to select coursework in IT application domains.


The first two years of the curriculum consist almost exclusively of required courses (ideally 11 IT courses, 10 of which are required, along with all six required math and science courses and the RIT standard seven-course Liberal Arts core).  The final two years is almost all open (three remaining IT core courses that require coop as a prerequisite, two three-course IT concentrations, six professional and general education electives, and the RIT standard six course Liberal Arts minor or concentration).  The curricular philosophy is to require as few decisions as possible before the first co-op so that career decisions about IT specialty areas and application domains can be informed by at least one co-op experience.


Another way to look at RIT’s IT curriculum is to break it up into general IT competency areas.  In this analysis I’ll focus just on the IT courses and ignore the application domain electives, Liberal Arts, and math and science requirements (except to mention that we require a two-course discrete mathematics sequence instead of calculus, since discrete math clearly is relevant to IT and calculus is not.  Discussions can follow in the bar…).


There are four fundamental IT areas in which all IT professionals must demonstrate a minimum level of competence.  Three of these, programming and application development, Web and multimedia development, and networking and system administration, are technical domains in which IT students may choose to specialize.  In RIT’s curriculum the foundation for these three areas is laid in the first two years through the pre-co-op subset of the IT core.  The fourth area, user-centered design and deployment, is taken primarily after the first co-op experience, because our experience is that students who have not been in the real world don’t really “get” these courses.  The human-centered courses provide the focus that integrates the three technical areas, which, at least in the author’s opinion, is fundamental to IT.  In other words, the user-centered courses are the critical component in an IT curriculum and enable the synergy of skills that defines a true IT professional.


Synergy:  The Coop Experience

Having outlined four principal IT competency areas, I’ll now turn to their inherent interdependence.  In short, it is the synergy of these four areas that defines IT, and one cannot be a competent IT professional if one of these areas is missing.  The conviction behind this provocative statement comes largely from reading several thousand co-op work reports over the last seven or eight years.  The co-op experience is a cornerstone of the educational philosophy at RIT and provides students with the opportunity to experience the field they are preparing for before they choose all the classes they will take.  Many RIT students have made mid-course corrections after a coop experience that corrected their misconceptions about a job or field.


One benefit of co-op to the academic departments is ongoing feedback on how courses apply to the real world and information on what employers expect of co-ops.  This feedback is delivered in a co-op work report each student must fill out in order to receive credit for the work experience.  Part of the report asks the student to classify their work experience by providing percentages for 10 typical IT job tasks.  When processing a work report, we try to interpret these percentages and categorize the job into one of several standard job titles.


Interpreting these data can be illuminating.  While some of the co-op reports can be clearly categorized as network/system administration or Web content development, for example, an increasing number are classifiable only as Jack-of-all-trades or general practitioner (GP) IT jobs.  In other words, the students do “all of the above,” typically for smallish enterprises that clearly need to perform a full range of IT tasks but are too small to support specialists in any one IT area.  The GP jobs, then, represent the fastest growing segment of our market.  Even a student whose co-op is clearly classifiable as networking, for example, might list 10% database, 10% Web site development, 10% system analysis because he or she may have had to build a database accessed from an intranet Web site to help manage networking data.  In short, the pure specialist in the IT field is largely non-existent.


In the current economy, many students are shifting their career paths in the GP direction by “diversifying their IT portfolios.”  For example, some students whose initial career goal was to specialize in networking are choosing a content development concentration instead of more networking for their second IT concentration or are spending their professional elective slots on IT courses from the database or interactive multimedia concentrations.  Many students diversify in that way after a coop experience in which they begin to see the importance of a breadth of IT skills and decide to address that when they return from co-op by broadening their course selections.


A recurring theme, both in co-op work reports and in feedback from industrial advisory boards and employers, is that regardless of the technical area, understanding and working well with users is critically important.  Figuring out what technologies might be useful to a user community and how to deploy that technology so that users can actually use it effectively is the goal of most IT pursuits, be it networking infrastructure, Web site development, database applications, or whatever.  This comes back, of course, to the user-centered design and deployment courses, which I will now address in some detail.


The Human Stuff

The four user-centered design and deployment courses, which we at RIT refer to informally as the “Human Stuff” courses, include Technology Transfer, Needs Assessment, and a two-course human-computer interaction (HCI) sequence, Human Factors and Interface Design.  Human Factors is normally the only one of these courses to be taken before the first co-op, ideally in the last quarter before the first co-op, but the other three are taken after co-op, as indicated above.


The Technology Transfer course, which holds the distinction of being judged the best course in the curriculum by alumni who have been in the field for a while, is described in another paper at this conference2.  The Needs Assessment course focuses on information gathering, including conducting an interview, designing a questionnaire, conducting a behavioral study, performing a task analysis, and several other skills and topics relating to how IT professionals can learn enough about a user community to assess needs that an IT deployment might be able to meet.


The first HCI course, Human Factors, addresses how people interact with technology by examining the theoretical foundations of the usability engineering lifecycle.  The second course in the HCI sequence, Interface Design, applies this by focusing on user-centered design and the critical importance of usability testing in the development of IT applications3.  This speaks to a fundamental difference between computer science and IT, specifically in the kinds of applications the two disciplines tend to build.  The traditional waterfall model and/or formal methods common in computer science and software engineering are not appropriate for most IT applications, in part because they depend on a requirements document that accurately describes the functionality required in the system being built.  In most IT applications, such requirements, if they even exist, are likely bogus because users are rarely able to express clearly what they want, often because they have no clue what is possible.  Until they use a working system (or a prototype), they typically can’t begin to provide much useful information on what the system should do.  Incremental design with rapid prototyping and a heavy emphasis on usability testing is the typical application development methodology for IT applications, which is very different from the software design methodologies promoted in most CS and SE programs.


The goal of the Human Stuff courses, then, is threefold.  First, the IT professional must work effectively with a user community, study the users, identify the tasks that they perform, learn their technical competencies, and basically see the world through their eyes.  Second, the IT professional must be able to identify technologies that could help his or her users be more productive or effective in performing their tasks, whether the specific technology is networking infrastructure, Web sites, databases, or (usually) a combination.  Third, the IT professional must deploy that technology effectively so that the result actually does enhance the users’ lives in the context of their corporate and/or societal culture.  If these goals are met, then the student is a true users’ advocate, which is probably the best concise definition of a competent IT professional.




The synergy of the three fundamental technical areas of IT, which is enabled by the fourth fundamental area, the Human Stuff, essentially defines IT.  If any of these areas is absent from a curriculum, then, I argue that it is not an IT curriculum.  In other words, while the whole is clearly greater than the sum of its parts, all of the parts have to be there, or there can be no whole.  Two of the technical areas referred to in this paper—programming and application development, and networking and system administration—seem to be on everyone’s plate at the IT table.  Most players also acknowledge the centrality of Web content development and Web mastering.  It is the Human Stuff that is most often underrepresented, if not completely lacking, and this is a problem, in my view, because, as I’ve hopefully conveyed, the Human Stuff is the glue that binds the technology together and makes it work for the user.  Since the user is the only reason to have technology, information technologists simply must connect with users.  If an IT curriculum is worth the name, it needs to address how students learn to make that connection effectively.  In short, for a curriculum to be considered an IT curriculum, it must produce graduates who are competent in all four of the fundamental areas of IT I’ve outlined.  This is especially true of model curricula for accreditation.


Accreditation is a hot-button item in any emerging discipline.  IT accreditation seems to be emerging extremely rapidly, given that the first IT program is only 10 ten years old and there are still so few IT programs in existence, but the relentless increase in the acceleration of change, not just in the computing field but throughout society in general, probably makes IT accreditation inevitable in the near future.  Time compression of the process aside, it is critical that any accreditation guidelines be carefully considered and that this emerging discipline be defined as its own discipline and not as an amalgamation that combines bits and pieces from traditional fields.  IT is a new field that addresses huge societal needs that are not met by traditional academic programs.  Therefore, IT programs should be stand-alone programs with an IT focus and an IT faculty, not just joint programs that borrow courses and faculty from traditional departments.  This is not to say that traditional departments and disciplines don’t have a roll to play in delivering an IT curriculum; clearly they can.  However, the focus of those courses must be an IT focus and the primary interest of a critical mass of faculty must be IT.  If an IT faculty group is not empowered to develop a curriculum that is independent from traditional programs like computer science, engineering technology or business, it will be difficult, if not impossible, for them to put together a true IT curriculum.  Finally, since accreditation seems to be moving so fast, we must be careful to establish a unified, coherent set of IT curricular guidelines that focus on the outcome of an IT program, namely the professionals that it produces and their roles in society.  A patchwork compromise of partial guidelines from disparate traditional programs will not realize that vision.


At the risk of stepping on toes, if not being downright incendiary, I’ve tried in this paper to take a strong personal position on IT curricula in the hope that lively discussion and reasoned deliberation can proceed.  We are at a pivotal point in the establishment of a new academic discipline that is critically important to our society.  It behooves us to look beyond our backgrounds and create a coherent and dynamic discipline for the future.  See you in the bar…




1.  Biles, Al, Information Technology Undergraduate Advising Handbook, Rochester, NY, RIT, available from, 2002.

2.  Holden, Ed, Perry, Ron, and Yacci, Mike, Technology Transfer: Before and After, in Proceedings of the 2002 Conference for Information Technology Curriculum, Rochester, New York, Society for Information Technology Education, 2002.

3.  Smith, Tiesa Nika, Globalization of the Usability Engineering Lifecycle: an Overview, in Proceedings of the 2002 Conference for Information Technology Curriculum, Rochester, New York, Society for Information Technology Education, 2002.



John A. Biles

Al Biles came to RIT in 1980 as a brand new Computer Science instructor, fresh from gradual school at the University of Kansas.  He officially joined the IT faculty in 1993, following his time in the barrel as Computer Science department chair from 1990-93.  He assumed the duties of IT Undergraduate Program Coordinator in the spring of 1996 and has spent the last six plus years trying to catch up.  He still teaches computer music and HCI courses when he gets a chance, tries to ride herd on around 1200 IT majors, and stays sane by playing trumpet with his computer, as heard at the conference reception on Thursday and as documented in another paper at this conference.  You can phone him at (585)475-4149, email him at, and visit his Web site at