Session Information:

Data-Driven Digital Transformation: Enterprise Architecture & the Chief Data Officer

For digital transformation to succeed; organizations must embed data-driven intelligence into current and future operating models as well as identify ways to accelerate the organization's use of data. With the emergence of data, analytics, machine learning, and artificial intelligence as core to all modern organizations it is essential for Enterprise Architecture and the Chief Data Officer to partner and enable the data-driven future organization.

Key Takeaways:

• Digital disruption as the new normal
• Understanding of key capabilities of a Data-Driven Digital Transformation
• How to build an effective EA & CDO partnership
• Enabling the Data-Driven organization

Session Transcript:

And the reason I'm excited that Jason is the person talking about this subject, is because he's done that for 20 years, and while he hasn't told me this story, I guarantee you.

there were bad days, ugly meetings, dysfunction, some things weren't brilliantly. Some things went badly, right? And that is how you can start to identify the trends going forward.

So Jason Barr Group, just kinda give us an eye presentation on what are the trends that are emerging, and most importantly, what you can do about them and ride those trends like a wave instead of have them write you.

Jason, the floor is yours.

Thanks very much, Chris. I've definitely got some scars. I'm sure there's plenty of people here that have scars as well. So, let's say, let's share some stories.

Live my job in other piece to do research in the industry. I've worked in the industry for a long time, as a consultant, and a chief architect, and our work in, our work in the tool company. But my job is to research the industry, and drive that into product support, and that's what a product strategy, And that's what I want to talk to you about today. What are the trends that we're seeing in the industry?

How can we, how can you deal with those?

So the first thing is just to give us a framework to talk about it.

Enterprise architects, we, maybe the biggest problem we see, an Enterprise Architect, gerry's, teams that so, focus solely on doing enterprise architecture. The goal is to just do enterprise architecture.

The ones that are successful, they're doing enterprise architecture to drive forward the business.

I know that might sound sound like a strange distinction.

But there are far too many people whose purpose is just to document.

Or just to precisely model the way things are.

But not to get use out of it.

So we want to focus very strongly on what are the what is the value proposition that you're providing to your company? And we see that that enterprise architecture breaks down into these three big buckets.

We want to support our company and they are increasingly digital whether whether the companies know it themselves or not.

All businesses are digital businesses and change is increasing in speed and the amount of IT intensive nus, the digitalization is increasing.

Change is getting increasingly hard.

So, when we talk about, how does enterprise architect and enable continual these digital business design, continue with digital business, evolution, it just starts with getting control of your, as the situation. That's the absolute first thing.

You want to drive forward change, but if you don't have control of where you are, then you can be, as well as, support, can't be as good or support as you possibly can be.

So providing this transparency, as businesses become more digital, as they become more IT intensity, it is much harder to understand how the business operates through IT.

It's just a black box, and if you take that thought to its logical conclusion, that's not a nice thing to say, but it is absolutely true, that many business leaders today have no idea how their company operates in practice.

Because they do not understand how it flows through IT.

I do not understand the consequences of how they want to drive their business forward, because it is this black box. So we have to open it up.

We have to make it transparent.

When change is happening so much, we have to provide a controlled governed operation.

Absolutely.

Put this when you speak to CIOs, when you speak to VPs, when you speak to CEOs, They can handle bad news.

Old business people handle bad news. I get it all the time.

What they really don't like is surprises.

So at the beginning of a budget cycle or a strategy cycle, your VP will have a goal. This is where we want to go as a business.

This is what we want to achieve, And that will result in change to IT.

If you can give them stability.

If you can give them confidence and how you drive that forward, that's fine. That's the best you can hope for, even if, sometimes you have to say, no, that's not possible.

Oh, we can't do it this quarter or this increment. We have to do it later.

That's OK.

But, if you get unexpected problems, because you know, some end of life happens on one of our systems.

And we have to spend three months replacing this, or upgrading this application, which means three months, where we're not delivering value as a company, that is the absolute worst thing you can say.

So, providing, providing controlled operations. Minimize that run cost. So you maximize the chain spend. That's like the very first thing.

Then we go paint to change.

Where many of enterprise architects want to be, how can we be involved in driving strategy to execution, and that, that requires two things. one is, how can you have a direction?

Not so much a target architecture, I'd say a target direction, because you never get to your target architecture. Change is always happening. The context around the company is always happening.

So, it's all about adjusting the direction for people to follow and making that visible for everybody.

And the second part, this is probably the hardest part of it I dealt with in my career, and I know many of the companies I've talked to, how do you prioritize?

There is always more ideas, and there are people and capacity to do things.

What should we do and why? How does an Enterprise architect help in that process to make sure we're getting the best bang for our buck as a company?

That's the big thing.

This is where we want to get enterprise architects to really become not not part of the see in one of the jobs I had. We used to be jokingly referred to as the Department of No.

And you don't want to be the department that people come to and say, How do we can we do this? And you say no.

You want to be the group of people who say these are the possibilities.

I understand what you're trying to achieve.

This is possible now. This would be a second step.

if we adjust your idea, then we can go this way instead becoming the Department of Possibility instead of the Department of know.

So that's the next step, the next value proposition for EA.

Then the third thing, and this is what we see very progressive organizations working on.

And sometimes it's the enterprise architects that are explicitly taking part in this process, and sometimes it's enterprise architects who are reacting to this happening and figuring out what to do, and that is, how do you deal with continuous change in how you do your way of working in the company.

So, we have, we have the company as a whole, that's the enterprise itself, sometimes designing.

But within that system, we have the system that changes the system.

The group of the organization that's doing the development work often well, or procurement and driving forward new solutions, you can think of them as a system too.

How can they work so that they can deliver change in a better way?

And, that happens in a continuous process.

More and more companies are moving over to these.

No, either project, a product, or value stream based approach, and product areas.

Whatever you call it, It's all about, how do you improve the throughput of change in your organization, how do you organize yourselves so you don't have this distinction between business and IT?

How can you distribute decision making this? And this is not a one step process. This is a continuous, continuous iteration, continuous feedback loop.

And it has a consequence for enterprise architects.

We'll talk a bit about this today and that is the need to democratize enterprise architecture.

The need to go away from centralized teams, or maybe not go away from, but to reduce the capacity of centralized teams, and spread out the decision making of enterprise architecture in an organization.

So they're the three big buckets that we think about when we think about how the enterprise architects, what enterprise architects work to deliver outcomes.
So now let's look at a few trends, and then we'll push those back into this framework to help explain the trends.

So, the first trends we'll talk about is digital twin of the organization.

This term has been around for a few years now. I think it was introduced by Gartner awhile ago.

The terms not so important, the principle that underlies it, is important, and the principle is that, in order to deliver outcomes as an Enterprise architecture team, or federated team, you'll try to help people in your organized organization make decisions, either about running the business or changing the business or way of working.

And the way you do that is to take the traditional enterprise architecture models, and combine them with business behavior.

What are the events that are happening inside your company that, combined with your architecture, help people make decisions faster and with better quality?

That's what we talk about when we talk about digital twin.

So originally this idea came from creating simulations of physical processes, but factories, mechanical design systems, production systems, molecular design systems I've seen as well.

The idea is, instead of just changing the system and hoping for the best, can you model the system, can you model the system and all the events that happen in the system.

So that you can change the simulation, and you can understand how things will work better?

And then make changes back into the physical system?

And if you apply that to Enterprise Architect or apply that to an organization.

If you think of the enterprise design itself, it is a system.

And the subset of that organization, which is driving forward change, rather than operating with the change driving forward change. That is a system within the system.

And for both of those systems, traditionally, we model them. We created our process views, and we create our capability views, and I don't mean that those down into different realizations.

But it's the way to get the most value out of it, is to combine it with behavioral information.

So which way, We take an example or I'd if, if you model a business process for customer onboarding, you might have a very nice multiple level process showing all the different stakeholders involved and applications, and all the different steps. And it may be imperfect whatever notation you choose to use.

But it doesn't really help anyone.

It might help if someone says how does that process work?

I'd like to know But that doesn't happen very often.

What they want to know is: why does it take five days to onboard a customer? That's crazy. We can't have a customer ordering ordering our, you know, product. And then they get onboarded to our product or service in five days.

They need to be onboard now.

