In this next post as part of my series on solution architecture for the Power Platform we’ll look at considerations for the support element of a live and working solution. This is something to consider for post go-live operations and we’ll look at this in detail today in this post! ✉️
Recap
So friends, if you didn’t already check out the post below, catch up on it now before continuing!
Need for support
So friends, let’s think about solutions we’ve put into live and that we have people using. With any of these, even if we’ve done extensive end-to-end testing, there can sometimes be the odd issue that makes its way into production.
For these scenarios, and some of the following we may benefit from a support function…
- Access assignment and issue resolution
- Resolution for issues where production environments have incorrect environment-level configuration
- Licenses not assigned
- More…
Scale and skill mapping
So, as you can probably expect there won’t be a story of one size fits all for support when it comes to supporting solutions. As solution architects we should be able to look at the solution we have designed and its size and suggest an appropriate support team to support the solution in live. This may include detail around the number of resources to support the solution, as well as the skills that should be available to support.
Moving into support
Another consideration we need to make is how our support team will actually pick up ownership of the support element of a solution gone live, and maintain it. There are a few things we can think about here which we’ll look further into in the next post…
- Solution education
- Hand over meeting
- Period of handover and learning
- Technical escalation and architectural ownership contacts
- Customer interaction and support introduction
What’s coming up?
So in the next few posts we’ll look at a few things around support being handover topics as well as interaction with the customer to prepare them for operations and BAU using the solution. 🚀