The architecture of Information

Loris Marini: Why are we here recording this episode? Well, the topic obviously is information architecture, but we have a bunch of questions. What is exactly information architecture? What is the difference between data and information architecture? How does it help data practitioners to be strategic partners to the business? Does it help us achieve more outcomes and be less helpless? And most importantly, how does it fit into the bigger picture of data governance, and data management? Are architects different types of people with different skill sets or are these people branching out from existing data governance initiatives?

These and a whole bunch of questions we’ll try to answer today with my guest is Dora Boussias. A data and technology leader, Dora is an expert in data analytics, enterprise architecture, and digital transformation. She works at the intersection between business and IT. Her job is to build relationships and balance strategic and pragmatic needs to simplify processes, boost operational efficiency, and bring timely, relevant, high-quality data for the right business decisions.

Four adjectives that describe Dora and her leadership style, which really resonated with me, are authenticity, empathy, inclusion, and resilience. In the past 25 years, Dora has worked in various industries: from financial services to health and medical and retail, leaving a mark in global organizations, such as Stryker, GE, and Prudential.

Absolutely stoked to have you on the podcast. Thanks for being with me today.

Dora Boussias: Loris, thank you for having me. It's my pleasure to be here. Thank you.

Loris Marini: What is information architecture? What do you think about the role and why do we need it?

Dora Boussias: Okay. Yeah. Thanks for the question. So, I want to differentiate information architecture from data architecture, just so that I can zero in on how I think of these two things differently. Typically, enterprise information architecture is understanding the data first and foremost, within the business context.

It's not about the bits and the bytes. It's not about the physical data models of an application. It's really understanding what the data means within the business context. How is it used? Always looking at the end-to-end flow of things. How do we streamline those data flows? End-to-end, right? What should be the authoritative source which we'd go get the data from? Especially when we're talking about enterprise master data that has an impact across many different processes and systems.

Information architecture also looks at that logical business information model. When I'm talking about a customer, what does that mean? What are the key data points and data attributes about a customer and its relationships within the organization? This is agnostic of any one system. I think of enterprise information architecture as the other side of the same coin with data governance. They need to work very closely together.

The way I think about data architecture, it's more about the physical areas, and writing the technical interface. It's more about the data engineering part, the physical aspects of the data, not so much in the business context of “Where shall we get it from? Why should it come from there? Who's using it?”

Hopefully, that helps answer the question, Loris.

Loris Marini: Yeah, it does. I was actually checking to understand this with just a quick browse on Wikipedia. There was something there that spoke about user experience and an active debate in the industry where there are people that believe that user experience is part of it and other people that think it's more about the system level, and big picture without necessarily worrying about who's going to consume the product. How do you see this?

Dora Boussias: See, we do not have standard definitions for what these things mean in the industry. Even information architecture and data architecture, the way that I explained it, I'm pretty sure there are people out there who think that everything that I said to describe enterprise information architecture is data architecture.

So, on that, I'm going to say what's really important is that within the groups in our organizations, we work on making sure that we level set. We use these terms and what they actually mean.

Now, if I go back to what you said, for example, you were looking at Wikipedia. Yes. Information architecture in some circles refers to how to place things on a web page. For example, it has to do more with a user experience, but that's totally different. And yet the term information architecture out there in the industry could be used to mean two totally different things. So, when I'm saying enterprise information architecture or EIA, again, it's all about the data, the right data, the business context of it, what it means, and working closely with the data governance side.

For information architecture, what you came across, and to my understanding, I'm not an expert, it's more about the UX and making a smooth user experience. For example, putting the right information in the right place where the eye will fall and they can easily get what they need out of that webpage.

Again, different than data architecture, at least in the way that I described it.

Loris Marini: Yep. There are many common denominators here, but one is strategy. The fact that we're trying to use information and data, intimately related, intangible forms of assets to try and help the business to thrive, reduce risk, improve efficiency, and grow. How does an enterprise or an organization come to the conclusion that they need to hire specifically information architects? What are the problems that bubble up? What are the red flags to look for and start hiring for these folks?

Dora Boussias: Typically, you have a need to focus more on enterprise information architecture. For example, when implementing big solutions. Across systems, things break. They break because sometimes what downstream expects from upstream is different. What upstream thinks they give downstream is different than what downstream think they get from upstream. Again, not speaking that common language. When we're really trying to simplify and streamline that end-to-end flow.

I think it's still the case where a lot of what's happening right now in organizations is that we’re so often project minded. We have a project, we have a scope, and we tend to forget that two or three steps down the flow of things, someone might actually need the data that I should be capturing now. Yeah. It's not in the scope, but they might need it.

For example, I’m capturing some information about a customer or about a supplier. I capture the absolute minimum of what I need. When I'm looking at the end-to-end flow, it could be another business process that’s outside of the scope of this implementation project that really needs data points like a shipping address. Maybe we're only capturing for this customer, their name, maybe a billing address some other information. We're not shipping them anything. We have to go through the order first. The time comes to ship the product and we find out we don’t have a shipping address. We have it in some cases, not in others because it's not something that was validated as part of the process.

I'm looking at the end-to-end flow of things because I'm trying to understand the data within the business context and business process. The other focus is to understand that what we’re capturing is similar in the way that the downstream processes and systems also think about it within the scope of the project. Because it’s not just about building and writing a technical interface to transfer the data. The name and the label might be the same, but what it really means and how the downstream process and the enabling technology for that process use it, is different.

So again, from an EIA perspective, we really focus on trying to understand the end-to-end impact of things. While we're doing that, we're also trying to streamline the flow of things. You do not get that kind of understanding unless we take the time to really think about what we're building. How does that fit in the ecosystem? Otherwise, things are getting developed piecemeal almost. And you just lose.

Take a step back. It's almost like you don't see the forest from the trees. You're looking at this tree and this tree and this tree. You need to see the forest from the trees and see what's the right path to get to the other end of the forest.

Those are key components of what an enterprise information architect would be bringing to the table. Highlighting and making sure that along with the business and the technical stakeholders, we work to understand that while we're architecting, it's going to feed into detail, design, and making sure that the build is right. They consider the end-to-end picture and the downstream impacts.

Loris Marini: Yeah, that's super cool. Essentially you almost act as a garbage collector. For those familiar with programming, tidying things up, ensuring that there's RAM and resources available. You act as a sort of glue, a bridge between what's happening in the real world and what's happening in the digital systems that represent the real world so that you can use them to make predictions and operate.

Sometimes they don't. Not because people don't know that domain because they do, but it's the end-to-end flow. It matters, as well. So, stitching those domains together in a way that is coherent is key as well. What's hard about it?

Dora Boussias: What's hard about it is that it’s a techno-functional role because you always have to be thinking about the business context of things as well. You have to be thinking about, “Hey, how is this data used within the business process? Who are the business folks that are using it and for what purpose?” We need to be asking these questions and then collaborate with data governance teams.

This is critical because, from a process perspective, we need to understand what that data means. Do we speak the same language? This is where you have to work very closely with data governance and data stewardship type folks that help drive some of those common definitions.

What's hard is that you have to have technical skills. You need to know how the systems work. You need to have enough technical chops that you can, on one hand, talk to the technical implementation resources. But on the other hand, you talk to the business stakeholders.

The other hard part about it is that in this type of role, you try to influence folks and how they think. We're getting better at this, but most of the time people are like, “I don't care. This is what I'm measured on. This is my project. This is my scope. I don't care.” I don't want anybody to break downstream, but sometimes folks don't think about it because the focus is on, “what do I need to deliver right here? I need to deploy this one system. These are the 50 attributes that I need. This is how my system understands them.” Does the downstream system understand them the same way? Meaning the people using those systems within the business processes. We need to pay attention to that.

It's a link in a bigger chain. If it doesn't play nicely with downstream, or if it doesn't take care to make sure that it provides what downstream needs, then we need to take time to do that. Influencing, forcing people to think from that mindset and bring a little bit in there.

