So it's kind of funny, we were just talking, the two of us, and we're waiting for our panel to arrive.
We've got a couple other folks coming.
And honestly, we both know the topic pretty well.
So we'll just jump in, and if our panel arrives, then they'll join us up on stage.
But that way, we get more time together, and honestly, I think we'll have a pretty great conversation today.
So very excited to kick this off.
This is our Architecture and Cybersecurity Executive Panel.
And I'll tell you a little bit about the group that you're going to be hearing from.
The Chief Architect Network is a group I helped put together.
It's a 501c3 non-profit connection of Fortune 500 Chief Architects.
Those are the folks that lead the architecture practices.
And we're all around the world, so it's kind of fun.
I like to say, from New Zealand to Hawaii, the long way.
So that's our group.
We do topic calls and presentations, and we also have a lot of events that we get together for.
So sometimes we partner with groups, so we're partnered with CypherCon.
Monster is actually one of the leaders of our cybersecurity network, which is a ton of fun.
We've got about 100 of our executives that are in that group.
And let's see, what else can I tell you about it?
We're going to be in London at the end of the month.
We do twice a year kind of global meetings, and we'll have about 40 of us together just at the end of the month, so I'm really excited about that.
So in this track, you'll actually hear from us in each of these conversations.
And there's Adi.
Come on up, Adi.
Well, actually, perfect timing as we introduce the panel.
So today's conversation is around the partnership between architecture, come on up, it's all good, and cybersecurity.
And it's really an enabler of our organizations.
And Nathan's going to lead us.
We're going to dig into how we align cybersecurity strategies with business goals, and ultimately share best practices, challenges, and our evolving approach to create secured architecture across the enterprise.
So without any further ado, Nathan, thank you so much for leading us.
And also Nathan is the leader of our Milwaukee chapter, and Adi is one of the leaders of our Chicago chapter.
So we've got all the architect network leaders here today, which is kind of fun.
Awesome.
Well, this is a blast.
Thank you for organizing it.
So we're going to have sort of a tell me how you really feel conversation about architecture and security, which is going to be really fun, because a lot of these panels can be like super boring.
So our intent is to make this very not boring, so you can tell us at the end if we accomplished that task or not, right?
So no canned answers, no it is what it is sort of types of answers in this panel today.
Okay, so our first question... actually, did you introduce yourself?
I didn't introduce myself.
I forgot that last time.
Who the heck is talking here?
I'm Grant Ecker.
I'm the chief architect... come on up, man.
I was like, huh?
I'm Grant Ecker.
I'm the chief architect at Ecolab, and I help to build the architecture practice.
Okay, so I'm chief architect at Ecolab.
I graduated from Walgreens Boots Alliance, Danaher, and Medtronic, where I was the chief architect in those organizations, and helped to build the architecture practice at Lowe's.
Thank you for asking.
I totally forgot.
Hi, I'm Aditya Kaushal.
I have the pleasure of working with Grant in Ecolab.
I'm leading architecture for the industrial group, and I also worked with him in Walgreens.
So primary focus for me has been on the data architecture side of things.
Thank you.
Good to see everybody.
So my name is Ravi Prakala.
I work as a head of engineering for consumer interactive at TransUnion.
TransUnion, as you probably know, one of the three bureaus.
We are primarily doing all the credit scoring and so on and so forth, but we are actually a global organization.
I'm actually responsible for close to about... oversee about $70 million worth of business.
So info security, we're a heavily regulated organization, so info security is central to everything that we do.
Awesome.
And I'm Nathan Liznoski.
I'm Concurrency's chief technology officer.
I work with Fortune 500 companies on their enterprise architecture and other kind of cool projects, and I get to lead the conversation.
So super blessed to be here.
Okay, let's start with Adi.
Okay.
So starting question is, how does enterprise architecture make a difference?
What practical difference is enterprise architecture actually making in the context of the security world?
What is it really doing for us?
So the way I look at enterprise architecture is that they have a wide view of the enterprise, the entire organization.
So it's their job to bring everybody, every key stakeholder in the organization to the table.
Whether it's data governance, it's security, your privacy or your legal teams.
They are responsible for bringing everyone to the table and making sure all the risks and point of views are talked about, discussed.
So essentially when you look at a solution or a particular enterprise business line of business, what you're looking at is they need to enable something.
They have to sell something.
They have to enable the organization in order to make money.
If you block everything, that's not going to work.
So it's a balancing act.
That's the way I look at it.
Okay.
Awesome.
Thank you.
How about you, Ravi?
What would you say on that?
So to me I think it's, if you sort of think about it, it's in the name itself.
It's architecture of the enterprise.
Right?
So primarily when you sort of think about, in many organizations at least the ones that I've actually seen, I have the distant pleasure of being a chief architect at Northwest Mutual for a number of different years.
And one of the key things that I see from an enterprise architecture standpoint is organizations tend to think about enterprise architecture as an IT architecture as opposed to basically thinking about architecture of the enterprise.
So what that means is how do you work with, partner with the business stakeholders?
How do you understand the business strategy?
And then how do you enable that business strategy?
Right?
Which kind of gets back to what Aditya was saying about how do you basically enable the business strategy by working with all the various stakeholders?
A lot of times, you know, in some ways you don't get a seat at the table unless and until you actually earn the reputation and then start showing results to the organization.
So I think in many ways done well, enterprise architecture organizations can actually not only enable the business strategy, but also position the organization for a tremendous goal.
So double click into that.
What practically does that mean?
Are you building like a vizio of the organization?
It sounds like it's more than that, right?
It's you are truly like engaging the organization.
Lay out like exactly what the outcome is.
Yeah.
So I think if you sort of think about it, right, the classic definition is many organizations think about business architecture as being something different.
And then IT architecture as being something different.
So if you sort of bring both the aspects together, put under the umbrella of enterprise architecture, then what actually happens is you are actually sitting with the business stakeholders trying to understand not only what is their three-year or five-year or two-year roadmap,
right?
What is the growth strategy?
What are the immediate challenges that the business is actually facing?
And how do you think about basically solving it from a technology standpoint, right?
It's not just about creating PowerPoints or, you know, theoretically this is how it's going to work.
It's about working directly with the business and understanding the challenges that they're actually experiencing.
Because then what happens is they become the advocates for the architects, right?
Because you are actually a trusted partner for them, rather than trying to basically, you know, push your way into, hey, this is a process that we need to basically follow.
Because the more advocacy that you develop with the business stakeholders, the greater the influence that you will have to basically either course-correct the strategy, if required, or even enable the strategy in real-time instances.
That's a great answer.
So let's bounce over to you.
The problem you're solving.
So if you, like, what is the number one problem that you're working with the business to solve right now?
Like, anything, what would it be?
So one of the major challenges which I've seen in work with the businesses around is they don't engage architecture or your security teams when they start looking at a particular idea or a particular solution.
So it's about building this trust with them so that they engage you earlier, and they can solve their problems.
The challenge is that they come up with a solution, and then they go to the architecture and the security groups to say that this is the solution, figure out how it's going to work for us.
By and large, that's already too late in the game.
So you need to engage early, build that trust, build that partnership with the business, and then you can look in terms of unlocking the business value around the enterprise.
Got it.
What's the number one problem that the business is engaging you to solve?
Right now, the project or the area I'm kind of focusing on is it's about taking new, innovative models, like vision and AI models, and incorporating it into our existing ecosystem in the enterprise and looking at them in ways we can commercialize them.
So that's one of the challenges which I'm trying to address right now.
Got it.
So describe that a little bit more.
Keep going into that.
So, what we are doing is we are building a kitchen operating system, which is going to be deployed in quick service restaurants.
Pretty much all our customers, and there are big customers, like, I won't take their names, but... and they're looking in terms of reducing their cycle time.
They're looking at reducing their labor spend.
They have challenges in terms of, especially when there's those busy times, they can't really handle the workload.
So how do we help using AI technology and the cutting-end innovation in order to improve the outcomes for the end customers?
You don't want your customers sitting in a drive-through or in the restaurant waiting in a quick service restaurant for 15, 20 minutes to get their orders.
That's the problem we're trying to solve for.
So is the role of the enterprise architecture team to design that system, or is it to design, like, the construct around the entire ecosystem and how everything fits together, or both?
I would say both.
It is a balancing act.
You have to take into account what are your partners, what are your vendors, how are you going to establish a pipeline in terms of scaling this out at hundreds of thousands of stores?
What is your strategy?
How are you going to be able to push the patching, the security mechanisms behind that?
How are you going to enable the services organization to have these equipment being delivered to an environment which is prone to failure because of heat, grease, a lot of turnover around employees, a lot of touch points associated with the equipment.
How do you figure out a way to make this commercially viable and yet secure?
That's a great answer.
Ravi, how about you?
What's the number one problem you're solving?
Yeah, for us, I think, I don't know whether there is one single problem that we're actually solving in an enterprise like TransUnion, right?
So we have, you know, for us, if we were to basically kind of pinpoint, there is a massive modernization effort that we're actually going through.
Data is a first class citizen for us and we hold a lot of precious data, PII, for everybody, every single person, hopefully in this conference room and more.
Every single U.S.
citizen, PII information is something that we actually hold.
So protecting it, you know, with our most precious tools and, you know, resources is one of the most important solemn responsibilities for us.
So when we talk about infosecurity, it's probably not a bolt on for us.
It's something that is actually central to everything that we do, right?
And I'll give you a couple of examples around how do we basically kind of think about some of these things because it leads into some of the major efforts that we're driving across the organization.
So when we are modernizing today, we are actually looking at a number of different options.
Some of them we are actually building solutions in the enterprise and some of them we are actually acquiring.
Like we acquire companies.
Last year I actually oversaw, you know, close to about $6 billion worth of acquisitions.
So one of the key things that we do is, and I think going back to the EA conversation that we actually began, the moment the company actually looks at, you know, acquiring a business, I'm actually engaged as a part of the initial what we call as a pre-diligence effort.
So we get engaged in conversations with the business along with the company that we are actually acquiring from a technology and information security standpoint.
So we go through a very methodical process of actually analyzing their infosecurity posture and then figuring out what are the gaps and then integrating into the rest of the enterprise, right?
So that's one major activity that we have actually done for the last many, many years.
We will continue to do it.
So that's one of the key efforts that we continue to basically kind of think about.
On the second part of the modernization where we are actually building platforms inside TransUnion, we have this platform which we actually co-branded as a one-choose.
So which is basically think of it as a large amount of data that is aggregating across multiple different data sources, both internal as well as external, to basically generate either models that actually serve our business customers or models that actually serve our consumers.
All these efforts are primarily focused on not only just delivering value to the market quickly, but also doing it in a secure fashion.
Because if you sort of think about anybody who's actually been involved, and maybe Aditya can actually double-click on this, data does not come in one shape or size or form.
It comes in different sizes, different shapes, different qualities.
Not only processing some of the data, but also making sure that we should have access to some of the data.
Who should actually see it?
What are the regulations that we need to basically comply with?
So I think it's an ongoing task for us in thinking about all these various initiatives in a consistent fashion.
Unfortunately, I can't get into the specifics of some of the projects because of the organization that I actually work for, but hopefully that kind of gives you a little bit of idea on how we think about it.
Awesome, thanks.
Alright, so let's get into what keeps you up at night.
If you are thinking about enterprise architecture from the context of your security posture, what are the one, two, three things that you're thinking right now, not necessarily about your organization, okay?
So take a step back from your organization for a second and say, generally, from the vantage point of enterprise architecture and what you're seeing, what are the things that you think are the primary focus areas that these folks should go back to their businesses and say,
hmm, I should put some attention behind that from a security posture standpoint?
So the way I think about it is that, first of all, all organizations have limited in terms of money they can spend towards security and enterprise architecture.
The challenge or the thing which we are reacting to is the threat vectors are evolving constantly.
In an enterprise, you're working with frameworks, you're working with a pre-existing posture, you're working with certain constraint around resourcing and how you do things.
That's a blocker .
The threat vectors are the people who are trying to get into your organizations, they don't have a playbook.
They can do pretty much anything which they can in order to get in.
But you have to follow the rules.
Now, you have to kind of look ahead, plan, and it's scary in the sense that you really don't know a lot of threat vectors which are potentially trying to get into your organization.
So how do you address them?
How do you react, proactively address that threat?
That's something which keeps me up in the night.
Got it.
So if you're thinking about those threat vectors, what are the 1, 2, 3, whatever like top areas that if you're walking into an organization right now, let's say you got a new job, you don't.
You love your job.
But you want to work with Grant some more.
Let's say that you were going to go in and advise someone about their organization.
What are the top 3 that you say, from enterprise architecture standpoint, from my vantage point, this is what I see most organizations need to knock out right away?
The common point of failures across most organizations are seen as the employees, the resource, the human factors associated with it.
So you have to spend or allocate resources in terms of training them, making them understand social engineering is a real thing, it happens.
You get texts, you get emails, you need to be proactively getting rid of them, putting platforms in place so that you can secure your network, you can make sure that you can test the software coming in, especially with the new AI work which is happening in most organizations.
There are a lot of packages which are being installed into the internal ecosystem.
How do we vet them?
How do we proactively monitor them?
Make sure that if you find the threat and essentially address that.
We can just get rid of the people.
If I had to design an ideal secure system, it would have zero users and would be air secure.
There you go.
How about yourself?
If you were walking in, what would you say are the top threat factors that you're paying attention to?
To me, if I think about an organization like TransUnion, there are probably two things that I think about.
One is, we want to be in the press for the right reasons, we don't want to be in the press for the wrong reasons.
So what this means is, when we launch a product, we want to obviously get a good feedback from our consumers, whether they are actually direct banks that we actually work with, financial institutions that we work with, or the consumers that we actually work with.
But from a security standpoint, we don't want to be in the press.
Probably many of you know what actually happened when Equifax breach actually happened.
It's a fundamental constraint to the business.
If you get into the press for the wrong reasons, given we are actually heavily, heavily regulated, there are nine different regulatory bodies that actually oversee TransUnion.
There's probably not one single day goes by where I'm not involved in some conversation or the other every single day with some of these regulatory bodies.
So the amount of scrutiny that we actually get is just ginormous.
So coming back to your first question about, hey, what keeps me up at night, is exactly that.
So there are obviously a whole bunch of people that have this similar responsibility, but it goes back to infosecurity is something that there are a lot of state-sponsored actors that are wanting to basically get into our platforms.
And every single design, every single solution that we are actually putting out, rather than actually worrying about how quickly we can actually get to the market, how do we get to the market at an optimum pace without necessarily exposing our valuable assets with security holes.
Got it.
Okay, I'm going to ask one more question of these guys, and then I'm going to turn it over to you.
So I want you to start thinking about what are good questions of these awesome gentlemen that you love to dig into.
I don't care how spicy it is, just ask them directly.
They've been around the block.
Okay, so the next question that I have for probably both of you is, some architecture frameworks are pretty well understood.
There's best practices, right?
Like, we know that certain things we just do because it's a good idea.
Patching, right?
Like, pretty straightforward.
And then there's some things that are really emerging, like some of the agentic frameworks.
They're emerging.
Maybe they're even starting to get to better practices, but a lot of it's not even there yet.
It's just like we're still discovering what it looks like.
Are there some that you think, like, everyone should look at this particular enterprise framework for these things?
Like, you lean on it, you use it, you take advantage of it.
And then where's the emerging frameworks that you're paying attention to or participating in that you think are the ones that are going to become better practices, but they're not quite there yet?
Like, just from your perspective of...
To me, I probably think about some of these frameworks in two distinct categories, right?
So the ones which are what I like to call them as traditional frameworks, which are, you know, they have been around the block for a number of different years, whether it is, you know, idea architecture frameworks or auditing frameworks and so on and so forth,
right?
So those are actually known in the industry for quite some time.
And it's not like every single... you can actually pick them up and then deploy it in your organization.
You need to basically think about what is the maturity of the organization, right?
And, you know, conducting some kind of a maturity assessment to basically, hopefully, you know, that's part of your... one of the things that Nathan, you might be actually focusing on, is how do you think about the maturity of the organization with respect to some of the legacy or classic frameworks?
But the emerging ones are the ones where I think I see, you know, if you sort of think about the AI, right?
There are a spectrum of things that are actually happening on the AI front.
There are no standard ways of actually doing some of this stuff.
And then specifically for us, given that the data is actually one of the fundamental citizens of how we actually think about it, all the way from data governance to, okay, what are the use cases where we can actually apply AI-related use cases?
And then what frameworks do we need to basically kind of think about is one of the critical things that it's been an active conversation.
I wish I could actually tell you that there is a magic bullet.
You know, we have a framework that we've actually implemented.
But I think that space is actually fast emerging and it's, you know, participating in some of these forums.
You know, we have a number of forums in which RSA and others where some of our, you know, some of our folks actually participate.
And then kind of taking some of those best practices and then seeing, okay, how does it actually work for TransUnion?
Because I think over the course of, I would say, maybe in the next few years, you will see some emerging frameworks that will actually come out, which will actually reduce some of the burden on the organizations, specifically thinking about some of these things.
But for now, I think it's, you know, unfortunately, you need to basically kind of be open about, you know, you might actually make a pick on one of the existing frameworks that may not actually work out.
And then you should be able to actually adapt some of these things moving forward.
Great answer.
How about yourself?
The way I look at it is that none of the frameworks are perfect.
All of them have challenges.
All of them have their advantages.
So the way I would do any framework in an organization is you bring the framework, take the data points from or the signals from the organization.
You need to understand where your maturity is.
Having a maturity assessment done probably is a good idea.
But take that into account.
Follow a damning methodology.
Define what you need to measure.
Analyze and improve and control that.
So frameworks were written to be comprehensive and cover probably all aspects which need to be looked at.
But does all those aspects or all those dimensions are valued in your organization?
Probably not.
So it's about enabling or accelerating the business.
So you have to take this framework and take the signals from the organization.
Combine them and refine them over time to come up with a strategy which works and helps accelerate your business.
Got it.
All right.
Let's get some questions from our awesome audience here.
Who has the first one?
Go for it, sir.
So the question was how do you tell the CISO and the rest of the business what the value of security architecture is?
So who wants to grab that one?
I can probably take a crack at this.
I think the question is fundamentally based on an assumption that the CISO doesn't know anything about security architecture.
And if that is the case, then I would humbly submit to you that that person should not be in the CISO role.
I think it's a... I mean, I'm partially joking.
But I think... you know, in many ways we sort of think about security architecture as something that is different from architecture in general.
And it's a vernacular that has been created in the industry for all kinds of interesting reasons.
But if you sort of think about security as nothing but an integral to...
You don't think about when you install your... for example, right, when you put in doors into your house.
You don't think about locks as being something different.
Right?
You need to have a door, and you can't have a door without a lock.
So why do you have a lock?
You have a lock because you wanted to basically say nobody can actually enter the house.
Right?
But why do we think about... why do we not think about security in the same way?
Because part of the challenge is because it's the vernacular that we actually use with some of our stakeholders.
As to, hey, security is something different.
It's something different from what technology does.
It's something different from what business actually does.
As opposed to thinking about security as an integral to everything that we're actually doing.
Because if you do not think about this as a common construct across your entire value chain, you'll get into some of these debates.
I know it's probably not answering the question directly.
But I think I would probably start there.
Why are those questions being asked?
Is there an education that needs to happen to some of these CISOs around what is the value proposition of architecture in general?
And then specifically security architecture.
I would echo that.
Essentially, most organizations need to carry an insurance.
Business needs to be educated in terms of what the risk is, in terms of not having security.
What's the reputation or damage associated with it?
They need to be aware of what's the worst-case scenario?
What's the best-case scenario?
What kind of investment they need to do in order to make sure that you are at a point where you can assume risks.
So whenever you do a project or an initiative across the organization, there is a risk associated with it.
So you need to be able to educate the stakeholders, the business owners, in terms of what the risk is.
Are they okay with assuming that risk?
I think it's truly about educating the organization.
I think I have another tangent on that question.
I have the privilege of working with a lot of different businesses.
So I get to experience how easy are they to work with?
How quickly do things get done?
And there's these stark contrasts between organizations.
One business might be like, cool, this project is going to take us four weeks because they are easy to do business with.
And their teams work well together.
And there's other ones where it's like, is this project almost done?
It's been a year and it was supposed to be four months, but it keeps dragging along because nobody is great to do business with.
And in those organizations, every team can be typified.
But if you take the security team as one piece of that, some security teams, they have a real customer service oriented mentality about them.
Their goal is to be your great advocate in getting your solution to production, but to get it there in a secure and appropriate and constrained and appropriate way.
It's governed, but it's the balance of governance and enablement in a sense that enablement has to come first because if you're not enabling something, what are you even governing?
You have to have both.
Whereas other teams I've interacted with, I feel like they're the no police.
And nobody wants to invite them to the party because they're not any fun.
So they're just thinking like, how do I avoid that guy?
Because even though they have some good ideas, they're really not an advocate for my production system.
And the ideas they bring to the table are usually about saying no to something rather than recommending something that's going to make it better.
Participating, as you said, in the architecture process.
Like , great, we're going to make doors.
Let's make them all locks.
Cool, right?
Versus, no, you shouldn't have a door ever, right?
Oh, I'm sorry.
So for me, it's about like, you know, whenever we have a problem with someone, we have to look at ourselves.
I'm not saying this about you, sir, but like we have to look at ourselves.
It's usually like it's a two-way street.
Like, am I an effective security professional in the way that I'm engaging?
And am I becoming a partner with the person that I'm trying to build a relationship with?
Or am I just like slapping things down on the table that they shouldn't do?
And in retrospect, too, looking at the other side of the table, like have they engaged you?
So there's that real opportunity, I think, about the mentality by which you engage.
And I think that's true for enterprise architecture and every job in general.
Great question.
Next question.
Yeah, you, sir.
Make sure you put a quote
.
Something gets promised and it falls short.
Yeah, so the question for everyone was you're spending so much time with the business.
Correct me if I'm wrong, okay?
You're spending so much time with the business trying to make sure you're building the right things.
Are you spending enough time with the people actually building them so your opinion and your engagement is worth it?
Like you're making a dent.
Is that kind of the heart of it?
And something you
can now promise.
Great point.
You don't promise something that you can't actually do.
All right, you want to hit that first?
Sure.
I've seen a couple of approaches on that.
One, whenever a project is in the inception phase, the business engages or creates a ticket for the architecture group to get engaged, the cloud teams to get engaged.
There is a T-shirt sizing which happens there.
And over the course, as the solution firms up, they are engaged and they're constantly iterating on it.
I think that's one of the approaches which has worked well.
The other is that, okay, we are going to do an MVP and then we'll figure out the rest.
That doesn't work too well.
It has a lot of friction points associated with it.
I prefer the approach, the first approach where you want to engage as early as possible with an understanding.
It's not perfect.
We will iterate.
We will pivot if necessary.
But again, that partnership needs to be built out.
At least for us, the way we think about it is there is a three-year roadmap, there is a yearly roadmap, and then we do the quarterly PIs that we actually go through.
When we are doing a three-year roadmap, a lot of times there is a lot of uncertainty.
There are not a lot of specifics.
We want to enter this particular market.
We want to do X, Y, and Z kind of a thing.
But when we sort of get into the yearly roadmaps and the quarterly roadmaps, a lot of times we actually do the runway planning for some other work that is coming up in the next quarter.
So I think the most important thing, at least for us, is engaging the right people at the right level.
You can't have an entire village participate in every single conversation.
So understanding who needs to be involved is the most important thing in the entire value chain of an organization.
So for us, when we are actually doing the planning for the next quarter, things are somewhat certain that we have the funding, we have things that are actually going to get done.
At least two to three PIs before, roughly about six months ahead of time, is when the actual solution starts taking shape.
The business stakeholders and the technology stakeholders participate.
And that's when, for us, we don't think about architecture as being something that is separate from engineering.
We call it a triad model.
There is a business stakeholder from the product.
There is the architect that is actually involved, and then the lead engineer who is actually involved.
So those are the three that are actually working together, along with infrasecurity at the center, making sure that whatever the solutions that we're thinking about, when we are sort of getting to execute, the majority of the things are actually sorted out from all the various perspectives.
I've experienced one really interesting thing that I've gotten feedback on sometimes is, how do you know if a leader is a good leader?
You look behind them, you see if anybody's there.
So many people, they're out there in front, they're doing stuff, they're engaging people, and nobody's following them, because they haven't taken the time, as you said, sir, about building a team of people, engaging a team of people that are contributing to the solution,
that believe in where they're going.
Now that, I think, is one of the real challenges of leadership, because it's one thing to be a leader where everybody follows you because they're comfortable and safe, and it's another thing to be a leader that challenges people to be the best version of themselves.
And I mean that really authentically.
I think one of the most challenges I have in my job is, a lot of times I'm going into companies that are stuck in the mud, or they're wanting to be something more than they are right now, but there's a lot of folks that are kind of like in a position because they've been doing a job for a while,
they're comfortable, and you have to unsettle that.
And there's a balance between the unsettling part of the job and the bringing people along for the ride part of the job.
If you're too strong on either side of those two pieces, you'll fail.
You'll either just stay where you are and nothing will happen, or you'll push too hard and people won't follow you.
Sometimes, you're right, I'm actually one of the people most called out for this, is engaging an organization and promising something can happen, but they have an engineering team that needs to be challenged to be right at the edge of their comfort zone that it can happen.
Because we especially do a lot of leading-edge stuff, ideally not bleeding-edge stuff, but leading-edge stuff is that.
Remember that Yoda says, always with you what cannot be done.
You're looking to challenge them to see that something can be done, but also listen to them and be like... because there's sometimes these projects where it's like, oh boy, this actually can't be done, or at least not for the cost that we're trying to do it for.
So you have to balance both of those.
So you're like hit the nail on the head.
You have to have that business engagement, and you have to have that partnership with the engineering team to lead them toward that possible future.
One other thing on this that I think is really a great mantra is starting with the end in mind, like with both organizations.
Where are we trying to achieve, and what needs to be true to accomplish that possible outcome?
And sometimes you discover that the thing that needs to be true isn't ready yet, and you have to park it for a while.
Or you discover, man, it is true, and we can iterate through that and decompose it.
So yeah, anyway, thank you for the question.
Next question?
Yes, sir.
How
do you enable the business to move
projects and knowing when to jump?
So if I understood that question correctly, it's how do you know when to balance you kind of like diving in to help versus let them operate, and you integrate between different teams.
Is that correct?
Yeah, and mainly enabling the business in certain things and knowing when to slow down.
Got it.
Okay.
So the approach I like to take is, first of all, you've got to acknowledge that generally enterprise architecture teams are lean.
They cannot cover all projects, especially the small and the medium ones.
That's where your good designs, patents, architecture principles come into play.
So the thought there is if you have a small project, we can give you a set of rules or principles which you need to adhere to.
And if there is a divergence, let's have that conversation.
So that engagement model works as well.
And if you have a patent which is pre-approved, the enterprise architecture, the solution architecture, security, the various governance bodies have looked at it and approved it, then you're reusing it.
We don't really need to get involved in it.
It's a checkmark.
Let's move forward.
Let's move as rapidly as possible.
To me, I think the best model that has actually worked, at least in the number of roles that I've actually played and seen in organizations, is the most important thing is becoming solution-oriented.
A lot of organizations, at least the ones that I've actually seen, sometimes enterprise architects tend to think, oh, this is my job, this is not my job.
Gets into it because of resource constraints, X, Y, and Z.
But a true enterprise architect who does not necessarily draw those boundaries, sort of thinks about the entire enterprise as his team, will actually figure out if it is a compelling enough business driver, how do you basically build partnerships across the enterprise to basically make some of these things happen?
Because I think that's not it.
So that's why the enterprise architects, in many ways, it's a hard job because measuring the effectiveness of an enterprise architecture organization has been a debate for decades.
But the good enterprise architects are the ones, when you go into an organization, you will know who is good, who is not.
Because you look at the number of connections that they have in the organization, how quickly they can actually get to a solution, because they don't actually draw the boundaries of, hey, this is my team, I can only do X.
And I think that's the one that, if there's anybody who wants to basically become an enterprise architect or pursue that as a career, I would suggest not only just grow your domain competencies, without which you cannot grow, but invest your time and energy in building relationships.
Because without relationships, nothing actually happens in any organization.
Super well said.
When I got my start...
Okay.
My first job was in high school.
And our family had built a...
This is a long story short, hopefully.
My family had built a house.
My wife and I promised each other never to build a house together.
But my family built this house, and I got this...
My dad got me an internship, let's just be honest, at this architect firm, okay?
Like not technical architecture, like drawing architecture.
And I worked there for three summers.
It was the coolest job, but I also learned I didn't want to be a building architect.
But one of the things that I learned from experiencing that was his job was to make other people successful.
If he had to go into the...
He had maybe 30 projects going on at any given point, right?
And he was drawing up these designs that were part of that ecosystem.
He wasn't just drawing designs.
He was having real conversations with the builders and the teams about how to make this work.
And he'd go in and build and design this architecture with them that allows them to be successful in the ecosystem.
I think that's the secret of our jobs, our technical architecture, is not to be like, if we're jumping into every problem individually to address problems and product teams, we've probably failed.
Our job is to enable them to have velocity.
And velocity in a safe and appropriate way.
Not driving the car off the cliff, but like, I can drive it 65 on this road because the guardrail is going to prevent me from flying off and dying unless I'm really crazy, right?
In which case, there's no other protections.
Our job is to enable that.
I think the secret of it is, do my guardrails enable the balance between velocity and security and starting up and slowing down without me having to constantly be involved in the team?
Or have I built something that causes me to constantly get pulled in as the expert?
And I think that's a little check for us all the time on that.
Okay, next question.
You want to hit that first?
Yeah, yeah.
So to me, I think, you know, the one principle that I sort of held on to very, very dearly over the course of my career has been, be business-oriented.
Understand the business.
Whatever domain that you're actually getting into, understand deeply enough that you can have a robust conversation with any business stakeholder or a technical stakeholder, right?
Once you do that, once I understand the business, then when somebody's actually articulating, this is a business need that they're actually trying to basically solve, then you can actually answer, hey, this is how we can actually solve it.
And these are the trade-offs, right?
Maybe not but, right?
Because a lot of times when, you know, if you have actually dealt with enough number of business executives, you know, when they read a magazine and they think that competition is actually, you know, embarking on something that actually has a tremendous revenue potential,
they don't want to hear any buts, right?
They want to hear how something can be done.
So understanding the time as to when you can actually have those conversations.
And all that stuff actually comes with building solid relationships with some of these individuals.
And it comes with time, investing time with some of these stakeholders.
So I think, to me personally, one is, you know, understanding the business and understanding the fundamentals of the business and then how does technology actually support some of those things and what are the risks and regulations that you need to stand behind,
right?
And helping them understand some of those things and becoming a trusted partner because eventually you prove it once, two times, three times.
They know that you're not actually bullshitting.
You're not saying no for the sake of saying no, right?
Then you earn the right to have the firm conversations with them and then say, I strongly advise you actually pursue this or I strongly advise you do not do this.
The way I would react is, yes, business value is critical.
That is the common goal across all groups.
Governance, legal, privacy.
So you have to kind of articulate that the function of all governing bodies is to enable the business and embrace conflict.
The teams which are bringing their issues or pushing back on a particular solution, they have a valid point of view.
So once you have a common goal that you have to enable the business, then you can work through those conflicts or you can work through those challenges associated with it.
It might require compensating controls.
It might require risk acceptances.
But you can move past that.
So I think aligning on a common goal that business is the most important thing which we are working towards enabling, that's critical.
And embrace conflict.
That's key.
Man, I love that embrace conflict.
I was going to say that.
Nice job.
Yeah, for me, that's right up there.
This idea that be willing to be wrong, be willing to engage in a conversation that is going to challenge you and challenge the people in the room, but do so in a way that everyone is seeking the truth.
And take the badges off, take the egos off the table and be willing to work toward a solution.
But then ultimately for me, I'd say the hallmark of my operating system is define where we want to go and then work toward that goal.
And that's easy to say, but most people aren't doing it.
Which is like, do we actually know where our destination is or are we just shipping whatever?
So define that end in mind.
I just mentioned that before, but I think that's really the key thing.
What is the end in mind?
What's the architecture of the end in mind?
Have we agreed to it?
Do we then understand the roles, responsibilities that are associated with that?
Because that's like the secondary problem.
Maybe you've associated with the end in mind, but you have a disconnect between roles and responsibilities to get there.
And then a lot of conflict comes up because different people believe their roles and responsibilities are in different ponds than they should be.
So really making sure that those lanes are clear, not in a way that's competitive, but in a way that is complementary toward achieving that goal.
Yeah, I'd say those are two huge things for me.
Sir, I think you had a question.
Accepting risk on a level where...
Yeah, yeah.
Why don't I give these guys the last word this time?
I just had a situation come up with this exact thing.
So I was immediately excited about this.
One of the things that we have to do a lot of times when we're engaging is determine what is the operating model that a company wants us to...
Who's power?
And what's the operating model they want us executing under?
Are we staff-logging this and you're in control?
Do you want a partnership?
Or do you want us to be in control?
What's the situation?
And in your case, maybe you're in a situation...
Let's just theorize for a second.
You've figured out there's a list of problems with the software or platform that needs to get addressed.
You've ranked them, you've prioritized them, you've given a clear background on what the issue is.
And you've then given that in a constructive and appropriate way to the team to prioritize.
You've done your job.
You put that in front of the team.
You're transparent and effective about conveying what the issue is.
And then you give it to them and you say...
You describe now.
You're the people making the decision.
You describe what the priorities are in this system.
And we have to live with it.
We only can make so many decisions.
So we've only put so many dollars so many places.
And if all we do is the security things, maybe we never get a feature out.
And vice versa.
So from my perspective, it's about the small number of decisions whoever has true power is making to be able to prioritize the stack.
And that's probably product management and other folks in the game.
Yeah, thanks.
Yeah, so I don't know.
I would say I would...
I never ran into...
I did not run into a situation where I actually gave up when there was a huge security risk.
I think the way I would probably approach it is there are a lot of contemporary frameworks around how do you basically classify a risk.
Right ?
It all comes down to basically, going back to what Nathan was saying, it depends on the organization maturity, but at least the organizations that I've actually seen, there is some sort of a risk management framework.
Right?
And you go through the criteria of identifying some of these risks and articulating what's the business impact of that particular risk.
Right?
And then also understanding who are all the stakeholders that actually have to make the decision and what is their leadership style.
For example, some of these stakeholders, at least the ones that I've actually seen, they fall into two broad categories.
Some of them are actually very emotional about the solution that they're actually thinking about.
They're probably not too much data oriented.
So you can't actually approach them with an analytical band of mind and then say, hey, you know what, these are all the numbers, this is where it is.
They're probably not going to listen.
You're not going to get their ear.
Right?
So you need to understand where they are and meet them where they are so that you can actually communicate effectively to them.
But there are other stakeholders who are actually very much analytical.
They want to look at the numbers, they want to basically understand how does it actually score, what are the ways you can actually mitigate, are there any mitigation controls that you can actually put in, what is the cost of doing some of these things,
what happens to the overall business case.
I think there are a set of gamut of things that you need to basically kind of think about on some of these things and see how do you, at the end of the day, if your fundamental interest is business orientation and solving a problem for the business, people will,
once or twice, you might actually lose once or twice, but the third time and the fourth time, you will actually win.
Well, I kind of understand where you're coming from.
I would take a two-hat approach.
First of all, let's kind of align on security organizations is incentivized to identify the organizational risk and stop the project in order to get them addressed.
So you're doing your job and then there is a scenario where the business needs to move forward and they're going to try and bypass it.
So at that time, you've worn a hat of a security architect.
You've identified the risk.
You've documented them.
Now you have to switch hats in order to help enable them.
Now you give them compensating controls or you work with the GRC organization.
But again, you have to wear a separate hat.
Otherwise, you will get frustrated.
It's not an easy job to do.
Awesome.
I think we've gotten to the end of our time.
Super thankful that you spent some time with us.
This was really fun.
I really enjoyed it when we opened up the AUS.
That was a lot more fun.
So thank you for spending time with us.
We'll see you guys later.
And I think we'll stick around a little bit.
We've got to get over to that lunch thing.
Awesome.
Thank you.
Thank you all.