So if you take your process, and you combine that with behavior information that you're measuring from your actual application, from your actual systems, to say, know what, From step one to step two. That's instantaneous.

That's fully automatic, from step three to step four, It's actually a types three days.

And the reason that's taking three days is because our self-service solution is so bad that our customers keep bringing in customer support, wondering what to do.

If you can show that, if you can show both the process and the behavior in the process to a decision maker, then they can decide, you know what?
It makes sense for us, that delivers value for us and our customers to go and make that change.

But you will never be able to make that decision If you're only showing the architecture itself.

That's when you overlay the behavioral events on the architecture.

That gives people the information they need to make decisions.

That's what Digital Twin of the organization is about: overlaying business architecture, application architecture, et cetera, with operational behavior so people can make decisions.

Next trend: Co socio technical architecture, socio technical architecture: Risk is an underlying enterprise design principle, the concept of open, Open socio technical systems, or open systems in enterprise design theory.

So, it's a very underlying principle.

The concept is that, well, the last, let's see, 50 years since maybe the late sixties, early seventies, it's been trained in in enterprise design or management theory.

Treat people like resources, human resources, HR, mean that the problem is in the name.

Treat people like Dumm automatons, and try and have a centralized command and control structure to tell them what to do and how to do it.

But the trend in the last 10 years, at least, has been to go a different ways to recognize that, people are not robots, people are not just resources in a spreadsheet, especially for us that working knowledge based systems are sort of knowledge areas.

People are incredibly knowledgeable.

People are very motivated, people are very creative, instead of having a command and control infrastructure to tell them what to do.

People are waking up to having, OK, let's organize teams, or let's make it possible for teams to organize themselves in order to solve a problem.

We don't need to tell individuals with a very strong hieratic management structure, how to solve a problem, we need to identify areas of autonomy in our company.

We need to explain to them what the objective is and the key results.

And, we need to allow them to identify these, people, with the most knowledge of how things work.

in detail, Allow them to create the solution, allow them to deliver the solution over time, allow them to use their creativity to come together in different ways with their skills.

So, it's all about opening up business, distributing a business, distributing the autonomy.

But at a fundamental level, it's about empowering people.

So we see this trend and we'll talk about it in a minute.

We see it in many techniques in many ceremonies. Now, but this is the underlying principle.

Let's just explain that.

So, for many organization, at all about, how do we get more throughput of change, how do we deliver more to the market, to our customers and our partners, how do we do it in a more reliable way, in a higher quality way, and faster time to value, continuous improvement?

The underlying principle that many people are using, whether they know it or not, is this socio technical architecture.

It's understanding that a command and control infrastructure is a bottleneck to decision making.

It may help in the initial investment process, that may be OK, but there will always be escalations afterwards.

Because you have a rigid hierarchy, people have to be prioritized across multiple different teams.

In order to do that, you need to create, you need to create projects.

Quite often they need to have deadlines so they can be funded.

As things change, it's really hard to change the scope and direction of a project.

So you stop escalating.

You start dealing with change. You start dealing with ripple effects across projects.

But if we go over to more of this distributed decision, making more of this Agile approach to cross functional teams that can organize themselves in a more fluid way and understand where they can take their own decisions, then we get more throughput.

We don't want to do it in an undisciplined way.

We want to We want to make sure it's disciplined.

Agile requires discipline, but we want to make it possible, but not many people speak about this principle of empowering people. I often talk about techniques, which is the next part.

Going from projects to product areas, is one term that people use in the industry, and another is to use value stream based development, And you, you may do that in a, in your own Agile way.

Or you may use a framework like safe, disciplined, Agile delivery, Or, you may use the term, these DevOps or something similar.

The point is, there are.

These are the books, but many people are reading now. These are the techniques that many people are applying.

These are fundamental the tongue follow step by step instructions on how to achieve this distribution of autonomy.

one of the problems we see, is, if you try and do something like project the product, without understanding the principle of socio technical architecture, then your, your Cargo Cult in nine in the industry, right. They are applying the technique with understanding the principle.

If you have A command and control hierarchy, and try and use product areas instead of projects, it's going to fail eventually.

So, the way people fail, if they try and apply agile techniques without understanding the principles of Agile.

If you're, if you're just trying to apply the technique, you will eventually fail.

