The role of the Architect Evangelist at Salesforce is to inspire and empower. In general, the architect is the most trusted digital advisor and technical influencer in the ecosystem. Because of this, the person in this role must always be looking for ways to engage with architects. He has to help them understand how to use our products and if they’ll be successful using them.

As an Architect Evangelist, Marc leverages his experience with Salesforce to help people learn best practices and make wise decisions with technical architecture. In this episode, we’re talking about the recently developed team and cover some of the team’s early content – especially the very popular Decision Guides.  We also lean on Marc’s lengthy experience dealing with technical debt.  

Tune in to learn more about what he does and how he can help you.

Show Highlights:

  • What decision guides are and how they put them out there.
  • How to know if you’re using a Process Builder in the right way.
  • The limitations of a Lightning Web Component.
  • The future of Decision Guides.
  • What technical debt is and the common symptoms of it.

Links

Episode Transcript

Marc Braga:

… Justifying my decisions, trying to show the benefit and the value, build versus buy types of things. And so the NBA came in, the way I looked at it was it provides the knowledge and the leadership skills that technical folks like myself at that time need to really reach their full potential.

Josh Birk:

That is Marc Braga, principal architect evangelist here at Salesforce. I’m Josh Birk, a developer evangelist for Salesforce, and here on the Salesforce Developer Podcast, you’ll hear stories and insights from developers for developers.

Josh Birk:

Now, before we get started, a message from our marketing department. We would love to know more about what you think about the Salesforce Developer Podcast and how you listen to it. So we have put a survey out there, which you can find on our various social media feeds, including the Twitter account @SalesforceDev. Now back to the show. There, Mark was talking about how his NBA experience delves back into his former role as a program architect for Salesforce. But today, we’re talking about the relatively recent team of architect evangelism and his role as an architect evangelist.

Marc Braga:

So it’s an interesting role. I’ve always thought of it as the best and most fun aspects of that program architect role kind of wrapped up all into one. Because going into a new customer, understanding their challenge, providing solutions, that whole sort of onboarding is super exciting. Also the pre-sales activities of an architect are really exciting as well. It’s where you’re strategizing, you’re brainstorming, and you’re putting those implementation strategies into place early on, and then things might get a little tactical after that.

Marc Braga:

So the architect evangelist role, I mean, my goal and our goal in architect relations is really to inspire and empower architects, our customer architects, our partner architects, all the architects in the ecosystem. So for me, it’s super exciting because the architect is probably the most trusted digital advisor, technical influencer, in the ecosystem. They’re making decisions about whether or not to use our products, and how they’re going to use them, and ultimately if they’re going to be successful using them.

Josh Birk:

Right.

Marc Braga:

So what we do is we look for ways either through helping build foundations and standards or different channels to push material out on our blog or upcoming website, just looking for ways to engage with and empower and inspire that audience.

Josh Birk:

Okay, so the team just released something called decision guides. What are they and why did you put them out there?

Marc Braga:

Yeah, the decision guides are awesome. Our products are, when we talk about the Salesforce products, we often talk about and we’re marketing them as very simple, straightforward to implement. And that is oftentimes the case, but when you get into a situation that architects are typically in when it’s an enterprise environment, it’s a lot more complex than that. And on top of that, it’s a good thing, but we have those three releases, we have so many automation options, so many tools.

Josh Birk:

Right.

Marc Braga:

And so, the decision guys, and you’ll see that kind of start to become a brand for our team with the architect relations as we release more of these decision guides because they were so well received, but the particular ones that we really worked closely with our internal teams was to help architects decide on how to make decisions between low code and pro-code solutions, meaning when to use Flow, when to use Process Builder, when to use workflow rules, when to use lightning web components in Apex, and how to either make decisions between those choices or how to make decisions about when to combine them.

Marc Braga:

So those two architect guides are divided between building forms on the front end, so things like dynamic forms and when to use those and lightning web components and others, and then on the backend with like record changes and the other options that I just walked through.

Josh Birk:

And I think you’re nearing the answer to this next question, but why start with those two? Why were they the priority?

Marc Braga:

There was a couple of reasons why we chose those at first. So first, we were starting to do the… Before record change, Flow is now an event that you can work within Flow. And then we wanted to clarify a lot of… So nothing official had come out about what to do with Process Builder versus Flow versus… And so the ecosystem would start to kind of fill those gaps. And we wanted to come out with kind of straight from Salesforce recommendations that were based on the research and the metrics that we know internally and make kind of like a recommendation to the ecosystem, an official, “This is what we think.”

Marc Braga:

