Middleware Planning and Deployment 102: Mapping Out Your Strategy

1. Middleware Planning and Deployment 102:Mapping Out Your Strategy Internet2 Spring Meeting 6 May 2002

2. Panelists • Tom Barton, University of Memphis/Internet2 • Renee Woodten Frost University of Michigan/Internet2 • Jack Suess,University of Maryland, Baltimore County • Ann West, EDUCAUSE/Internet2/Michigan Tech Middleware Planning and Deployment 102 2

3. Agenda • Introductions and Overview • Two factors for success: Environment and Leadership • Case Study: U of Maryland, Baltimore County • Discussion • Break • Third factor for success: Implementation • Case Study: U of Memphis • Discussion • Research, Resources, and Wrap up Middleware Planning and Deployment 102 3

4. A Bit About Middleware Middleware makes “transparent use” happen, providing consistency, security, privacy and capability • Identity - unique markers of who you (person, machine, service, group) are • Authentication - how you prove or establish that you are that identity • Authorization - what an identity is permitted to do • Directories - where an identity’s basic characteristics are kept Middleware Planning and Deployment 102 4

5. Map of Middleware Land Middleware Planning and Deployment 102 5

6. Topics Not Covered • Business Case • Long-term Value • Technology details Middleware Planning and Deployment 102 6

7. Themes • Middleware is not just a technology project • Implementation challenges are a reflection of the • Institutional culture and needs • Installed technology, requirements, and available resources • Leadership Middleware Planning and Deployment 102 7

8. Contributors to Success Middleware Planning and Deployment 102 8

9. Institutional Environment Middleware Planning and Deployment 102 9

10. Institutional Environment • Public vs. Private Institutions • Institutional Vision vs. Local Control • Change Readiness • Strategic vs. Tactical Planning • Role of IT • Policy & Legal Constraints • Resource Determination/Allocation Middleware Planning and Deployment 102 10

11. Institutional Environment: Public vs. Private Institutions Public and private institutions will be subjected to different governance pressures that may impact how Middleware might be developed and deployed. • Legal • Financial • Organizational Politics • Governance Structure Middleware Planning and Deployment 102 11

12. Institutional Environment:Vision vs. Local Control • Effective middleware development will require participation from all quarters • Is there a strategic vision for the institution or is business done an a day-to-day, year-to-year basis? • Are business practices and applications well-coordinated? • How “hardened” are your silos? • Development in a culture of cooperation and information sharing is less effort Middleware Planning and Deployment 102 12

13. Institutional Environment:Change Readiness • Changes the way we do business • Shifts control of services and/or applications • Relies on unfamiliar technologies • Requires additional communication • Change is tough • Free agents can be used to innovate • Command-and-control required to ensure stability • Need both. Think about incentives. Middleware Planning and Deployment 102 13

14. Institutional Environment:Strategic vs. Tactical Planning Middleware development and deployment will require both approaches. • Strategic planning to define the implementation “road map,” ensure long-term success and ongoing alignment with the institutional mission • Tactical planning and project management to ensure implementation stays on time and on budget Middleware Planning and Deployment 102 14

15. Institutional Environment:Role of IT • Perceived Value of Central IT • Is Central IT seen as adding value, or as a barrier to progress? • Will it accepted in a coordinating role or will a surrogate be required? • Strategic Resource vs. Tactical Tool • Are strategic decisions made with IT in mind, or is IT a bolt-on after the fact? • Are funding decisions made with IT input? Middleware Planning and Deployment 102 15

16. Institutional Environment:Policy & Legal Constraints • Ownership of Data • Is data stewardship well-defined? • Is it centralized or distributed? • Access to Data • Formally or loosely governed? • Access authority centralized or distributed? • Data Administration • Centrally managed or distributed? • HIPPA and FERPA compliant? Middleware Planning and Deployment 102 16

17. Institutional Environment:Resource Determination/Allocation • Financial Resources • Centrally managed or distributed? • Multi-year or annual budgets? • Human Resources • Centrally managed or distributed? Middleware Planning and Deployment 102 17

18. Leadership Middleware Planning and Deployment 102 18

19. Leadership Requirements Developing an Enterprise Directory is akin to implementing an ERP project. • Executive leadership • Developing campus support • Change management • Managing expectations Middleware Planning and Deployment 102 19

20. Leadership:Executive Role • Unlike ERP, a CIO can’t 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) Middleware Planning and Deployment 102 20

21. Leadership:Developing 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 all opportunities to discuss the project with faculty, staff, and executives • Don’t forget to build consensus in your internal IT organization Middleware Planning and Deployment 102 21

22. Leadership:Change Management • Like ERP, middleware cuts across divisions and requires broad support • Create a sense of urgency to the project, why is it important? • It isn’t possible to over-communicate • Identify ways to involve stakeholders in the decision making process • Make certain you develop some quick wins Middleware Planning and Deployment 102 22

23. Leadership:Managing 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 • Middleware’s benefit is often found in productivity gains or through self-service. Identify ways to measure this ahead of time. Middleware Planning and Deployment 102 23

24. Leadership:Final Comments • IT is responsible for campus technology 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 and successes • Success enables more success. Make sure you can accommodate later requests quickly. Middleware Planning and Deployment 102 24

25. Case Study #1:Enterprise Directory Project Planning at University of Maryland, Baltimore County Jack Suess, CIOjack@umbc.eduhttp://umbc.edu/~jack/sac2002

26. What I Will Discuss • The business factors driving this initiative • The directory development team and process • Development and deployment of new applications using the directory service • Creation of a single sign on web authenticator • Future directory plans at UMBC • Applying the lessons learned - how to jumpstart a directory project • Questions Middleware Planning and Deployment 102 26

27. Business Factors UMBC Needed to Address - Fall 1999 • Finishing up 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. Middleware Planning and Deployment 102 27

28. Business Factors - ContinuedFall 1999 • We had successfully deployed our web portal, myUMBC and were getting requests to extend it to alumni, parents, and prospective students. • Fall 1999, we saw WebCT usage plateau, discussions with faculty pointed at need to make it “easier” to use course tools. • Eliminate faculty handling of student account problems • Make it easier to “enroll” students • Eliminate the need to know HTML Middleware Planning and Deployment 102 28

29. Business Requirements • Applications needed 7x24 access • The indecision over our SIS/HR plans made using those systems directly a mistake. • We needed to reduce transactions on our overloaded administrative systems. • We had reorganized support services and made our Helpdesk the focal point. We needed to empower them with ability to manage basic account functions. • To support alumni we needed to expand authentication services beyond solely using Kerberos Middleware Planning and Deployment 102 29

30. Why Deploy an Enterprise Directory • Hype- Directories were hot technologies in 1999, though not necessarily mature. • UMBC has a large Unix infrastructure and significant Unix development experience • We didn’t want the complexity or cost associated with using a DBMS • We wanted to solve this in a way that would allow us to collaborate with other schools. Middleware Planning and Deployment 102 30

31. Getting StartedJanuary 2000 • I2 was beginning to focus on the problem of middleware, I saw this as an opportunity for UMBC to be engaged in I2. • I2 was soliciting schools to participate in an Early Adopters program and UMBC applied. • I was the initial project sponsor for middleware at UMBC. • January 2000 we created our middleware project team Middleware Planning and Deployment 102 31

32. Directory Project Team • A technical lead was identified and the project team created. • Members represented all areas of IT • I needed to get the team understanding what was meant by directory services • Sharp differences on team over what directory platform to use • I2 middleware group was very helpful in framing issues for consideration Middleware Planning and Deployment 102 32

33. Directory Development - Engaging Non-IT Staff • I met privately with our Vice Provost for Academic Affairs and CFO to discuss the project and get their support • I worked through our IT Steering committee and discussed the project in terms of the business factors, not technology. • In hindsight we should of done a better job broadly communicating this to the campus. Middleware Planning and Deployment 102 33

34. Selecting a Directory Product • This became contentious - we looked at NDS, AD, Innosoft, iPlanet and Oracle • Our process looked at initial cost, cost per entry, API, scalability, and availability. • We had concerns about directory products tied too closely to network LAN products. • iPlanet had the best product but cost was a concern. Opportunity struck - we purchased Innosoft - iPlanet then bought company and transitioned customers over to iPlanet :-) Middleware Planning and Deployment 102 34

35. Defining Data Access Strategy • We initially focused on data needed for whitepages and account management. • We negotiated read access to SIS and HR. • Updates to demographic data would be done through our portal, myUMBC. • Where duplicate data exists in HR/SIS we used most recent entry as “current” • Broad IT support was critical here, we needed input from our analysts and DBA’s to fully understand what data was needed and get database triggers defined. Middleware Planning and Deployment 102 35

36. Defining Data Update Strategy • Goal for account generation was that a PT student could register that day and get an account within 30 minutes. • We discussed merits of real-time, near real-time, and batch updates of directory. • Realtime - triggers between DBMS tables • Near realtime - triggers generate a changelog queue • Batch - extract and update periodically • Selected near realtime to meet our goal for account generation but lessen dependencies. Middleware Planning and Deployment 102 36

37. Directory Development TeamMarch 2000 • 1 full-time directory architect • 1 directory programmer (.75) • PT access to an Oracle DBA (<.25) • PT access to SIS and HR analysts (<.25) • Allocated $75,000 in startup funding Middleware Planning and Deployment 102 37