Sorry, assuming people go around this, this loop.

I understand the principle.

They start achieving, let's sorry, let us start implementing techniques such as Project product.

Then one of the consequences of that is Enterprise architecture, as we know it gets democratized.

As teams get more autonomy to take more decisions, enterprise architecture decisions move out to the to the product teams or value stream teams rather than being centralized. Now not everything can be distributed.

There will always be things that go across value streams or product areas.

So there will always be a need for enterprise architects that work across the organization.

But one of the goals is to understand that we won't always be making centralized decisions.

Sometimes we'll be enabling the set up so that other people can take decisions in a federated way.

So let's go into that.

So, if I go back into business, IT, Transparency, and Governance, just quickly re-iterate that it's about making things visible, it's about having your traditional enterprise architecture information.

And combining that with the organization, information, people's apartments, teams, value streams, whatever it is, an understanding enough, so that you can control what you're doing to enable change.

And as an example of what does it mean from Digital Twin?

What does that mean from socio technical architecture?

We say that enterprise architects and now applying behavioral information from digital twin, such as measuring non functional requirements issues, applying those onto the enterprise architecture, something as simple as applying cost information, or including cost information in their enterprise architecture models, and rolling those up.

So that decision makers can see that consequence in a cost perspective of what they do.

From a socio technical architecture, it's understanding that the reason that you document, the reason that your model is so that other people can understand, in a, in a medium, to large scale organization, it is maybe one, 1% of the employee base.

That has A, high level view of how everything hangs together, and it's probably you brought the Enterprise Architect or your team.

Everyone else is focused on their job.

But when they need to understand, when they need to make a decision, when they need to collaborate, they need to find that information fast about how everything hangs together.

And ideally, they don't have to come to you, because you set things up in a way that it's easy for them to find that information.

Not because you don't like talking to them, but that you get to use your time on strategic design.

Which is what almost all architects want to do, as well as the collaborations.

If we then go over into, what does that mean in terms of driving change?

Well, we want to have our traditional enterprise architecture models.

We want to, we want to create the current state and the future direction.

We want to document that and make it possible.

But we want to do that in a way that supports the prioritization process.

When people do the prioritization process, they care about three things. What is the benefit?

What is it going to cost? How long is it going to take?

And your enterprise architecture needs to answer those questions, or it needs to facilitate the conversation, to answer those questions, in the fastest way, and in the highest quality ..., so that people can make decisions about prioritization.

What is the benefit normally that comes with, with the initiative, the change initiative?

How long will it take?

In order to understand, how long will it take and what will it cost?

You need to very quickly understand, what is the proposed solution, and what is the impact into the organization?

Which systems, which processes? Which teams are going to be impacted by this proposal?

And for each of those, how do we get those into the process? How can we then get their information about, OK, well, my part of the system is about so big.

That's going to take three months, three months, it doesn't have to be perfect estimate.

It has to be an indication of the size, so that you can make the prioritization decision.

And for each one of those, you can say, Well, what do you already have prioritized in your backlog, OK?

Well, it's going to be it's going to take us to prove to program increments or seminary sprints in order to do our part of the change, but we are currently already prioritized for the next three increments Linux 12 sprints, so we can't get that.

We can't even attempt this until whatever the date happens to be.

And if you do that for everybody that's involved, you very quickly get an understanding of cost benefit and time, and from there, it's not to quickly make a Yes, or, no, decision.

That's almost always to start negotiation, negotiating.

This is where you start becoming the Department of Possibilities.

OK, we have an ID or change initiative now to go to market deliver this new product or service idea.

The way you currently envisaged that we can see a timeline of where the different people the different teams need to be involved when they can do their work.

But, if we change and, say, Looking, instead of going to market, uh, instead of going to market with a full, covering all our channels, let's just go to market, just with a mobile channel.

And let's make it fully digital, so that we don't have to involve customer service.

Let's try and do it with a soft launch with a particular part of our customer base, which are comfortable using our mobile channels.

And, let's test, if the concept works.

Let us actually find out, and, if it does work, then we set up Phase two and Phase three, where we build out the solution.

That's when you can start having that conversation.

That you start becoming an Enterprise architect that's part of the code design.

Your company, rather than the Department of Note.

