Subscribe
Share
Share
Embed
CJ & The Duke discuss "The Slash Dilemma", "Hybrid Roles", "A Day in the Life of an Architect", "The Amish Stakeholder Metaphor", the Virtues of Architecture, essential skills, and operating in the grey areas.
Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk
Hey, everybody. Welcome to CJ and the Duke. My name is Robert DaDuke Fedorick, and I'm also joined by my cohost Corey CJ Wesley.
CJ:Hey, Robert. Good to be here with you today. I'm coming to you live from Hope Park, Illinois.
Duke:Representing three one two over here in Chicago, Illinois.
CJ:Nice. Three one two. That's what I'm talking about. It's old school.
Duke:Yeah. Alright. So why don't we tell people what this podcast is about?
CJ:Absolutely. So this podcast is about us spitballing our ideas about ServiceNow, bringing our vast experience with the platform and with the industry to bearing, maybe giving some folks the benefit of wisdom that we've gained over the years.
Duke:And tonight folks, we are going to be talking about ServiceNow architecture, and we'll probably be talking about that quite a bit over the series, but tonight especially we're gonna talk about what is a ServiceNow architect.
CJ:And what is not a ServiceNow architect.
Duke:Yeah, and this is super important because when you go out there in the wild and you're like looking for ServiceNow jobs or if you've been in the ServiceNow ecosystem long enough that the recruiters are getting to you, you see this all the time. Such and such a company wants an architectdeveloper, an architectadmin, an adminarchitect, a devarchitect, or any combinationarchitect. Corey and I call this the dilemma.
CJ:Yeah, absolutely. The dilemma is like Robert just said, right? Is that when the client comes to you and they want, you know, a little bit of everything, you know, a jack of all trades type, We want an architect, but that architect should really also be able to build a house for us. We be able to shine our shoes. We should be able to go into the CEO's office.
CJ:Right?
Duke:Shine our shoes. Me a sandwich, architect. Right.
CJ:Pseudo, make me a sandwich. Yeah. I mean, you know, I mean, I've I've seen it many, many times. Right? You get hired for an architect and they want you to do like literally everything under the sun.
CJ:And they don't quite understand why that's a problem.
Duke:Right. So listen, Corey and I are pragmatists too. We realize that, you know, not everybody can afford two separate resources. Right? And so everybody's just trying to do the best with what they got, But push comes to shove, and an organization is saying you're an architect slash dev, when push comes to shove, which are you?
Duke:Because the differences between the two roles are actually distinct and meaningful. The way I like to think about is, what does each role try maximize, right? And so what does an architect maximize versus a dev?
CJ:Yeah, and I think that's a really key way of looking at it. When you think about maximization of the role, you think about what is the role best suited for in terms of alignment inside of this project, right? Are you the implementer? Are you the guy who's doing execution? Are you the gal that's doing the blueprints for the project and thinking about the platform and the project holistically?
CJ:Are you the person who's the caretaker, right? Are you coming through at the end of this and you're thinking about, Okay, this thing has been built. How do I make sure that it doesn't break on my watch? Ultimately, as an architect though, when you come in, you want to have more of a holistic viewpoint of everything that's going on. Right?
CJ:I think the developer is the guy who's going to look at things at a more of a of like a five, ten foot level. But as an architect, you're looking at it at a 50,000 foot level, right? And you're flying an airplane, you're looking at the map of the entire instance, the entire platform, and you're trying to guide the client through to the best possible outcome, not just this project, but setting them up for all future projects.
Duke:Right. And while it's conceivable that somebody could do all of that stuff in one day, I like to think about the difference in what are you on the hook for? A developer is going to be on the hook for delivery, We told you to deliver this, this, this one thing or the other. And did you do it in a robust way? Right?
Duke:Right. In an excellently developed way versus the architect is on the hook for the design. So you could basically, a developer can be put into a situation where it's bad design front to back, but they could still be a good developer. That design's not what they're on the hook for, but the develop the the architect is on the hook for the design itself. So if it's a bad solution, I'm sorry, That's architecture.
Duke:So you can see the kind of natural conflict arising there. Right?
CJ:Yeah, absolutely. I mean, I've I've joined projects before where the code was written beautifully, right? Like just beautiful code, commented very well, formatted so it was very human readable, you know, script include calls, like the whole nine yards, right? Beautiful, beautiful code, very, very maintainable and upgradable, right? But the solution itself was crap, right?
Duke:Yeah. You know,
CJ:we've got global business rules firing off, we've got rest calls that aren't formatted correctly, we've got static headers, We've got all kinds of crap. Right? And and and, you know, the developer is like, hey, look, I built this thing according to the way it's according to the way I was told. And when, you know, when I asked questions, they said this is the way to do it. So I did it.
CJ:Not that guy's fault. Think about it.
Duke:Yeah. So takeaway number one of the podcast. If you're in that position and people are saying, hey, we need a dev slash architect or an architect slash admin or whatever the slash may be, always ask on paper, which one am I? I can do both. I'm a pragmatist.
Duke:But which one on paper am I? Because when push comes to shove, like what happens when you have a conflict with yourself? Know, like when it comes yeah. Down to When it comes down to design versus delivery, which one gets the resources? Which one gets those extra hours, that extra day of time?
Duke:And if you're an architect, it's gotta be the design.
CJ:And that's why being clear with your client upfront, right? Like one of the soft skills that we'll talk about later, being clear with your client upfront and knowing what the requirements of the project are and the expectation setting, all of it is really key for successful project, right? And as an architect, that's one of the main things that has to guide you, right? Is that the success of the project, and that really starts with the requirements gathering.
Duke:Actually, all you recruiters out there that might be listening, this is a great thing to make sure that you look like you know what you're doing in front of the customer. Is when they tell you, Hey, we need a devarchitect. If you can be a beachhead to that conversation and say, hey, listen, dev and architects are different things. So on paper, which one do you really mean? You look like you're a more credible provider of the resource.
CJ:And when you think about it too, as the recruiter, you you not only do you want to be credible, but you also want to be credit to be credible for your reputation, but you want to be credible credit creditable for your rates, Right? And for the rates of the person that you're actually trying to sub into the Right. To the position and for the success, right, of the project. Because when you if someone comes to you and I've had this happen before, and this is a little brief segue. Right?
CJ:But if someone comes to you and they say, hey, we got this project, we need a guy who's got, you know, ten years of IT experience, ten years of ServiceNow experience, they need to know orchestration, they need to know integrations, they need to know JDBC, they need to be great with data architecture and oh, by the way, we're gonna pay them $70 an hour and we need them to do all the development and architecture, Like as a recruiter, that rec should never come off your desk, right? That client should never be a client or the client should never should have the understanding that there's no way you can fill that role with a resource who can do that job. That's just plain and simple.
Duke:Kind of a short tangent to that, Corey, but do you do you find that there's a different posture and experience with the customer if you're coming in as an architect versus a developer?
CJ:Absolutely. When you come in as an architect, I feel like the client is more inclined to listen to your views on practically everything ServiceNow. And that's a good thing if you know what you're talking about. I find that the client is more willing to defer to you. They're more willing to listen to your suggestions on if things need to be rebuilt or redone, or if there's a difference in opinion, they are more likely to defer to yours because they consider you an expert on architecture.
CJ:Right. If you come in as a developer on the other hand, right, you get a little bit more pushback, right? You get the, well, we had an architect look at this and this is what they recommended.
Duke:Yeah, or our BAs, our BAs said this. Right. Right, yeah.
CJ:And our, and our, you know, and our, yeah, our business unit really, really emphasized that these are their requirements. So we just really need you to build it. And, you know, so you're not taking this seriously, you know, there's a gravitas that's associated with the word architect.
Duke:Oh, gravitas. That's exactly gravitas. I love that word, man. That's I'm gonna borrow that. Alright.
Duke:So that's the slash dilemma, ladies and gentlemen. So we know we know reality is reality and sometimes you're just, you're gonna fill two roles. But you gotta find out what the dominant role is. So take that advice and, and go out there and slay. We're gonna transition right now into what are the kinds of things an architect does.
Duke:Sometimes there's this perception that an architect is just a senior developer. Sometimes there's a perception an architect is a senior BA and or maybe even a prog program manager of some sort. So let's talk about some of the things an architect actually does for a ServiceNow instance.
CJ:So an architect, you know, in in my opinion, is starts off as kind of like the caretaker of the instance, right? And you can think of the instance as the ServiceNow program. And so why I say as the ServiceNow program, because the instance is not just the technical parts of the instance. You have to take a step back and call the instance also stakeholders of that instance. So it's gonna be, you know, it's owned by IT, it's gonna be your IT stakeholder who's typically like the IT director.
CJ:But then it's not, it doesn't just stop there, right? Like it's his boss too, who's in the line of business, who's spending money on this thing and wants to see some kind of business value return. So when you think about like what does an architect do, the architect is the caretaker of the instance and the platform and the program. Their main responsibility is for the development of that program, the continuous development of that program, and pulling out and extracting as much value from that program to return to business as possible. As technologists, we often forget about value for the business.
CJ:Let me tell you, you cannot forget about value for the business. Right? Value for the business is paramount. This is the one thing that will continue to get you jobs. Yeah.
CJ:As as an architect, that is that has to be the primary thing on your mind when you get dropped into any situation. How can I turn this instance into value for the business?
Duke:My take is as being a protector of present and future. And so in the protection of the present, there's this concept of ensuring that the stakeholders now don't impede the stakeholders of the future. Right? We see this in products like ITBM. Often it was the case that the first group that does any kind of project management, the first group that deployed ITBM would customize it so much that it was completely useless to other ITBM types of users.
Duke:Right? And things are a lot better now that they have team spaces, but back in the day, you know, and and in general
CJ:It's like any incident problem. Right?
Duke:Yeah. In general, the first, the first team to get to a process dictates what that process looks, acts and feels like. And as an architect, your posture has to be one of, hey, listen, a bunch of different political entities might also be interested in this process. And so you can't customize it to the point where it is a perfectly tailored suit to one political entity. Alright?
Duke:So that's the present. And in terms of the future, I like to think of it as who's gonna be the eyes on for what's coming down the pipe. A perfect example, this is in New York version of ServiceNow. There's this awesome new feature called ITSM roles. And what it does is it allows you to make different roles for the different processes in ITIL.
Duke:So you can have people that do exclusively and only incident management and people who do exclusively and only request management. It's a twelve year old problem. It's immediately applicable to every instance in the entire universe. But who's responsible for gleaning that kind of intel and bringing it back to the customers so that they can leverage it? You for damn sure don't want to wait for them to discover it because they're not on docs every day reading this stuff or in community reading this stuff.
Duke:They're just doing the rest of their day job. So it's the architecture who has could be like the present and the future eyes on.
CJ:Yeah, absolutely. Right. When you think about it from the customer standpoint, the customer doesn't care, right? They just want their value, right? They don't care about the value of the whole.
CJ:They care about the value of the part, right? And so as long as they're getting what they want out of the part, the value of the whole can go jump in the lake, right? Like it is really all about me, me, me, me, me. You have to think about it that your stakeholders are typically selfish, right? But the architect can't be selfish.
CJ:The architect has to be the person who is in the center, who is deciding what departments, who is basically trying to ensure equity for everyone, right? Or equity as defined by your chief stakeholder, which is the guy who signed in the checks ultimately.
Duke:Yeah. We just talked about the slash dilemma. Right? But I always like to think about architects as sharing at least some of the domain of like, there's architects that lean program manager. There's architects that lean developer.
Duke:There's architects that lean VA. But I think you have something really like pertinent to say about the architects that lean BA because you know, the architects have got to be able to extract information from the customer.
CJ:So yeah, absolutely. So as an architect, right, you know, when you come in, you have to be able to extract the requirements from the client. Typically, your client doesn't actually know how to tell you what they want. They tell you what they want from the standpoint of what they understand and what they know. That's not always ServiceNow.
CJ:Typically that's not even always technology, that might even not even be the business. Sometimes you're expected to come in as an architect and learn their business and know it better than they do, learn the technology in their instance and know it better than they do and tease from them what they're actually trying to accomplish. You know an architect with that skill set, let me tell you, can go to bed and wake up on a pile of money every day. Nice. But it's true, right?
CJ:Because clients don't always know what they want. They know what they've been told to ask for. But if they don't understand that a menu for example might have four pages and they're only looking at the first page, they might miss the fact that we actually serve breakfast and they want what they wanted was bacon.
Duke:Should I give them the Amish metaphor?
CJ:Let's go for it.
Duke:The US has a population of people called the Amish and they are of Germanic descent. They've been in The US for as long as The US has been around, but they basically mindfully stopped their technological progress, and they mindfully and purposely live a life in a pre industrial fashion. So there's various parts of Pennsylvania you go to where you're going down a street and you'll see like people in horse drawn carriages. And that's the Amish, and they live kind of like a simple technology free farming life. Now, if you asked just a regular old Amish dude, hey, how are we going to get from Amishville, Pennsylvania to New York?
Duke:They're gonna describe the world to you in a way that you are completely surprised and it's not gonna make a whole lot of sense to you because he's gonna say, okay, to get to New York, we have to figure out where we're change our horses We're going to have to carry a wagon of this dimension so that we can pack all the dried goods that we're going to eat along the way. We're going have to figure out where we can make camp and yada yada yada. Getting from Pennsylvania to New York is really long and arduous and it's going to take us days. Meanwhile, you're over here thinking, dude, we're gonna go to the airport and we're gonna wait in line for fifteen minutes and then we're gonna board a plane and we're gonna go to New York. And in four hours between the idea of going to New York and now, we are going to be in New York.
CJ:Absolutely.
Duke:So you got to think about your customers as that way. They don't actually literally know what they want. They know kind of what they want and they'll describe it in a context that only they have exposure to. And it is the gift of the architect to be able to reconcile that with what's possible.
CJ:Yeah, absolutely. Right. Like if your client is describing to you project management but they're telling you that it's incident management, it's your job as the architect to correct them.
Duke:Ding. You
CJ:do not want to be that guy who creates a situation where I come in and someone's built a custom app in the resource table.
Duke:Oh Jesus. Yeah. Like, so like big lesson, the last thing on earth an architect is, is somebody who gives somebody whatever they want exactly the way they ask for it. You know a little bit about what an architect does, right? And what an architect is.
Duke:I want to talk a little bit about the virtues of architecture. This is a framework that Corey and I have worked on a little bit, and it's postures and virtues and higher order things that you want to adhere to, and it's going to make everything that you do in architecture a whole lot easier. You just think in terms of like maximizing these four things. And the four things are scalability, sustainability, modularity, and transferability. And it's a work in progress.
Duke:We're going to be adding and taking away from this all the time, but let's first talk about scalability. Corey, do you want
CJ:to take that? Yeah. I wanna take that one, man. I so wanna take that one. So, you know, when we talk about scalability, right, like, is the ability for your work to continue to work when you add things to it or add users to it or add people to it or add parts to it or add anything to it, right?
CJ:Like its code has to continue to work. Your platform has to continue to work. Your ServiceNow instance has to continue to work. You cannot build a solution where it works for five people. When you add the sixth, it breaks.
CJ:Right? Like you can't do that. One of the virtues and one of the first virtues of being an architect and doing and building out great architecture is building out solutions that work for one person, for five people, for 10 people, for 100 people so that the client does not have to call you back every month because they onboarded a new division or a new department. Right? That's rule number one.
CJ:Yep. Your solutions have to scale with the client's needs.
Duke:Yep. If you're looking at a solution and you're about to deploy it, it pays to think, is this going to fall apart if I multiply the usage by 10? Right. And things to look for is like anything manual. Oh, well, this doesn't work quite right.
Duke:So what we're gonna do is get an admin to come in once a week and quack, quack, quack, quack, quack. You know, okay, that might work if you have 10 stakeholders, but if you have a 100, forget about it. You're gonna need a full time admin.
CJ:Absolutely. It's a wrap.
Duke:Yeah. So scalability is about can you get 10 x the usage out of it for your for the design you have today? Can you facilitate new stakeholders? Yeah.
CJ:Right. Without it falling apart. Right? And look, you know, I've been guilty of this in my, you know, my earlier days. I built a solution that was a great solution.
CJ:It was run it was, we were pulling in alerts from an external source and, you know, it was running well. I made the mistake of making the, the the rest of the integration, synchronous instead asynchronous, right? Yeah. And so, you know, we were pulling in, I don't know, man, a lot of alerts per second, right? And it was going great.
CJ:And then we switched from the test environment to the prod environment. Yeah. And let me tell you that thing blew up. Wow. Yeah.
CJ:You know, so you I mean, you just got to think about it, right? Like you got to make sure that that that what you built is something that, you know, will actually stand the test of time.
Duke:Yeah. Standing the test of time bleeds into the next virtue. And I'll take this one. This is sustainability. So while scalability is, hey, can we get more and more stakeholders fit on this without falling apart?
Duke:Sustainability is, like how much does the solution cost us? And just think of this in terms of energy, right? Not necessarily time, not necessarily money, right? Just think about it in terms of energy. So if you have highly customized solution that's really, really, really refined for one team, that's gonna be harder and harder for you to sustain.
Duke:It's gonna cost you more effort on upgrades. It's gonna cost you more effort when new stakeholders come on. Right? So sustainability is how much extra does it cost you to support this going forward?
CJ:Right. And at what point is it now a conversation on whether or not we should rip this out and rebuild it?
Duke:Yeah. And any type of thing that like, this is where automation comes in handy, right? Because anywhere where you're Hey, somebody's going to run this report and then manually look at those records, you're violating sustainability. Anywhere where it's just like you're doing some kind of funky, weird thing that an admin is going to have to check-in on once in a while, that's a violation of sustainability. So sustainability, you got to think about energy cost going forward.
CJ:Yeah. And you know why that's important? Because you're not going to have the same set of stakeholders or users that you started with. No. Right?
CJ:And and if you have to switch anything out and you will have to switch anything out when I'm in, what I mean by that is people, right, people will be swapped out. If your system is not sustainable, those new people won't know how to use it. I mean, that goes into a whole another conversation about training and documentation.
Duke:No. Seriously. No. Seriously. Like, it's not a whole different conversation.
Duke:That's the conversation.
CJ:It's this conversation.
Duke:Yeah. Like, let me tell you, man.
CJ:There's a, there's a,
Duke:there's a, can I say the F bomb? Go for it. No, there's an F bomb vendor out there who specializes in ITBM, who literally told me they don't do documentation because it's difficult, and they're deploying highly customized ITBM solutions with no documentation. So you know what that means? That means the day they leave, the day they leave, the incumbent resources start the process of back engineering.
Duke:Now tell me if that is F bomb, F bomb sustainable.
CJ:Not at all. Not at all. I mean, that that's nuts when you think about it. Yeah. I like that.
Duke:I'm looking at you ITBM vendor. You know who you are. Shame on you. Shame on you. Okay, sorry.
Duke:Next virtue.
CJ:Awesome. So modularity, right? So modularity is the ability to actually upgrade your system, right? Like they upgrade your platform, upgrade your solution, your instance, what have you, right? We're to take that a step back and we're just going to talk about the solution.
CJ:So modularity is the ability to upgrade the solution in place without having to rebuild the whole damn thing, right? So you want to build solutions where if you have to interface with several different parts of the platform, that if one area needs to be changed to facilitate a new requirement, you could do that without rebuilding the entire system, right? You don't want one giant business rule that's controlling like every aspect of your freaking solution, right? And then so what happens if all of a sudden that integration goes from a, you know, a SOAP integration to a REST integration? It's like, oh man, none of this is going to work.
CJ:We got to rebuild it. No, you can't have that, right? So you should be able to switch it out. There should be endpoints. The endpoints should be documented.
CJ:You should be able to take that little cube section out, right? Come in with a laser, draw, you know, square around it, cut it out, pull it, you know, go ahead and build that REST integration and tie it back into the endpoints, you know, of input and output and keep it moving. Right? You know, your idea the idea is that you want to be able to save your customer, your client time, money, trouble, you name it. Right?
CJ:Like, you you want them to think, oh man, this guy did a great job because when we upgraded, it only took one week instead of four.
Duke:I have a slightly different take on this. So when I think about modularity, I I think about, let's just be like the Zen Buddhist architect, right? Solutions are impermanent, okay? And, well, I'm a huge believer that ServiceNow is a great, fantastic long term home for my processes. Right?
Duke:They're just like the reality is either I will implement an improved process that's got nothing bug fat to do with my current process.
CJ:Okay. Or
Duke:I will outsource the process to a vendor or I will outsource it to a different app. That's just exquisite at doing that one tiny little thing.
CJ:All right.
Duke:Okay? And so when I'm thinking about a modular application, I am thinking that about something that is easy to replace. Either if it's a replacement with ServiceNow or outside of ServiceNow. And to be able to do that, something must be packaged in a module. So packaging is important here.
Duke:This is where you want to be super, super savvy on update sets and scopes, right? So scopes are super easy to like just package a solution in and I can turn it on and off right from the scope, right? But basically building something to be able to be easily replaced or disposed is a virtue in and of itself. And I packaged that under the modularity virtue.
CJ:Absolutely. Yeah. I could definitely see both, both takes on that. I think, you know, there there's definitely a lot of virtue in what you said and what I said too. Yeah.
CJ:So I think, you know, I think if we if we if we put both of those together, we can come come away with a really good picture of what modularity looks like. Mhmm. And, you know, yeah, I think we'll go from there.
Duke:That's why we got both of us on the podcast. Right?
CJ:Because Absolutely.
Duke:Yeah. Because you're not just the the the best source of ideas. Right? There's
CJ:I wouldn't say that now. I mean, look, I've been told, like, I've got the greatest ideas. Yeah.
Duke:I should've said you're not you're not the only one. Anyways, okay, fourth virtue, transferability and this kind of, we touched on this, maybe Robert went a little bit overboard in talking about that F bomb ITBM vendor, But transferability is a big one for me because I've been in this space for twelve years and I've been to, I haven't had that many customers, right? But even on my journey, I have been and left many customers. And what do people do in my absence? Do you think I just leave them high and dry and say, it's been fun.
Duke:See you.
CJ:Yeah, of course.
Duke:No, man. I totally don't do that. No. There's like, the trans the virtue of transferability is the same virtue that CEOs use when they have those succession plans. So the transferity transferability virtue is a succession plan for your interest instance.
Duke:Not every dev is gonna be there forever. Not every architect is gonna be there forever, especially in a red hot bull market, where you can just walk anywhere and say, hey, I'm here to do your ServiceNow stuff, and people will hire you. So transferability means you're gonna have to have a set of physical documented artifacts so that you can transfer the essence of what this instance is to a new resource. And so we're talking about memorializing all your system knowledge, an executive summary of your major features, ingress documents, developer standards, vendor standards. This stuff all matters.
Duke:And the more transferable your ServiceNow instance knowledge is, the more scalable and sustainable and modular the architecture will be. It's an underpinning of the underpinning.
CJ:Yeah. I mean, you know, basically what you just said. You know, I don't have a whole lot to add on that. I think I think what you said was was was really a perfect way to talk about, you know, transferability. It's really about all the things that you don't wanna do, but you need to do anyway.
Duke:Right. So those are the those are the virtues of architecture and stay tuned. Gonna be coming back and visiting those in-depth, maybe even changing it up a little bit. So those are the virtues. Let's talk about skills an architect needs to have.
CJ:Oh, man. This is where I love here.
Duke:Yeah. Launch it
CJ:off for you. Yeah, let's talk about soft skills, right? Because nobody ever talks about soft skills and soft skills are really important. Soft skills are the separating feature, right, between a great architect and okay architect and maybe even a bad architect, right? You you can walk into any room or any virtual room or any video conference, right?
CJ:And you start to talk to the client. The client is going to start to grade you immediately based on how you speak to them, based on how well that they perceive that you understand business, not necessarily their business, but business in general. Doesn't mean you need an accounting degree. Doesn't mean you need to have gone to college for it. Just means that you need logic.
CJ:It means you need to understand value creation. It means that you need to be able to convey that to the client, right? It means that when you sit down with the client, you need to be personable, right? Like these are things that the client is looking for, right? When you're an architect, right, you're an expert, right?
CJ:That's the thing about it. We're going say that word again, ex expert, right? Like as a developer, you could be, you know, a guy who does an execution task, like who executes a task. But as an architect, they expect you to be an expert. And as an expert, they expect you to be able to speak well to them, to their stakeholders, and even to their bosses, right?
CJ:You need to convey professionalism at all times. You also need to convey your expertise, right? So if you can't do any of that as an architect, you're not gonna have it as successful of a career as you would. And I won't say you won't have success, right? Because the market in ServiceNow is like Robert said, red hot bull market, right?
CJ:You'll likely get success, but you'll get more success, better rates, better satisfaction, better execution, more client retention, all of those good things that you like to hear when you're looking at, you know, you're trying to land your next client, all of those things that you really want to have happen don't happen unless you have those soft skills. Right? This is a business ultimately, and you need to know that side.
Duke:No kidding, man. And and like soft skills are people skills. Right? And, the architect is gonna be dealing with people all the time. And when they're dealing with design, like they're on the hook for design, but everybody wants a piece of design.
Duke:So that soft skills are gonna be what makes the architect rise above all those challenges.
CJ:I'm I'm sorry. Go ahead. I didn't mean to cut you off.
Duke:I was gonna lean into the soft skills a bit and talk about storytelling.
CJ:Oh, yeah. Yeah. Yeah. That's great.
Duke:Like, need to have the whole range of soft skills. Right? But a really key skill is storytelling. You must be able to tell a story that motivates people, that it compels them to listen, where they can imagine them being in the shoes of whatever character you're portraying. Right?
Duke:But storytelling is the secret sauce for getting people to buy into your design rather than theirs. Why is that important? Go back to the Amish principle, right? They're only gonna describe things in reality that they know, but they're still gonna be loyal to that interpretation. Your storytelling is gonna be what garners
CJ:the trust. Right? Abso freaking lutely. Yeah.
Duke:Absolutely. Hey, look. Listen. Hey, I have won. Sorry, my teams have won four hackathons.
Duke:What do you think I did in those hackathons? Do you think I was a developer? No, dude. I took like six hours to do nothing but craft a story. And then they deployed me in the last five minutes to talk to the judges and the crowd at hand and the voters.
Duke:And I just all I did was to quote unquote, all I did was tell a story. That's the reason why we won is we took the development and we've wrapped a story around it.
CJ:Man, let me tell you, you don't get the job unless you can tell a story, right? Nobody is hiring you first. Nobody's saying, go build this thing for me and then I'll decide whether or not I'm going to hire you. Right? They're going say, talk to me first and then I'll decide if you get to build a thing.
Duke:Like How do you get somebody who is definitively against you to be with you? Yes. Storytelling. That's it.
CJ:Yes. Absolutely. You cannot undervalue it.
Duke:Alright man, but there's more skills than that. Hit them up with the next one Corey.
CJ:Yeah, so adaptation, right? So this one's important. This one's served me really, really well. So I probably, I might overvalue this one maybe a little bit more than most people do because it served me really well in my career, right? So as a professional problem right, is like one of the most important tools in my toolbox.
CJ:When I parachute into a job, right, typically I parachute into a job at well, I parachute into a job at all stages, right? It could be the start of it, could be the middle, it could be almost the end. I have to adapt to whatever's going on. But what's even more important to that is that, no battle plan, survives first contact, right? Some famous guy said that.
CJ:I can't remember which general. But the ServiceNow project is the same. Everyone sits down and we all talk about and great how this project's going to go well, and this is what we're going do and yada yada yada, everybody's smiling and everything. And then you start doing development and all of a sudden you're a week behind and the client's piss. And all of a sudden you realize that you might've under scoped everything, or you can't necessarily pull off what you thought you could pull off, blah blah blah.
CJ:Right? But you're at an impasse. Right? Now you gotta figure out what the hell you're gonna do. Right?
CJ:That's where adaptation comes in. Right? The flexibility to to run into that roadblock and work around it, work over it, work under it, whatever you need to do to get to that finish line so that you can have a successful project at the end, right? Failure is not an option because we're talking about money here, right? And so, you know, we always gotta bring it back to that, right?
CJ:The client isn't hiring you for fun, right? They're paying you to come in and give them value. So if you can adapt around failure and that failure is sometimes going to come in unexpected places, that failure is often going to be the fault of your client, you know, with bad requirements or changes scope or whatever that you might have to accommodate, right? If you can't adapt to that situation and succeed despite it, you cannot succeed as an architect.
Duke:Is this where we hit them with the principle of the least worst?
CJ:Yeah, man. Yeah. Is this So you
Duke:Go ahead. You hit them with it.
CJ:Alright. So, you know, when we when we're talking about the least worst thing, right, sometimes you get into a position where, you know, you get hired for a job and the client has given you like, you know, roses and rainbows and you come in and you realize that they lied their ass off. And you're in this situation and like I said, they've built a custom map on the resource table and they're like, we want to expand this to seven lines of business. And you're like, I thought I was writing six business rules and an inbound, email action. And it's like, you know, so what do you do?
CJ:Right? So sometimes you just have to go with the least worst option, right? The best option in this case is to recommend to the client that they build a custom app, that they scrap everything that they've done, right? And do it the right way because it's going to be for all the virtues of architecture that we talked about previously, right? Client is not always going to like that, right?
CJ:You know why? Because it's going to cost them a lot of money, right? And as we talked about, know, so what do you do? Well, You get sometimes you pragmatist, gotta take a yep. Right, you'd be a pragmatist and, you know, Robert, go ahead and talk to him about being a pragmatist.
Duke:Pragmatism is reality. And so sometimes you, like you don't get these ideal situations. You get a choice between three or four or five non ideal situations.
CJ:Right.
Duke:And you're going to have to figure out what's the least worst of those. But what do you use as criteria to figure out the least worst? And that's where I'm going say that the skills of the architect means a definitive, strong background in going wide on ServiceNow. You cannot escape platform experience. Don't nobody come into the ServiceNow space with no ServiceNow deployment experience thinking they're going to be an architect.
Duke:Don't no admin think, oh, I'm going to do a year or two an admin, I'm to be an architect. Does not work that way. You must pay your dues. You must actually work hard to find ways to pay your dues to be the architect level of experience. And so this is going to mean experience in multiple process areas of ServiceNow, it's going to mean development of custom apps, and it's going to be a very high degree of utilization on both reporting and performance analytics, so you can extract the value out of whatever process you're talking about at the time.
Duke:But there is no substitute for build experience on the platform. You must, you must get yourself in harm's way. Get in those trenches, fight the hard battles, right? And with that experience, that's when you can, that's what's gonna give you the capability of adaptation. And Corey, you've got a great, a great story about this, right?
Duke:Because I'm going to just warm it up for you that once you get that significant platform experience, that allows you to operate in the gray areas, yeah?
CJ:All right, so yeah, so what you have to do, right, is in terms of learning the gray areas and learning and being an effective architect who can actually leverage that platform experience is that you got to learn the rules before you can break them, right? So I tell this to my son all the time. We're talking about English and grammar and those sorts of things. And you know, he's wondering why he can't put, you know, in a sentence in a certain way or why it has to be punctuation and this, that and the other. And you know, I told him that, look, you have to learn these rules before you can break them.
CJ:You got to know what your teacher's looking for, you got to know what the language expects, you got to know the mechanics before then you know how to actually break them in a way that's creative, right? Like, you know, poets do this all the time too, right? Poets, you know, will take the English language and they will break it and twist it all kinds of way. Rap is a very good, example of that. Jay Z has a line where he says, you know, I pronounce, words that I pronounce the web, like something around words that, you know, aren't pronounced the same way in Webster's dictionary or something like that, right?
CJ:Like how he takes words and he breaks them up in the syllables and such and whatever, just bend to the rules of language, right, to make them work for at his beck and call. Right? It's the same thing in architecture, right? If you don't know ServiceNow, then you don't know how you can actually break the rules of the platform in order to make it work for your solution, right? So I've talked about, you know, building a custom app and a resource table, but there instances where I have co opted pieces of ServiceNow that have already been built and built the pseudo app using the out of the box stuff, right?
CJ:Tying them together with, you know, a few business rules here or client scripts there, they kind of turn, you know, something that's out of the box into something that behaves a lot more like a custom app, even though, right, it's not in the scope, it's not an official custom app. Because you learn the rules of the platform, you're able to bend and break them and make them, you know, work for your specific use case without breaking the platform. You know, so it is those things right there that, you know, that you get with experience. And if you and and they're easy to to tease out when you don't have that experience, you know, if I'm the guy that's following you.
Duke:Alright, folks. That is the end of our time here. Thank you so much for listening. We have covered in this podcast the slash dilemma, things that architects do day to day, the virtues of architecture, skills that you will need as an architect. Stay tuned.
Duke:We'll have way more ServiceNow architecture talks. I am Robert The Duke Fedorick, and this is CJ
CJ:and The Duke.
Duke:Alright. Thanks for listening,
CJ:Take care. Goodbye.