Middleware Deployment Issues

1
Middleware Deployment Issues

• Jack Suess, CIO, UMBCjack_at_umbc.eduhttp//umbc.ed
  u/jack

2
UMBC Institutional Profile

• University of Maryland, Baltimore County.
• Established 1966. Enrollment is 11,200.
• Carnegie designation of Research/Extensive
• Centralized administration and IT services with
  strong faculty governance structure
• Heavy IT emphasis, about 25 of students in IT
  related majors.
• Locally developed SIS/HR system. Recently signed
  on to implement Peoplesoft.

3
What we will discuss

• The business factors driving this initiative
• How we got involved in developing directory
  services
• The directory development team and process
• Development and deployment of new applications
  using the directory service
• Creation of a single sign on web authenticator
• Integrating WebCT and Blackboard course
  management tools
• Questions

4
Business Factors Driving the Development of
Directory Services

• Fall 1999.Finished with Y2K.
• UMBC decided we would begin discussions to
  replace our SIS, HR and Finance systems.
• UMBC started two online graduate programs and
  began planning for a third program. We needed to
  add more web-based self-service applications,
  especially account generation.
• We had successfully deployed our web portal,
  myUMBC and were thinking about how we may extend
  it to alumni, parents, and prospective students.
• Fall 1999, saw WebCT usage plateau, discussions
  with faculty pointed at need to make it easier
  to use course tools.

5
Directory Services_at_UMBC

• Internally we had decided that the indecision
  over our SIS/HR plans made using those databases
  directly a mistake. We felt LDAP-based directory
  services offered us more flexibility and we
  didnt have to worry about overload on
  transaction systems
• Dec. 1999, UMBC applied and was selected to
  participate in the I2 middleware initiative.
• UMBC created a middleware team to plan directory
  development.
• March 2000, purchased Innosoft directory server
  and began development

6
Directory Development Team and Process

• As then Director of OIT, I was the project
  sponsor and evangelist for middleware
• A technical lead was identified and the project
  team created.
• Members represented all areas of IT
• Need to educated team on directory services
• Sharp differences on what directory platform to
  use
• I2 middleware group was helpful in framing issues
  for consideration
• I worked with VPs and Vice Provosts to get
  support for project and access to data

7
Development and Deployment Phase 1

• Phase 1 September 2000
• Decided to load all students in SIS who have
  applied UMBC to date, 275000
• Decided early on that directory data would not be
  authoritative or updated directly by end-users.
  Updates to SIS/HR done through myUMBC and
  propogated back to directory through database
  change logs
• Where duplicate data exists in HR/SIS we used
  most recent entry as current
• Identified need for a common web-based
  authentication system, we created a service we
  call webauth.

8
Development of Webauth

• Modeled after Kerberos, cookies function as
  tickets and web services use redirects to get
  service tickets. Here is how it works.
• Client authenticates to webauth and gets a
  ticket-granting cookie (TGC), applications use
  this to get service cookies for applications.
• Applications connect to service, if they dont
  have a TGC the service redirects them to the
  webauth server with an encoded redirect that can
  get them back to the service after getting a
  service ticket
• Created apache module to replace basic auth
  service
• Created Java and Perl interfaces
• Available upon request but consider I2 shibboleth

9
UMBC Directory Applications

• Brought up directory-enabled account generation
  and management system
• Web-based, allows delegation of control over
  different functions to groups/people based on
  roles and needs. Helpdesk can now reset passwords
  and quotas.
• Self-service, students can now select username
  and password without coming onto campus
• Supports user email redirection and lookup
• IntegratedBlackboard and WebCT to use our
  username/password and autoenroll

10
Blackboard Integration

• Great product but..
• July 2000, UMBC purchased a level 3 contract from
  Blackboard. Paid them to read our webauth cookie
  and retrieve authenticated username. UMBC wrote
  Java classes for them to call. Brought this up
  January 2001.
• Extract users twice a day from directory and
  batch load into Blackboard. For fall 2001 we will
  automatically enroll students into their course
• Had problems authenticating students coming in
  through some ISPs. Tracked this to the way ISPs
  play tricks with caching servers, we had to
  revamp java classes.
• Had to figure out how to provide guest access.

11
Iplanet to AD Integration

• Summer 2001 began work on linking iPlanet
  directory to Microsoft AD
• Provide login access to labs running Windows 2000
• Reverse engineered Microsoft AD account entries
  to get this to work
• Windows 2000 fully deployed in all labs January
  2002

12
Blackboard Phase 2 Fall 2002

• Developed group containers for people that track
  course enrollments
• For fall 2002 we will have students
  auto-registered into their blackboard courses by
  connecting BB to LDAP for updating course
  enrollments
• We use course containers for other services like
  limiting lab access to students in particular
  classes

13
Peoplesoft Plans

• Bringing Finance 8.4, HR 8, EPM 8.3 in July 2003.
  SA development will then start with deployment
  done by 8/2005
• Recently begun testing of using LDAP for
  authentication and managing user profiles in 8.4
  with good results.

14
Results

• The directory service has been our most reliable
  service, at least 99.99 uptime.
• These self-service applications have revamped the
  way we support users and the services we provide.
• Automated Blackboard connections were well
  received by faculty.
• Using a directory allowed us to utilize our
  institutional data in an academic context. The
  staff that did this would never be able to
  directly access and update our legacy SIS tables.

15

• Leadership Style

16
Leadership StyleRole of CIO

• Developing an Enterprise Directory is akin to
  implementing an ERP project.
• The role of the CIO is similar
• Executive leadership
• Developing campus support
• Change management
• Managing expectations

17
Leadership StyleExecutive Leadership

• Unlike ERP, a CIO cant expect other executives
  to sponsor middleware.
• A CIO must make the case, meaning justifying the
  ROI, of middleware
• Identify the tangible benefits from middleware
  that matter to your campus
• Make certain you treat this as a major project
  with a well-defined system development life cycle
  (SDLC)

18
Leadership StyleDeveloping Campus Support

• Laying the groundwork
• Meet privately with key leaders and explain
  middleware and discuss what it means to their
  unit. Include faculty leaders in this
• Use the bully pulpit a CIO has to discuss the
  project with faculty, staff, and executives
• Dont forget to build consensus in your internal
  IT organization

19
Leadership StyleChange Management

• Like ERP, middleware cuts across divisions and
  requires broad support
• Create a sense of urgency to the project, why is
  it important?
• It isnt possible to over-communicate
• Identify ways to involve stakeholders in the
  decision making process
• Make certain you develop some quick wins

20
Leadership StyleManaging Expectations and Budget

• Like ERP, middleware development is an on-going
  process
• A well-written project plan with quick wins
  defined at appropriate intervals is key to
  managing expectations and budget
• Life-cycle budgeting needs to be identified
• Middlewares benefit is often found in
  productivity gains or through self-service.
  Identify ways to measure this ahead of time.

21
Leadership StyleIT Architecture

• I feel IT Architecture needs to become a
  cornerstone of strategic planning
• Your architecture should provide a framework for
  evaluating scenarios and options
• Middleware is a one of the key pieces of a
  successful IT architecture plan

22
Leadership StyleFinal Comments

• CIOs are responsible for IT architecture, of
  which, middleware is a fundamental component. No
  one else will do this for you.
• Every campus has leaders that must be brought on
  board for major projects, seek them out.
• Make certain you develop formal plans, identify
  quick wins, and communicate the benefits.