Afternoon! How are you all doing? What I would like to know, and please comment below, is what you think a Power Platform Solution Architect Role (SA) looks like? Are you a Power Platform SA, what does your role look like? Do you think there is a difference between the job role of a Dynamics 365 SA vs a Power Platform SA? What’s the difference between a lead developer and an SA on power platform / low code ?
I'm going to try and answer these questions above if I can, below.
I have been having some very interesting chats with friends and colleagues over the last few days as to what the definition of a Solution Architect (SA) role inside the Power Platform, low-code space, actually is.
And it's got confusing. Because there doesn't seem to be one answer, and it seems to differ depending on who you speak to.
I LOVE the Power Platform. As I have explained before, it has changed my life in many ways. I am in a very happy place, mentally, and that is a lot down to the role that I am in, the feeling I get when I speak to clients/colleagues that I am truly helping others succeed.
My aspirations are to go and become a Power Platform SA. At the start of the year, I planned out my goals, one of them was passing the PL600 exam by the end of the year. This is the Microsoft SA certification. I took the exam at the start of January, expecting to fail it, so that I would have some pointers on where I need to revise and improve. But, to throw a good spanner in the works - I passed it! Oops.
Now I feel like I need to start with the SA role and work backwards to see what it looks like, whether I would enjoy it and what tools and skills I need in my toolbelt to achieve this goal.
Detective Jon starts here.
I put a post on LinkedIn to find out whether any of the SAs in my network wanted to chat to me. Luckily a few of them did. The conversations I had were interesting and varied and descriptions of SAs differed depending on who I spoke to.
I then went to Microsoft Learn, and looked at the definition of an SA there:
"Microsoft Power Platform solution architects work with stakeholders and focus on solutions that affect their organization’s broad business and technical needs."
The key parts of this sentence to me were "work with stakeholders" and "focus on solutions that affect [ the] broad business and technical needs".
This to me talks about two main themes:
Soft skills - communication, empathy, leadership
Holistic technical knowledge and the art of the possible.
Speaking to Jason Earnshaw, I realised that there is a different answer depending who you speak to as to what an SA does and there are these core themes above, but deep into the role there are some differences between the specifics of the role. This blog post is going to try and look at these differences and then try and get a consensus on what an SA is.
A deeper dive into Microsoft's definition of a Power Platform Solution Architect Role and how it relates to SA job descriptions.
Looking at the learning pathway for PL600 there are some main points for becoming an SA:
Project governance
Environment strategy, including data and scalability of solution
Understand capabilities of all components of Power Platform
Data modelling and best practice for Dataverse
Data security and DLP
Reporting and Power BI
Data integrations
ALM
Testing and go-live
Next, I wanted to look at job descriptions from various partner websites to see how these elements factor and whether the descriptions mentioned these attributes:
What I found interesting is that in the Microsoft SA learning path, there are no real mention of the soft skills that are needed. I imagine this is due to the nature of soft skills not being a right or wrong answer, and therefore very difficult to quantify. Time and again in the job specs there were similar sentences such as "Well-rounded stakeholder management experience" and "Serve as clients' main point of contact throughout all project phases".
There also seems to be a differentiation between technical SAs which are more aligned with the delivery of a project and being a technical leader/owner as well as pre-sale SAs which look to validating the business requirements and potentially creating a POC.
I want to concentrate on delivery. It's where my passion lies. I love speaking to new people and feeding off their passion for the problem they are trying to solve or the business process they are trying to improve. Looking at LinkedIn profiles, I have noticed that people in SA roles quite often have developer backgrounds. Not always, but it seems to help. Maybe as Power Platform SA, a developer background is not as necessary but having a holistic art of the possible view, is, with a focus of being customer obsessed.
When I spoke to Stuart Baxter, he explained how he sees that there are two types of SA, "there are both technical and functional Solution Architects and there are some architects that do both," he continued to say, "it is important for any architect to have the fundamentals of both sides so that options for the client can be iterated over. For example: a plugin over a Power Automate cloud flow, and the pros and cons of each".
So, what is a Solution Architect?
I have come to the conclusion there is no right or wrong answer to this question. I think an SA is all of the items listed above from Microsoft Learn as well as the softer skills: client/stakeholder engagement, broad understanding of technical knowledge of the Power Platform and wider Microsoft ecosystem, as well as how the solution could fit into the existing architecture that the client has by understanding the potential risks associated with that implementation.
I have a focus to become an SA, but I am also aware that there are areas I need to invest my learning time in. Namely some parts of Azure, also some softer skills such as how to handle a client question when the answer is not known. Also, some amazing feedback from EY Kalman was about asking the client 5 why's. EY explained that "you have to keep asking why, it helps to iterate towards that big question, that breakthrough moment with the client". It is about asking them the reason why they want to go down a specific route and how it will solve their business problem. Being tech agnostic and understanding the business process and function first, and iterating over that process to understand where the "value add" can be gained from the Power Platform and its suite of capabilities.
In my view, there is a divergence between Dynamics 365 and Power Platform SAs, a Power Platform SA may slightly lean to the more technical than functional side. But I think this is very much up for debate.
Special thanks to all of you who had chats with me over the last day or so. It has been insightful:
I really appreciate you all taking the time with me to discuss your roles and what it takes to be a successful SA.
In summary
An SA needs to understand the Power Platform technically from a high level, with preferably one or two highly specialised areas. They need to be an excellent communicator; a strong leader; have the ability to empathise with everyone involved in the project from client stakeholders to junior consultants on the delivery team.
They have to know the toolset well, from a functional perspective and either have the experience in project to be able to build it from a technical perspective, or be able to lean on a technical architect to help them build it technically.
They need to be the owner of the solution from a data model perspective, with special consideration in security, governance and scalability. The need to be able to have harder conversations with clients if the solution is not technically viable. They need to be a point of escalation contact if a project is not in the right shape technically or is deviating from the statement of work. It's also not just a matter of passing the PL-600 exam, this is great of course, but real-world experience is a must have.
Thank you so much again to all the people who spared their time with me.