In this next post as part of my series on solution architecture for the Power Platform, we’ll look at translating initial customer requirements into a high-level solution design to propose to the customer we’re working with. This post will look at the element where we match up the problem and the need with technical elements and components we can implement to create a solution.
Matching requirements to functional components
So as previously mentioned in past posts in this series, following initial discovery and meetings with your customer, you should have a documented idea of what they’re attempting to achieve, their business problems and the workflows we’re attempting to improve.
The next part of what we have to do as solution architects is start to look at the tech and solutionising parts! Fun!
Here we’re basically going to run through the high level requirements that we understood from the customer and we’ll map these to components in the platform we can use to meet those requirements. This might be as high level as saying we’ll map an app to a requirement, or a Dynamics 365 solution to a requirement, or a plug-in to a requirement etc.
There’s an important part to keep in mind here. We should have already captured information around the customers existing toolsets and implementations as background knowledge. Let’s say we have a requirement to host something in a storage solution in the cloud (Blob Storage in Azure as an example). Now if we add Azure as a solution into our requirements and functionality mapping, whilst the customer already utilises another cloud solution, that might not go so well with the customer.
It’s important that our designs take into account integrations we have to make with existing systems to built into the customers ecosystem and not attempt to rebuild it.
Architecture diagrams
Once we’ve done this kind of requirement and component type mapping, its important to draw the lines between components to identify integrations and potential missing components such as automation, custom logic, and plug-ins we may have missed.
We can do this by producing architecture diagrams which show the components we’re planning to implement at a high level, their categories, and how they relate to each other.
Data design
The next element we have to design as part of a solution is the data model. This can be done at a high-level during the pre-sales phase to make it clear as to which key pieces of data are needed and in which places, then when it comes to project kick off and continuing with the implementation, this can become more granular and defined for developers to work from. We can design these and present them as entity relationship diagrams.
Process design
The next thing we can include in a high level design is a design of the processes being implemented as part of a solution… anything that will become custom logic, automation, stages in a partially automated process etc
It may be that we can make suggestions to improve a customers process and we do this by presenting process designs to them.
Interface wireframes
The next thing we can include in high level designs is some detail on the user interface we will design and develop as part of the solution. For GUIs, we can produce visual wireframes to demonstrate these, but we should think a little further than just that.
We should also include accessible design in this element of our design document. We MUST start thinking about accessibility from the word go if we want developers to even consider it when building the solution.
Security design
Now don’t forget this one friends! I so commonly see this one missed out on projects where developers / consultants remember it towards the end of an implementation and then don’t have scoped time to implement this part of the solution.
Check out the posts below to get an idea of some of the things you should be thinking about when designing security strategy for your solution.
What’s coming up?
So friends, there’s still more that we can include in a high-level solution design document such as integration considerations, deployment options and more but hopefully this gave you an idea as to some of the things you should be including in high level solution designs during pre-sales. Remember this varies based on the size of the solution, and what I’m not suggesting is you need to add very high detail in every area of a design or proposal for a small or even medium sized solution… but a solution architect should judge the size of the requirements attempting to be met and make an informed decision as to the detail that needs to go into a document based on this.