We always want to also balance. That's another big challenge. Think of it from an enterprise perspective, because again, information architecture is enterprise information architecture, E-I-A, right? So, we want to balance thinking from the enterprise perspective with the needs and what we're trying to do right now. You can't go to one extreme or the other.

You can't only be thinking about end-to-end because making all of that always be perfect will take too long and people are just not going to go for it because we need to deliver. But on the other hand, just focusing on delivering this right here right now, and not thinking a little bit more intentionally about how these fit into the rest of the ecosystem and what the business process depends on it. Is there anything that we need to do? That's not good either.  We need to balance the two and this is more about architecture.

The other thing I would say too, is sometimes folks think, “We're going to build all of that.” Well, not necessarily. It's kind of like when you're building a house. You need to know if you're going to be building a one-story ranch or a two- or three-story home. How are you going to architect your foundation? How big, how strong is your foundation going to be? So, we need to architect it for what we need now and later, what downstream needs are. But then we can iterate through the building, keep on adding features or build for this specific set of features or in this specific area.

Especially when it comes to enterprise master data, enterprise information architecture has a lot to do with enterprise master data, as well. Remember, it's the other side of the coin with data governance, where again, the focus is on all data, but predominantly enterprise master data that have wide impact. 20%, 80% impact, or something like that.

Loris Marini: Yeah. The most critical, vital part of the datasets that you keep finding anywhere, everywhere across the enterprise. They keep bubbling up at the center, the nexus of the graph.

I want to pick on this concept of enterprise information architecture. Do you think those principles apply outside the enterprise in practice, not just in principle? Do you see people worrying about the end-to-end impact of data solutions or products in smaller organizations? I know this is primarily relevant for large beasts.

Dora Boussias: I think it's relevant for mid-and large types. I mean, small depends on how small, right?  Obviously, the larger you are, the more impact, the more of those spaghetti diagrams that you see, because we just keep them building piece by piece and not trying to streamline and simplify, really understanding the end-to-end picture. Remember one of the things I said is, “How do I simplify flows?”

So, to answer your question, I don't know that I have like a hard number. If you're over 50 people, you have to have it. I think it applies, no matter the organization. However, it gets to be a lot more complex and a lot harder when you're working in mid-and large organizations because we also always have to do with everything that has been built over the years. All of the habits that have been put into practice.

Again, part of this role is influencing a little bit the mindset and finding a nice balance between, “what I need for now and how does that fit with the rest of the ecosystem?” Can we balance it? I want to say when the organizations are larger, that's where the need is pretty big too. In much smaller organizations, you might have folks that kind of do that because they understand it. It's probably one person wearing many hats and they're that one go-to person.

If we don't put the focus and have an intentional role for it in mid and large organizations, then I don't think it's going to happen. When you have any intentional role and it's something that is recognized as part of the operating model, that means there are measurable goals.

Typically, when that happens, the maturity of the organization is also such that the success criteria for the program implementation are not only, “Hey, I'm going to implement whatever system.” It could be a CRM, an ERP, or a smaller system. So, the measurable objectives might also change. You might be implementing it commercially or the territory management system is needing XYZ data to come from this ERP so they know what kind of incentives they can give to the salespeople.

That's a success. Not only implementing this system but making sure that when you get downstream, they have the data that they need, because guess what? They expect the data from that ERP. How do you measure success? Changes. When you get to that level of maturity that you put focus on that end-to-end picture.

Loris Marini: I was thinking back to that remark that I made about small companies and teams. For the folks in the audience who come from a software development background that stumbled upon data and now they're working as data engineers, data scientists, or sometimes data analysts, they're comfortable with developing software.

There's a term that in software development we use to, I think, map something that gets close to the definition you gave me at the beginning of information architecture, refactoring. Stepping back from writing code and satisfying requirements for the right now and seeing the big picture and how we simplify and streamline. Use one term instead of five different terms to mean the same thing.

That's easy to measure because you see the impact of refactoring code by looking at the compilation time, and response time of a function. There are clear numbers associated most of the time. This happens with automation. We work in integrated development environments, IDEs. They are designed to measure all these things. As a software developer, when you simplify the flow, you know immediately if that was a good idea or not. Often the motivation to do that work starts from yourself, your frustration as a developer because you're trying to build code, but it keeps crashing. After two hours of debugging, you realize, “Okay, we need to rationalize this whole thing.” This has become a mess with so many developers doing their thing. Now, someone has to do the hard work.

This is a long introduction to a question that I've been asking myself a lot. This is hard to do in software development when you have four, five, or six people writing code. We still do it in open-source projects which are contributed to by thousands of people. So, it's something that we know how to scale in code development because of those tools and systems and automation we have.

In an enterprise, you're looking at so many different stakeholders with different backgrounds. The sales teams speak the sales language. They don't know how to write code. They don't care about a particular metric. They have an operational need and maybe a frustration on the field. That frustration needs to be communicated. How many hops do we need to go through and how accurate is the information flow in this sense?

Dora Boussias: It’s not easy. Another key point, I think, for enterprise information architects to be successful is that they need to understand the business. You could focus on a domain, let's say, on the supplier space or the manufacturing area where you're working with a lot of different materials. It's not like one person in the entire enterprise.

However, there is a challenge there that you need to understand the business enough to even have the technical expertise, the right mindset, the right behaviors, and the right skills. Communication plays a role. Like I was saying before, this is a techno-functional role. You're working with a team and it's part of the operating model.

The thing is, no one always has all of the answers. No person has all of the answers. How do you work with people and ask the right questions that get people thinking so they can start understanding the impact and then collaboratively you get to those right answers, better answers that this is how we should architect and do it?

Yes. It's hard. Especially when you have an enterprise information architect working on more than one project. You need to be a fast learner, I think because it's not just about the technical or bringing all of that expertise and doing the models and the flows. First and foremost, you have to be thinking, what is the business purpose here? Why is that data flowing from here to there? Should it flow from here to there? Who's going to use it? What do I need?

You call it tomayto; I call it tomahto. Same thing. You call it commodity code; I call it commodity category. It’s the same thing.

Loris Marini: A lot of asking questions too and challenging assumptions.

Dora Boussias: Absolutely, absolutely. You could be an enterprise information architect working on the implementation of a PLM system or a supplier management system or whatever it is. The more knowledge you have about that technology, whoever the vendor is, that's great because you bring that in and you know how it works.

Asking those questions to get people thinking, a lot of times to get to the right answers, you kind of get that information out of people's heads to also get them to start thinking about business processes and dependencies. Who's going to use this data, for what purpose, and why?

People tend to just jump into technical implementations when they're talking about end-to-end processes with a particular system in mind. It's very hard to disconnect. Sometimes I say if I had pen and paper, forget the system. This is not us trying to fit our business into a particular technology. This is us trying to understand how we want to manage our business. It's about supplier management, right? What do we need to know? What are those steps? How do we want to manage it? Let's figure that out. Let's understand the data, then we'll figure out the right technology to bring in.

Loris Marini: Can you outsource this?

Dora Boussias: How we're going to configure the technology to fit our business, not the business to be forced into whatever technology solution.

In the end, whatever we do in this space, again, it's all a link in a bigger chain. We need to make sure that it flows and we need to follow through with that data. I didn't say before, but that's another thing there are a little bit of the more technical aspects now of an enterprise information architect, meaning, “Hey, do I need to replicate this data?” Because everybody tends to, “Just give me the data. I'm trying to simplify flows and I'm trying to not copy and replicate data all over the place.” But to answer the question, “do I need to bring this data?” You need to understand what data you need for what purpose.

Those are hard questions to answer, especially because we've been so conditioned over the years to just say, “I'm going to go implement the system. This is the data. Somebody downstream is going to need it. Here, take it.”

From an EIA perspective, I don't want to keep on copying data all over the place. I also don't want to replicate it unless I have to. I'm bringing in the more technical aspects of it where, “Hey, I want a real-time view of that data, not just batch it and bring it into the other system. By the way, when it comes into the other system or when I want visibility on it, it's just visibility. I should only have visibility of that data if it's enterprise master data.

We're working with our data governance friends here to have an understanding that within the business process, even if that data goes downstream, that doesn't mean you can change it because it’s enterprise master data.  That's the other thing we do. We get it from downstream. We're making copies and other people make modifications to it and we end up with multiple versions of the same thing. We don't know what's the right version. Again, we don't always take the time to really understand and say very intentionally, “Well, now this is what this means. This is how we're going to use it.” Sure. You need visibility. Great. But you shouldn't be changing it. If you’re changing it because you need something else, well, let's speak about what that is. Let's not overwrite what is considered enterprise master data.

Loris Marini: Because you don’t want to mess with that.

Dora Boussias: You have a different version down there. So, there's a lot of the governance aspects of it come into play. Yes, it is hard. It is tough. You need to understand the business. You need to have technical chops and bring it all into the conversation at the right time, as well.

Loris Marini: Yeah. So, I think the main aspects that I'm getting so far are: enablement, knowing who does what, and how to make them more effective as a result of the job of simplifying and worrying about the end-to-end. Scope and range, knowing about the business and the technology, and being able to look at the bigger picture. A ton of people skills, communicating the needs, and being persuasive enough so that people take action because ultimately, you're one person. How big is a team typically in a large enterprise that worries about architecting?

Dora Boussias: This is typically not a big team. I've seen it in different ways in different organizations. Data from the perspective of information architecture, it's almost like an afterthought. What was going into building the technology? What are the data and how do we manage it? Not process it, but manage it. That includes governance and information architecture and stewardship and quality and all of that other stuff. Everything that it takes to manage data. That's typically been an afterthought.

Yeah. You know what, I wanted to double back a little bit on what you said about a ton of communication skills. This is very important because you don't just tell people; you need to influence people. How you ask the questions, how you say it when you say it. How do you not put people on the defensive? In a very collaborative and transparent manner, how do you work together and start bringing in value?

Back to your original previous question, how do you know these things? Yeah. You need to try hard to understand the business. That's important because then you can get better examples to communicate or articulate something. What's in it for the person that you're talking to? Why should they work with you? Because, hey, maybe they're building something in here. Maybe they're not thinking about analytics. We talked about supply management, for example.

It could be the same type of leader. Some folks even. Especially the leadership perspective that there's another process and yeah, maybe that's a different project and it's implemented something different, but how do we connect and make sure that we drive those synergies? Make sure that they're not as disconnected as you think, and what we do here will impact there? These things are not disconnected. Everything is interconnected in our organizations.

Loris Marini: Yet in most of the large enterprises, it feels like you're in a little box. They slam a label on you. There's a job description. You do your job; you walk away sometimes feeling that the organization could do just as fine without you.

It’s such a pity because we are part of the same organization. We have the same goals. We are part of something bigger, but there are cultural silos. There’s the concept of, “You don't need to worry about that because your job is X. So, what about X? Here are your KPIs. We're going to give you a nice promotion at the end of the year if you meet them all. It's 10% of your salary.” Happy days.

That enforces a system where everybody just looks at their own feet. Sometimes I wonder, what kind of culture, and incentives should we aim to put in place so that this whole job of connecting becomes easier and more efficient?

Dora Boussias: So, you touched on a couple of things.

Several years ago, I put together what I called an enterprise information management framework, the EIM framework. Another way to think about it is almost kind of like a framework for a holistic data strategy. You've got different components: enterprise information architecture is one of them, but then you have governance, stewardship, and privacy. You have information governance which has to do with records management, retention, and so forth. Security, analytics, MDM. I took this through the organization. It got established.

I had a series of town halls. I was speaking about it and I had a footnote that absolutely sounded really big because I wanted to make this point. Not one of the pillars or components of this framework means that we're successfully managing our data. That framework was kind of like a bird's-eye view of everything I need to manage data as an asset.

What I'm trying to say is that if we want to drive business outcomes, we need to work together. It's a culture of collaboration, trusted partnerships, and transparency. That’s what happens when you get to that maturity level when you have the right folks driving things.

Another critical factor in making this whole thing work in my mind is having the right folks in the right roles. So, you have the right folks that can communicate it the right way. Get executive leadership support because executive leadership, it's also one of those critical success factors. What happens is what I said earlier that the measures change as well. A lot is happening here so, success means that the entire thing works, not just one piece.

So, guys work together, and figure out the dependencies. Those become measurable goals. If that's what people are measured on, then we're getting away from what you were just saying, “My measurement has to deliver this.” The whole mindset, the whole way of working in culture changes.

There are so many different aspects of this, but yeah, having the right folks to drive it, getting the top to be behind it with the right investment going in. Focusing on the people aspect of it and the cloud and the process. Just driving goals through the layers that connect.

Yeah. People can have their own individual goals, but no matter where you're sitting, they all point back up to key strategic business objectives. Somehow, they need to connect. Otherwise, we're going to keep proliferating where everybody is thinking for their silo.

For the last several years, all I’ve been hearing about is organizations wanting to go through a transformation, business transformation, and digital transformation. Transformation, more than anything else, is about getting people to work together. It has so much to do with the culture. It's about changing how you do business every day and people do business every day. The technology part of it is there to enable it. It's a tool, but that human factor, that people element, and how we work with each other is the culture of the organization. In my mind, that's the most critical thing to make these things work.

Loris Marini: Yeah. I love that.

Discovering Data is trying tbridgegs us all together and makes us realize that we're very similar instead of being different across all the roles. I strongly believe that. When I think about a data leader, I don't think about a software developer or a strategist or a consumer of the data, someone in procurement and sales and marketing. I think about them all because to me, you're a data leader if you take responsibility.

If you say, “I know that the data that comes in and out from my sphere of awareness is going to impact people and processes in the business. This is going to happen inwards and outwards, upstream and downstream. I resolve to take responsibility to try my best, to make sure that both incoming and outgoing are fit for purpose, whether I know how to code or not.”

A lot of times, it’s not about implementing the change yourself. It’s about explaining the right way to the right person so they can go and implement it. If you don't have that storytelling piece and a culture where these people are receptive to that input, they can die. Even if you tell the most amazing story, if those folks think, “This does not drive my KPI, I'm not going to get paid. If I do this, it's going to die there.”

It's almost a web where every node, every hub of this network has to be connected where the hubs are people and their intention of serving other people. Almost the servant leadership kind of philosophy. The spokes that are connected are communication – lines of storytelling and people skills, empathy that we need to be able to feel what it's like to be the person downstream.

I know this might sound like an idealistic view, but if we were to wipe the whiteboard clean and describe what such a system would look like, imagine the possibilities, right? Imagine working in an environment where you know that there are people backing you up all the time no matter where you look, no matter which relationship you take into account.

They all think like you. They all want this to succeed. They all do it without first focusing on their self-interest and realizing that their best interest is only a consequence of the interest of the collective organization. I would probably stop everything I'm doing and go work for an organization like that.

Dora Boussias: If I may Loris, right. Let me just say here what I'm thinking about a data leader.

Even if I just think about the words data and leader. First of all, I'm going to start with a leader who, for me, has got to be a business leader. You have to be thinking about, “What impact am I making for my business? Am I driving business outcomes, business results that make a difference? Yeah, I'm doing it with data, but is it actually helping my business or am I just doing busywork?”

Skills for the right role. Someone that can communicate, get the executives to understand this very complex thing about data and whatever that is so hard for folks to understand sometimes. So great communication skills. Not just for the executives, depending on who you talk to. You need to know your domain. You need to have good expertise in the data domain. It doesn't mean you know how to do everything, but I think that has to be your core domain to do a really good job.

It also means that you can drive change. You have to be resilient because the pushback is going to be there, especially when you're trying to drive a data strategy in a mid to large size organization where for decades, people have been used to doing things differently and data was always an afterthought.

You’ve got to be a visionary who knows how to balance what we need right now. You’ve got to be good with prioritization because everybody wants better data. How do you prioritize demands? You need to get that engagement. Not just your core team or the people you work with, but the whole organization thinks about data literacy.