That's when you start showing that you can provide bang for the buck.

Yeah, it's about getting value out to the market.

It's about you, who really understands how the business operates through IT, facilitating the conversations with the distributed value streams, or product areas, in order to show possibilities, to make changes.

And the way, the way you do that, is on top of your enterprise architecture, you need to show you what's happening in terms of change initiatives.

You need to show the change initiative process from ideation, through prioritization to actual execution, in individual value streams and teams.

Being able to show changes in status, OK?

Now this part of this change initiative is finished, which means this team could potentially be re prioritized to help with a new initiative, which we think is very important.
In terms of the people, people are the ones who have the knowledge about It's not always the enterprise architect to understand everything have a shallow overview And probably go deep in a few areas, that they know who to talk to, Who have the depth in all the areas?

How do you facilitate that process?

How can you include, in your enterprise architecture, older people, teams, and value streams, so that you know who to talk to all, probably, better, so that they know who to talk to.

So they can work together to develop new ideas, develop new possibilities.

When you do that, you start understanding the impact. You start showing the connection between these teams and strategies So that they can come up with more ideas.

You can use them to be the knowledge. Another fantastic, creating knowledge workers that they are.

It's not about you just doing all the work and distributing the load. You're facilitating people working together to get more throughput to get more value out into the market.

We can go into the third one, which is, How do you as an Enterprise architect to help, with this continuous way of working?

So we just talked about the change process, and how important it is to understand the change process, and actually have it, part of the enterprise architecture.

Once you have that, you can start measuring improvements in the change process.

So change process is about getting feedback in feedback, about how you develop change, and feedback, about how you democratize change.

So your goal is to move away from plan, build, run, continuous value creation, But you still have these many steps.

You have your ideation step, and you have your prioritization step and you have, if things fit in one value stream, that's great and it can be pass to that value stream and they can determine a solution.

But, there will always be some things which cross value streams and teams or autonomy areas.

And then you need to go through the process, we just discussed.

You can measure that process.

How many of our change initiatives require going across different value streams or teams?

What is the trend over time?

How can we change our value streams, re assign teams, so, that have different areas of responsibility, so that we can get more throughput?

Because, when we have to prioritize across teams that have their own priorities, that's when things are hard.

It will never be possible, while I've never seen it possible.

To identify value streams and product areas perfectly, so that everything can be isolated.

You may be able to reduce the amount of cross area prioritization you need to do, but I've never seen it eliminated, But you're trying to do that.

How can you continuously change? You need to measure lead times?

Measure prioritization times.

You need to measure team handoffs, because those friction points between teams away, you are wasting time generating value in the marketplace.

And once you measure, you apply that on to your enterprise architecture.

To show, OK, maybe we can reassign teams.

Maybe we can use team topologies in a way to understand, Let's split these teams.

So that one is deliberating customer value.

But another part is now focused on delivering some of the plumbing which we see as is always needed in all of our change applications, doing organizational that's the term. I've just lost it. There's organization organizational analysis, which will show you communication handovers between teams.

How can you analyze that, measure it, and overlay it?

How can you include people in the process who probably understand this better than you within their area, Include them in the process so they can help you adjust the enterprise design to get more throughput to improve the way of working?

So that was a quick look.

And enterprise architecture trends.

So we start by just saying enterprise architecture, there are three types of value, whether they're 3 or 4 or 5, how you, how you categorize it is not so important, but the point is that there are different types of things that we do.

And we have these major trends, one that is all about adding behavior of your company onto the enterprise architecture, the traditional structural architecture.

So that you can help make different, help make better decisions in those three areas, of controlling the as is or driving change, or improving how you drive change.

And the other one, the social, technical, socio technical architecture, which is all about, how do you get the most out of people?

Do you treat people, not as a resource, but as the creative, are motivated, proactive knowledge workers that they are, and allow them to take some of the autonomy, the decision making, as enterprise architects?

Sometimes that can be a bit scary. So we haven't seen a reduction in the need for enterprise architecture.

It's just about where it happens, and how it happens.

And there will always be a need for enterprise architects to make these kinds of decisions that go across.

But, sometimes, those decisions are happening out in the teams or value streams, sometimes that heping centrally, because that's where it makes sense to happen.