And those two use cases, the forms and the record change, are probably the two that are of the most in need right now where architects are making day-to-day decisions in all level of architect, platform architects and solution designers and solution architects are making decisions on those points all the time.

Josh Birk:

Yeah, I mean, it feels very, not only core to how we’re building out applications on the platform, but also as you’re saying, I think most blatant overlap of functionality that we have on the platform. Can you give me a taste, for instance, I would probably lean to Process Builder versus Flow, but mostly just because it’s the devil I know kind of thing. So is there a scenario that comes to your mind where if I’m walking into Process Builder I’m definitely doing it the wrong way?

Marc Braga:

Yeah. So that’s interesting that you say that because in the guide, it’s officially, they’re kind of calling out, the internal teams are kind of calling out the end of life for Process Builder. So there’s one.

Josh Birk:

That’s a good one.

Marc Braga:

And then second, within that guide, they really did a good job of detailing the performance difference between Process Builder and Flow.

Josh Birk:

Got you.

Marc Braga:

So that was some of the best feedback that we got from the ecosystem was just the honesty and the transparency about the decisions that we’re making on our products and really how they perform, and so that’s helping our architects make informed decisions.

Josh Birk:

Yeah-

Marc Braga:

Because I’m with you, I was always going Process Builder. I would remove a lot of code and move to Process Builder, and then there’s a lot of unknown implications when you do that. And then you have also like how do you make a framework of should I have one… We recommend one Process Builder per object. Is that maintainable? Does that scale? So yeah.

Josh Birk:

I’m also generally the kind of person who would lean to code versus click kind of thing. And if I can build a lightning web component quickly to do something, I will. But the concept of a dynamic form, is there kind of a similar conversation there where it’s like, no, a lightning web component is actually going to be less efficient than if I’m just using the thing that’s on the platform?

Marc Braga:

Yeah. So there are still some limitations that are… Again, one of the nice things about the guide too is it calls out what those limitations are between each of the solutions that are being reviewed. And there still are plenty of limitations with dynamic forms. I mean, they’re not GA yet, so they’ll be built on.

Marc Braga:

But one of the things that jumps out at me really is when I was deciding to build a lightning web component, or when I needed to build a lightning web component, certain things like dynamic visibility of a field on a form in real time, which somebody that’s outside of our ecosystem is so used to being able to do that pretty easily. And of course you can do that very easily with a lightning web component, but that doesn’t allow you… We’re trying to say, “Okay, let’s do what we can declaratively first.”

Josh Birk:

Right.

Marc Braga:

And so that’s one that jumps out. You can do that now with dynamic forms. And so that eliminates a lot of the use cases where you would jump to, okay, I need… What seems like a pretty straightforward form to build often surprises somebody that they would have to build a custom lightning web component to support that, well, now you can do that declaratively.

Josh Birk:

So how do you see these guides evolving? What’s the future for them?

Marc Braga:

Yeah. So these guides, we’re talking about that strategy now and maintaining them. So our architect website is launching around Dreamforce, for Dreamforce. And so ultimately, these guides and other guides will be a big part of the resources and artifacts that everybody can find on that website. So today, they live in Quip, public Quip documents.

Josh Birk:

Got it.

Marc Braga:

Announced on the blog, link to the public Quip document. In the future, you’ll find those types of resources on our architect website. And there’ll be essentially an entire architect guides section on the website for similar type content.

Marc Braga:

And so what we’re doing now is kind of pulling the ecosystem to understand where are the top areas that the architects in our ecosystem want these sorts of resources on? And they are around really our architectural pillars of performance, scalability, maintainability, security, governance, cost optimization. So every guide will take a similar angle to what these first two guides did and come at it in the context of an architect or put the architect lens on it, thinking it against those pillars, those architectural domains.

Marc Braga:

And then you’ll start to see every guide or every piece of content, every document that’s on that website have a cross-cloud multi-product angle on it, like these guides do as well. And we’ll start to have guides that help you make decisions about from a data architecture perspective like when to use platform events, when to use big objects, when to use external objects, standard objects, custom objects sort of thing.

Josh Birk:

Got you.

Marc Braga:

Same thing with integrations. The decision guides were received, I mean, something like close to 13,000 views in the first 90 days.

Josh Birk:

Right, right. Which is awesome, congratulations.

Marc Braga:

Awesome. Yeah, so there’s a big gap for that. And what that says is that I, for myself, when I was an architect, so I’m still an architect, but when I was in consulting, I needed this, you know?

Josh Birk:

Yeah.

Marc Braga:

