The Essential Guide to Salesforce Solution Architect Responsibilities

Depending on the type of organization, a solution planner may have slightly different tasks. In a consulting company, a solution architect may be assigned to a specific project and customer, while in a product-based company, a solution architect may work with multiple customers to teach them about a product and review their solution design. Overall, a solution engineer is in charge of the following main tasks:

1. Analyzing user requirements

Business needs are at the heart of any solution design, and when a project starts, they are outlined in their most basic form. It is important to involve many different groups from the start, including those with

professional skills to figure out what needs to be done. The business partner sets the standards, and as technology changes, this calls for multiple changes. To save time and effort, solution developers need to be involved in making the user requirement paper.
The program is designed by the solution engineer, which may affect how the business does as a whole. Because of this, requirement analysis is a very important skill for a solution engineer to have. A good solution engineer needs to be able to work with many different partners and have the skills of a business researcher.

2. Specifying non-functional requirements

Non-functional requirements (NFRs) might not be obvious to users and customers, but if they are missing, it could hurt the total user experience and hurt the business. NFRs handle important parts of the system like speed, delay, scaling, high availability, and recovery from disasters. The following picture shows the most popular NFRs:
The following NFRs should be taken into account, as shown in the figure above:

2.1 Performance:

How long will it take for people to load the app?
How can we deal with slow networks?

2.2 Safety and following the rules:

How can we keep unauthorized people from getting into an application?
How can we keep bad people from attacking an app?
How can we make sure we follow local laws and audit rules?

2.3 Recoverability:

How can we get a program back up and running after an outage?
How can we get back up and running as quickly as possible after an outage?
How can we get back the info that we lost?

2.4 Maintainability:

How can we make sure that tracking and alarms are set up for applications?
How do we make sure that applications will work?

2.5 Reliability:

How can we make sure that the tool works the same way every time?
How can we check for and fix bugs?

2.6 Availability:

How can we make sure that an app is always available?
How can we make an app work even if something goes wrong?

2.7 Scalability:

How do we keep up with the growing need for resources?
How can we come up with a good number for a quick increase in use?

2.8 Usability:

How can we make it easier to use an app?
How can we make sure that the user experience is smooth?

3. Getting people involved and working with them

Stakeholders could be anyone who is interested in the project, either directly or indirectly. Along with the customer and user, it could also be the development team, sales, marketing, infrastructure, network, support team, or the group supporting the project.

4. Handling various architectural constraints

Constraints on architecture are one of the most difficult parts of designing a system. To find the best solution, a solution builder needs to carefully handle design limitations and be able to negotiate between them. Often, these limits rely on each other, and putting more focus on one can make others seem worse.
These are some of the most popular ones:

4.1 Cost:

How much money is there to put the answer into place?
What kind of return on investment (ROI) do you expect?

4.2 Quality:

How closely should functional and non-functional needs match the results?
How can we make sure the answer is good and keep track of it?

4.3 Time:

When should the result be sent?
Is there any leeway with the time?

4.4 Scope:

What is the exact expectation?
How should the difference in needs be treated and made up for?

4.5 Technology:

What kinds of technologies can be used?
How flexible is it to use old tools instead of new ones?
Should we build it ourselves or buy it from someone else?

4.6 Risk:

What could go wrong, and how can we keep that from happening?
How much danger are partners willing to take?

4.7 Resource:

What needs to be done to finish solution delivery?
Who will work on putting the answer into place?

4.8 Compliance:

What are the area laws that could change how the answer is done?
What are the rules for audits and certification?

5. Making choices about technology

The most important and difficult part of a solution architect’s job is choosing the right technology. There are a lot of different tools out there, and it takes a solution builder to figure out which ones will work best for the answer. To make the right choice, the solution engineer needs to know a lot about a wide range of technologies. This is because the technology stack picked can affect how the product is delivered as a whole.

6. Developing a proof of concept and a prototype

Most likely, the most fun part of being a solution builder is making a prototype. To choose a proven technology, a solution engineer must create a proof of concept (POC) in different technology sets to see how well they meet the solution’s functional and non-functional requirements.

7. Designing solutions and staying through delivery

Solution architects work on designing solutions after they have learned about functional requirements, non-functional requirements, solution limitations, and technology choices. This is an iterative method in a rapid setting, where the goals may change over time and the solution design needs to be able to keep up.
The solution builder needs to create a solution that will work in the future. It should be made up of strong building blocks and be able to adapt to changes. But the solution engineer needs to be careful about standards that change a lot and use a plan to reduce risks.

During solution design, the solution architect is in charge of a lot. Here are some of the things they do: