Session Information:

Data Governance has become a hot topic in most data camps of late. Now, more than ever, governance has an opportunity to focus on the consumer impacts that data while delivering resilient systems. Governance is no longer just about defining data, building catalogs and defining standards – it is time for agility and expansion of our thoughts about governance as a whole.

• Defining agility in governance
• Building trust and engaging data consumers
• Breaking the mold – tips on driving consumer first principles in data
• The non-functional requirements that drive consumer satisfaction

Session Transcript:

He is Andrea ... for joining us, from nationwide to talk about: the journey of Enterprise Architecture, Customers, and Operations, and how you bring it all together.

Andrea has over 20 years of experience building in consulting, quality, process, and information management.

She has a proven success in offering organizational best practices for integration, data, quality management, and fitness by design. She is an IAS, a certified, CI T D information Architect, and is certified in six Sigma, and Lean.

She has designed and built a data quality and analysis framework with predictive models, developed and executed data management standards, resulting reduction of data loss, designed and executed on enterprise level data rationalization strategy, and data repository ranking.

Andrea, what a privilege to have you with us. We're super excited about your presentation, about learning more about an industry leader and practitioner who is making this happening right now in the organization.

Thank you for taking the time to share your expertise with our global audience today.

Absolutely, and thank you very much. I'd like to welcome everybody today.

Good morning, I'm in Columbus, Ohio.

And I'm going to talk about, if you noticed the very long title that I had, designing a customer focused Governance Model, that aligns business architecture for competitive advantage and continuous improvement.

This is a mouthful, and it kinda makes your brain starts spinning. So I want to break this down a little bit. Before I get started.

Customer focused is a tough one. A company exists for a reason.

Providing services or products, I speak in terms of data, Let's face it.

Data is the backbone of a company.

Governance data is the key to competitive advantage and continuous improvement.

The data comes through somewhere, rather recording a click, or entry into a text box on a website, purchase of a product or services.

Then there's all the stakeholders, depending on that information, once it has been recorded in process.

In this case, we will be focusing primarily on the stakeholders, not the origin of information.

While I might mention safeguards along the way, I am focusing on systems of data and their subsequent life cycles, and that accompanies a customer base governance model.

And that again, a bit vague and a large concept.

When I think of governance, my head explodes into a million threads. It's actually like the New York Subway System.

So we govern through patterns, principles, security, privacy definitions, meta data, conformance, quality management. There's a really long list, there's not one governance model to fit the world.

At the other price level, letters to each of these concepts can be exponential.

Hence, we tend to define governance at the enterprise functional level.

I will be speaking across enterprise and functional terms, but mostly focusing on functions.

Business architecture, this is the underlying system of systems that a company depends upon for almost every function of the company.

Continuous improvement and competitive advantage.

These should go hand in hand.

For every dollar you save on systems, infrastructure, process, and time, you lead to one more, one form or another of competitive advantage.

It is not just about having the hottest coolest product or service that drives a successful company.

In the end, this is a conversation about governance, data, and driving success for customers, the company, and the true gears of the Success Engine, which is the data consumer.

I'm going to take you on a journey that is an amalgam of many data adventures throughout my career. I will not give get into why we modernize, or form or integrate, but dive straight into practice and goals with some analogies.

I will not get into, excuse me, in companies that I've worked for. I have seen the top-down approach of governance.

If we can define it, place it in a hierarchy, and catalog it, we succeed.

Don't get me wrong.

Defining data for common understanding is very important.

Standards and policies evolve from examples, roadmaps.

As a reactive measure or regulatory, the origin is not important.

We all need common guidewire these concepts help us evolve our data practice.

There is a dividing line between hierarchical approaches to governance, especially when thinking in terms of day to day operational engagement.

If you look at my slide, I like to build an understanding and definition of governance based on the needs of the data consumers, So therefore, I'm doing that, functional governance versus the enterprise. Now, enterprise, those are those large ticket items that apply to the entire enterprise. standards.

Policies, and enterprise tools, for data discovery and cataloging, et cetera, but I'm going to talk about functional implementation of governance.