In my mind, that's a key pillar in implementing a data strategy as a data leader. That means it touches many different people. So how do you get people behind this? You got the executives, but things don't work because, “Hey, I'm telling you to do it like this.” An executive said to do it like this. There are so many layers in the organization and you need to work with these people. These people need to be engaged. They need to adapt and work with you. Not against you as you're trying to drive implementation of that data strategy.

It's not an easy thing. The other thing I think we haven't touched on is that this is not just something that happens overnight, right? It's a journey. You've got to start at some point, but again, there's so much chaos, sometimes messy. A data mess. There is so much opportunity to better manage our data, right? This is typically a multi-year program until the time you get to keep on optimizing and do even better with your data. It's a journey.

As a data leader, you need to be a visionary who can get people engaged, get executives on your back, and all of these folks working that can also execute. This is why I was saying that you need need to be able to prioritize. You need to be focused on your execution, and your vision. You can lead and can execute. Visionary, lead, execute, and data. Okay. Knowing about data. Four words, but there's so much behind all that we can take each one of them and talk for a day about what they all mean.

Loris Marini: Cool. So, let's experiment. Let's imagine we have that whiteboard and we were to step into an organization where the leadership is mature enough to realize that they needed to treat data and information as real corporate assets, not byproducts.

We have people on the ground that are frustrated because things don't work, systems break. There are constant updates. Maybe external providers are contracted to fix things and they just make the system worse. So, the whole thing is ripe for change. Everybody wants it. If you were to be hired to fix it, what would you do and in what order?

Dora Boussias: Yeah. You repair. You don't just do data literacy first, and then you go and implement governance, architecture, or analytics. A lot of these things are happening in parallel. What I would do is make sure that I work with the right executives. Get that backing because pushing this bottom line only takes you so far. So, you have to have that executive support. To get that, maybe you need to show some quick value-adding. Typically, you start with like one big champion, like an executive that can understand and show some value, and then more will be excited to come behind it.

I would do that. Once I got that and a conversation going, then I can focus on my vision. What is my mission? Again, when I'm EIAM, just manage data as an asset and how big the scope of that data leader is. Are we talking governance and architecture and privacy and security and analytics and MDM? Are we only talking about some of these things? So, let's first understand what’s in the scope of this leader, and then we'll try to figure out what's got the biggest business impact.

I would partner with my business stakeholders to figure out what’s got the biggest impact, then how we're going to start operationalizing, making a little bit of progress in literacy, a little bit of practicing how we store and govern data, a little bit of progress with MDM or quality.

It really depends on where the needs are. You might have data leaders that are going into the organization and their focus is all about information security, for example, or just privacy and archiving and retention and records management. So, it depends on what it is that this leader is called for as long as you get somebody that just gets everything.

Loris Marini: It’s almost like an equalizer. You equalize the response based on what the business needs and so prioritize everything at the same time. You might put more weight on something rather than something else. Having less in your scope while simultaneously stimulating change.

Dora Boussias: You can’t keep boiling the ocean. You have to prioritize. You've got to have your own map too, right? You’ve got to show, “Okay. If I do this, what is the benefit this is going to bring us? Why should we focus on this first?” It's got to be a really good benefit. You should be able to feed, "Okay, naturally, I should do this first before I do this next part, but there are a couple of things that can go in parallel.”

I think it's important to be very focused on the scope. What are the commitments? How do we stay diligent, executing those commitments and showing value? Why do we keep driving things like data literacy and getting more and more people to understand it? Well, I think data literacy is a lot about getting folks to understand, well, why are we doing this governance and architecture and analytics?

How do we engage the right folks? How do we make them part of the solution? All of these folks, sooner or later, they're going to need to change how they work day-to-day. Otherwise, if all of these people in their organization keep on doing what they've always been doing, we're never going to make progress towards better managing our data, which is what we're trying to do in this role and in this scope.

Loris Marini: We are creatures of habit, right? Making that change is going to cost energy. I'm just thinking about the resistance and stories that might pop up in your mind from these 25 years that you’ve spent doing this.

Dora Boussias: 27, actually. Yeah, I'm getting older.

Loris Marini: Yeah. Time flies, doesn’t it?

I do have one last question for you because I'm conscious of your time. We have already taken more than an hour. What would you like to see less of in the industry as a whole and what do we need more of, as a complimentary request?

Dora Boussias: What I would love to see less of is just jumping into building things. I'd love to see less of thinking that technology is the answer to everything. There is no silver bullet. If technology was the silver bullet, we would have solved all of our problems. I'd like to see more understanding of how important that human element is and the culture of how we work.

I’d like to see more end-to-end thinking. It's not just about building, but end-to-end thinking within the business context. Let's say we're trying to put together a huge report with KPIs. Okay. Why those KPIs? Let's get to the bottom of it and then we can find the right technology. So, more focus on culture, understanding that it's not the technology, but it does take all three. People, process, and technology. Less of jumping into build and more about thinking before you act.

Loris Marini: Less reactive.

Dora Boussias: Yeah. Have a method to the madness, if I were to put it simply. Don't just activate and go build. Take a moment to understand the end-to-end impact. It is going to pay off in the end because many times we’ve built things then six months or eight months down the road, we realize, “Oh, that goal, we didn't catch that. Yeah, we didn't catch it,” or, “We have to go and redesign because we never thought about the downstream.”

Loris Marini: Reality outside of the organization has changed. Now, we need to change the systems. That flexibility and ability to respond to changes is also a consequence of that culture, those incentives, that interconnectedness between roles and the right roles, as you said.

Dora Boussias: Yeah, and well, you just said, the changes out there. Even as M&As are happening and we're getting new systems in our organizations to merge, we'll acquire them, or the market changing again. It's really doing justice to think about that foundation, that architecture.

Architecture is not the detailed design of, “Hey, I have the system with these lines and I'm going to write these interfaces.” Don't get me wrong. That's all very important. Let's just take a moment here first to think, “Hey, if I do this, what else depends on that? Where are we going? Where’s the next phase of the program going?"

I've come across some instances where, okay, we have this multi-year program and we're starting and we're building everything for this phase. Let's say, we'll go live in this one division. We're going to think about all of them. We're not thinking about the next phase, not from a build or a detailed design, but just from the end-to-end implications and dependency so that we can architect right.

We architect and design and build something here without thinking about what I'm going to need eight months from now. I know something is coming. I say, “Oh, I'm going to think about that then.” We're going to miss something. I mean, it happens all the time. So, let's understand where it's got an impact across the processes. Let's make sure that we understand that we'll set it up right to begin with. Then, I can build for that division. I can build for the other division or business unit or the other set of capabilities. Iterate through building and keep on adding more functionality to it.

Also putting a sound architecture that can actually scale and flex because like you said, things are changing dynamically. We're only going to start putting band-aids and having a hard time maintaining it for the long term. We're going to have to reengineer, rearchitect redesign.

Loris Marini: Well, the future is bright. I just recently read a post by Bill Schmarzo. He posted on Data Science Central, Six Steps to Becoming Value-Obsessed, I believe from Tom Davenport and Randy Bean?

Dora Boussias: Okay. I think I saw it. I haven't read it yet.

Loris Marini: Virtually every metric of the six steps is down when measured from a big survey this year compared to 2019. So, it seems like we are slowing down as opposed to ramping back up. So, there's a lot of work to do, that's for sure. What's the best way to get in touch with you?

Dora Boussias: Oh, LinkedIn, I'm pretty active on LinkedIn. Anyone that wants to, I'm always open and approachable and I'm here so we can learn from each other. So, I try to stay very active, especially in the LinkedIn community because it's a give and take, right? If some of the things that I say help someone, that's really what I want to do, that's great. At the same time, I'm learning every day from all of my friends and colleagues on there. So, LinkedIn is the way to get ahold of me.

Loris Marini: Super resonates with me. I'd rather learn than be right.

Dora Boussias: I believe in always getting better at whatever it is and learning more. I’m a future learner.

Loris Marini: Dora, thank you so much for your time. I really look forward to many more of these conversations in the future in many different forms.

Dora Boussias: Loris, this has been a lot of fun. Thank you so much. I really appreciate you having me on. Maybe we'll do it again sometime. Thank you so much.

Loris Marini: All the best.