What do Solution Architects do?
My personal experience!
Welcome 24 new members who joined us! We're a community of Salesforce SA, BA, Devs and admins! If you enjoy this post, forward to a friend of yours, so they can join us.
The role of Solution Architects often gets mistaken with those of Technical Architects or Product Owners in a project.
So I got curious and asked ChatGPT if it knows something. Here is what it says:
Unfortunately, as you see above, all I received back is a generic response. Might as well replace SA with Business Analyst or Product Owner and I couldn’t tell who is doing what.
Being a SA myself, let me tell you my own experience - the real truth behind SAs role.
Solution Architects are the functional leads in projects. They understand the business needs, design functional solution and guide technical team to build that solution.
Ok, but how do they really do that?
I will break that down by looking at every piece of a project cycle and explain what SAs do in each of those pieces. So fasten your seat belt!
Every project can be broken down into following pieces.
Project Kickoff —> Discovery —> Analysis —> Build —> Testing —> Demo
—> Go-live —> Hypercare
It starts with Project Kickoff (warm up clients, introduce team members) and ends with Hypercare. Build, Testing and Demo usually run on a 2-3: week sprint and get repeated until all the project work is completed - till we reach Go-live.
So let’s see what SAs do in each of these pieces:
Project Kickoff: Set an agenda
When the project is initiated, you normally have 1 week before you start actual requirements session (aka Discovery) with your Stakeholders or Clients. During this time, SAs work together with Project Manager to outline an agenda of different sessions for that Discovery. SAs go through Statement of Work (SOW) and outline which topics and subtopics need discussion and how much time is required. This sets the stage for Discovery or gathering requirements with the clients.
Discovery: Lead sessions
Solution Architects are the captains who lead the discovery sessions with a Client. They carefully review the SOW again and understand what the client is asking for.
Once the discovery is in motion, they speak with Clients understanding what they are looking for. First, they walk through As-Is (or current process), understand pain points and along with clients, design the To-be process.
During this time, they have a Business Analyst who helps with documenting notes, drawing diagrams and supporting SAs.
In some projects, I’ve seen BAs lead the discussion and SAs will provide input where necessary. But in this stage SAs and BAs work together to understand everything Clients are looking for.
Analysis: Analyze and put requirements together
SAs then take on task to put the requirements together (via User Stories). In a lot of cases, BAs do this work as well. But, SAs review the work and make sure all the requirements are fully captured.
This is a team effort between SAs and BAs again where they go through all the notes.
Here are the questions they go through:
Have we captured all the requirements from the clients?
Do we have all the fine details necessary for the requirements. Is there anything missing that we need to go back to clients for?
BAs mainly write the User Stories, Acceptance Criteria, assumptions while collaborating with SAs.
Analysis: Developing Solutions
Solution Architects now take it one step further and start putting the Solution for each User Stories. In this phase, usually SAs work alone or work with a Technical Architect. They capture all the information which becomes a guideline for Devs and Admins to build out the stories.
Example, if a new text field is required, if automation is done using a Flow, if field visibility are handled using Dynamic Forms, if there’s a need to design Object Model and so on.
If you want to see an example of a complete User Story with solution, use this link.
Build: Prioritize and scope out the Stories.
Once solution is crafted, SAs estimate the Story points (using Fibonacci sequence) or other method. They divide the stories into Sprint and based on capacity of developers/admins in the projects, assign right number of User Stories for each sprint.
During the actual build phase, they are responsible to clarify any questions devs or admins have regarding the stories.
If Devs are stuck or something is not clear, SAs are responsible to clarify those and lead the team forward.
They co-ordinate with Technical architects if there are data or integration tasks as well.
Testing: Guide QA/Tester
Quality Assurance or tester mainly performs the testing. They reach out to either devs or Solution Architect if they’ve questions on User Stories. SAs also co-ordinate with QAs to make sure all Stories are being test properly with Test Cases.
Demo the product
Once a Sprint is complete (usually around 2-3 weeks), one of the crucial roles of SAs is to demo the product to clients. They need to show to clients what has been built so far and get their feedback. For a project perspective, this is an important milestone as this is the first time Client is visually looking at how the product is coming along. SAs also capture any changes or new requests from the client (either for Backlog or to change some requirements).
Go-Live: Orchestrate the deployment
Once everything is built (through multiple sprint cycles), now it’s the time to Go-live or call it Production deployment. Usually Technical Architects lead the dev-ops process, but SAs play a crucial role in orchestrating the actual deployment as well.
Solution Architects works with TAs to put together a deployment timeline – from Pre-deployment activity to actual deployment to Post-deployment activity.
Oversee Hyper care
Following the project’s launch to production, there is typically 2-3 weeks of hyper care phase. During this time, SAs interact with clients to capture bugs or issues and work with tech team to fix them.
With help of BAs they also capture any new requirements, additional feedback and put it in a project backlog.
This is what Solution Architects do in a project (whether in-house or as a consultant).
As you can see, they are in the driving seat to lead the project from Initiation to Completion!
