Title of your presentation here

1
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
2
I gave the wrong address for the lecture notes.
The correct URL is

• http//web.mit.edu/lerman/www/Madrid2007
• You should be able to download files from there.
• Some of these files are large, so do this from a
  reasonably fast Internet connection.

3
Case 3 Formulating Strategy for Academic
Computing

• Background/History
• Council on Educational Technology
• Major Outcomes
• Lessons

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

• However
• The Council did not try to define MITs 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

6
Caricature Models for MIT
Venture-tech

Flex-tech
Tech-tech
7
Forever-tech
Global-tech
Ed-tech
8
MITs choices in the use of educational
technology must fit the Institutes mission and
the core beliefs expressed by faculty, students,
alumni, and staff. These core values and
beliefs fall into three categories
Foundation of Strategy Decisions

• Inseparability of education and research
• Uniqueness of MIT community
• MIT Values -

9
Five Initiatives Arising from Process

• Technology Enabled Active Learning
• OpenCourseWare
• DSpace
• iLabs
• The Singapore-MIT Alliance

10
Task Force approach with all constituencies
includedExtensive use of outside consultants to
support and push processExamined core values
and competenciesFocus on big picture
strategyLeft tactics for operating
organizationsUse of interviews to gather data
about opinionsMajor consultation effort for key
actions
Lessons from aspects of MIT process
11
Case 4 The iLab Project- Lab Experiments over
the Internet

• Problem Statement
• Some Examples
• Technology Approach
• Dissemination

12
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 dont scale well and cant
  easily be shared
• All institutions must own all labs

13
The iLab Vision

• Many labs shared worldwide
• Some are unique (unreachable locations, rare
  materials)
• Many simple labs

Campus network
Internet
Client
Service Broker
Lab Server
University Databases
14
The iLab Vision

• GUI to lab
• Integrates useful generic tools (graphing,
  numerical analysis, simulators)
• Allows for remote collaboration and tutoring

Campus network
Internet
Client
Service Broker
Lab Server
University Databases
15
The iLab Vision
Service Broker
Campus network
Internet
Client

• Serves GUI to Client
• Mediates between Client and Lab Server
• Performs generic functions user management,
  data storage
• Single account access to many labs
• Managed by end user University

University Databases
Lab Server
16
The iLab Vision
Service Broker
Campus network
Internet
Client

• Service Broker acquires user data from
  University Databases
• User authentication through University IT
  infrastructure

Lab Server
University Databases
17
The iLab Vision

• Order of magnitude more lab experiences
• More lab time to users
• More sophisticated labs available
• Communities of scholars created around iLabs
  sharing educational content

Campus network
Internet
Client
Service Broker
Lab Server
University Databases
18
iLabs 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)
19
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
20
Lab Use
over 3600 student users (for credit) since
1998
21
Uniqueness of iLabs

• Pedagogy
• iLabs introduce laboratory experiences in
  subjects that didnt have them before.
• iLabs enable laboratory experiments at most
  opportune moment in curriculum.
• iLabs allow students to perform experiments in
  pleasant environments at times of their choice
• iLabs minimize frustrations with hardware
• iLabs allow students to work in a stop-and-go
  mode

22
Demonstration The MIT Microelectronics lab

• The web site
• http//openilabs.mit.edu
• Provides open access to some of the labs.

23
Uniqueness of iLabs

• Logistics
• iLabs can be located in places inaccessible to
  students
• iLabs hold unique scaling characteristics
• round the clock usage
• from anywhere in the world
• Economics
• iLabs can be broadly shared ? fundamental change
  in economics of the lab experience

24
iLab 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

25
Project Boundaries

• Our architecture doesnt 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 LabView and analysis
  packages like Matlab

26
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 iLab Shared Architecture builds on top of the
  current generation of web services.

27
iLab Experiment Typology, 1Waves 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.

28
iLab Experiment Typology, 2Waves of Development

• Sensor Experiments (?2007-?)
• Publish and subscribe based architecture
• Triggers and event-driven data monitoring
• Flexible data analysis
• Data archive

29
Lab Providers Goals

• Lab Providers Goals
• To share a lab with colleagues students through
  the Internet.
• What a Lab Provider Does Not Want To Do
• Register 100s of student accounts for other
  peoples 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 universitys courses.

30
Batched Experiment Topology
Clientside Campus
Labside Campus
31
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

32
What a Lab Provider Does Not Want To Do

• Register 100s of student accounts for other
  peoples 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 universitys courses.

33
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

34
Student Web Session
35
Student Service Broker SessionLife 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 students 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.

