CIO Ryan Snyder on the benefits of interpreting data as a layer cake
During the first two layers, we frame the data solution in business context terms, with the business leading these discussions but IT still involved.
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.
About Author
