CIO Ryan Snyder on the benefits of interpreting data as a layer cake

A data and analytics capability cannot emerge from an IT or business strategy alone. With both technology and business organization deeply involved in the what, why, and how of data, companies need to create cross-functional data teams to get the most out of it. So Thermo Fisher Scientific CIO Ryan Snyder and his colleagues have built a data layer cake based on a cascading series of discussions that allow IT and business partners to act as one team. Martha Heller, CEO of Heller Search Associates, recently sat down with Snyder to find out more.

Martha Heller: What are the business drivers behind the data architecture ecosystem you’re building at Thermo Fisher Scientific?

Ryan Snyder: For a long time, companies would just hire data scientists and point them at their data and expect amazing insights. That strategy is doomed to fail. The best way to start a data strategy is to establish some real value drivers that the business can get behind. At Thermo Fisher Scientific, those value drivers fall into three distinct areas. One is streamlining our own back office, and the other two apply to our customers’ businesses of advancing scientific discovery and accelerating clinical outcomes.

What are some examples of data solutions in each of those buckets?

In the back office, a very exciting area for us is the manufacturing space. Unlike many other industries, life science manufacturing involves a lot of custom non-repeatable activities, so we can wind up with tremendous variability in terms of how products get manufactured. Historically, we drove productivity through Lean Six Sigma and optimizing workflows. But with the advent of Industry 4.0, we’re putting sensors across our manufacturing processes, which give us vast sums of data our leaders use to rethink those processes.

On the scientific discovery and clinical outcomes side, many of the instruments we sell are becoming digital. Microscopy and gene sequencing, for example, generate a very large amount of data, which our customers are trying to analyze. The more we can create platforms to connect and simplify it, the easier it is for them to get to the data that matters. This is especially true when they have datasets from multiple instruments. How do they bring all of that data together? That used to be the burden of the customer. But as a vendor, we can accelerate discovery by connecting those different datasets.

You’ve talked about your data platform as a layer cake. What are the layers?

In IT, we often talk about the layers of a technology stack. The layer cake metaphor shifts the data discussion from an IT discussion to the intersection of business strategy and technology. So it’s about how we create layers from the business concept, like advancing discovery, all the way down to a technology solution, like a visualization tool.

The first layer is the business concept layer, where we deliberately organize sessions with our business partners to discuss where in our business data create value. This is no different from how an HR organization would develop a talent strategy to underpin a business strategy. So mapping out those ideas is integral to the first layer.

The second layer is the consumable layer, where customers, both internal and external, can access and use the data. This is where we select visualization tools, for example. The third and most complicated layer is architecture and governance, which we’ve linked together as one layer.

With the first two layers, the business is the driver with IT in a support role, but with the data governance and architecture layer, IT and the business are side by side, working through complex decisions about governance and architecture together.

The last layer is raw data, which is where we get the data out of the source systems, organize it, secure it, and figure out which data lakes to use. These aren’t typically business discussions; it’s largely IT.

So, with the layer cake model, we have a cascading set of discussions between IT and our business partners, the business driving at the top levels, and IT driving at the bottom.

What’s an example of a data problem that illustrates how the layers work?

Let’s take the goal of simplifying our revenue reporting across the company, for instance, which can become overly complex in a business that’s grown through acquisitions, many of which with their own finance systems. At the business concept layer, finance leadership engages in a cadence of discussions with IT and data engineering leadership to discuss the process change necessary to create enterprise self-service revenue reporting. At the consumable layer, we decide how people will consume the revenue data. Is our goal one portal or should we have one portal for revenue on the clinical side and the other for our product businesses? At this level, we involve the general managers, who consume the data, and a few more IT people scale the solution. We click down in the org chart as we move through the layers.

What happens at the architecture and governance layer?

During the first two layers, we frame the data solution in business context terms, with the business leading these discussions but IT still involved. At governance and architecture level, however, the IT team drives the conversation to decide on the data standards and rules that will allow us to manage the consumable layer. Does the data live in one or many clouds? Do we want to use the same visualization tools for each business? Who has access to the data?

And then at the raw data layer, the IT team makes engineering, storage, security, and other tooling decisions.

What are the advantages of putting data architecture and governance together as one layer?

Speed and avoiding rework. When we did an initial assessment of our data capabilities, we saw we had lots of little teams, each with little databases, with everyone making the right decisions about data for their view of the world, but no one was looking across those little databases. We needed a layer that brought IT and business leaders together to look across that landscape. You need some investment from both sides to look for the better way.

How has the layer cake structure benefited the company?

It’s given us agility. We can make sense of very complicated datasets across the enterprise, but then allow for people to solve problems at a very local but orchestrated way. The layer cake gives IT a chance to see all the business problems that data might solve, and the ability to solve those problems quickly. It also gives the business some ownership over data decisions.

What were the challenges of putting the layer cake together?

We had to shift from project management to a product management model, which was very important because when you fund the growth of a data strategy project by project, you end up with a Frankenstein’s monster of shortcuts, because you run out of money or time. In a product model, the teams are not time-bound architecturally; they’re driven by product outcomes versus project outcomes. Shifting to the product model can take a lot of time and effort.

Another challenge was I let the teams get too attached to some legacy technologies. The data space is advancing so rapidly and there’s so much happening in the startup communities that you can get stuck if you stay on outdated technologies too long.

The third challenge was to make sure we had ambitious long-term data strategy goals, including artificial intelligence, but could start small in a manageable way that created value. You have to be able to solve little problems while bringing them into a whole vision. If you don’t, you could spend a year solving small problems while missing the big investment opportunity.

What advice do you have for CIOs who want to build a similar data structure? Find a few internal partners who have the desire and ability to help you build the model, because the roles you’re asking your business partners to perform are not ones they’ve traditionally held. They want the data, but do they understand what they’re signing up for? The business and IT teams can truly operate as one. Focus on who your first partners should be, because the best additional advocates for developing a data strategy won’t necessarily come from you; they’ll likely come from other business peers.