Blog Series – Solutions Architect: Jim Llewellyn

As Credera’s Head of Business Success and lead Solutions Architect, I am completing our blog series with a summary of the role. My colleagues Saptarshi and Jon gave good personal accounts of their experiences. Collectively, we offer our customers business success and long-term impact on their Salesforce projects. This is my overview of the role and its importance to our customers.

Perfecting the art of solving problems

I’ve been working in IT since 1994. As a technology professional, your job is never done. You could always do better, there are countless ways of solving problems. 

When I first did my solutions engineering training with Salesforce, they’d interrupt delegates by holding up the question WHY? on a board. It’s not so much about using Salesforce to do a certain task, it’s about why you’re doing it. In contrast, technical architects are very much focused on the ‘how’ – the nitty gritty of how something is achieved, the enterprise architecture, technologies, etc.

Communicating expectations

Salesforce has an answer to everything, so you need to know how valuable a solution is to your client before you offer it. If their organisation is not mature enough to use a particular feature, the Solutions Architect needs to understand that. 

You have to take into account where the client is in the Salesforce lifecycle. Part of my job is to articulate this to various parts of the business. That includes our own business, our sales executives, developers, project teams – and our client as well.

When we’re supporting pre-sales discussions, estimating what a solution will look like, we work out a range of options. What will do the job with some manual input vs push a button and the whole lot is done automatically.  AI really can do it for you, but would you buy a Rolls Royce when you are happy with a Ford? Those are the key skills that are really important. You can’t ignore different options to get a robust answer for the client. 

To achieve the best solutions, you really need to talk to the client. The more time you can get to understand and be with them – their pain points, their real world experience, why they’re asking for solutions – the better placed you are to match their expectations. “We just want someone to make it easy for us to make a decision!”. For example, if you’re researching buying a TV, you might go to John Lewis and say, this is what I want, to get a couple of options to choose from. That’s the trusted advice – clients trust us to know what we’re talking about. We will give you what you need, so your money is spent on the right solution for you.

A frame of reference

I’ve had my fair share of long hours developing code to implement a solution. I know that when you have an understanding of context then you can better prioritise your time and efforts. People love writing cool stuff and delivering cool solutions. A Solutions Architect needs to add a frame of reference so they understand and make best choices.

When you compare the skills between a Solutions Architect vs Technical Architect, the biggest difference is the softer skills. It’s about an understanding grounded in technology. You need to know the details, but then be able to move away from this detail to get to a high level solution.

At Credera, we’re always looking for people who understand these concepts. If you are a Solutions Architect or are hoping to take your career in that direction, apply for one of our open opportunities, or get in touch with us on LinkedIn. 

• News