38. Development and Deployment- Phase 1 • Phase 1 – Generate new web-based account management system, go live August 2000 • Decided to load all students in SIS who have ever applied to UMBC to date, ~275000. This was a mistake, we should of limited it to active members only. • Challenge was how to provide different levels of access to the directory without complex ACL’s and grant this access to other web services. • We created a service we call webauth, which is similar to Shibboleth’s pubcookie. Middleware Planning and Deployment 102 38

39. Development of Webauth • Goal was to provide a web-based single sign on (WebISO) that can authenticate across any web-based application. • In summer 2000, nothing had been released that did this. We modeled our approach on Kerberos and each web service has a unique service ticket • Created apache module • Created Java and Perl interfaces • Available upon request but I would strongly suggest you consider I2’s Pubcookie. Middleware Planning and Deployment 102 39

40. UMBC Directory Applications • Webadmin –web-based tool to enable delegated authority of dir updates • Course management system – accounts and course auto-enroll • Windows 2000 migration - supporting Active Directory • Remedy ticketing system – feed client info • Webauth extended to third parties • VPN access Middleware Planning and Deployment 102 40

41. UMBC Directory Applications - Webadmin • Created Webadmin, a web-based tool for accessing the directory, released 8/2000 • Allows delegation of control over different functions to groups or people based on roles and needs. Helpdesk group can now reset passwords and quotas. • Self-service - students can now select username and password, create email aliases, and forward mail without coming onto campus • Mistake - the user interface could have been better Middleware Planning and Deployment 102 41

42. Delegating AuthorityFall 2000 Goal - Let Helpdesk immediately handle basic account tasks on behalf of users without root access • Store user preferences in LDAP as attributes, wrote LDAP interface to Unix systems • Users must use Webadmin to update account • Helpdesk can reset passwords, quota, set forwarding address, and Unix preferences. • Fall 2000, delegation horror story. Helpdesk student stole class project from another student Middleware Planning and Deployment 102 42

43. Integrating Course Management Tools with the Directory • One of our initial goals was to simplify the faculty effort when utilizing course management tools. • Eliminate account management problems • Simplify enrollment of students into a course • Purchased Blackboard Level 3 license, paid them to accept our Webauth credentials solving account management issue, 1/2001 • We developed code for WebCT 3.1 to accept our webauth credentials but decided to drop WebCT Middleware Planning and Deployment 102 43

44. Supporting Windows 2000 Spring 2001 • Goal - Migrate our public labs from Windows NT to Windows 2000. All our labs provided common file access (AFS) and used our Kerberos authentication. • Problem - Windows 2000 requires AD, how do we get our account information now stored in iPlanet into AD? • Spring 2001, tested AD against existing Kerberos environment and got this working Middleware Planning and Deployment 102 44

45. iPlanet to AD IntegrationSummer 2001 • Summer 2001 began work on linking iPlanet directory to Microsoft AD • Reverse engineered Microsoft AD account entries to identify what is needed for an account entry by looking at before/after. • Wrote LDAP connector in Perl to update AD when iPlanet entries are created or change. • Windows 2000 fully deployed in all labs January 2002 • Metamerge now provides a connector for this Middleware Planning and Deployment 102 45

46. Remedy IntegrationSummer 2001 • Goal - Keep client information (phone, office, email) up to date in Remedy • Developed a connector between LDAP and Remedy (Oracle DBMS) that updates Remedy whenever certain data elements are updated in LDAP. Middleware Planning and Deployment 102 46

47. Extending Webauth to 3rd PartiesSpring 2002 • Spring 2002 - provided linkage to one-card vendor (DieBold/JSA) for eCommerce. We provide a link from our portal to our JSA. • We provided JSA with a webauth service ticket for their server and webauth client code to request validated campus-id when presenting a webauth cookie. • I’d love to do with with other 3rd Parties such as Sallie Mae Solutions Middleware Planning and Deployment 102 47

48. Blackboard Course Auto-EnrollSummer 2002 • Added course containers to LDAP that track enrollments to courses (add/drop) • Wrote a Java servlet for Blackboard that is updated by LDAP connector • For fall 2002 we will have students auto-registered into their Blackboard course. • We use course containers for other services like limiting lab access to students in particular courses, mailing lists, etc. Middleware Planning and Deployment 102 48

49. VPN Access • Fall 2002 Goal - Rollout VPN services in fall to secure wireless and provide remote access to administrative applications • Driven through LDAP group membership • Due to limitations in VPN users can only be in one group, we had to be creative in how we defined groups to meet needs of different users. • Most users automatically defined into a group but some people have to be managed manually Middleware Planning and Deployment 102 49

50. Short Term Plans AY 2002-2003 • The following are project proposals under consideration • Peoplesoft 8.0 integration with LDAP • Automated account deletion/deactivation • OS/X Netinfo and Novell 6 integration • Shibboleth • Alumni access Middleware Planning and Deployment 102 50