So this is where I diverge from the common tenets of governance, the renegade and May six bottom-up.

Let's face it, unless you are building everything from scratch, you have legacy data, systems and existing uses for that data.

In most cases, prior to my arrival, some executive Level Groundwork has already been laid.

They have charters, bowls, budgets, they've set up timelines, et cetera, but nothing really has happened as far as what are truly trying to deliver.

As I kick off a project, I start with a listening tour.

Prior to the listening tour, I figure out the org chart.

Identify the data practitioners, and ensure I have a decent representation of organizational activities, revolving around data.

Sorry about that.

My questions follow a set of themes who, what, where, why, when, and how. And as you can see, the Zachman Framework is probably one of my favorite tools. It's actually quite common for enterprise architects also.

So for me, who is your audience, your consumer? What those goals, responsibilities, and expectations for an outcome?

Where source of the data, why, the purpose, when frequency span of time, and speed. How tools, process, methods, and practices. These are the questions I asked my constituents, or those stakeholders that I've identified.

As I gather the information, I will identify major processes in a range to observe.

one of the things I like this approach, one of the reasons I like this approach, is actually because it allows me to focus on the data consumer and practitioner.

They provide the building blocks for a solution.

As they walk through processes, discuss schedules, et cetera, they typically expose challenges. These challenges drive a lot of the non functional requirements.

I'm also able to identify missing data, which will lead to new data requirements.

Also, let's face it, the data practitioners are using data today, if all we do is deliver the same data without improving the experience, or not driving advantage.

OK, at this point, I'd like to identify a Sigh Park, and this is a comment, six Sigma tools, Supplier, ink, input, process, output, and consumer.

Where we literally string together, well, we take individual processes, identify who is giving us the data, where's the data coming from, what kind of data what's the input, what process does it support, what are those outputs and who are the customers by doing PSYPACT So I'm able to stitch them all together and identify a lineage.

And while the lineage isn't literally about the data handoffs, what it does give me is the relationships of people, teams, and systems across the organization.

Now, I can determine, hey, have I really found the end of the process, or have I really found the start of the process?

Later on, I'd like to string the sidewalks together and work my way backwards through a data lineage, which will identify those systems and teams, which I've already spoken about with listed.

So, going through this process, identify not only that process, et cetera, but people are very willing to explain to you what the challenges are. I take lots of notes. And as I go through these processes, I observe as much as I can. I do a passive observation.

I sit behind the person, I just let them do their work, and tell me what they're doing, and then as we are able, I'll take a break and actually start interacting a little bit and ask me, Hey, why did you do that?

Is it necessary to open three tools when you might be able to use one, things like that, and that helps me identify some of the gaps or some of the opportunities beyond just the simple challenges that have already been discussed.

With a list of challenges, I'm able to analyze potential sources and include that in the lineage.

This is an ad hoc form, a phase like analysis. In other words, where does the challenge originate?

Where should it be identified, and how you resolve it? And where?

So, for example, if I have data latency, it's not the data consumer for the most part, that's going to be impacted, I'm going to go through this process diagnostic.

And I'm going to find out that and, you know, based on various metrics, we'll talk about that later, That while the admin system or the source system is able to provide the data, there's something that's happening in between an acquisition where the data is not arriving on time, or if it actually is at the source then.

So, the next step is to review my findings. The side talks then stitched together.

And then you start having the conversation about, with those teams that are responsible for the data pipeline.

one of the things I've always found fascinating is the relationships that form across the lineage.

Typically, I find that the source system team and the subsequent teams responsible for the data, are not cognizant of how the data is used or why it's important.

That is a very tough nut to crack. But, on the other hand, if you're bringing together a group of people, you're reviewing the PSYPACT, then they're gonna start understanding what they are true. Goals are.

It's not that they need to get data out of their pipe by nine AM or that they need to make sure that they have, you know, heuristic Lee expected volumes of data based on the time of day and day.

