With the UN Climate Change Conference (COP26) due to take place from October 31st, Salesforce’s recent Net Zero announcement marks a welcome and timely achievement.
Salesforce’s commitment to addressing climate change can be seen further in its Sustainability Cloud product. Version 2.0 (expected in 2022) aims to “accelerate customers’ path to Net Zero, empowering organizations to track and reduce their carbon emissions and become a sustainable business”.
But beneath the headlines, there is a hidden side to sustainability that we don’t often hear about – a side that relies on smart, collaborative design. This is how anyone who is responsible for designing and building Salesforce – Salesforce Architects, Admins, etc. – can make a positive change.
I spoke with CEO and Solution Architect at The Architech Club, Gemma Blezard, to find out what Salesforce professionals should be thinking about in their mission towards responsible, long-term sustainability.
What Does a Robust and Scalable Solution Look Like?
You’ll no doubt have come across these buzzwords time and time again. But what do they mean in the context of Salesforce architecture? Perhaps, instead of describing what a robust and scalable solution is, flipping the question on its head could be more beneficial. So, what is not a robust and scalable solution?
Here’s what Gemma had to say.
Gemma: I’ll start on a comic tone. If you want to know some horror stories, there’s a great place you can go called OrgConfessions. You can read confessions from system administrators and developers around Salesforce – things they know they shouldn’t have done, or things that they have found or inherited in their org that really shouldn’t be there.
I suppose it starts by saying, our “Salesforce sustainably” mission has been inspired by a couple of projects that I’ve worked on in the past, and overall observations of the standards out there in terms of client experience.
As consultants, are we really thinking about the experience that we give to our customers? That experience is, ultimately, that they can pick this thing up and run with it themselves. We are in the business of enablement. Gemma Blezard
So, what does enablement look like? Well, you have to understand the risks. Salesforce is a shiny new tool, and it is a great platform to work with. I love the fact that you didn’t have to install it on a computer years ago when I first logged in. Now you have Trailhead, and it’s so accessible, free and easy to learn Salesforce.
That comes with great benefits – fantastic benefits. And it also comes with great risks, because it’s very easy to get carried away and over-engineer things if you don’t fully understand them yet. Also, it can be easy to get caught up in the excitement of working with these great features.
Look at what I can do here: I can build a field, I can build a lightning component, I can make a path, I can produce an invoice out of thin air using flow – all of these things.
But what we’re trying to get people to do is – yes – encourage and nurture the excitement; be excited about Salesforce, it’s an exciting platform. But we have to think about it first – think about your business’s goals.
If I build this quoting tool now, it produces a renewal opportunity automatically. Then I’ve written up an apex class that is going to produce a PDF based on a visual force template that I have put together. You’ve got to think about the people who come after you. Is it going to be easy for someone who joins in three years’ time to support users who can’t raise a quote because something’s changed? There’s a new picklist value and the apex class hasn’t taken that into account in its decision-making and logical flow process, so no PDF is being generated – just as an example.
So, that brings me to the concept of ‘technical debt’, which can arise for many different reasons. But not robust, not scalable solutions, to me, are reactive implementations of Salesforce:
“We just need to get this in right now, because we have an immediate priority and we don’t care how it’s done. We just need to get it done.”
Those projects, ultimately, end up in failure because there’s not enough thought.
Another example – projects that have stalled because the customer wasn’t ready. They knew they wanted the tool; they knew and understood everything it could do; they understood the benefits and how quickly it could get set up. But when it came to applying that knowledge to their business, they hit a wall. They had to stop, go away, and start thinking about it in more detail.
That’s how you create that scalability; you think if it works now, will it work in two, three years’ time? Is it still going to work with 200 people in this org instead of five?
Examples of Robust and Scalable Solutions
What are two of your favourite examples when thinking of solutions that have made a positive impact?
Gemma: Oh my goodness! The two projects I was working on at the same time in 2016 helped me grow as an architect, and as a well-rounded architect. I was having to specify code design, I was having to do solutions, I was having to coordinate three managed packages, sometimes four or five in one single org.
The things that made those projects so positive: number one, they spent the time to prepare. They spent time thinking, yes, we know these features, but they spent time taking it to their users. They asked, “what would you think about… we’re going to introduce a concept to you… tell us what you think about it.” And the discussions that came out of that led to the backlog, it led to the use cases, and it led to a project plan and implementation scope.
I think back on that particular client so proudly because they owned it; they knew how much work they had to do on their side; they weren’t expecting the partner to come in and deliver the earth. They understood that, in order for this to be successful, it would have to be a joint effort on the part of the partner successfully translating their requirements into a solution that works, is scalable performant, and creates a smooth user experience. But they also had to think about the quality of their own requirements.
It’s so often we get solutions thrown at us over the fence:
“Gemma, can you set up single sign-on?”
“Why do you want single sign-on?”
“Because the business wants it.”
Yes, the business wants it, but the security benefit is what’s most important. The user experience benefits when they don’t have to remember all these passwords – that’s what I’m trying to push. Solutions that have made a positive impact have focused on each of those facets in equal proportion.
Lucy: It sounds like there’s a lot of context to thinking about the project scope that came to be.
Gemma: Yes, I think there has to be. It’s very tempting to template everything. Yes, sometimes we have to template our approaches as consulting partners if we hope to scale. But equally, I think if we template too much, we can lose sight of the nuance that exists in that customer; that customer’s unique journey, unique culture, and unique set of skills that we need to recognize as part of that project to deliver that success.
Building Salesforce Sustainably
Lucy: It’s a fine balance because there’s a limitless number of requirements, or outcomes, or factors that can go wrong (or right). But back onto the topic of sustainability, I heard that you’re also advocating that, by streamlining your org, we can reduce the impact of data centres on the environment. That’s quite a new concept. Can you explain the connection between the two?
Gemma: It’s huge actually. Case in point: we have a client struggling with performance issues. They have a private sharing model. They have an excess of 20 million transaction records coming in and out – it’s huge. We know, given the volume of transactions going in and out between Salesforce and the client’s on-premise systems, that’s processing power between Salesforce and also your own servers. So, your carbon footprint is affected and Salesforce’s footprint is affected too.
As a multi-tenant architecture, every Salesforce instance is part of a greater whole. Gemma Blezard
Could we maybe archive 10 million of those – put them in a data warehouse somewhere so that we can reduce the volume of transactions, increase the performance, and reduce the burden on the data centres? Or you could look at another way of doing this; is it the fact that we just need to be able to see these transactions on demand, and we don’t need to house it in Salesforce? Salesforce Connect might be better. That’s also going to reduce processing power. You’re only exposing the data – you’re not lifting and shifting and posting it.
Really, what’s happening with integration is someone posts a letter, it gets received, and then they write back – it’s the same analogy. Think about Royal Mail, for example – that costs money for the postie to pick up and deliver. It’s a similar situation when you post an integration between systems; someone’s got to pick up that request and execute it. Then they’ve got to secure it, and then they’ve got to keep retrying it. So, the better your logic and the more strategic you are about how you handle your data, the better your impact on the environment.
Lucy: That’s really interesting because it’s all so intangible – it’s not physically like a vehicle moving something. We think of our carbon footprint in that sense.
Gemma: I think Salesforce owns the data centres, but we’re all responsible for contributing to that.
Signs You Should Seek an Architect to Improve Your Sustainability
Lucy: So, looking at this level of sustainability and how to improve it (your processing improvements for your Salesforce org), I’m guessing an architect would be the best person to advise on that. What are some of the signs you should seek an architect for improving that sustainability?
Gemma: Any kind of transformation where you have multiple clouds in play, multiple systems in play, multiple AppExchange packages in play. Equally, if your data’s all over the place and you need to think “what is your actual strategy going to be, which system are we going to house our products in?” That’s going to be the source of truth for products versus customers. If you’ve got any questions about the “how” around Salesforce, that is when you should seek an architect, to get that well-rounded view and an understanding of the pros, cons, and considerations for each of the routes you want to go down.
Summary
Thank you to Gemma for sharing her invaluable insights into how Salesforce architects can help users take real steps towards sustainable futures. Although improvements may feel distant and intangible at times, we can all take responsibility for streamlining our processes, which will help us to #SalesforceSustainably.
You can learn more about The Architech Club team and their scalable, sustainable approach to ‘enablement’, as well as Gemma’s inclusion-inspiring Ladies Be Architects community.
As a partner of COP26, Salesforce has been leading some interesting conversations ahead of the conference – you can read more about the project’s goals here. Marc Benioff is certainly keen to spread the word and promote sustainability in business: “What is your company’s COP26 commitment?”
Comments: