Summary

• Wayne Eckerson, president of Eckerson Group, and Dan O’Brien, research analyst, discussed the concept of data and analytics operating models, which refers to how organizations organize their data and analytics resources for alignment and efficiency. The responsibility for implementing these models typically falls on the head of data and analytics, who may have different roles and reporting structures within the organization.

• They discussed the concept of the "purple person" who possesses both business knowledge and technical capability in the field of data analytics. They also talked about the shift from a dictator-like, top-down approach to a facilitative role for the enterprise teams in order to meet the specific needs of different business domains.

• Wayne discussed the importance of identifying data-savvy individuals in different business domains and supporting them through training and coaching. He also emphasized the need for establishing standards, documenting best practices, and creating a self-service data platform to facilitate the development of solutions aligned with business requirements.

• Wayne discussed two approaches to creating a purple layer in data analytics. The reddish approach involved empowering existing teams to gradually adopt standard practices, while the bluish approach involved assigning experts from the enterprise team to individual business domains to support and build solutions tailored to their specific needs.

Transcript

Dan O'Brien

Today I'm speaking with Wayne Eckerson about his most recent report “Operating Models for Data and Analytics: How to Align Resources Across the Enterprise”. Wayne is the founder and president of Eckerson Group, and a globally known author, speaker, and consultant.

Hi, Wayne, how are you?

Wayne Eckerson

I am terrific and yourself?

Dan O'Brien

I'm fantastic. Let's hop right in. So in your report, you're talking about operating models. What are data and analytics operating models, and who is responsible for them?

Wayne Eckerson

Yeah, good question. “Operating models” is a term that's gained relevance in the last number of years. And to be honest, I'm not sure where it came from. But to me, it really speaks about how you organize your data and analytics resources within an enterprise so that they are aligned with each other, whether they're residing in the enterprise or corporate level, or out in the business units or departments or domain level.

Because oftentimes we see that, especially those groups, the enterprise group and the main groups are completely non-aligned and oftentimes at odds with each other. And even within those groups, especially the enterprise groups, there's not a lot of alignment between the data team, the analytics team–which might be an analytics center of excellence. And there's no reach out or way of supporting in a consistent, systematic way. business units and departments are in the domain.

So in short, an operating model is how you organize yourselves in the data and analytics realm to ensure alignment across the enterprise and that you're getting the most bang for your buck from your data.

Dan O'Brien

Fantastic. And so if we have these models, who is responsible for implementing them? Who's in charge of this?

Wayne Eckerson

It's the head of data and analytics or the chief data officer or the chief data and analytics officer. It could be different people. Could be a head of data, a head of data engineering plus head of analytics plus a head of governance.

That's the thing. There's no one right way to organize, especially your enterprise teams. And there's no one right way to manage and set up who they report to within the organization. For instance, a lot of companies will put both data and analytics in IT. Some will put data in IT and analytics outside of IT, and put data governance outside of IT.

Some will put everything outside of IT. That is my preference: to move all of data analytics outside of IT, but it's not necessarily what happens in most organizations, for obvious reasons. Data is a very technical undertaking. You need engineers and they, engineers, are typically housed in the IT department. But yes, it's the head of data and the head of analytics, or one person who's in charge of both who's responsible for the operating model.

Dan O'Brien

Right. And so you have all these teams. It can be bespoke. It's different for each company, but you've color coded them and you grouped them nicely using a blue–purple–red system.

Can you talk about what these colors signify and how they're used to relate the teams?

Wayne Eckerson

Yeah, many years ago at a former job at the Data Warehouse Institute, we came up with this notion of the purple person. And the purple person or purple people were those who could really make dating analytics work successfully at organizations. They were purple because they're a blend of blue and red. In other words, they weren't just blue, in IT, and they weren't just red, in the business.

They were basically a perfect blend of business knowledge and technical capability. So we call them purple people. And this color coding works well on the operating model side because you're going to have more technical people at the enterprise level on your data engineering team, your data architecture team, and your analytics teams. And then you're going to have more generalists, who still are technically savvy but more business-oriented, work and live out in the business units or departments.

And you need a way to connect them. And that's the purple level or the purple zone. You need people who have the technical expertise, but also business or domain knowledge to build solutions that actually work effectively and are delivered quickly to satisfy business needs.

So there are many ways to create that purple layer, but ultimately that is the big challenge of an operating model: how do you organize your resources to ensure that you've got both business knowledge and technical knowledge at the point of intersection with the customer? And that's not always the case in most organizations.

Dan O'Brien

So between these teams, we've got directions of flow, of information and control. Can we just give an example, discuss an example, of a top-down flow? So that's what you call blue to purple.

Wayne Eckerson

I think it's really important to understand for the blue team, the enterprise data and analytics team, that in the old days they used to do everything, right? They would get the data, model the data, store the data, and then they would build out the reports and the dashboards on behalf of the business units and departments, or what I call the domains. So we used to say that they kind of dictated everything. They were dictators.

But in the last 20, 30 years, there's been a slow-moving mutiny against that model. The business units don't like having to get in line and wait for the enterprise resources to come serve their needs because usually it takes too long, costs too much, and they don't deliver what they want when they want it. And if they do, it's usually out of date by the time it gets delivered.

The old model of the enterprise group, the blue teams, essentially doing everything is gone. The new mantra is not I'm going to dictate what you do. It’s “I'm going to facilitate what you do.”

So the new role, with some exceptions, of the enterprise teams is to facilitate development in the business domains. In my opinion, the flow is mostly about facilitation.

Now there's still a lot of development work that the blue team is going to do. Only the blue team can do enterprise-based cross functional solutions. Only the blue team is really capable of managing ingesting data that’s shared across functional areas. So they're going to be managing the data repositories.

After that, most of the solutions are going to be built and reside in the business domain. So the blue team really needs to facilitate that local development work. They need to find out who actually is data savvy and has data requirements and analytics requirements out in the domain. That's the first thing. Find out who your customer is in the business domain, and then figure out how best to serve them.

And from what I've seen you can help oversee them, train them, coach them, support them. I'm talking about data analysts, typically, and data scientists or managers of data analyst teams or data scientists teams that are out in the business.

Also it’s important to establish standards and document best practices and provide a platform on which they can work: a self service platform that makes it easy for the business domains to build the stuff that they need for their own business processes.

So those are the main things: coach, support, train, establish standards, document best practices, and educate people about them in the business domains. And then create this self service data platform that makes it a lot easier for the business domains to service their own needs.

And then the reverse side, the business domains also need to participate. They are the repository of business requirements. They know what they need, right?

So they need to make themselves available–which they often don't do–to folks who are going to develop solutions for them, to express their business requirements. They also need to take an active role in governing the data because they know what the data should be and what it means. They need to create definitions that are consistent across the organization, this is data governance.

The business domains play a huge role in not only building solutions for themselves, but identifying their requirements and governing the data and the output of their solutions. Also, they’re building reports and dashboards and make sure that they're all standardized consistent and aligned across the enterprise.

Dan O'Brien

Great. And now to go back to these purple people. These hybrid teams, it seems they can come in a lot of forms. Would you be able to discuss some of the common forms these hybrid teams are appearing in?

Wayne Eckerson

Some are more bluish and some are more reddish. And oftentimes this depends on the capabilities and interest of each domain. And this is what makes it challenging for enterprise teams, that there's no one size fits all. 

Every business unit is going to need to be dealt with differently based on the kind of resources it has, the number of data analysts, how skilled they are; the number of data scientists, if there are any; and what their requirements are.

In most organizations, you'll see sales, marketing, and finance are pretty sophisticated when it comes to using data. And a lot of them have built out their own teams, oftentimes their own solutions, using their own tools. And they've become silos of sorts, data silos. And that's usually a problem, but an opportunity, right? If you've got groups like that then the opportunity is to empower what already exists there, but make sure that what they're building is built in a standard, consistent way so other people can take advantage of what they're doing and we're not creating fragmented data. That's where a lot of the standards become important. Hopefully you’re adopting best practices and educating people about those, and then providing a platform.

Now these guys usually typically have their own tools that they're wedded to and you may not be able to rip them out of their hands by any means. But at some point, hopefully, you can get them on a standard platform because they can see that it makes them much more efficient and productive. They can get out of the business of having to become and be systems integrators and systems administrators on their own.

So that's more of a reddish approach. We're just going to empower the teams that exist and slowly, gradually move them in a more standard way of building and managing solutions.

Now a more bluish way to create that purple layer is to have experts on the enterprise team be assigned to individual business domains to support those domains and get to know those business domains inside and out. And maybe even sit in those domains two or three days a week, or maybe even more, so that they gain that domain knowledge that they need to be able to one: recommend solutions proactively, and two: build them quickly and effectively, because they understand that business needs inside and out.

Typically what we see there is companies building out centers of excellence or tiger teams or SWAT teams. Or even just individuals who are more than specialists, someone who can build ETL pipelines, model data, and build dashboards–we used to call them spanners because they span the stack–and are required to develop a complete data analytics solution.

So you assign people who are enterprise-oriented. They are hired by and reside in the corporate team. However, you assign them to each domain to build out the solutions and capabilities that that domain needs to meet its own business goals and objectives.

That's more of a bluish approach. SWAT teams, Tiger Teams, and spanners as we've called them, assigned to individual domains.

Dan O'Brien

Well, thank you very much, Wayne. I appreciate your insight.

You can read Wayne's report “Operating Models for Data and Analytics: How to Align Resources Across the Enterprise” on our website, EckersonGroup.com.

And Wayne, what's the best way for listeners to keep in touch with you and maybe reach out about their data analytics needs?

Wayne Eckerson

Sure, people can reach me at [email protected]