What we're really talking about here is being able to start connecting the dots between these groups and letting them hear each other and the types of challenges they've had.

Each perspective adds to a great story that we will later start working with, and improving processes, et cetera, or designing that new the lifeline of data.

By reviewing the existing process, we can start defining a future state by marrying the lineage, ..., and challenges.

More importantly, a community is evolving.

This, this single act drives engagement across the ecosystem toward a common goal.

These relationships drive trust and engagement through the future life cycle of data.

This is where we break them all and start driving consumer first principles.

In other words, when a baker understands that the sandwich shop opens at 11 0 AM, they know the bread must be there earlier, in order to ensure that the first customer gets a sandwich.

The sandwich shop will dictate the type of bread, and the Baker will deliver that.

I love analogies because they illustrate commonality their logic logical and they help us explain the problems that we're facing.

When I compare data life cycle to a common experience, I up route existing paradigms toward the user of the data.

Once upon a time, we refer to this as IT for business, but never quite achieve that in most cases.

At this point, we can define functional and non functional requirements, identify success factors, and we've identified the stakeholders required for a successful outcome.

Not only that, but later on, you're going to be tapping into this brain trust or community of people, to Natalie, you know, further review requirements. Make sure we're delivering the right kinds of things to show and tells, et cetera. They're also going to help us determine how to test. How are we going to validate that they're getting the same data they used to, but through another process. Or that any of the new requirements have been met.

Now I'm going to shift gears again and a role like mine is limited. It's not just limited to governance. It expands into data acquisition, process creation, and management, as well as managing quality.

I am an information architect.

A typically sit between the business and IT and my roommate lamped on either side, depending on the organization, but no matter what, the goals and approach have stood the test of time.

The beauty of this approach is re-use, whoops, sorry.

As I built the site box and learned about the challenges associated with the existing data ecosystem, I also identify the definition of quality in terms of the evolving community.

What's important?

Why is it important?

I will now focus on the source of trust and data, simply stated quality.

I'm going to compare 2 or 3 schools of thought regarding quality.

If you do a Google search for the dimension of Data quality, this is commonly what data governance people were referred to. Is that is the dimensions of data quality, and, if you look on the left on this slide, that's functionality efficiency, usability, reliability, maintainability, and portability.

Well, most of these focus on the end user.

There's also other functions like your reliability, maintainability, and portability, that's very much in your IT shop and in your design. But if you don't listen, if you don't hear what the current challenges are, you're not going to prevent them from happening again. You're not going to improve the experience.

Next, we go to the dimensions of quality, which are identified by ISO.

And that's ISO IEC 91261.

The dimensions of quality are accuracy, timeliness, precision, reliability, currency, and relevancy.

And, oops, I think I just flipped that around, and I apologize, it was the quality attributes, are, your governance is, is your architectural perspective, and your dimensions of quality are the, the governance view.

I'd like to go a little bit further, actually because ice groupings, eissa, is the International Association of Software Architects, and in fact, that's who has blessed my certification from professional and now distinguished as an information architect.

In the IC groupings, you'll see there's three different types of groups, and they have continuity with the other viewpoints from governance, and from the architectural perspective, or the, you know, the ISO perspective.

But what they're doing is, they're talking more depth, and they're really showing us the types of, quality dimensions, answer, and management for data, and it gives us the ability to start really talking about what's important to us.

It's unfortunate that you can't just have 100% of everything, for example, I want to have reliability and performance, but I want to have accessibility, personalization, and customizable ..., there's a point where you have to make tradeoffs.

The architectural quality attributes support governance dimensions of quality, whether directly or indirectly.

the issue is mapping the relationships to expand on quality attributes.

You know, we just talked about that from ISO, the expansion of the ISO quality attributes into these groupings. It's not only easier to map against governance goals, but in most cases, it forms a tangible common language across business and IT goals for quality.

Most of the companies I've worked at in my past have been tribal.

one of the first things I'm trying to do is standardize language so that as we're progressing through the project, as we're identifying issues, or as we're re evaluating our design or or goals, we have the ability two look at and discuss things in common terms. Additionally, if you go back to the sidewalks, I can point to something I'd say that's where it happens.

And so, between having common language and graphical images that help us identify where we're at, you now have a common way of talking at any meeting.

And I think that's really important to have what I call repeatability. Because even from a psychological perspective, that repetition becomes more comfort.

It also helps you drive, you know, that trust.

That community you're developing, hasn't existed before, in most cases. And if you have everybody working together towards a single Goal, I E, I need my data, by this point. I need to report, you know, create these reports, or I need to file these regulatory notifications, or whatever it might be.

I now have the ability to work upstream. When I have a challenge, I know exactly who to go to. Why I would go to them, and when.

So you've just given me as an end user, peace of mind.

I now know these people, I trust. They have my best interests at hand, et cetera.

So based on the previous research I did where I did the sci Parks, et cetera, I can associate user stories and experience against the quality attributes that we have here and drive a common set of goals throughout that data life cycle.

In most cases, the challenges previously identified will back to the groupings again from ISR.

So I'm going to veer off the path just a little bit right now and I want to talk about defining quality.

I start digging around for operational data and metrics as soon as I can.

As soon as I can identify who participates in that data life cycle, I want to find out what we currently measure, what types of problems we're able to detect.

I want to look for duplicate issues, or and root causes, preventive actions, corrective actions, the whole shot, But in order to get there, you have to have that type Discipline. And a lot of cases, you're lucky when you can find a couple of dashboards.

And, typically, again, you don't have consistent dashboards across your organization as far as that data pipeline.

So that's one of the things that, you know, goes on my list of things we're going to have to fix throughout this process.

The next thing I'm going to talk about, as I'm defining quality, is, I'm also executing Agile form of six Sigma.

The principles that I like to use will drive continuous improvement, and, in this case, so, I like this image, because it talks about the reality of that life cycle.

Domain, you know, D is where I'm defining my current data life cycle, identifying my stakeholders, experience, et cetera, as part of that, Define Stage.

M I am, you know, gathering any metrics to measure current state of the ecosystem, but also to extend the user stories with system evidence.

A: Again, I am constantly analyzing the evidence forming hypotheses and providing insight into solutions.

I is driven by the requirements that have been gathered, the metrics and reality, also known as the budget.

And then there's control, or see, going to jump back on the previous path to discuss quality goals and priorities.

Previously, I explained mapping user stories and experiences against the quality attributes.

No matter what you see, no matter what you see as the basis of defining quality, the next step is prioritizing the quality attributes.

In most cases, priority rule relates to purpose with a logical association. This is a challenge.

Stakeholders will agree the quality is important, but define quality based on their perspective.

From a systems perspective, I'm going to be thinking about performance reliability, availabilities, scalability, security.

But from a user perspective, I need to be able to use my data, get to it quickly.

Align it with my goals, even though the enterprise or source system may not quite conform the data the way I need it.

Then, of course, there's that maintainability, manageability, support, ability, et cetera.

The cost of quality for each attribute is exponentially aligned to the degree of the solution.

So, I was speaking earlier.

If I want to have a billion nine's, guess what? I'm going to have to give up something. And typically, that ends up having some consequence with the end user experience of spending a lot of cycles on keeping my systems up, et cetera.

And maybe I have to back off on some of the customizable IT or personalization that I might offer. So again, it's this balancing act. And your organization, one of the first things you really need to do before you kick off one of these projects, is identify what is the priority of quality?

And what is most important, as we spoke earlier, from end to end, it's going to vary, and so now we negotiate.

And maybe as part of that life cycle, you do focus on something upstream that you may not at the user thing in the user space.

So I'm going to give you another analogy.

So for example, I'm at the sandwich shop and I have a choice between baloney and pursuit, wonder bread, or a baguette.

And when it comes to those quality attributes, I want to have that prosciutto on a baguette. I want the best sandwiched possible.

The reality is that I can afford either the ..., with the Wonder bread are bologna on the back. And so maybe it's not everything I wanted.

And don't get me started on condiments or cheese that just blows my budget right now.

So that, again, well, actually, illustrate. I love this one because it illustrates the fact that scope creep costs you money and it will reduce what you deliver. So in the end, I'm going to end up with either that pursued on wonder bread or Bologna out of back that.

So this is that, again, that perfect illustration of balancing against the quality attributes.

Before I move on, I'm going to talk about failure modes and effects analysis.

This is actually one of my favorite tools on Earth.

I don't know how many times I use this, but at this point, I could probably just know, ..., talk about this without even doing any research and working on filling in all the boxes.

This is an excellent tool for identifying the priority areas, for monitoring and measurement, as well as identifying things that we may or may not be able to fix prior to our releases. But, at least it helps us to prioritize. And that's something that's really important, because sometimes, when you get a big group of people together, it's very difficult to actually come up with that common.

Got a set of goals.

With the failure modes and effects analysis, what you're doing is you're identifying, fail, and what the type of failure is, what kind of fact a failure has, and who it impacts the severity and impact. I can't do my job.

Um, or, I am not able to access the data I need for a study.

We get to the root cause, the frequency of occurrences, existing controls, and detect ability.

Now, this could be used for existing systems, but what I'd like to do is I'd like to use it on my design.

And that's what they call, design FMEA.

And while it has the same types of content, what you're going to be doing is you have to come up with the hypotheses of what could happen, based on your knowledge of other systems.

So if you know that you have problems with network load balancers and you know their ability to detect whether or not a service is running, that's something you're going to put here. And then you'll walk through the process. So if it fails, because we're not able to, we're not that. There's not a good communication between the network load balancer, and you know that the council could get my words sorry.

But if you know if you, if you're losing track of the data, between those two points, because you have the service isn't up, now I know what the potential effect is, I know what the cause is.

And I can actually look at is there anything that controls that.

Is there a fail-safe in there that will prevent the failure from happening?

I'll identify any of those. And then I look at additional recommended actions.

When we start working on this, you have a group of people, and I tend to start with each of those.

I'm gonna call them silos for now, just because they typically are not going to start with, OK, who's the, who works with the admin system or the source system, who works on ETL and data distribution and management, and then who is working with data consumption or accession, not to go back data modeling data. You know, your data repository and then your end user walking through this with them we can identify from X from experiences.

one example is if you if your end user is experiencing latency and data then we can drive it back through that PSYPACT: identify the location where the most commonly happens, especially if we have metrics and then we're able to start working on how do we prevent this from happening.

It's always something that happens once.

Every two years versus something that happens.

Every month And when I'm trying to run my books, that's going to play. yeah.

And we have this thing called an RPN or a risk priority number, which is the output of this process. And, while that's not a rational number, the RPN is another former prioritization. And it helps you look at from all different perspectives.

Once I tie all that feedback together and compile a final FMEA analysis, I can work through with all of the stakeholders and make sure we all agree on the RPN. Sometimes we may adjusted a little bit based off of, you know, while you don't understand the impact it has on me.

Or, you don't know, you know, I don't know if we've actually hit the right root cause.

But by streamlining that, and cleaning that up a little bit, we actually get to, yet another tool, another visual, and another set of language that I can communicate, refer to, and, again, drive, drive the priorities of the project.

It is important to remember that no matter how much pre work relating to quality design you do, circumstances change.

This can lead to new areas of focus and measurement and change your priorities, that is all part of continuous improvement and a byproduct of control.

So, remember, hi, Kind of took a break from control, or back?

So, as I had to my conclusion, I wanted to return to the goals I had.

I wanted to talk, or have a conversation about governance, data, and driving success for customers, the company, and the triggers of this Success Engine for the data consumers.

By focusing on all the contributors, but starting with the consumers, you have the ability to relay stories and experience and share, share I And identify those priorities in a way that anybody along that, that community, is able to understand. Now, we join together, and we care about the experience of the end user.

And that truly is going back to you remember, I said IT for business? It means that while I have all the needs, et cetera, I'm going to tell you what they are.

