Information Technology in Education Lessons from Computing in

Information Technology in Education Lessons from Computing in a Large Research University Steven R. Lerman Class of ’ 22 Professor and Director, MIT Center for Educational Computing Initiatives MIT

I gave the wrong address for the lecture notes. The correct URL is http: //web. mit. edu/~lerman/www/Madrid 2007 You should be able to download files from there. Some of these files are large, so do this from a reasonably fast Internet connection.

Case 3: Formulating Strategy for Academic Computing Background/History Council on Educational Technology Major Outcomes Lessons

Strategy Formation Process The Council on Educational Technology was appointed in the fall of 1999 to guide MIT’s strategy in using technology to enhance the quality of education.

However… The Council did not try to define MIT’s approach to educational technology for all time The Council does not have operational responsibility for MIT activities The Council did not limit initiatives by departments, schools, or centers

Caricature Models for MIT Venture-tech Flex-tech Tech-tech $ $

Forever-tech Global-tech Ed-tech

Foundation of Strategy Decisions MIT’s choices in the use of educational technology must fit the Institute’s mission and the core beliefs expressed by faculty, students, alumni, and staff. These core values and beliefs fall into three categories: • Inseparability of education and research • Uniqueness of MIT community • MIT Values -

Five Initiatives Arising from Process Technology Enabled Active Learning Open. Course. Ware DSpace i. Labs The Singapore-MIT Alliance

Lessons from aspects of MIT process Task Force approach with all constituencies included Extensive use of outside consultants to support and push process Examined core values and competencies Focus on “big picture” strategy Left tactics for operating organizations Use of interviews to gather data about opinions Major consultation effort for key actions

Case 4 – The i. Lab Project. Lab Experiments over the Internet Problem Statement Some Examples Technology Approach Dissemination

Statement of the Problem There is enormous educational value in hands-on laboratory experiences, but… … conventional laboratories are expensive and have complex logistics: Scheduling, equipment cost, lab space, lab staffing, training, safety … conventional labs don’t scale well and can’t easily be shared All institutions must own all labs

The i. Lab Vision • Many labs shared worldwide • Some are unique (unreachable locations, rare materials) • Many simple labs Campus network Client Internet Service Broker University Databases Lab Server

The i. Lab Vision • GUI to lab • Integrates useful generic tools (graphing, numerical analysis, simulators) • Allows for remote collaboration and tutoring Campus network Client Internet Service Broker University Databases Lab Server

The i. Lab Vision Service Broker Campus network Internet Client University Databases • Serves GUI to Client • Mediates between Client and Lab Server • Performs generic functions: user management, data storage • Single account access to many labs Lab Server • Managed by end user University

The i. Lab Vision Service Broker Campus network Internet Client University Databases • Service Broker acquires user data from University Databases • User authentication through University IT infrastructure Lab Server

The i. Lab Vision • Order of magnitude more lab experiences • More lab time to users • More sophisticated labs available • Communities of scholars created around i. Labs sharing educational content Campus network Client Internet Service Broker University Databases Lab Server

i. Labs at MIT Place holder for picture from Kent Dynamic signal analyzer (EECS, to be deployed 2004) Shake table (Civil Eng. , to be deployed 2004) Polymer crystallization (Chem. E. , deployed 2003) Microelectronics device characterization (EECS, deployed 1998) Heat exchanger (Chem. E. , deployed 2001)

Educational Experiments MIT graduate and undergraduate courses since Fall 1998 NUS (Singapore), Fall 2000 -03 (20 -30 st/yr) Chalmers U. (Sweden), Spring 2003 -04 (350 st/yr) NTU Athens (Greece), Spring 2004 (35 st/yr) CCU Taipei (Taiwan), Fall 2004 (200 st/yr) Makerere U. (Uganda), Fall 2004 (150 st/yr) U. Parma (Italy), Spring 2005 (30 st/yr) Over 3000 student users (for credit) since 1998

