I am currently preparing to take the Microsoft Dynamics 365 + Power Platform Solution Architect certification. Or “MB 600” for short! As I prepare I plan to write revision notes in this post I will discuss the Solution Architect’s role.
Solution Architect’s Role
Before we dive into solution planning it might be useful to consider the overall role of a solutions architect and what qualities they will be expected to bring to the planning process and onward into the wider project.
The Solution Architect will be a functional and technical expert who will effectively own the solution and its design.
- The Solution Architect must have a strong functional knowledge of the Dynamics 365 apps.
- The Solution Architect will typically have past experience of the type of corporation into which the solution will be deployed.
- The Solution Architect will have an understanding of the business issues to be resolved.
- The Solution Architect will have a strong knowledge of the Power Platform, they will have typically already worked as either a functional consultant or a developer.
- The Solution Architect could be considered the “next level of professional”. By this I mean they will typically be senior to the other consultants / developers on the project. Often they will act as a mentor to other technical team members.
- The Solution Architect does not typically write code, but they must appreciate when a no-code/low-code approach is workable and when the target solution requires custom code.
- The Solution Architect will be responsible for solution envisioning, a process of identifying which parts of Dynamics 365 and the Power Platform can deliver the customer’s need. And where custom components / integrations maybe required.
- The Solution Architect will leverage their functional and technical knowledge to “own” the overall solution and its design.
- The Solution Architect should become the “go-to” knowledgeable person for all technical queries.
The Solution Architect will be a problem solver looking to understand how technology might address the stated business issues.
Whilst it is right for us to consider the solution architect as the owner of the solution. Don’t forget that they are part of a team which will include many other members. Including program / project management plus many functional and technical staff. A few possible roles for team members are shown below. In my opinion it is important to be aware of these roles but also be mindful that in real-world projects the exact roles and mix of team members can vary from project to project.
In the largest organizations the Solution Architect may need to collaborate with other Architect roles. For example, Enterprise Architects maybe responsible for defining the “bigger picture”. They will help ensure the systems being envisioned by the Solution Architects are designed to fit within broader organization plans / roadmaps.
The Program or Project Manager will no doubt be the formal head of the overall project. But it is often the Solution Architect who is looked on by the team members as the “real” leader. They need to set an example to the rest of the project team and serve as a role model and mentor. The Solution Architect often sets the tone for the rest of the team, a positive lead will result in a positive team!
The Solution Architect is often thought of as a trusted advisor who consults with the customer and implementation team members to refine business needs into a well-defined and cost-effective solution.
In gathering business requirements (in fact in all aspects of a project) the Solution Architect will need to demonstrate a high level of “soft skills”. These could include;
Collaboration – you will need to work closely with your team members and also the wider business community. Be assertive but at the same time you must listen to the ideas of other team members. A good architect is likely to be a good negotiator and can therefore “encourage” positive outcomes.
Coordination – The Solution Architect may need to work with the project manager to coordinate tasks / resources. They may also need to recommend in what sequence the solution components should be developed.
Communication – The Architect must demonstrate high levels of both written and verbal communication skills. It maybe key for them to translate between “business speak” and technical jargon. (Don’t forget being a good listener is as important as being a good talker!)
Constructive feedback – The Solution Architect may need to give feedback to any of project team.
Problem solving – above all else I like to consider the Solution Architect as a problem solver. Someone who understands the business issue and can propose solutions, this may involve being able to see the difference between a symptom and the actual cause. When solving problems a forward thinking approach is essential, a good Architect will always look for long-term solutions.
- Delegation – as mentioned above the solution architect will not typically write code. Therefore their ability to delegate this and other tasks maybe critical.