You're going to give me a solution, but you're always gonna keep me in mind, in order to make sure or negotiate what the solution may be.

So, while the pill it, because, I just want to go back and say, you know, this had the potential for being a very huge topic. I could talk about any one of these concepts for a very long time.

So I tried to focus on the approach, give you some examples, and draw, and, you know, driving towards that quality and governance goals into the design process while ensuring that delivers will meet the needs, priorities, and goals of that data consumer.

The perspectives I have shared focus mostly on quality.

To me, this is the ultimate deliverable in an information architecture and a solid driver for governance and is illustrated by comparing quality attributes, dimensions of quality and the ice groupings.

We have not addressed other functions of governance, such as regulatory requirements, privacy, security. These should be defined at the enterprise level.

Again, there is a purpose for both the enterprise approach and the bottom-up approach.

And.

Typically, yep.

So, typically, if we focus on top-down governance, we tend to lose a job, but while governance is a form of control, we need to govern in an adaptive banner, And that is where we go back to the beginning and talk about that enterprise governance, again, the rules, the frameworks, the structures, et cetera. But functional governance is for the people.

It engages the people.

And by having engagement, by knowing who is part of your lifeline of data, you now build trust, and trust goes a long way.

Thank you.

Excellent, Andrea, thank you so much for that, for sharing your expertise there in your journey.

You're in a very, very unique position, and I'm looking at the comments here from the audience, You're such a unique position because you're actually the Director of Actuarial Data Governance, for a, you know, a large insurance company. You're living this things. You know, they, they out. If you look back, like a few years back, when you started on this role, and you, and you got into the organization, what are some of the things that you, that you'll learn right away, that you thought there needed to be done differently? And you start building in there really align with the models that you share with us?

So I won't know. And people don't really just give that information up because I think it's hard to express the pain you have unless you're going through it. And that's why the listening tours are so important to me.

I get to not only hear from them in terms that they use on a daily basis, which helps me understand their language, but I also get to see I watch, I observe, and then I can identify a lot of opportunity for improvement.

And what are some of the things that you felt that, you know, without, Of course, you know, getting too specific on the, on the, on the people in the, in the business. But what are some of the things that you found?

Route this listening tours, that that really helped you a lot along the journey, and that were maybe not obvious from looking at data, you know, looking at process designs. What are some of the insights you know, that, that you've gathered from those? So, I like to look at the concept of user experience.

You know, a lot of the times, when we think about user experiences, about interfaces made, you know, frameworks, things like that, but it's also about anything that you consume, Especially in terms, like data.

And if you're not able to do what you want with data and you're doing a lot of manipulation, et cetera, that's off to your best advantage. The more you humanly touch something, the more likely you are to actually not be able to repeat a process.

So, those are a lot of, that's a lot of what I look for, is what is actually in the process, from the very bottom, beginning, all the way back. For example, if I don't get alerts that there's a problem on my system, and I have to just, you know, eyes on glass, keep on monitoring something, I'm going to miss something, want to take a drink, my coffee.

So, those are the types of opportunities I'm gonna look for, from a procedural perspective, from a systems perspective, tools perspective, et cetera.

And that's gonna help me make sure that what was defined as the goals of the project actually aligned to the experience of what we're trying to solve.

And, and, Andrea, on following up on that, as you, governance is hard, because governance has multiple levels, right? As you know very well. You can be, look at you, talk about enterprise, you talk about function. You know, you have all, you have to establish ownership of so many different levels at the data level, at the process level.

And the ownership is something that sometimes it's hard to nail down because in large organizations because everybody has their finger on something and either too many people want to own it, or sometimes nobody wants to own it. Absolutely.

So the question is, how, how do you collaborate effectively and navigate, you know, this dangerous waters of ownership and establishing ownership.

So, what's very interesting about the approach that I have is often, you know, you take a life cycle of data, and you already have these, you know, groupings of people.

But I like to call them my silos in the original state, but they don't really talk with each other. And so I might be overcompensating for something. I'm afraid will happen later on. Or your data consumer may have had a problem at some point and now are compensating for that. I like to look at that entire no end to end.