Lab Use over 3600 student users (for credit) since 1998

Uniqueness of i. Labs Pedagogy i. Labs introduce laboratory experiences in subjects that didn’t have them before. i. Labs enable laboratory experiments at most opportune moment in curriculum. i. Labs allow students to perform experiments in pleasant environments at times of their choice i. Labs minimize frustrations with hardware i. Labs allow students to work in a “stop-and-go” mode

Demonstration: The MIT Microelectronics lab The web site: http: //openilabs. mit. edu Provides open access to some of the labs.

Uniqueness of i. Labs Logistics i. Labs can be located in places inaccessible to students i. Labs hold unique scaling characteristics: round the clock usage from anywhere in the world Economics i. Labs can be broadly shared → fundamental change in economics of the lab experience

i. Lab Design Goals Scaling usage of online labs to a large number of users Allowing universities to share access to equipment Single sign on to labs at multiple universities Freeing lab owner/operator from administration (i. e. authentication, authorization, storage of results, archiving of data, etc. ) of users from other universities Allowing universities with diverse network infrastructures to interoperate and share resources

Project Boundaries Our architecture doesn’t deal with specific hardware and software interfaces to lab equipment Our architecture is intended to be compatible and complementary with commercial software such as National Instruments Lab. View and analysis packages like Matlab