And so, there’s-

Josh Birk:

Yeah, it was the manual you didn’t even know you were missing.

Marc Braga:

Exactly. And it’s always on every architect’s list to build one, you know?

Josh Birk:

Sure. Sure. Are there other things rolling out with the website that you want people to know about?

Marc Braga:

Yeah, so there’s a couple other things. We are also working on a diagramming framework so that there’ll be a standard set of components and diagrams that our ecosystem can use to download and build the diagrams that they need to for their customers and their organization, system landscapes, SSO flows, capability maps, those sorts of things with a standard library of components and symbols that they don’t need to start from scratch, and it’s clear what each of the icons represents, and templates that they can use to start for either their use case, their industry, et cetera.

Marc Braga:

Because again, architects know, when you go to build it, you’re typically starting from one that you’ve already built, so you can use the same sort of look and flow. But you’re always starting from scratch a bit, there’s not that standard library that you can use. And so we want to be able to provide that, and it’s something we’re excited to do from within the website.

Josh Birk:

How have you found adjusting to communicating with the community and reaching out and letting people know that you’re in the role and stuff like that when you’re having to do it all virtually?

Marc Braga:

Yeah, it’s definitely different than I… Because as you know, the evangelist role is so much about engaging with the community. And I was so used to, especially in the consulting world, being on the road and doing that in-person. And that’s a big part of what I’m excited to get back to in this evangelist role.

Marc Braga:

For instance, we had a South Florida Dreamin convention that was canceled. It wasn’t moved. And so luckily over the years, I’ve formed a solid network of customers and partners that I reach out to. So we’ve held a few workshops, and I’ve been able to reach out to that network. Also, the LinkedIn community has been fantastic. So gathering, like when we’re making decisions on that diagramming framework, for instance, or sharing the decision guides and getting feedback on those, all our different social channels have been huge.

Marc Braga:

So where I would have, and where I was expecting to do so much in-person, it’s like you said, it’s been a challenge to try to adjust and pivot that, but I think we’ve been successful. And now we have marketing support for our architect relations team too, so I just expect that to help even more, yeah.

Josh Birk:

Right. Got you. Okay, so I do want to touch on something that you have talked about on stage before, specifically technical debt. It’s something the industry talks about a lot, maybe sometimes talking more than actually doing anything about it. First of all, how would you as a architect define technical debt?

Marc Braga:

Okay. Yeah, that’s a good topic because it’s everywhere.

Josh Birk:

Right.

Marc Braga:

And one that I’ve talked about in the past in webinars and my South Florida Dreamin event session was going to be on that. But yeah, so technical debt, it’s a liability, and it’s incurred due to poor quality or suboptimal solution design. And it can be planned or unplanned, most cases it’s unplanned. But I think the reality is, and most of us need to be aware that, it’s also you plan for technical debt as well. You planned it in sometimes. And it’s expedient in the short term to do that and can be costly to maintain and support in the future.

Marc Braga:

So yeah, I guess that sums it up. It’s a liability that you have within your system, within your infrastructure. And it can come from either poor quality of an implementation or a suboptimal design.

Josh Birk:

So I want to pick up on that thread a little bit more because it’s really interesting to me. So plan technical debt would be when you’re intentionally in a planning phase for something, and how does that work then? Is it like you’re pointing at one part of the architecture, and you’re like, “We realize this is flawed, but it’s also to get us to our deadline”?

Marc Braga:

That’s exactly right, yeah. An example would be you have a dependent system that is also being either procured or built at the same time, and their schedule is not going to be met. And so you have to come up with an alternative so that your system, in this case, let’s say it’s launching Sales Cloud. And one of the integrated systems is also being sunset and replaced with something else, and that one’s not ready. And you’re incurring technical debt by building dependencies for the old system knowing that the new system will come online eventually.

Josh Birk:

Got it. And I’m just going to go ahead and apologize for anybody who has seen some of my very, very old code. But at a previous job, I used to make a habit of putting a comment above a line of code that would say something along the lines of, “This is the hackiest thing I’ll do all day.” So as a developer, I’m sure I have increased technical debt myself.

Marc Braga:

Yeah. And so similarly, we capture that like in Jira or whatever else you might use for your agile project management. We’re capturing similar snarky type comments on like, “We know we shouldn’t have this in there, but we’re planning for this technical debt, and let’s keep a sprint at the end for taking care of that.”

Josh Birk:

Right, right. And there’s nothing quite like a developer trying to hunt down a bug and you see a reference to somebody naming out another engineer who’s no longer in the company.

Marc Braga:

