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 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 |