And then, first of all, again, standardized language.

Give ourselves something we can look at zero point two and talk about our experience together. And that's where, you know, first of all, just the Zachman Framework is going to help me a lot with understanding who, what, where, why, when, et cetera. But does sci parks are critical?

That is how I literally can show you this is my process and this is what happens.

And you now understand that I go for that to stitch them together, and then I start looking at what is, what is quality defined as based on what I'm hearing?

And then I read that back and make sure that everybody agrees.

Now we're addressing concepts. We have common language, we have diagrams, we can point to, which I tell you.

When I'm an analyst, and I'm talking to an infrastructure architect, that is a really hard map to make, But if I can point to things and talk to things, we eventually end up with an understanding.

Andrew, another question that came up here, is that there you are a few years, 5 to 6 years ago. You started in the e-start and ... while Nationwide Insurance, and you're doing Data Governance and you know you're, you're get kinda getting things align and getting them the right place. And then bang, a global pandemic hits you.

And, the question is, now all of a sudden, some of the governance items that we had have to be different because of the of the remote work and all just different, you know, adjustments that we had to make.

How has that affected you? And how have you kind of adjusted to this to this new new way of being?

So, this is really interesting.

one of the things that I didn't talk a lot about that is really important is, by understanding what the requirements are, the needs are, et cetera, you're able to build a lot of things in, And one of the things we built in was the flexible ability to measure and monitor. So, for example, data quality is probably one of the most important things to me, just because, like I've been on the receiving end, and I want to trust the data more than you trust the data if you're consuming it.

With that being said, we actually had a little bit of a bump as a team in the beginning.

But we took quite well to being remote. And again, it came down to, I have, you know, we've established a language which we can speak it. We've identified who we need to go to at each, you know from end to end. All of that was defined and being defined during the pandemic.

And it actually was the backbone that kept us all together.

Now, I have, you know, if I have data quality issues, if I see an alert thrown, etcetera, I know exactly who to go to, how to manage it, how to communicate it, et cetera. We have common practice.

All of these things are built in along the way, so that when we actually deliver data to the end user, the thing we were focusing on was their adoption.

So, the, the remote work did not significantly change the governance and the structure you had, Not at all. And actually, it's strange. But we kind of question, right now, you know, you, you still have some social distancing and Ohio are allowed to take our masks off. But only if you're fully vaccinated. And so one of the things that's very interesting is we feel like we're less connected now because we all come into the office. We sit at our desks and go on video calls. That is great. You know? This is I love that comment So true I've been hearing that for a lot of the organizations that we work with that I feel so lonely here this office now because I don't get to interact with the same people That makes The faces and smiles that we miss that.

Know, this is such a big deal, as a matter of fact, I'll put a plug. Our next conference is actually the digital workplace transformation and this we're going to tackle this process, this item, a hat on for three days, and now in, later, in the third week of July, so because as you said, it's not, even though it's the people. I think once your perspective gets shifted, it, it may never go back to what it used to be.

Yeah. It's very interesting, and, you know, we're trying to figure out how to, you know, work together in person, again. And we find that, you know, the week, we have a hybrid model. So, we're in the office this week next week or at home. But, yeah, I feel far more effective.

And how But, you know, it's adjusting And yes.

The pandemic was a good wakeup call for a lot of us in the way that we work and identifying like, hey, how do I really have to stay at the office? How do I manage my work better and the most important thing that we learned is you take a lot of micro breaks at home.

You don't do that at the office.

True. I have time for one more quick question here, and this one came up in the commentary, and I want to, I want to make sure I hero.

You talked about, during your presentation, you talked about, you know, developing trust in the data, which is an interesting concept bright, and it's not trivial trust. That data, it requires governance is the chorus processes requires ownership. I mean levers so that you can trust the data.

So, the question is that, how, you know, in, I mean, an insurance company actuary their data services. I mean, you gotta trust that data. So, the question is, give us some tips on how do you build and sustain trust with your data.