36
Service BrokerLaunching the Client
37
Batched Experiment SubmissionWeb Service Calls
38
Batched Experiment Status CheckingWeb Service
Calls
39
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.

40
iLab Generic Services

• User authentication (and registration)
• User authorization and credential (group)
  management
• Experiment specification and result storage
• Lab access scheduling

41
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
• iLab-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

42
Making iLab software available

• iLab 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

43
What Have We Learned? 1 the students view

• Students are intrigued and motivated by iLabs
• Better student participation and higher scores
  than regular homework
• Students dread real laboratories and appreciate
  iLabs 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
• Cant 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

44
What Have We Learned? 2 Ad-hoc iLab
development and management does not scale

• iLab developers are not IT specialists and want
  to minimize development work (want to reuse
  generic lab components)
• iLab managers do not want to deal with individual
  user management
• iLab consumers want to see single portal to
  multiple labs
• Need an iLab Shared Architecture

45
Lessons from iLab Project

•  
• Breaking complex IT problem into collection of
  web-based 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

46
For More Information

• del Alamo, J. A., L. Brooks, C. McLean, J.
  Hardison, G. Mishuris, V. Chang, and L. Hui, The
  MIT Microelectronics WebLab 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 WebLab 6.0
  An Implementation Using Web Services and the
  iLab Shared Architecture. International
  Conference on Engineering Education and Research
  2005, Tainan, Taiwan, March 1-5, 2005.

47
Case 5 Providing IT Services at MIT

• Complexity of IT providers
• Central IT organization
• Distributed IT organizations
• Lessons in managing IT in complex organizations

48
IST Services
49
IST Organization June 2006
Susan Hockfield President
Rafael Reif Provost
Terry Stone Executive Vice President
ALL ACADEMIC UNITS DEPARTMENTS, LABS and CENTERS
at MIT
Jerry Grochow VP for Information Services
Technology
Allison Dolan Director Telephony and IST Shared
Services
Theresa Regan Director Operations
Infrastructure Svcs
Greg Anderson Director Client Support Services
Wayne Turner Director Administrative Computing
Vijay Kumar Director Academic Computing
50
Central IT Expenditures
51
VP for IST Advisory Interactions
Council on Educational Technology (CET)
Academic Council
Administrative Advisory Committee (AAC-II)
Information Technology Coordinating Committee
(ITCC)
Jerry Grochow VP for Information Services
Technology
Administrative Services Policy Coordinating Commit
tee (ASPCC)
IT Leads
IT Partners
52
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

53
Case 3 Providing IT Services at MIT

• Complexity of IT providers
• Central IT organization
• Distributed IT organizations
• Lessons in managing IT in complex organizations

54
IST Services
55
IST Organization June 2006
Susan Hockfield President
Rafael Reif Provost
Terry Stone Executive Vice President
ALL ACADEMIC UNITS DEPARTMENTS, LABS and CENTERS
at MIT
Jerry Grochow VP for Information Services
Technology
Allison Dolan Director Telephony and IST Shared
Services
Theresa Regan Director Operations
Infrastructure Svcs
Greg Anderson Director Client Support Services
Wayne Turner Director Administrative Computing
Vijay Kumar Director Academic Computing
56
Central IT Expenditures
57
VP for IST Advisory Interactions
Council on Educational Technology (CET)
Academic Council
Administrative Advisory Committee (AAC-II)
Information Technology Coordinating Committee
(ITCC)
Jerry Grochow VP for Information Services
Technology
Administrative Services Policy Coordinating Commit
tee (ASPCC)
IT Leads
IT Partners
58
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

59
IS/IT Groups in DLCs

• Media Lab
• Economics
• BioMicro Center
• CSAIL
• MicroTechnology Lab
• Open CourseWare
• Office of Sponsored Programs
• Lab for Nuclear Science
• Sloan
• CAO - LFO
• Research Lab of Elec.
• EECS
• Plasma Fusion Center
• Libraries
• Mathematics

• Chemical Eng.
• Controllers 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

60
Academic Computing Organizations
EVP Terry Stone
Provost Rafael Reif
Chancellor Phillip Clay
Jerry Grochow VP for Information Services
Technology
Dean for Undergraduate Ed. Daniel Hastings
Academic Computing In DLCs
Director of Libraries Ann Wolpert
Vijay Kumar Senior Associate Dean Office of
Educational Innovation Tech,
MIT Open Courseware Anne Margulies, Executive
Director
Academic Media Productions (AMPS) Babi Mitra,
Executive Director
61
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
• MITs IT structure does some things well, and
  some things poorly