DUKE: All right.
And what are we talking about today, Corey?
CJ: All right, Duke.
Today, we're going to talk about the evolution of the architect.
DUKE: Yeah, actually kind of neat that we're almost at episode 100
and we're going to talk about this and our first episode was , what
is the ServiceNow Architect?
So almost perfect timing.
CJ: Yeah, I know.
Right.
Like things all are like times a flat circle, right?
Everything comes back around and we're now we're, back here talking
about, service now architecture and being a service now architect.
And I mean, I think a lot has changed since that first episode, Duke.
DUKE: Yeah.
CJ: Like, I mean, the ecosystem isn't the same at all.
There's things out there like generative AI.
Right.
And we're not going to touch a whole lot on that in this episode.
I don't think when you never know with us, right?
Like organically things pop up.
DUKE: I mean, we probably could, but okay, with the gen AI
thing, I think there's a lot of.
I don't want to say hype, right?
Because I haven't seen it enough to gauge its power, but I think there's so much
general hype about AI in like the whole tech industry that I think people are
thinking that AI is going to take more and more and more of the architect's
work, like get the AI to do it, right?
Get the AI to do what though?
CJ: Yeah.
Well, we'll get the AI to do what, but also what.
Is available for us to do that.
We aren't doing right now because we're doing things that the
AI might be capable of doing.
when I think about technology over time, right.
There's more work always gets created by more technology.
Right.
And.
Throughout the history of mankind, right?
Whenever a new technological advancement happens, right?
Like people always think that's it.
That's the end of work for humankind, right?
Never the case.
What ends up happening is that there's more work created, by what
that technology enabled, right?
I mean, you think about.
when people went from the horse to the car, there's an entire, I mean,
just so much work got created by just having the ability to drive
places instead of riding a horseback.
So I look at Jenny, Jenny, I, it's kind of like the same thing, now that Jenny, I
is there and we'll be able to do certain things that we don't really know, like to
what extent is ever going to evolve, but.
now that Jenny, I can write my code comments, for example, right?
Like I can focus a little bit more on some other things that, don't take as
much time as writing code comments.
DUKE: I definitely get the code commenting.
we just had that whole gen a.
I episode, right?
I don't want to get to like, do the whole episode over again.
You know what I mean?
But to me, it's just I feel like there's a, at least on the developer
side, . There's this whole thing about, I mean, I know it's not everywhere,
but there's certainly a few people that tend to think, ah, well, like
Jenna, I could just do the dev for us.
CJ: Yeah.
DUKE: And it's just like, no, no, it's not going to happen or at least
not, in the foreseeable future anyway.
CJ: yeah.
Right.
Like I'm not expecting that to happen anytime soon.
I think we're a long way from that to be quite honest.
I do think though.
Gen AI can be a great teacher,
DUKE: Yeah,
CJ: and I think if you look at it from that perspective, you can get
a whole lot of value out of it.
DUKE: Okay.
So maybe bringing it back to the architecture thing.
I think, architects have way more to worry about.
And in the case of Gen AI, it's not like, do we use it?
Do we not use it?
But in what context does it work?
Well, And what do we have to be aware of?
Like, it's not something you just turn on and get value.
CJ: right.
No, fair enough.
, because also, you know, Jenny, I likes to hallucinate, right?
and Jenny.
I is not necessarily train a best practices, right?
Like, I've seen some VR pop up, right?
Like in some gr and some AI generated code, right?
So.
There, there's a little bit more there than that needs
to be accounted for, right?
And when you start thinking about it and start thinking about who gets to do what
or how it gets to be done in the instance.
DUKE: And plus there's just, Oh, John Dahl, shout out to John Dahl.
He was writing this, great article on the limitations of it.
And he talked about stuff like you've got to keep it trained.
it's literally not push the button and it's trained.
CJ: Right.
DUKE: you've got to be careful on what you train it on and then maintain it.
It's not like learn once and it's always good.
there's always like a refinement and a fine tuning and adjustment.
so it's not like the architect is the one who's going to have to understand
the fundamentals of Gen AI if a company is going to use it and not just have
some garbage in, garbage out system.
CJ: Yeah, I mean, that's the architect's job though, right?
The architect's job is to worry about instance.
And when new technology comes on, that changes the way that the instance works.
now it's the architect's job to understand, like, how that's going to
change how things work and to be able to, Control it, I guess maybe it's the right
word, but sometimes I don't , feel like that's the right sentiment, but control
how it, works inside the instance, right?
Because at the end of the day, you're the gatekeeper, you're
the guardian of the instance.
DUKE: the guard.
I mean, absolutely.
The guardian, you're the person who's going to be rewarded or punished based
off of how this thing ends up working.
CJ: even bigger than that Duke, right?
Like you're the person who determines the business value of the
ServiceNow instance in that company.
you're the person who decides whether or not that investment will make a return.
it's huge.
I don't know if we always like take a step back and really think about the place that
we're in as ServiceNow Architects, right?
When we own that instance, right?
When we have their guardian standing there at the, with the sword and the
shield, you know, making sure that the thing goes right and that we stay
on best practice and we, you know, deliver actual output, People spend a
lot of money for service now, right?
Companies do, and you know, they expect to give value that is more than the
value of the money that they put in.
And we're some of the folks who decide on whether or not that's going to be true.
DUKE: Yeah.
it's definitively not as easy as it was.
If it ever was easy, right?
It's, it's definitively harder than it used to be.
I mean, just think, like, I build myself as a ServiceNow architect, but I'm
like way behind on the Gen AI stuff.
I hear word of mouth about ways in which it's weak and so how I have to factor
for that just in case it comes up.
But on top of that, I'm just thinking about every new
thing they roll out like RPA.
I
CJ: Yeah,
DUKE: mean, there's people who have already worked for
20 years in the RPA domain.
And now it's like, okay, if I'm an architect for a, for a
customer, I've got to find a way to come up to speed on that too.
CJ: yeah.
there's so much and on the platform.
Now, there's no way you can ever be an expert in all of it.
Like we used to back in the good old days.
Right.
We're like, I know the entire platform soup to nuts, right?
Like, you know, you can't anymore.
Like, it's just impossible.
DUKE: the people that work for a company, And just say, okay, like, we're going
to have to leave the actual execution of some of this stuff and all the
knowledge of best practices and all that stuff to an SME, ITOM guy, you're
the person who's going to tell us if my discovery is set up well or not, because
I could be a supremely good ServiceNow architect, but , maybe discovery is
the one tech I don't really know.
CJ: Yeah, fair enough.
Right.
Um, I could
DUKE: a bunch of rage people in my DMs, like, I can't be an
architect without discovery!
Yeah, yeah,
CJ: And, I've got a, I've got a pretty good discovery, experience.
I won't get those raised DMS.
but yeah, You can't learn everything.
You can't know everything.
I think maybe, you know, the architect's job, I think maybe as it's evolved
over time is, taking a progressively, , larger step back from the lens
that you used to view the instance,
DUKE: I agree at least I think about that a lot.
I'm like, I wonder if there's a case to just have the architect be kind of like,
how do we ensure that this is good for the platform and scalable and maintainable
all the, as Carleen says, all the ables.
CJ: All the ables.
DUKE: so if someone comes in, you're going to deploy, Some kind
of financial services module, right?
And maybe it's new, maybe it's old, but the key is, I don't
know anything about this process.
And so I'm going to have to trust that the SME knows what you're talking
about, but no matter what they build, it must be testable and upgradable,
CJ: Right.
DUKE: And rational.
So maybe the architect is somebody who ensures that, there's, the
documentation thing, right?
CJ: Yeah.
DUKE: Make sure that they have documentation that I can understand.
Number two, make sure that there's ways to test this thing.
Number three, make sure it's got some instant scan stuff built into it.
CJ: Yes, right.
Silence.
DUKE: does it make our security stuff go bonkers?
And so maybe taking all the platform tools that have
manifested over the past few years.
And just applying them to solutions that a non architect or a sub
architect, or some kind of domain specific expert is building.
CJ: Yeah, you're going to create better processes, right?
In which everything else funnels through, and using the tools the service now
has built progressively over the last.
several years, To make that job easier because the platform, while
they've been building those tools to make the job easier and better to
maintain, they've also been building and making the platform wider.
So you've got more to maintain.
Right?
And so I think, as an architect now you can no longer afford to ignore
the tools in the instance if you want to manage it successfully.
And effectively.
DUKE: totally agree.
and it's because I just, I just don't hear people talk about like instance
scan upgrade center all that much.
CJ: we've got a couple of folks in our network, And it's the same folks, right?
1 or 2, 3 people, who talk about it but not nearly to the extent that
I would expect and those couple of folks can't carry that entire,
portion of the instance, right?
Like, I do think that , we need , more voices out there who
are really, evangelism aside.
I think you can't really do this job effectively in a, a large instance,
unless you're using these tools.
how can, you know,
DUKE: Yeah.
CJ: so I, yeah, I just really do think that, we're doing
ourselves a disservice and we're doing the instance of the service.
If we're not using some of those things, like was it the admin dashboard,
that we talked about a few episodes ago, Duke, um, what is the thing
DUKE: Yeah.
Yeah.
The admin.
Uh,
CJ: It's admin dashboard, right?
DUKE: yeah.
Yeah.
CJ: I think it's called something else.
I feel
DUKE: No, I mean, yeah, that's, Hmm.
We're gonna have another episode on that maybe there's some like crazy talented
people working on that, but it's all it's showing is plugins that I can't
upgrade or can't activate, or grouping the plugins into like value propositions.
And then that's strapped to a task management dashboard for me, and I'm just.
If you think about all the administrative dashboards across the
platform, security has one telling you all the different things on your
instance that are bad, like bad, bad.
And then you have all like administrative info.
You want to know how many admins do I have currently active?
And when was the last time they logged in?
what update sets are currently subprod instances?
Do I have any changes coming for service now?
Like, just think about all the potential.
Stuff you could see on the admin dashboard and it's just I don't know.
They don't they don't like it's not um, what am I trying to say?
Corey?
CJ: I think, I think you're trying to say, Duke, that there's more that can be done.
Right?
DUKE: And I'm not like, I'm not trying to pull anybody down about it.
Right?
But why invest into things that are already like, we already have
dashboards that have my stuff on it.
My tasks.
my group's tasks.
We've got all that.
CJ: Yeah,
DUKE: but what we don't have is like one singular interface that says,
here's the stuff you should be worried about from a security perspective.
A performance perspective.
a upgrade perspective.
instant scan perspective and just have that in one spot.
Yeah,
CJ: for somebody to bill, it really does, like, dovetail with everything
we've been talking about right now.
Right?
Like, you know, the ability to manage the instance.
That's what the architect's role has evolved to write the ability to manage
the instance in terms of how you implement, Service now, essentially,
DUKE: because we're like, mean, some of us have been blessed to have
been at this a long time and just.
like me, I learned a teeny tiny bit over a very, very long time.
I'm not special.
I'm not smart.
I'm not, I'm not, I'm not genius smart, right?
Like I'm no Mark Rothoff.
I'm not a Corey Wesley.
I'm not a Nathan's birth.
You know, um, I'm just some regular old schmo that, that just did
a little bit over a long time.
if I had to come in now, I would be so out of my league in the architecture sense.
CJ: man, you
DUKE: what is this, like, is this a good idea or not?
The only thing I'd have is just another rant about documentation,
which we can totally do right now.
But,
CJ: I'll tell you what you got that we did that that I think is
one of your superpowers, right?
Is that you outwork everybody.
DUKE: uh, I'm glad it looks like that.
Oh,
CJ: this is what you go with it.
Just go with it.
DUKE: I'm trying to get at is.
I would love to have that admin homepage the way I want it because then you
could, take somebody from any level and just like, Hey, you're the architect.
Now, here's a dashboard for you with architectural stuff.
You might be interested in.
They'd be like, but I, but I, but I, Oh, well, okay.
Well, what about the security stuff?
Let's take that on first.
Now I even have some like hooks I can use to research.
You know what I mean?
CJ: right.
DUKE: or upgrade center is saying, Hey, on your next upgrade, just FYI, you're
going to have like 85, 000 collisions.
What?
What's the collision?
That sounds awful.
Well, it is awful.
Okay, maybe we parse it down to 5, 000, but , then I'm forced to learn right then,
right there, what is a collision even?
Why is it bad?
do I stop it from happening in the future?
CJ: I don't know enough about Gen AI to know how it works
in the instance around this.
Like is Gen AI hanging out, like Clippy, you know what I mean?
It's like, what is the collision?
I'm glad you asked.
You know what I mean?
It's like, you know, you pop over there and it's like, Would you like to
know about this problem record today?
Right?
You know, I feel like that's coming, right?
And I think it's going to be great.
DUKE: yeah, we, we said that on the Gen AI episode 2, which we're gonna
put in the, there's gonna be so many episodes in the description below.
If we'd only get paid a quarter for every episode we listed in the description
CJ: I know, right?
If only he got paid anyway.
DUKE: What else keeps you up at night, architecture wise?
, CJ: data.
Data keeps me up at night.
, 10 years ago service now.
Bear with me on this, right?
Like, so service now has always been a platform that has done way
more than it says on a 10, right?
Like, it's
DUKE: the tin.
Okay, go ahead, Zork.
CJ: Right.
But this build is an ITSM platform.
Right.
And the first thing I did when we got it, when I was a customer, it started
doing other stuff with it, right?
Like the first thing I did was say, yeah, ITSM is great, but I got these
business processes over here that this thing will be perfect for, right.
So it was always outworked itself.
And what that means is that it's, it's been a platform that's
accumulated a lot of data now, maybe not as much then as it does now.
And probably not as much data that matters then as it does now, but
now 10 years later, this thing is a repository of just stuff that you
probably don't want to let leak out.
And how you avoid that keeps me up at night.
Like who has access to it?
Not, and this is not just external threat actors.
Right.
I think about like, who has the right roles and permissions to access the
things that only they should see and not the things that they shouldn't.
you know, who has the ability to actually exfiltrate data from the platform through
like, I don't know, exporting through XML or or Excel spreadsheets, whatever.
Right.
there's a lot of different aspects to this, when I consider my responsibility
to the business and the businesses data and how that could compromise,
you know, operations and it's
DUKE: Yeah.
Oh,
CJ: And so that's.
Right.
Yeah,
DUKE: integration that required user sync.
And somebody just exported the user table and like sent it to their vendor.
It's, uh.
That's not something you want to do.
CJ: no, no, not at all.
Right?
even service now took a different stance on this over time.
Right?
Like, and so when you look at your, um, your subscription, reports, right.
It used to have the names in it.
Now it's got CIS IDs.
Right.
DUKE: cute.
Yeah.
CJ: yeah, right.
Like, so, you know, take a little bit of that PII out of there.
We don't want want to be sending back and forth, you know, the entire
list of users that you have in your company, especially that not the
entire list of privileged users.
. Because that, subscription report is going to show who has admin access.
it's things like that, that, there's been a shift over time,
as more and more companies are solely exist inside of computers.
Right.
And, , I think, , was Mark injuries and who's a software is eating the world.
Right.
, so, any company you have is, is now a software company, . If
you're doing it right.
, and so as that shift has happened, , we're all tasked with safeguarding, , all of
your company, which now exists digitally,
DUKE: Yeah.
it goes so far beyond just simple ACLs.
Which are hard enough, which are hard enough.
Then you deal with like encryption and newsflash, there's more
than one flavor of encryption.
and like, you've just got to, you've just got to know this stuff.
or know about its existence.
CJ: Yeah.
Yeah.
That's like that one,
DUKE: Listen, I don't do enough shouting out to people though, who deserve it.
Cause I always disliked ACLs cause there's nothing visual about it.
. Service now evolved from just lists and form based interfaces.
And so it was really hard to figure out like, Hey, who can read this table?
Like I had to find the record
CJ: right?
DUKE: or records in a list and which one, but application engine studio, have
you taken a look at It's it like rolls
CJ: I mean, to the extent that they exist normally, I know
where you're going with this.
DUKE: well, I mean, if you if you because application engine studio is
another way to look at the composition of an app and it's slightly dialed
down a bit, like, it's simplified, but it's interface to show you the roles
and crud rights on all the tables.
Is just, uh, it just, it's beautiful.
It's just very organized, very, as is like, if you have a scoped app,
it's just This is what it, and it only, it only breaks down from that if
you start doing ACLs against fields.
Right?
But,
CJ: Right.
DUKE: if you're just doing tables, where's my create, read, update,
delete, and what roles have what?
It's just a graph of boxes and just checked every box for
every role that has that right.
It's beautiful.
CJ: Yeah, no, you're right.
all right.
So this is 1 of those things, right?
When you're in the system and you're just doing the stuff, right?
Some of this stuff phase into the background, right?
Like, I've, I was just building an app using AES,
. A couple of weeks ago and yeah, it does do that night and it
didn't even ping to me, right?
Like that was significantly different than looking at it through the
main interface and on the platform.
But you're right, like it is.
Easier as much more streamlined and much more transparent, which is great,
? We should always be looking for UI interfaces that are much more transparent
to what's actually going on because they're a lot easier to manage.
DUKE: it's so good for building data structure that I kind of
forgot how we did it old school.
Like I know we went to like tables and columns and we like manually
created the rows for the fields and such, but it's just so easy in AES.
But then you hit this brick wall.
Cause it's like, I got the table.
I got all like, I got all my five tables that I want and I've got all my forms
and like, okay, let's go get to it.
What do you mean go get to it?
Oh no.
Now it's back to old school to manually build out nav menus and modules.
CJ: Yeah,
DUKE: for whatever reason, AES doesn't do that.
CJ: well, no, I, it, it did that for me, I think.
DUKE: Doesn't it doesn't create the modules for you.
You got to do that.
CJ: Oh, well that sucks.
DUKE: then I, then I pop open studio, right?
There's studio and application engine studio.
Right?
CJ: Oh, yeah, yeah, yeah.
No, you're right.
I was in studio like, and that,
DUKE: right?
Which studio do you want?
CJ: yeah.
That's not confusing at all.
Lemme, lemme ran on that one for a minute.
, like who thought it was look, come on Studio and application engine studio.
Like, let's come on.
Can we do better than that?
Like I call one.
it when I'm workshop.
I don't care.
DUKE: well, like I, I like them both for different reasons.
I, I do have to explain it to my coaching cohort quite a bit, like why
studio and application engine studio.
I'm like, okay, well with application engine studio, they're trying
to dial down the skillset needed to build a tiny, simple app,
CJ: Right.
DUKE: so happens that that simplified interface is great for like.
95 percent of the things that I would do anyway,
CJ: Absolutely.
DUKE: but studio, when it came out, had an entirely different user in mind.
It was just like, I'm building an app.
Like, just show me all the freaking pieces of the app.
All of them.
CJ: yeah.
Like make this easy to link up source control.
Right?
Like boom, boom.
Right?
Like, you know, give me all of the various pieces of an app.
And I totally agree with you.
I love it.
Then it's that cold search man.
Cold search.
I got cold.
Search is amazing.
DUKE: search.
Yes.
CJ: Right?
Like, and there's a lot of right.
There's a lot of external apps out there that you can use to actually
do cold searching your instance too.
But 1 of the.
Yeah.
Tips that I was just taught recently, right?
Is that, you can open studio and you can use code search.
Against anything in the instance, it doesn't have to be in that
app you're working on and.
DUKE: not know.
It's not, it's not filtered to the
CJ: No, no, no, no.
You can pick different scope.
You can pick global.
You can pick any of the other scopes, right?
And you could just do a search against them.
It's great.
And if you're looking for something, , as I was in a specific
case, , that somebody had, written before me and that person was gone.
It really helped me find like , where in the system was calling
this scripting include because Duke, there was no documentation.
DUKE: Can we, okay, that's a great segue.
Can we talk about documentation?
I just, I think, I think that horse is still moving.
It needs another hit with the bat.
CJ: Man, like, I talk about cold commenting, right?
All the time with Jenny.
I love to see you, Jenny.
I evolve into it.
Like my kick ass documentation partner.
DUKE: when I look at how I develop a document, I, there's a lot of
stuff in there where I'm like, why can't the robots do this?
for example, like, I have sections in my documents, like, like, when
I'm doing an architectural document for an app, I built, I have a section
called data structure where I list out the tables and the columns and
the properties of the columns and.
You know what I mean?
So I might have table one and it has a reference in it to table two.
And so when I describe the reference, I actually like hyperlink
within the document to table two.
CJ: Makes
DUKE: And that way, like when this thing gets 20 pages long.
Nobody has to scroll.
They could just, Oh, this references to there.
I don't know about there.
Let me click.
And I go there
CJ: So your doc is an app
DUKE: basically.
Yeah.
And I'm just like, why?
Like, surely the thing could just output a word doc in nicely formatted ways.
At least has the table and the columns and the fields and
the properties of the fields.
And then all somebody might have to do is fill in the intent of those things.
So a human could understand them and then the one thing that the human must
do all the time, I think, is to talk about, like, do an abstract of what the
app is there to do and kind of log the decisions that were made along the way.
Because as you all know, the app that somebody wants on day one is
rarely the app they want on day 60.
CJ: Yeah, yeah, that a great point.
Right?
And that, you know, that we've got an entire episode about requirements
gathering and and specifically the 1 where I was, helping
you with your coaching cohort.
Right?
DUKE: Yeah, yeah.
CJ: Right.
And towards the end of that up, right?
Like there's a, there's a point in there where we pivot a little bit from
basically what you thought you wanted to what I suggest that you could probably
use that you thought was a better idea.
DUKE: Yep.
I do it with my coaching cohort all the time.
They have to make their own capstone project.
And it's always like the most common thing is.
Here is the entire picture of what this process I picked look like.
It's something they're familiar with, right?
And my current coaching cohort, shout out to Kathy.
She works in the mortgage industry and she's doing this whole
how to close a mortgage deal.
And it's just like crazy complex.
But we make decisions to say, okay, we're going to reduce the scope, reduce the
scope, reduce the scope, reduce the scope.
So we have something now we're getting into like agile and
minimal viable product discussions.
Right.
But
CJ: startup.
DUKE: yeah, but like the AI couldn't possibly look at the
composition of your app and infer that you had de scoped stuff.
CJ: Right,
DUKE: So the, like at the end of the documentation and, those hard
asses on the team that are like, well, I asked for it this way.
You know, and it's like, where were you in all the meetings where we all
agreed that we were de scoping that.
CJ: right.
Exactly.
And, and it's important to know, like, you know, because not everyone's
going to be in those meetings.
Somebody might be out sick.
Maybe they weren't invited.
You should always only invite the people to the meetings who need to be there.
Not more, not less.
Right?
Like, let's be clear on that.
Hate meetings with too many people.
I hate meetings in general.
Right?
So I would like to have them as concise as possible and only as many
as are, as are absolutely needed.
Yeah.
That said, right, like when we make those decisions, it's important to
understand, why they were made and who made them and record that so that it
can be, , it could be, , reviewed later.
one of the things that I, this is going to be interesting, right?
Because my part time job is, you know, city council where the entirety
of the job is doing meetings.
Let me tell you what the difference is, right?
Like Robert's rules of order.
Like if every corporate meeting was run with Robert's rules, let me tell you how
much more effective and efficient it be.
An agenda that needs to go out X amount of days before the meeting starts.
? And you can only discuss what's on the agenda.
? Somebody's taking detailed meetings.
I mean, minutes.
? So you can always refer back to those minutes can go into your documentation.
? Because they're the living, breathing kind of accounting of
what happened in the meeting.
All of these different things.
Right?
And.
DUKE: it's 1 of the pillars of Western civilization, buddy.
Robert's drills for
CJ: yeah, I mean, you know, and maybe did this, did, did you invent those Robert the
DUKE: me.
No, it was a different Robert.
Yeah.
Hold on a second.
I got to build an affiliate link.
So we're gonna put a link in the description below for that.
Oh, man.
Okay.
We're at 32 minutes.
CJ: No, man.
How'd we get there?
DUKE: I don't know.
It's good though.
I'm not going to do much editing on this one at all.
CJ: Yeah.
Oh.
DUKE: so we covered what we covered like data and roles and all the
different administrative interfaces.
And we talked about documentation and we talked about how do I make the
platform such that I plug in SMEs.
CJ: Yeah,
DUKE: You know, and, and make sure that I can trust and verify what they put in.
I feel like we're missing a ton of stuff.
CJ: I'll do, I mean, there's a ton we're missing here, , but,
, we've gotten this far with it.
And I think this might, there might be a part to this episode at some point, right?
Like, you know, in terms of what's changed, , there's 1 last thing we
had on our list that I really do want to, , cover we close out and , it's a
question that you said, actually, that , you've been seeing a lot and you've
been getting a lot from folks, , and the ecosystem is, do I need to know
how to code to be in the ecosystem?
DUKE: Yeah.
I mean, well, gosh, there's so many jobs in ecosystem and we will have
links to every episode that we've done on them in the description below.
So some of them, no, like I don't think you need to like learn to code to be
a BA, but I would say like everything, admin implementation and architects,
like absolutely, I don't know how you can't, I don't know how you can't.
Even for admin, right?
, what do you think an admin is going to do?
Are they going to be first level support for ServiceNow problems?
Probably.
What if the problem is in a business rule?
What if the problem is in a notification that is running a mail script?
CJ: Yeah.
DUKE: What if the problem is in a client script?
Like, all the config things that we, all the config tools have
this JavaScript block in it.
CJ: yeah.
No, you're, you're absolutely right.
, I
DUKE: and then especially the higher you go, like up into
architecture, forget about it.
I'm not saying you have to be like a pro co, like you have to
be like a Professional JavaScript developer, but you definitely need
to like, how would you know if somebody gave you shit code or not?
CJ: yeah, I mean, you wouldn't write, , if you're not able to co
and I think really , the best thing that happened to me as I was getting
on boarded onto the system, right?
Is that the folks who were training me on how to do it.
Really leaned into.
You really need to learn how to do JavaScript, right?
Like I had, I was not a programmer when I got into the service ecosystem, right?
I've done some, uh, yeah, I've done a lot of like command
line scripting and DOS, right?
Like that was, that's where I could work.
. But, you know, in terms of anything, JavaScript, python, anything like
that, like real coding languages.
No.
, but yeah I learned over time, right?
and I was valuable while I was learning.
That's the point that I'm actually, that took the long way around to get to right.
But I was valuable , while I was learning and I'm not a professional
JavaScript developer now, right?
Like I'm pretty good at JavaScript in service now.
. You can be valuable as you're learning how to code and service now, as
you're learning javascript, as you're learning, , glide script, right?
Like you can be pretty valuable and service now, just, , while
learning javascript snippets, right?
Like, you know, how do you find, like, how many characters are in
a, , and in a subject line, right?
Like, you know, that learning that, uh,
DUKE: I've been totally stealing that , for my coaching course, or just in
the JavaScript part now, and it just, I took totally, like, I feel like I
open my mouth and then you fall out.
, you're not training to be a JavaScript developer.
You're not even trained to be a junior JavaScript developer.
You're training to know enough, string manipulation, arithmetic, logic.
And that's it.
CJ: Loops and loops, right?
Like, if you know,
DUKE: That's why I put that in logic, like conditionals and loops is yeah.
CJ: Yeah.
But if you know those things, right?
Like you could, I mean, you're 80 percent of the way there.
You're going to be good.
You
DUKE: just practice from that point on.
Right.
CJ: it is just practice from that point on it and applying it.
And as you start to apply things, you'll find gaps and then
you'll go and Google those gaps.
Right?
And then you won't have those gaps anymore.
That's how it works.
Right?
Don't pick up a book, you know, how to learn JavaScript.
Hmm.
Oh
DUKE: all right.
CJ: yeah.
So don't pick up a book on like how to learn JavaScript in like 30 days, right?
Like pick up the ServiceNow instance, right?
And start building something, and then figure out like where your gaps are
and then figure out how to plug them.
DUKE: Okay.
We're at 37 minutes.
So we should probably think about wrapping this up.
Hey, listen, if you have something insightful to say about how
architecture has changed over the last few years, what keeps you up
at night as a ServiceNow architect, please put them in the comments,
wherever you're finding this podcast.
And, , if you get some good insights, maybe we'll have you on the podcast.
We have episode two of this.
CJ: All right.
And still no outro.
And we're out.