Yeah. I can’t imagine if I went back and looked at the code that I wrote compared to what people are able to do nowadays. It’s like-

Josh Birk:

Yeah, I feel like that’s developer purgatory, like that’s going to be our circle of hell at some point where it’s just you have to go look at your code from… And it’s not like the code you wrote yesterday, it’s the code you wrote like 10 years ago. This came up in a previous episode. I was at a barbecue with a company, this company, the hackiest code all day company that I worked at, and I had left the company, but I was still coming to the barbecues to hang out with my old employees. I’m talking to these two guys, and then they asked me who I am because I’m not employed there. And I’m like, “Oh, I’m Josh.” And the look of fear and awe on their face. And I’m like, “Oh, you’re the front end developers now.”

Marc Braga:

Now, okay, we can put a name to that comment, a face to that comment.

Josh Birk:

Right, exactly. I don’t think I showed up to any other barbecues after that. Okay, so let’s talk broadly a little bit about this. What are some common symptoms of technical debt itself? What is an org feeling from that?

Marc Braga:

So from a salesperson’s perspective especially, you might see you’re getting, let’s say, complaints about the user experience or you’re getting performance issues. You’re hitting governor limits, that sort of thing. Let’s say you have an abnormal amount of admin support requests, and that’s telling you that either something wasn’t built correctly to meet the use case or the business need or the requirements that really needed for that process. And so, those are typically indicators that it’s either poorly designed or the quality of the code or the quality of the implementation is not where it needs to be.

Josh Birk:

What are some specific strategies for combating technical debt once it’s actually in the organization itself?

Marc Braga:

Yeah, so first and foremost, just be real about the fact that it exists, identify it, document it, have a plan to clean it up. So like I said, dedicating a sprint or dedicating storage within a sprint to plan to clean that technical debt up, and then have ways to avoid it. And so, ways that you can avoid it are establishing and enforcing a strong governance model between IT and business, so everybody has skin in the game and they’re aligned on the objectives. Meaning that like the situation we talked about when you can identify it, if there’s a ton of admin requests in the process and when the user experience isn’t meeting the need, ensuring that those objectives are being met earlier.

Josh Birk:

Got it.

Marc Braga:

Also that governance board, we said identify and document. Because it’s one thing to say, “Okay, we know we’re doing this.” And then to your point, a new team rolls in or a different consultant firm comes on, and it’s lost.

Josh Birk:

Right.

Marc Braga:

And so first and foremost would be documenting the technical debt that you’re aware of. And then as part of that governance model, doing periodic reviews of when you’re going to clean it out and periodic reviews to avoid any further build-up of technical debt.

Marc Braga:

And then the other thing you can do is do an app rationalization exercise, and understand whether it’s a better decision to buy it versus build it. It’s often in most cases buying instead of building is less expensive and easier to maintain in the long run, and you’re not incurring technical debt that you might have if you were to build it. And so that’s an option. And of course, we have the app exchange for a lot of those types of situations.

Marc Braga:

And then make your architecture and your designs modular, focus on connected systems and system-oriented architecture, so that you’re planning accordingly with your engineers about when you can retire certain elements of technical debt that you might have planned in, and you can do it in a way that doesn’t impact the entire system.

Josh Birk:

Got you. And that’s our show. Now, before we go, I did ask Marc about his favorite nontechnical hobby, and there seems to be a growing trend within the pod episodes. And in fact, one of the things that he really likes to do is just going outside.

Marc Braga:

So anything on the water, outside with my kids.

Josh Birk:

Nice.

Marc Braga:

I do a lot of boating, do a lot of boating, a lot of tubing, fishing, and paddle boarding. So anything I can get the kids out of the house, outside, especially on the water, that’s a blast.

Josh Birk:

Nice. The wife and I are really trying to get our kayaks out on the water whenever they open up the beaches. But one nice thing about a boat, it is pretty easy to do social distancing.

Marc Braga:

That’s true. And I didn’t buy a boat, I joined a boat club. So I avoided all the maintenance and storage of a boat.

Josh Birk:

Wise.

Marc Braga:

Yeah. Luckily, they kept that open. So it was social distancing, and then I can avoid all the other responsibilities that come with a boat.

Josh Birk:

I want to thank Marc for the great conversation. Of course, I want to thank you for listening. If you want to learn more about the podcast, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast service.

Josh Birk:

And once again, remember, we would love to know your opinions about the Salesforce Developer Podcast, so head on over to our social media feeds, especially our Twitter account @SalesforceDevs for a survey. Thanks again for listening, and I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.