# Integration High-Level Plan: Provisioning The table below contains a list of general items for consideration as you onboard into provisioning services using SailPoint IIQ. In preparation of your School or unit's initial meetings with the IAM team, we suggest you review the materials listed under the Discovery Phase section and think about assembling documentation in advance. If you have questions regarding this process, or would like to discuss in more detail, please contact . Sort *Deliverable(s)* *Description* *Responsible* *Feedback* **Discovery Phase** As-is system landscape diagram Diagram and description of the following as they pertain to the School's user identity management: • Major systems • Databases • Data feeds • Data flows • Connections/relationships to existing HUIT system landscape School IAM Target system inventory Inventory of target systems that use School identity data (or attributes from the identity management database) that includes details about: • The database schema and elements • Any metadata information that needs to be provisioned to targets • Systems that are dependent on the data in the target system • Manual or automated Processes these systems support or impact School IAM Source system inventory Inventory of applications or systems that push data to the School's identity management system, including details about: • The database schema • Other systems to which they push data • Manual or automated processes they support or impact School IAM Feeds inventory Inventory of data feeds to and from School systems as they relate to user identity management, including details about: • Frequency • Format • Contents • Data transformations that happen as part of the feed • Whether the feed is automated or manual School IAM Connections inventory Inventory of data connections to and from School systems as they relate to the management of user identities School IAM Business context diagram Representation of high-level view of the overall business/system boundary as it pertains to identity management. Describe and describe interactions with identity data of groups that: • Generate user identity data • Use identity data School IAM User account request process Description of the account request process for both sponsored and other accounts School IAM User account creation process Description of the account creation process, including how access to various resources is assigned School IAM Other School-specific onboarding/request processes Description of any other school-specific processes, such as • How groups are managed • VIP handling if different from the norm • How access is authorized • Population-specific onboarding/request process flows • Population-specific offboarding process flows School IAM Distribution list management process Details about how distribution lists are managed, where the data for them comes from, who maintains them, etc. School IAM Helpdesk/user support processes Details about issue triage process, including existing support tiers, SLAs, etc. School IAM Development environment Describes the development environments for each app; ideally, there are different environements for development, QA, staging, and production School IAM Testing and data validation processes Describes any QA processes, including unit tests and regression test suites for existing applications; availability of automated regression tests will mitigate a lot of the risk of breaking applications during integration activities School IAM Password rules and policies School password policies/rules and repositories; include a fit gap analysis with security.harvard.edu policy for each repository. School IAM Username policies Description of any user naming conventions, their significance, and whether they differ by population; also, how are duplicate username issues resolved? School IAM Email name (address) policies Description of any email address naming conventions, their significance and whether they differ by population; how duplicate username issues are resolved; who gets email School IAM Timing/schedules Details timing of different activities that tell the story about peak/key provisioning dates/times, maintenance windows, etc.; frequency of key events (daily, weekly, monthly, yearly) School IAM Stakeholder analysis Description of the stakeholders and communication channels, as well as key contacts for developing a communication plan. School IAM User population overview Summary of the user population currently interacting with the School's resources, including: • HUID holders (e.g. students, faculty and staff) • Non-HUID users • Business process owner for managing the various identified user populations School IAM User population characteristics and count Results of analysis of School's user population, described in terms of population name and description, as well as the key attributes that are needed for the user identity management: • Number of user accounts by role • Number of user accounts by HUID/non-HUID that are enabled/disabled • Number of non-person/resource accounts • Data schema for the various user populations, including user attributes with details about the characteristics and/or interpretation of each attribute School IAM Resource management matrix Provides details about how key resources are provisioned and managed School IAM Sponsored account requests Analysis of sponsored accounts, focused on people vs. non-people (service/resource) accounts, with details on the types of service accounts; includes source system (application) School IAM Self-registered accounts Analysis of user population focused on self-registered accounts; includes source system (application) School IAM Device management Analysis of user population focused on devices and how they are managed within the identity management context School IAM Historical use of the Central Harvard Sponsored Role processes Describes how Central Harvard Sponsored Role (previously known as POI) processes are used at the School, including gaps/issues as well as a matrix of who gets cards (if applicable) School IAM Overlapping population credential Analysis of duplicate identities or users with multiple credentials, including details about how duplicate accounts are handled School IAM Cross-relationship map Identifies any relationships between attributes coming from different sources in a matrix and captures the overall data model in one place School IAM **Analysis and Design Phase** HUIT/School gap analysis Analysis based on information discovered in previous phase that identifies gaps between HUIT and School's identity management systems IAM School Business functionality requirements Definition of business requirements based on: • Process flows • Process triggers • Data mapping relationships • Data transformations that need to happen • Data dependencies • Process dependencies • System of authority requirements IAM School To-be landscape diagram System landscape diagram, showing the to-be state of School systems integrated into HUIT's identity management landscape IAM School To-be system design High-level system design that communicates system state after SailPoint integration IAM School To-be data model Data model that captures the necessary changes required to accommodate school's data model: • Objects to be moved • Triggering events of interest • Attributes to be synchronized • Direction of synchronization • Authoritative sources for the data IAM School To-be support model Describes what support will look like during and after implementation IAM School Data validation strategies Describes in detail how data validation will occur IAM School Technical requirements Describes any technical requirements needed to meet prioritized business requirements: • Development/test environment • Any other infrastructure needs • Backup and disaster recovery • Security • Development requirements IAM School Implementation plan Plan for the iterative delivery of business value until prioritized business requirements are met: • Key dates and deliverables • Communication of status • School representation to serve as key product owner • Milestones IAM School **Implementation & Testing Phase** *Actual deliverables will be fleshed out during the implementation planning process, but some items are covered below. Assume each deliverable below includes sub-deliverables which imply some design, development and testing.* Environment setup Setup environment to support the development process (dev, QA, stage) IAM School Data model HUIT data model can support school's key attributes: • Extend database schema • Test extended schema with sample school identity data IAM School Data quality analysis and remediation Outcome of data quality analysis and recommended remediation steps IAM School Data feeds Data feeds are in place for identified/prioritized synchronization target and sources IAM School SailPoint provisioning plan Provisioning plan to be implemented in SailPoint IAM School SailPoint IIQ connectors IIQ connectors in place for identified provisioning targets IAM School Support processes Document modifications to support processes to account for new implementations IAM School User acceptance testing User acceptance testing of newly integrated functionality, with an eye to making sure that the various business processes are supported School IAM User acceptance test plans Test plans to be followed for user acceptance testing School IAM Integration regression testing Run regression test suites to make sure applications work as expected IAM School Issue log Create, triage, and resolve issues on UAT issue log School IAM N/A **Deployment Phase** Deployment plan Plans for deploying changes to production IAM School Transition plan Plan for transitioning effort from development into operations School IAM N/A Communication plan Plan for communicating changes to end users, including training of support staff where needed School IAM N/A