In my last point on the topic of architecture, I kicked off this series around solution architecture with a bit of a high level around different types of architecture when it comes to working in the digital space, but also with low-code platforms. Now we’ll dive deeper into solution architecture specifically, with a focus on solution architecture when building on the Power Platform.
What is solution architecture?
So, in the context of working with low-code, but also somewhat generally speaking, solution architecture is the process of designing and implementing solutions built with the low-code tools that a platform such as Microsoft’s Power Platform offers. ‘Solution architects’ have the role of owning this process end to end from the initial requirements gathering, question asking and designing of a solution, all the way through to making it production ready it and moving it into support.
There’s many things involved in solution architecture such as understanding the customer being worked with as well as their needs, the platform in question i.e. Power Platform along with its limitations, best practices for building high quality, secure and scalable solutions that deliver reliable and strong user experiences, whilst being a pretty awesome question asker 😉… that’s just to name a few things though! Solution architecture is no simple, or small task, and there is a whole host of different parts to it to take care of!
What does the process look like?
So as we’ve mentioned, solution architects take an ownership role of the end to end process involved in delivering a solution built on the low-code platform including the movement of it into BAU / operational use and support.
As per Microsoft’s thoughts, some of the stages involved include…
- Pre-Sales
- Initiation
- Analysis/Design
- Implementation
- Delivery
- Operation / BAU
I’d agree this is a good high-level outline of the stages involved in the first discussions needed to be had around the implementation of a solution, all the way through to the movement of it into business as usual / operational use and support.
One element I’d probably add somewhere near the beginning, and which possibly even fits into the pre-sales stage is the ‘why?’ and the success planning element. This is the element that focuses on conversations with the people in the business roles attempting to get value out of the solution and covers the sort of questions like…
- “What is the present inefficiency
- “Why is a solution needed?”
- “What is trying to be achieved?”
- “What would a successful outcome be?”
A lot of the outcomes from these kinds of questions will give the solution architect great business context which will make requirements capturing a lot easier!
Whats coming up?
So, hopefully this gave you a very high-level introduction to some of the elements of solution architecture and a glimpse at what is involved. In the next posts in this series, we’ll look at some of the elements in greater detail to understand the real role of a solution architect! Stay tuned friends! 💖