Subscribe
Share
Share
Embed
Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk
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.
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.