Top 10 difference in roles & responsibilities of Solution & Technical Architects in Salesforce

10 Differences Between Salesforce Solution and Technical Architect

How often have you been asked on transformational projects that who would be doing what? Especially when you have multiple types of Salesforce Architects. Various titles, you name it, like Chief Architect, Lead Architect, Platform Architect, Enterprise Architect, and the list goes on.

In this post, I aim to share my experience and point of view on the difference between the roles & responsibilities of Solution & Technical Architects concerning Salesforce implementation.

Instead of just writing a few bullets, I would explain it as a story, just like I did here.

Once upon a time in the bustling city of Alpharetta, a growing company named “Shivasoft” decided it was time to implement Salesforce as their new CRM system. They hired two well-known Salesforce gurus, Sarah, the Solution Architect, and Tony, the Technical Architect. They were ready to conquer the world of Shivasoft, one Salesforce configuration at a time.

However, upon their arrival, they realized that not only did the company have no idea what their roles and responsibilities were, but Sarah and Tony were also unsure how to divide their tasks. It was like a scene from a sitcom, as the company’s employees and the Salesforce gurus stumbled their way through the project, hoping to make sense of their roles.

As the project progressed, Sarah and Tony tried to take turns doing various tasks. One day, Sarah would be mapping out process flows, while Tony would be discussing page layouts, dynamic forms or quick actions. The next day, Tony would be elbow-deep in Apex code, while Sarah would attempt to make sense of security settings. The office turned into a playground of trial and error, much to the amusement of the employees.

Realizing that they needed to get a grip on their roles, Sarah and Tony organized a meeting to determine their responsibilities. After several hours of intense discussion and a whiteboard full of scribbles, they finally identified the 10 key differences between a Solution Architect and a Technical Architect.

  1. Solution Architects focus on understanding business requirements, while Technical Architects dive deep into technical details and system architecture.
  2. Solution Architects design the functional aspects of the system, ensuring that it meets the company’s goals and objectives, whereas Technical Architects concentrate on the system’s performance, security, and integration.
  3. Solution Architects create user stories, process flows, and wireframes to illustrate the proposed solution, while Technical Architects develop technical specifications, data models, and integration designs.
  4. Solution Architects align the project with industry best practices and Salesforce guidelines, while Technical Architects ensure that the solution follows technical best practices and the latest technologies.
  5. Solution Architects are responsible for stakeholder management and communication, whereas Technical Architects primarily interact with developers and other technical team members.
  6. Solution Architects oversee end-to-end solution delivery, ensuring it is scalable and maintainable, while Technical Architects focus on the system’s stability and reliability.
  7. Solution Architects evaluate and select Salesforce applications and third-party tools to meet business requirements, while Technical Architects assess the technical feasibility of these tools and their integration with the existing system.
  8. Solution Architects collaborate with business analysts and product owners to define functional requirements, while Technical Architects work with developers to translate these requirements into technical tasks.
  9. Solution Architects leads or guides user acceptance testing (UAT) and ensure that the solution meets end-user’s expectations, while Technical Architects are responsible for system testing, performance testing, and ensuring code quality.
  10. Solution Architects focus on change management and user adoption, while Technical Architects handle release management and deployment processes.
  11. Bonus – The solution Architect would review the solution built by the team to make sure they followed best practices of out of box capabilities, point & click-based approaches, and configurable capabilities like flows, reports, etc. however Technical Architect would review best practices, design patterns, and frameworks, etc. are followed correctly for Apex, LWC, Triggers.

With this newfound understanding, Sarah and Tony embraced their respective roles and worked together seamlessly, like two sides of the same coin. The Salesforce project, once a chaotic mess, turned into a well-coordinated symphony, making Shivasoft’s CRM system the talk of Alpharetta.

The story of Sarah and Tony teaches us the importance of understanding the differences between roles and responsibilities in any project. It shows that with clear communication, collaboration, and a bit of humor, any challenge can be overcome, and success can be achieved.

Feel free to share your point of view & feedback on this post. Also, don’t forget to check this article from Salesforce Ben to learn about other Architect’s roles & responsibilities.

Posted

in

by


Related Posts

Comments

9 responses to “10 Differences Between Salesforce Solution and Technical Architect”

  1. Ashish Agarwal Avatar

    Nice article Jitendra! There is always confusion & ambiguity between the roles and responsibility of Solution Architect vs. Technical Architect. This article gives good clarity. 👍

  2. Sita Avatar
    Sita

    Hi J2, A very needed article in today’s project scenarios the differences between Soln Architect & Technical Architect

  3. Pallavi Saigal Avatar
    Pallavi Saigal

    This is an excellent piece. As a Business Analyst and Delivery Lead myself, I feel in my role I can grow as a solution architect as well, if I tread along the right path across the Salesforce ecosystem. One may not need to know it all, however can help with requirement analysis at a functional level, help with process flows, acting as a client advisory and building the right bridge for communications between the Business and the technical team.

  4. Yusuf Kaydawala Avatar
    Yusuf Kaydawala

    This topic is confusing for every stakeholder in a project. Great point of view!!

  5. Phani A V Avatar
    Phani A V

    The role you described for a SA is more of a BA + Engg mgr role.
    I would expect a SA to do the job of the roles described for TA, and I don’t see a need for a separate TA role.

    1. Jitendra Avatar

      Would you expect SA to setup / help DevOps Pipelines, PMD code quality, Apex code reviews, etc ?

      1. Gaurang Avatar
        Gaurang

        DevOps Pipelines, PMD code quality, Apex code and code reviews are generally done by Tech lead and dev team members.

  6. Gaurang Patel Avatar
    Gaurang Patel

    Not all companies have luxury of having both SA and TA. Generally there is an Architect and he/she is SME, work on technical details, system architecture, data models, integration designs, technical best practices and the latest technologies and ALL OTHER items you mentioned are done by Business Analyst or Product Owners

  7. Doug Dunfee Avatar

    Exceptional post sir, thank you so much for writing it and sharing your thoughts! Might be this article should be the gold standard in my opinion for any conversation on this topic going forward. Any other supporting articles that agree or have some differences very welcome! Perhaps one on EA vs TA? 🙂

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from Jitendra Zaa

Subscribe now to keep reading and get access to the full archive.

Continue Reading