But, there's a need for Enterprise Architect, who can enable that to happen.

So, instead of just making decisions, just doing documentation, that's now about facilitating how others can participate in those decision making processes. There's documentation processes.

So, if you, uh, if you wanted to have a takeaway, that you could use tomorrow, I mean, I'd start with, what are the outcomes you're trying to provide?

Not not so much, how do I do enterprise architecture?

Because one of the things we've found is there's a huge difference between, let's say, between precision and usefulness.

Many enterprise architects, trying to be precise, we must model or document, exactly how things work.

But, you end up with something so complicated that no one else, apart from yourself can understand that.

There's a big difference between that and saying, how can I produce something useful, because these teams that are here need to drive toward their own decision making.

I need to provide something useful so that my VP of B2B sales understand its possibilities, rather than a Yes, no.

That's a different mentality.

It starts with outcomes you want to achieve.

And then once you have that URL about how can we have a democratized enterprise architecture process that improves the quality of decision making for these outcomes?

Improves the time to decision making for these outcomes?

If you can, if you can talk to your CIO, OT, or VP, and whenever they say, how, how hard can that be? How complicated is that? When can I have it?

If you can answer that question in a week, instead of three months, with better quality. So that they can make a decision about prioritization, then that is a huge change in the value that you're bringing to a company.

So they do that. And so that's that's our approach. So that's how we see trends in the marketplace.

That's not so much about new trends, It's about how these principles of adding behavior and treat dealing with people, how they and the democratization that ensues.

It's about, how do you incorporate those schemes into existing techniques that we do?

Jason, thank you very much. I was going to ask you a question and then someone actually asked almost exactly the same question.

And part of this, you included in your, in your presentation.

But let me ask it anyway.

You're going to hate this comparison, but I'll say it anyway.

There have been historical examples, we're leaders have delegated everything externally and let everybody do their own thing, just say some basic, vague stuff and see what happens to famous people who did that, or Adolf Hitler and Putin, and you can see what the outcome is. Because they don't have what you're suggesting.

That is what I'd like you to spend a little bit more time on, and that reflects one of the questions. Let me read the question ever very clearly.

First, he says, thank you very much for the enlightening presentation.

What competencies does the enterprise architecture organization need to build to improve in order to be able to get to the level of capabilities you've described?

Now, you said some of that, There's, it's really, it's easy for people to go command and control, right. Because it feels it, Even though it doesn't work. It feels like you're in control.

What do you say to the people?

Whooo you're you're kind of saying Let go those, those hands a little bit, like, How do they do that, Can you talk about that OK, that's a tough one, So thanks!

You're right. It's it's an interesting way to frame the question with what's going on in the world at the moment.

If I can ...

with the, with the people that you names, one of the, maybe one of the famous terms that came through and those people are well as well, is trust, but verify.

So in Enterprise Architect Terms, that's something that you can adopt.

Also, one of the things I said, as we went to Lung, is, Agile, Agile requires discipline, right, talk, talk more about that, That's really important. So, what we're talking about here is not anarchy.

It's not giving.

That's not giving carte blanche control to people.

It's about distributing some of the autonomy.

But those people are part of a process. You're all part of the same organism, the same organization.

People can't lose sight of that.

So what you're saying to people is, I trust you to make decisions within this product area.

But your job as the as the top level Enterprise Architect, and some of the capabilities you're talking about.

Is being able to define and document what those domains of autonomy and why communicating them in a good way.

Most probably most people.

one of the one of the terms I like to use, if you've heard of the term headlands raise up Netherlands res.

Go to something like never attribute to malice that which can be explained by stupidity.

If you drop stupidity and just say explained by lack of information I'd never attribute to malice that, which can be explained by lack of information.

Just me, keeping that in the back of my head.

Like, when I used to work as a chief architect, and I had 26 different architects across six different countries, many different subsidiaries working.

I couldn't be on top of everything.

And people would always do something that, that I didn't like, but I would always try and remember, they're not doing it.

They're not doing it to make me unhappy. They're probably doing it because they don't understand.

They're probably doing it because they do not have enough information.

They want to do the right thing, but they don't have the information to do the right thing. So it's my problem.