The Case for Web Services Web services represent a new version of an old concept -- they allow one computer to invoke a procedure (method) on another. They are platform and vendor independent (we routinely use a Java client a Windows XP/. NET Service Broker a Windows 2000/2003 lab server. Because they are usually based on http that we all use to access the web, they work well with campus networks. They allow a computer to define how it will share its resources in a well-defined (WSDL) interface. The i. Lab Shared Architecture builds on top of the current generation of web services.

i. Lab Experiment Typology, 1 Waves of Development Batched Experiments (2003 -2005): The entire specification of the experiment is determined before execution begins. The user need not remain online while experiment executes. Interactive Experiments (2004 -2007): The student client portrays virtual lab equipment (GUI). The student can interact with experiment throughout its course.

i. Lab Experiment Typology, 2 Waves of Development Sensor Experiments (? 2007 -? ): Publish and subscribe based architecture Triggers and event-driven data monitoring Flexible data analysis Data archive

Lab Provider’s Goals: To share a lab with colleagues’ students through the Internet. What a Lab Provider Does Not Want To Do: Register 100’s of student accounts for other people’s students. Store experiment results for students from other institutions and decide when they can be deleted or how to archive them. Decide who can view whose experiment results, especially when it involves setting policy for another university’s courses.

Batched Experiment Topology Service Broker Lab Clientside Campus Lab Server Labside Campus Service Broker 2 Campus 2 Lab Server 2

Lab Provider Responsibilities The Lab Server team must connect the lab server to the Service Broker by implementing the Service Broker to Lab Server Web Service API; will usually supply the student lab client software, which must implement the Client to Service Broker Web Service API; Client only communicates with the lab server via the Service Broker using these APIs

What a Lab Provider Does Not Want To Do Register 100’s of student accounts for other people’s students. Store experiment results for students from other institutions and decide when they can be deleted or how to archive them. Decide who can view whose experiment results, especially when it involves setting policy for another university’s courses.

Service Broker Responsibilities The Service Broker is both a web application and a web service that stores and manages student experiment records; provides mechanism for but does not specify local campus course and privacy policy; authenticates users and transmits credentials but not user IDs to Lab Server; manages workflow between client and lab server

Student Web Session 1. User authenticates over SSL 2. SB lists user’s groups 3. User chooses effective group for session. Web Browser Service Broker 4. SB lists available Lab Clients 5. User chooses Lab Client for session. 6. SB launches client.

Student Service Broker Session Life Cycle The student contacts the Service Broker (SB) via a standard web browser. The student either registers for a new account, or authenticates himself to the Service Broker (current implementation offers ID/password over SSL) The SB lists the student’s group (class) memberships, and asks the student to choose an effective group for this session. The SB lists the lab servers/clients available to that effective group, and asks the student to choose a client The SB launches the lab client (often an applet) for the student.

Service Broker: Launching the Client

Batched Experiment Submission Web Service Calls Lab Client 1 Submit(experiment. Specification) and save a copy on the SB Lab Server 2 Submit(experiment. Specification) 3 4 returns Client. Submission. Report contains experiment. ID Service Broker returns Submission. Report and saves a copy on the SB

Batched Experiment Status Checking Web Service Calls Lab Client 1 Get. Experiment. Status( experiment. ID) 4 returns Experiment. Status Service Broker 2 Lab Server Get. Experiment. Status( experiment. ID) returns Lab. Experiment. Status 3

Service Broker Administrative Services Adding, modifying, and removing lab servers and clients. Adding, removing, or confirming user access. User management including assigning users to groups and modifying access rights. Managing experiment records.

i. Lab Generic Services User authentication (and registration) User authorization and credential (group) management Experiment specification and result storage Lab access scheduling

Our Long Term Vision Creating a movement within higher education (and potentially other levels) leading to global sharing of laboratory experiments over the net Creating an informal “barter economy” to facilitate sharing of lab equipment Sharing beyond access to lab equipment to include pedagogical materials and teaching experiences “i. Lab-ready” experimental equipment and software Sharing of time on national and international experimental equipment such as space-based experiments Improving education through expansion of lab-based learning opportunities around the world

Making i. Lab software available i. Lab software and documentation will be made publicly available “for comment” postings followed by formal releases Release under an open source license Welcome comments and advice from anyone interested

What Have We Learned? [1] the student’s view Students are intrigued and motivated by i. Labs Better student participation and higher scores than regular homework Students dread real laboratories and appreciate i. Labs’ convenience Tend to work late at night (unpleasant to be in real laboratory) Simplified interface minimizes frustrations with hardware Students have trouble handling “real-world data” Can’t distinguish good data from bad data Have difficulty manipulating data (graphing, extracting parameters) Have difficulty comparing measured data with theoretical models System problems detract from educational effectiveness

What Have We Learned? [2] Ad-hoc i. Lab development and management does not scale i. Lab developers are not IT specialists and want to minimize development work (want to reuse generic lab components) i. Lab managers do not want to deal with individual user management i. Lab consumers want to see single portal to multiple labs Ø Need an i. Lab Shared Architecture

Lessons from i. Lab Project Breaking complex IT problem into collection of webbased services can be effective Separation of responsibilities/roles is effective approach to organizing IT system Design from real-world cases rather than hypotheses about functionality users want Incremental approach to extending functionality over time can be useful

For More Information del Alamo, J. A. , L. Brooks, C. Mc. Lean, J. Hardison, G. Mishuris, V. Chang, and L. Hui, “The MIT Microelectronics Web. Lab: a Web-Enabled Remote Laboratory for Microelectronics Hardison, J. L. , D. Zych, J. A. del Alamo, V. J. Harward, S. R. Lerman, S. M. Wang, K. Yehia and C. Varadharajan. “The Microelectronics Web. Lab 6. 0 – An Implementation Using Web Services and the i. Lab Shared Architecture. ” International Conference on Engineering Education and Research 2005, Tainan, Taiwan, March 1 -5, 2005.

Case 5: Providing IT Services at MIT Complexity of IT providers Central IT organization Distributed IT organizations Lessons in managing IT in complex organizations

IS&T Services Client Support Academic Computing Administrative Computing Operations and Infrastructure

IS&T Organization June 2006 Susan Hockfield President Rafael Reif Provost Terry Stone Executive Vice President Jerry Grochow VP for Information Services & Technology Vijay Kumar Director Academic Computing Wayne Turner Director Administrative Computing Greg Anderson Director Client Support Services ALL ACADEMIC UNITS DEPARTMENTS, LABS and CENTERS at MIT Theresa Regan Director Operations & Infrastructure Svcs Allison Dolan Director Telephony and IS&T Shared Services

Central IT Expenditures

VP for IS&T Advisory Interactions Academic Council on Educational Technology (CET) Administrative Advisory Committee (AAC-II) Jerry Grochow VP for Information Services & Technology Administrative Services Policy Coordinating Committee (ASPCC) Information Technology Coordinating Committee (ITCC) IT Leads IT Partners

Projects/Studies • Providing network bandwidth as appropriate for research and teaching activities • Providing cost effective operations and support in a very heterogeneous hardware and software environment • “From innovation to service” -- moving innovative software and services into production • Central vs. distributed support -- creating the “seamless” user experience” • Redundancy in key servers and services • New student information system • Many-to-many computing – providing services where students have many choices for personal-use computing: Athena, laptops, desktops, classroom computers. • Shift to Voice over IP telephony

Case 3: Providing IT Services at MIT Complexity of IT providers Central IT organization Distributed IT organizations Lessons in managing IT in complex organizations

IS&T Services Client Support Academic Computing Administrative Computing Operations and Infrastructure

IS&T Organization June 2006 Susan Hockfield President Rafael Reif Provost Terry Stone Executive Vice President Jerry Grochow VP for Information Services & Technology Vijay Kumar Director Academic Computing Wayne Turner Director Administrative Computing Greg Anderson Director Client Support Services ALL ACADEMIC UNITS DEPARTMENTS, LABS and CENTERS at MIT Theresa Regan Director Operations & Infrastructure Svcs Allison Dolan Director Telephony and IS&T Shared Services

Central IT Expenditures

VP for IS&T Advisory Interactions Academic Council on Educational Technology (CET) Administrative Advisory Committee (AAC-II) Jerry Grochow VP for Information Services & Technology Administrative Services Policy Coordinating Committee (ASPCC) Information Technology Coordinating Committee (ITCC) IT Leads IT Partners

Projects/Studies • Providing network bandwidth as appropriate for research and teaching activities • Providing cost effective operations and support in a very heterogeneous hardware and software environment • “From innovation to service” -- moving innovative software and services into production • Central vs. distributed support -- creating the “seamless” user experience” • Redundancy in key servers and services • New student information system • Many-to-many computing – providing services where students have many choices for personal-use computing: Athena, laptops, desktops, classroom computers. • Shift to Voice over IP telephony

IS/IT Groups in DLCs • Media Lab • Economics • Bio. Micro Center • CSAIL • Micro. Technology Lab • Open Course. Ware • Office of Sponsored Programs • Lab for Nuclear Science • Sloan • CAO - LFO • Research Lab of Elec. • EECS • Plasma Fusion Center • Libraries • Mathematics • Chemical Eng. • Controller’s Accounting Office • Alumni Association • Medical • Urban Studies & Planning • Chemistry • Academic Media Production Services • Plasma Science & Fusion Center • Treasurer's Office • Human Resources • Center Space Research • Student Services • Resource Development • Facilities • Broad Institute • Technology Licensing Office

Academic Computing Organizations Provost Rafael Reif Chancellor Phillip Clay Dean for Undergraduate Ed. Daniel Hastings Academic Computing In DLCs Director of Libraries Ann Wolpert MIT Open Courseware Anne Margulies, Executive Director Vijay Kumar Senior Associate Dean Office of Educational Innovation & Tech, Academic Media Productions (AMPS) Babi Mitra, Executive Director EVP Terry Stone Jerry Grochow VP for Information Services & Technology

Useful Lessons from MIT Experiences Diverse goals of university have led to distributed responsibilities and costs Outsourcing vs. internal provision Difficulty in knowing full costs of IT provision Intergroup communication is crucial in diversified computing provision MIT’s IT structure does some things well, and some things poorly