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 iam@harvard.edu.

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 POI processes Describes how Central 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