University of Michigan MCommunity ProjectLiz Salley (salley@umich.edu)Product Manager, Michigan Administrative Information ServicesLuke Tracy (ltracy@umich.edu)MCommunity Co-Technical Lead, Information Technology Central Serviceshttp://www.itcs.umich.edu/mcommunity/*

Project OverviewWhos in, whos out. MCommunity will allow the University to know who is and is not a member of the U-M community so that central University offices, departments, schools, colleges, and campuses can grant and remove access to online resources as needed and appropriate.Managed data for managed access. It will provide identity management, roles management, data sharing and reconciliation, and directory services for U-M. It will bring together data from multiple institutional sources and will organize, present, and secure the data in a way that is particularly well suited to managing access to University resources.A collaborative effort. Planning for, and development of, MCommunity is a collaborative effort across U-M IT units and across the many units that will use the new system.*

Project OverviewOne-stop directory shop. MCommunity will provide units and end users with a "one-stop directory shop" for provisioning of services, access control, and directory-enabled applications.Robust tools. It will provide a robust set of tools that include/enable:Identity and life-cycle managementReal-time provisioning of central IT resourcesReal-time provisioning of local IT resourcesClearly defined and documented programming interfacesAuditing systemIntegrated workflow*

Current Legacy EnvironmentFor limited purposes. Directory Services purposed for white pages and e-mail delivery.Weekly updates. Directory Services updated from Systems of Record weekly.Home-grown ID management. Home-grown identity management based on NetID/LoginID management.Data not purposed for provisioning. Institutional data sources not purposed for IT provisioning.Central provisioning home-grown. Home-grown provisioning system for central IT services.*

Problem StatementsMultiple data sources. Most units need to go to multiple data sources to obtain information they need; there is a lack of a common data management strategy.Slow updates. Currently, data feeds do not arrive quickly enough to fully automate access provisioning or de-provisioning campus-wide.Time-consuming to get access. Going through existing official channels to provision access for members of the extended University community, including guests, faculty with very short appointments, volunteers, etc., is very time-consuming and unrealistic.Manual processes. Many units still use manual processes to create identities or allocate resources.*

Problem StatementsInconsistent data, duplicated effort. Storing user information locally can create data inconsistencies and, in many cases, causes duplication of effort. Many departments keep their own copies of data that are less current or accurate than authoritative sources.Difficult to use. Existing authoritative data sources are difficult to use, and it is difficult to gain access to them.Local control wanted. Units demand local control of access to IT services.Consolidation needed. Institutional sources of identity data need to be consolidated into a central identity management system.Better life cycle management needed. Consistent and predictable life cycle management practices are needed.*

Data & Governance: BeginningsData policies in place. U-M has long-standing policies and a structure for institutional data stewardship and management. http://www.mais.umich.edu/access/policies.html Unique ID in place. Existing IdM systems are already using a single, institutional Net ID (U-M "uniqname") and non-social security number ID (UMID). One person = one uniqname = one UMIDSingle ERP system in place. Student Administration (SA) and HRMS systems of record have already been transitioned from many separate mainframe applications to a single, integrated PeopleSoft ERP system.*

Data & Governance: Convening a TeamEarly input from stakeholders. MCommunity Governance Board convened before project was funded. Membership includes:Institutional data managers for student, employee, and alumni dataIT directors and managers from representative schools, colleges, health system, and librariesIdM project leads from central IT units (Luke and Liz)Pre-implementation phase. Two-hour meetings, twice per month, for 8 months. Established high-level scope and vision; assisted enormously in building our business case and estimating the project timeline and costs.Implementation phase. Two-hour meetings, once or twice per month, for 16 months. Continued to guide high-level scope and vision, as well as make detailed implementation decisions.*

Data & Governance: Key OutcomesStrong vs. weak identitiesVocabulary: How do we talk to campus about what this means?Minimum data standardsIdentity lifecycleReal-life business cases*

Data and Governance: Key OutcomesAuthority and accountabilityHow do we enforce standards in a highly decentralized environment?System enforcement vs. guidelines and best practicesDecentralized authority and accountability to ensure guidelines and best practices are followedResources for IT directorsSee MCommunity Sponsoring Authority Policies and Agreement http://www.itcs.umich.edu/itcsdocs/r1460/ *

MCommunity Project Architecture *

MCommunity Project ArchitectureLive data feed from Human Resources and main campus Student System of Record.Nightly updates from remote campus Student Systems of Record.Nightly updates from Development/Alumni System of Record.New Sponsor System for creating and managing identities for sponsored affiliates, people who are affiliated with the University but who do not appear in any of the official University Systems of Record.Sponsored affiliates include, for example, conference attendees, contractors, incoming faculty who need access to U-M resources before the hiring process is complete, and others.Support for both strong and weak identities.All person data from above systems fed into a secure person registry.*

MCommunity Project ArchitectureInside the person registry. Real-time identity matching and reconciliation, institutional data precedence rules, data normalization, regulatory privacy policy, and identity lifecycle processing occurs in the person registry.Exception handling. Workflow system is utilized for exception handling.In real time. Distilled identities are populated and maintained in the directory in real-time.In the directory. Institutional Roles, User Groups, Departmental Roles, and departmental attributes exist in the directory.One stop for IT provisioning. Directory functions as the one-stop directory shop for IT provisioning.*

MCommunity Project ArchitectureReal-time bi-directional provisioning tools facilitate central and departmental IT provisioning.Full LDAP access provided through a replica of the directory to facilitate business-rule verification prior to committal to directory.All components of MCommunity are instrumented for central auditing and logging, enabling event correlation and incident response.

*

Reflections on Progress So FarImplications of our vendor solution:Up until now, we have mostly used open source and home-grown products to meet the extensive customization needs of the diverse U-M community.Customizing a vendor solution has brought with it staffing and cultural issues that we are addressing and learning from.Expectations of magicScope creepIntroduction of project management methodologyEnterprise vs. commodity serviceSystems programmers becoming enterprise developers*

Luke begin the presentation with this slide.*Luke will present this slide.*Luke will present this slide.*Luke will present this slide.*Luke will present this slide.*Luke will present this slide, then we can move to Steve for questions.*Liz will begin the data & governance part of the presentation with this slide.*Liz will present this slide.*Liz will present this slide.*Liz will present this slide. Then we can go to Steve for questions.*Luke will present this slide.*Luke will present this slide.*Luke will present this slide.*Luke will present this slide.*Luke will present this slide. This is the last slide, so after this we can go to Steve for more questions and discussion.*