This week our guest on the podcast is Steven Herod is a Certified Technical Architect and Managing Director at Accenture where he is responsible for Global Salesforce Operations. In this episode, Steven shares some distinctions between being a developer and an architect and some of the roles that architects play in creating successful applications and strategies used to get across the finish line. Additionally, together we talk about the term architect and how it has gained momentum within the Salesforce ecosystem.
Show Highlights:
- Steven explains how architecture is like an onion
- Areas of Responsibility, including the ability to understand and create system boundaries and how it fits into the layered concept of what an architect is and does
- How the architect works within a team, plus the architect and developer relationship, how to be on the same team and work together in a positive environment
Resources:
Shout Outs:
Episode Transcript
Steven: I’ve been working in the Salesforce ecosystem now for nine years. I’ve been a certified technical architect and Salesforce since 2012 13, depending on exactly when you count..
Josh: That’s Steven Herod, a managing director at Accenture who is responsible for their global Salesforce operations. My name is Josh Burke and a developer evangelist at Salesforce. And here on the Salesforce developer podcast, you’ll hear insights and stories from developers for developers. Today on the podcast, we talked to Steven about some distinctions between being a developer and an architect and some of the roles that architects play in creating successful applications. And we started off by talking about how the term architect started to become more popular within the Salesforce ecosystem. I
Steven: think there’s an element of Salesforce growing up I mean, architects always loomed over me. You know, when I was working at an insurance company, I had a boss who would definitely have described himself as a software architect. He was a Sun Microsystems. And, you know, he taught me a lot about data modeling and the value data modeling and, and and was very much that kind of, you know, thinker and we’d have lots of esoteric conversations about ways of doing things and, and architectural conversations. But I got that role, you know, starting off in the company as a solution designer, and then really was identified, I think, by by, you know, him and others as being someone who would be appropriate to be an architect on the basis of the way I talked and thought about things in terms of its popularization. Now, I think there’s always a there’s an ambition push that that says that everyone wants to, you know, be the next thing up So you see a lot of you see a lot of that just in terms of all kinds of job titles, you know, as as why I appreciate myself somewhat when I say, I was the CTO of an organization. You know, I could say that I was a CTO Chief Technology Officer. Yeah, right. Okay. But we had 19 employees. Right. Right. Like we did, we did, you know, in business to business messaging for, for, you know, invoice presentation, it’s, yes, I was a CTO. It’s not quite the same. It’s the same thing to have, you know, you know, a major corporation or something like that. So it’s, it’s all relative, and I think, you know, I’m, I think it’s okay. During the week, I mean, I wasn’t called an architect until I got a business card that said it architect and someone else gave me the title. I didn’t know that until someone gave me
02:55
Josh: Is it kinda like you can’t give yourself a nickname.
02:58
Steven: Yeah, something like that. much.
03:04
Josh: Okay, so I want to I want to pick up on a few of the themes from your previous presentations, blog posts, for instance, can you describe to me how architecture is like an onion?
03:17
Steven: I gotta remember what I said now, I’m like, well, it was like it was it was the quoting Shrek, because that was a heavy, heavy presentation that one so it’s layers and layers and layers. I think there’s a couple of formalized approaches to architecture that talk about the concept of perspectives. And and, you know, an architecture is is a general term, but you could look at things from, you know, a software and application architecture or systems architecture or an integration architecture and, like, there’s all different perspectives, you can look at business architecture is a real thing, and how business areas work together. So, you know, there’s lots of different angles on it, and there’s all sorts of different levels as well. Enterprise Architecture is, is quite a different thing to software application architecture. Some of the principles might be the same, but but the forces at work obviously, quite different.
04:16
So, you know, it’s a, it’s a many layered thing. And sometimes the way to think about things was, you know, that, you know, if you’veever seen one of those, like, slide packs of the human body where, you know, there’s seven slides and as you peel back each slide, you see a deeper and deeper into the person, then then that’s really, you know, a way to look at architecture from a life perspective. So, I think that’s, that’s, that’s an interesting way to do it, because it also gives you ways of thinking about problems that that claim every time you do it, because this is what it is I have with templates that you build, you know, I love templates, and then I use them and find all This one isn’t quite, you know, it’s not, it’s not focusing on on the thing I need to say, right? Because it’s coming at it from a slightly different perspective. And you know, I don’t want to just say redundant things. There’s, there’s things I need to say, and the template isn’t covering it. So I need to cover it from this perspective.
05:20
Does that answer your question?
05:23
Josh: that it does, and to kind of segue into that – you define a term areas of responsibility in your talks. And so give me the elevator pitch on an on an area of responsibility? And how does that kind of fit into that layered concept of what an architecture is, or what an architect is?
05:45
Steven: Well, one thing that’s really important about systems design is really around boundaries, right? And understanding where one thing ends and another thing begins because what crosses over a boundary is really important right? and not having clear boundaries and not having clear understanding of the information transfer between the two boundaries is a leading cause of confusion and solutions, right. So, so messy noisy boundaries or boundaries that are inconsistent result in systems that have been written and unreliable. So, when you talk about an area of concern, it’s really that within my area that I’ve defined with its boundaries I control of of the design and the understanding and then I have a clear interface to another system. So for most self fix, you know, their architecture stops begins and ends at the age of the Salesforce API’s. And they design what they designed within the Salesforce platform. And then they’ll say to some of our you need to, you know, use these API’s to communicate to me and you need to give me Your API’s not communicate to you. And that’s where things like, you know, handing over your enterprise wisdom to a third party to have unfettered access to your Salesforce data, right nice for them to do anything they feel like at any point in time gives me the screaming.
07:18
Josh: Because that’s a that’s a that’s a really unclear system boundary, right? And you’ve basically said, you know, to the other party, well, you can do anything you like, anytime you like, and I’ll just try and figure out what happened. And that’s and that’s really, really terrifying.
Steven: Particularly when they don’t understand the unintended consequences of multi object transactions, right? You’ve got different transactions for every object you touch. So yeah, when I say areas, an area is arbitrary, right? You just, you just want it relative. So one thing I don’t think that’s popular enough and Salesforce is the concept within Salesforce world of application by…
08:02
Josh: because the application means so many things in Salesforce
08:06
Steven: …collection of tabs is generally you know that the thing and and that’s a UI concept it’s not actually a system structure right? So you know within a Salesforce org you really have to think about applications as a you know, the collection of objects and automations and all those things are related to it. And then that leads and things like your application packaging and so on. So you know, it doesn’t really matter your area you just need to know what it was and know that you’re working with it and have other parties who were engaging with you understand that they have boundaries with it boundaries began in.
08:45
Josh: which I assume factors heavily into things like packaging and CI and, you know, you have these rotating cogs that are sort of working together.
08:53
Steven: It does and, you know, that’s where you get some confusion because you know, Salesforce is very object centric, everything right and title effectively. But, you know, when your deal or dealing with the account object Well, you know,
09:11
Josh: okay, so that’s uncanny because I was actually just thinking to myself, if it doesn’t touch the account object, is it really a Salesforce application?
09:21
Steven: Well, yeah, it doesn’t I mean, I, you know, we’re drawing circles that basically say, you know, here your three custom objects do what you like with them, but touching the case object, your own peril.
09:34
And, and, you know, you have to come through a governance approach and justify your existence for wanting to touch the case. Because, you know, the five core objects in Salesforce are the most heavily trafficked freeways in Salesforce, and, and you’ve got to protect them.
09:51
Josh: Right. So let’s talk distinctions about developers and architects. I’m gonna, I’m gonna throw the first one out there because I’m a fan of video games. I’m also a fan of beer. Not sure you had a very visual way of showing that. So if it doesn’t translate well, we’ll go to another analogy. But how would you describe the difference between a developer and an architect as you would put it in beer term?
10:13
Steven: Well, that the that that slide says, you know, that, that of a developer is one be that an architect must be a room full of beers, right? It’s just more beers. And, and, and I’m like, no, it’s, it’s not like that. It’s not just more of something. It’s a change in perspective. And an architect doesn’t think of, you know, beers is and then knowing that more beer they say, will be as a mechanism for passing out alcohol. And alcohol results in a sense of social relaxation. And I seek the sense of social relaxation. So what’s the approach that I want to do give it that although I might have a bourbon so it’s that kind of kind of approach to it. Or you know, it’s seeing past the thing and seeing what the intent was behind it. And then finding out other ways to do it. The other analogy was the car right, which, mechanic saying that the two cars are completely different from their perspective, there’s no parts that are the same, there’s no, they don’t even have the same fuel systems. But, but an architect will say, well, they carry seven people in like, Oh, 600 kilometers or 400 miles, the Americans.
11:31
So it’s, it’s basically the same thing, right? And that’s, that’s the intent that you’re sort of getting at behind the scenes who what’s the consequences of that choice? What things can I now do that I couldn’t do before what things have I limited my choices for but making that choice, and, and, and so on and so forth. So to me, it’s very much a perspective change.
11:55
Josh: It sounds like it’s a lot more or a lot less about the nouns and more about the functions and the nouns and how those functions in or interact with other nouns.
12:04
Steven: Yeah, yeah, it’s it’s the, it’s the interactions of the system and the consequences of those choices that I think are very important. Right. So and that’s, that’s the, I think, one of the differences that comes up. I think the other thing that gets people forget, or some people are attracted to from the architect, and certainly, you know, I remember working with a guy, I’ve worked with a few guys in my past, who would have used being an architect as being the opportunity for them to basically beat anybody else over the head with their idea and dominate the conversation. But that, that, I think is a lot less popular than it used to be. And and now it’s as much about persuasion and you’ve got a it’s not an there’s no such thing I’ve learned through experiences that it doesn’t matter if you’re right.
13:01
Because if you can’t convince people of the consequences of both of your choice over another choice, and often a lot of why you chose to be right turn out to be wrong later because of a change in circumstances. And you can’t cater for that. All you can say is that you made sure you covered yourself at the time the choices were made, that they were the appropriate choices. That’s why they said yeah, every everything you do is wrong, just not yet.
13:35
Josh: So let’s let’s dig into a couple of those key points. Because that whole you know, the idea of an architect being the guy who can kind of use the bully method to to get a design done, obviously feels like kind of the wrong path. How, how do you think an architect and a developer should be integrated into the same team like what’s a what’s a good positive relationship between the two roles?
14:01
Well, I’ve got a friend slash acquaintance called Johnny, who I quoted, and he’s got a wonderful blog, and in which talks about this, and really the joy, the purpose of an architect is to what a good architect should be with the team, right? And should be engaging with the team. And, and, and allowing the team to work on the details and understand the choices that the architect is suggesting. And to provide feedback to those choices, right. And, and for the architect to, to engage and, and fold the developers feedback and suggestions back into their overall design. Because the developers know what actually happens when you call the method, right. They know the consequences of the choices that you’re making and the behaviors that they’re saying. And they need to provide that information back to the architect and the architect needs to, to weigh that up in the context of their decision making.
15:09
And an example like I would give is that I worked somewhere where, you know, my boss, who was an architect architect would say, all you need to do all the class level diagrams for the developers, like, like actually naming all the classes, right? And showing the class diagrams of how it should work. And then the developer should just go write the code. And I always viewed like, That’s insane. I don’t know, man, I don’t know how to build in Eclipse a rich client platform application. Susan does she set up our main method picking doing that is a level of detail that I that I don’t have the knowledge of and is difficult. What I need to tell her is, you know, we want to keep these things separate from these things so that I can swap that out. And she was responds with, well, okay, this is how you would do that in this thing, I would use this kind of module approach. Right? And I’d go okay. And, you know, we would we would pass on the I would pass on the desires while we were trying to achieve and they would reply with how you would do it with that programming technology. And it was more of a symbiotic relationship, right? And I want a constant communication. So that that to me, I think is the model for work.
16:31
Josh: Does Salesforce, offer some unique challenges there given the multi tenancy given some of the just some of the core aspects of the platform like do you go to a developer and you’re like, this is the design, these are the separations. This is you know, this is kind of how we’re going to modularize everything and then the developers like that’s great except for governor limits.
16:52
Steven: I think everything you do in Salesforce is defined by what you can’t rush and the consequence of your choices. So, you know, we were discussing the old, you know, do I add fields to this object? Do I create a separate custom object? Or do I create a polymorphic object where basically I can feel to you in 10 fields to you and 10 coats to you, and but it’s all in one custom object case extension. And we were discussing that yesterday afternoon. And, you know, I’m very much one who makes a decision, you know, make a decision right in my head. Okay, what’s the consequences of that? Okay, what’s the consequences of that? What’s the consequences of that? of that? Oh, my God. Okay, let’s back up three steps, right, it might take a different path, and going down that path to see where we end up. And generally what you’ve now got is a series of trade offs. And you have to make a choice over given the circumstances and the nature of the problem which trade off is more or less appropriate, right. So yes, it is and then you look at the here with Salesforce you have to look at what’s controlled by the customers licensing versus what’s controlled by soft and hard limits. And you also, you know that the added complexity is you have to take into account all of what would other people think about this. So things like Salesforce health checks who have particular feelings about how things should or shouldn’t happen, will disagree with that choice, often without the context of the point of view that you were making that choice and, and, and so, you know, you have to have the appropriate justifications as to why you that went that way. So it is a very unique environment. And it is it’s, it’s, it’s one in which you can often you have two or three choices and you have to make, you know, the one with the consequences. That’s why I struggled so much with the right answer. When people say, you know, architecture isn’t about the right answer, it’s about the least wrong answer.
19:07
Josh: So well that’s interesting because it’s like you’re on one side, you’re kind of going through this almost Dr. strange going into the multiverse looking for, you know, the right set of actions that’s going to keep things successful and interest in the application over time. But then it also kind of sense sounds like as context changes, eventually, something’s going to go wrong. Like, how do you how do you balance it? So that architecture is providing that level of success and trust, but also kind of realized that as you as you say, your right answer is just one that’s not wrong yet.
19:43
Steven: That’s some of it, there is a certain element of it. Yeah, I suppose cover your ass in the sense of making sure your justification is well documented and trade offs and yeah, there’s a there’s a strong focus on Enterprise Architecture of making sure that this are recorded with the justification. And so that when they come into question later that the justification that’s understood that you know that you made an informed decision at the point in time that you made it.
20:12
I think there’s a someone on Twitter who I’ve never met by any know from Twitter um, she’s a software engineering architecture architect and she publishes some stuff on her tweet stream. That’s, that’s great. And, and I think it was a Grady Booch quote, something like architectures, the things that are hard to change in an application.
20:42
And so anything that’s difficult to change at a later date is architecture. Which is why I’m often you know, I really don’t care about a whole range of decisions because I don’t view those things as being difficult to change. Once we’ve made the choice on on this approach to contact models, I don’t really care about, you know, picklist values, all the method name and all that, because it’s, it’s not no one ever failed a project because, you know, the method names are wrong. It’s inconvenient. It’s annoying, it’s frustrating. But it’s not, it’s not going to result in a catastrophic failure. Right, which is what would happen if you, you know, try and use a single contact record for seven or eight different uses.
21:28
Josh: Right? Yeah. If you can’t talk to your data, you can get much done.
Steven: Yeah.
21:33
Josh: So through that process, how do you know when you’ve arrived to that least worst answer, like how do you know it’s time to put down the pencil and stop designing?
21:44
Steven: Mmm, good question. I mean, I spent a good proportion of the first part of my career actually worrying did I did I did I am i doing the right thing? And is this the right choice, right. And templates are a great way to give you that fear. You know, you’ll be at the template, am I supposed to know what this is? And you know, it’s just the right way to do it. I think for me, it’s have you have you encountered all the parties who might have an influence over this problem? And have you elicited from them the major forces that matter to them all the major challenges or restrictions that they have? And then on that basis, Do I have enough information to make the choice based on the constraints that I know the choice has, right? So for instance, if I say I’m going to use platform events to send a message to an off platform system, I need to know how many events I might send because of the limit on comet subscription right on 24 hour period. I need to know that the party on the other side has the ability to do a comet reception. I know that they need to have a firewall, the ability to manipulate their firewall to allow potentially these connections, I know that they need the ability to to deal with a choice in response, I need to know that they’ve got the basic capabilities. And I also need to know that there’s budget allocated to that team to make those changes, right. And a willingness on their part to make the changes because I am never, I am never surprised by by often a customers middleware team is unwillingness to ever change the middleware despite the persistent middleware to be that that layer and for you to have to accommodate different feel always working so those are the sorts of forces I would take into account for making the decision and that why you might pick a suboptimal solution like you know, call outs from Apex and have to build your own retry compensation layer using batch jobs and various other approaches, because of the party on the other side not doing anything else. And that’s a constraint that you have to document right? Because you’re never gonna convince the other party to, you know, transition to real time, middleware, you know, in the time frames and and the considerations that you have for the project you’re working on.
Josh: And that’s our show. No, before we go, I usually ask my guests what their favorite non technical hobbyists and Stephen actually gave me a couple answers. Normally I would, I would kind of pick one of the two. But honestly, in this case, it sounded like somebody needed to get a little credit.
24:32
Steven: I’ve learned to embrace as I still play video games, so I play Overwatch, with my wife with my wife and I have to comment that she carries me. So if I’m maybe play Overwatch, or I’m playing Dive, she’s usually Moira and keeping me alive. So if I’ve done well, then she’s always done, done better. So not out to Barb. Thank you for that and Is I build, I build model airplanes like scale model airplanes, which is something I used to do when I was I was a kid. And I’ve taken up now as an adult because it doesn’t involve me staring at a computer screen. And I find it peaceful and distracting.
25:16
Josh: So while I have you if the sound of Stephens voice seems a little familiar to you, it could be from his many presentations as appearances at Dreamforce. Or it might be from his own podcast, which I’d like to be able to give a shout out to…
25:28
Steven: Code coverage on, on on, you can look it up on the codecoverage.org and follow it on iTunes and Stitcher. I while away with Matt Lacy, my my friend from down under in Melbourne. It’s an infrequent podcast, I think we got two areas and then the introduction. It’s a fault not no longer for another podcast. And of course, it’s no longer about Salesforce one because the naming changed. So it’s whereas some people take podcasting professionally, we very much tend to get into a hobby so lucky to get three or four episodes out a year at the right we’re counting. But people seem to enjoy themselves..
26:07
Josh: So you know we while away at it if you’d like to listen to Matt and Stephen while away, we will put a link to that podcast in our episode notes. And if you would like to know more about this podcast, head on over to developer.salesforce.com/podcast where you can hear old episodes, and you’ll have links to your favorite podcast services. Thanks for listening. A huge thanks to Steven for a great conversation about the role of architects and I will talk to you next week.