In the last blog we covered some of the essential artifacts that are required as part of your solution presentation. There are some other artifacts that will aid you in telling a compelling story and may be done in your presentation (but should be avoided). In this blog I will also cover a presentation approach at the end you can use to structure your presentation using these artifacts to further emphasize the importance of structuring your presentation.
Please do not take my words as gospel I am just providing an approach (that is still evolving) that works for me but you should try out approaches and land on your own style. Lets dive in.
Contextual SSO Flow Diagram
Most CTA scenarios have "Access Requirements" either called out in a section on its own or mentioned as part of "Visibility Requirements". Contextual SSO Flow diagram is the best artifact that supports the solution for these requirements. This diagram should not be prioritized, but if you have time available should be included as part of your presentation. Otherwise, you might likely be asked to draw it during the Q&A session.
This diagram should communicate the target user's (Internal or External) SSO experience and should include bidirectional details based on the following flows calling out the SSO flow by name:
User Authentication
Federated SAML IdP Initiated
Federated SAML SP Initiated
Social Signon (OpenID Connect (OIDC))
Delegated Authentication (HTTP) (Very Rare Usecase - Application Intranet)
OAuth 2.0 Web Server (Web Application)
OAuth 2.0 User-Agent Flow
OAuth 2.0 Authorization Code with PKCE
ESB/ETL Integration
OAuth 2.0 JWT Bearer Flow
OAuth 2.0 Client Credentials Grant Flow
Token Refresh
OAuth 2.0 Refresh Token Flow
Device
OAuth 2.0 Device Flow
OAuth 2.0 Asset Token Flow
We will cover some of these flows in detail but below is a contextual (catered to the scenario) SSO flow diagram for a Social Signon scenario for customers. The main highlights here are to callout the three endpoints on Auth Provider that will be leveraged: one to get authorization code, the other to request endpoint, and the endpoint to request user info for custom registration.
Data Migration Strategy
If you have called out deprecation of any systems in your solution or there are specific asks for data migration (usually in the overview, current landscape or its own section) in the scenario then this is an important artifact to include in your presentation.
This artifact should be specific to the requirements by calling out the systems we are extracting the data from, and mentioning the process of planning, pre-load, data load and post-load steps if any. Below is a sample from Greenhouse recycling.
Business Process Flow
This is an optional diagram and should not be prioritized over any other diagrams described before. It can be the most time-consuming diagram to generate and requires a significant level of detail. Also given a scenario can have multiple business process flows, multiple diagrams may be needed. Personally, I avoid this diagram given the time constraints and thus I have not included a sample as I don't have one for any mock scenarios.
Given you decide to include this artifact, the following details should be included:
System Tracks as swimlanes to differentiate the process elements by system
Process elements categorized as user actions or automated logic
Integrations if any and data exchanged and processed
Artifact Story
Now that we have gone through all the artifacts and their importance. It is important to know how each artifact should be presented as part of a connected story. The below diagram shows a possible way of using the artifacts to answer the key questions you will need to answer as part of your solution approach.
User Licensing, Role Hierarchy and maybe Contextual SSO flow can be used to highlight the users and how they will access the system. The System landscape will cover the systems in play, how they interact and what is being retired. The Data Model will answer what data will support the business requirements. Business requirements should be specifically solved and process flow can be used to aid the conversation but not recommended. The Data Migration strategy covers how the foundational data for the system is being planned on migrated. And finally, Environment Strategy and Governance covers the project delivery and governance process to guide the transformation.
Conclusion
In this blog, we covered some of the good to have/ones that can be avoided artifacts. Out of the above Migration Strategy might be the most pertinent in case of migration considerations as there are a lot of details to keep track of on top of your mind since they are mentioned in multiple sections. SSO flows could be skipped but important to mention the SSO flows in your system landscape and call out the specifics like "registration handler will create customer record from user info provided for UserInfo endpoint in OIDC SSO flow on first login". Avoid business process flow due to its complexity and not much value added.
But again adding a disclaimer that these are just my opinions around artifacts or approaches I find useful.
Resources
The following sources were leveraged to compile this article.
Comments