If they're doing something I don't like, that's my problem, to make it more obvious, where are they, where they can take their own decisions, and why, and where they need to communicate, either with me, or with a colleague and a different team.

And that's something that enterprise architects need to, as part of the competence, right?

Trust, but verify.

And when you verify, it's not because someone's trying to do the wrong thing at A, to kick up the bump for you to say, I need to enable them to work better, They are probably trying to do the right thing.

Now, I'd say in nine times, out of 10, people try and do the right thing. But there's always a spectrum of competence.

Help them do the right thing.

Michelle.

So Jason, I hear in that if I'm again, you and I are working together in the same company, I'm hearing two major dimensions.

one is hiring and keeping people who share your values, trust, level of collaboration, etcetera, because you cannot fix a diabolical.

Machiavellian actor in your organization. Who's just out for themselves. You just can't fix it. You gotta get rid of those people, in my opinion. And don't hire them to begin with if you can, avoid it. Right. So that was the first piece.

And then the second piece, which, I think, is what the questionnaires is focusing on, is, so you got all this autonomy, but you only have so much autonomy.

So that seems to be where the magic is, is to tell them, you have autonomy, within these bounds. It's almost like you, you directed someone. I want you to go decorate this room in your house, but stick to the basic motif for the rest of the house.

No not to put pastel colored wallpaper or something up if the rest of the house doesn't look like that.

So I know that's a grossly simple example, but I think it's the nuance, right, where you're saying to someone, understand our esthetic, understand our design, methodology. Understand our approach, our principles, stay within those bounds.

Then you've got all the autonomy in the world.

And by the way, I trust you, so don't do anything. Terrible.

I am describing that. Kinda, right, yeah, that's right. That as part of that, that hiring process, or getting people into your team process. I mean, I know, it's hard, all of us, all of us have been involved in hiring processes, how do you ask the right questions.

Somehow, you know, you need to find out, I guess we all, we all work with people who think that enterprise architecture is how can I document correctly undocumented.

If someone says that, you know, they're not the right people for this kind of role, right.

All right. They are all about how can I deliver value in a controlled way, according to the nonfunctional requirements and the principles, and should we use pastel colors or not?

That's what you're trying to find out, and they're the conference's competencies you're trying to build in your team.

You know, we all have to document according to some notation but that's not the end goal. That's That's just the tool you use sometimes.

I think there Yeah We're out of time on that on the presentation, but I think I assume you're open to questions If someone sends you a question and wants to talk to you about this.

That's very important because that What you're describing is a level of sophistication.

That is magic when it works.

All right.

It's just magic, and, and that's why the whole point of your talk was, what is the future, and what are the future trends, or where are they going? So I would say to anybody on the call, if you're listening to this or listening later to this, and you go down, that sounds really hard to do Well. Yeah, that's the future.

Right.

But as you take the steps to build that organization, you'll be able, at least, you know, what your North stars, your North star is to get to this level of sophistication in the world.

And the most important, nice, I say in my book, helping humans be heroes in the age of automation, well, you could say, helping humans be heroes in the age of sophisticated enterprise architecture.

That's what you're helping them bring out, Yeah, Maybe I can quickly change that, will make an Airbrush. Anyway, if you're interested, more than happy to have a chat.

Reach out to Jason, and I want to thank Jason, you and your company for sponsoring this event. It's incredibly helpful to do that.

This was an eye opening.

kind of, you know, mind twisting, which is exactly what you were. I think we're trying to do and help us think forward and figure with the sophisticated layers.

And thank you for your 19 years before this year of success, including the scars and the victories that brought you to the ability to be able to communicate this topic the way you have, Jason. Thank you, everybody. Thank you very much for joining. We will have another session coming up. I will be gone for the next hour.

I haven't conflict. It was prior to this. So, we will have Brian, I think will step in and do the next section. And that's going to be Bailey from the Tupperware Company speaking about his journey. So everybody joined back up in another hour and again Jason, I simply say thank you very much for bringing all of your insights and ideas to a group of people who will probably send you some e-mails you get some questions.

Looking forward to it. Thanks.

Take care, everybody, see in an hour?

Absolutely. For the rest of the audience, we'll see you in 15 minutes at the top of the hour. We will see Chris.

Thank you.

Thank you.

Blah, blah.