So, the approach actually is meant to build that trust and build the relationships. Again, I keep on referring to the community of my data life cycle, right? By asking people questions, by observing, first of all, they understand, they know that you understand what they do.

An actuarial function is that simple, let me believe me.

But on the other hand, you know, as a data person, I can understand what they need.

And I can also understand how hard it is to do some of the work that they're doing, Going, you know, further upstream and further upstream, you start introducing each other.

And now you do. You build that community, and now I trust individuals, trusting individuals is a big part of the deliverable.

I have the ability to communicate consistently across the group.

We are able to sit down and talk about problems. I gave them a lifeline. For example, the actuaries have a lifeline. If they need somebody, they need help writing a query, or something. it's not performant, or whatever it might be. They have somebody to answer that question.

We have Communications and Alerts and that's a subscriber bole entity. Therefore, depending on how much you want to know, you don't have to know more than that.

So, by building the community, starting out and building the relationships in the beginning, you have Trust with Individuals. And, again, that leads towards, you know, that trust the data we have met their needs. We have given them the lifelines and we try to simplify their day.

And that's one of those things that actually, you know, it will change over time, we will have continuous improvement activities in the future.

Andrea, thank you so much for giving us this insights from a real practitioner standpoint. We appreciate that very much on behalf of our global audience. We want to express our gratitude for you to take the time to do that.

Thank you very much, and I appreciate your time today.

Thank you.

Thank you. Ladies and gentlemen.

That's Indra Sefer, Director of Actuarial Actuarial Data Governance, and Nationwide Insurance, a true leader and practitioner in the area of data governance and the what great conversation with Andrea. We're going to be wrapping up day one, right now, but I want to talk to you about what's coming tomorrow. So, you can access the agenda. We have posted several times on the chat, the link for that, but I'm gonna do a quick preview here with you. We're gonna start tomorrow sync at the same time, 8 50 AM, US. Eastern Time.

We're gonna, we're gonna kick off tomorrow, Brian Raffle is going to be doing the introduction tomorrow for you. All for the first session, I'll join everyone after this X second session.

And on the first session, we're going to have the senior Vice President of Customer success of, from Lean I X docs to talk to us about how APM, software, as service, as a service management can benefit from each other. He's going to be followed up by the leader at BIS Design, who's going to talk about faster, better decisions, to unlock organizational value. And then we're going to have to world class, practitioner sessions, one coming from the leader of innovation and visualization Roche directly from Europe.

Alan ... is going to talk about, from issues to innovation, developing a composable business architecture to drive innovation and improve resilience.

Roche is an incredible journey to accelerate excellence and innovation in the biopharmaceutical industry. So it's very comprehensive insights on what that looks like from inside the company right now. And then we're going to wrap up a super interesting presentation from Rakesh. But towel rack cache is an advisor for an consultant for the London metropolitan police. And he's going to talk about the data driven approach. You're not in the processes around digital transformation, to acknowledge excellence, and business priorities, and social priorities when it comes to the London metropolitan police. So very, very interesting. Industry leaders, and true practitioners sharing their insights on, on enterprise architecture, architecture, directly with us. So, I want to thank all of you for joining us today. We had fantastic interaction and questions throughout the day.

I expect no less from you tomorrow, because you're a wonderful audience. For those of you who want to follow up on some of the discussions we had here, you can look undermining GDPR is on LinkedIn. I have a posting there, where you can thank the speakers. You can ask additional questions. You can see the commentary, what the participants and speakers are saying about the conference. I will post a quick update about what happened this morning. My morning, he or whatever you are, in the world, different time zone. I'm going to post an update in the next couple of hours, under that link. So, feel free to no comment, like share liberally, and keep the conversation going. Basically, until we meet tomorrow, again, live on enterprise architecture.

As you close the session, there is a popup that comes up that you can provide feedback on the session. And I guarantee you, that the conference production team listens and reads every one of your comments. So, we thank you for that, and wish you everyone a great rest of your day, bye, Bye for now.