I'd like to start this two-part series with a definition of what data-driven design means in our data world today. Most definitions say data-driven design has some of the characteristics described below. Let's take a closer look.

Data-driven design: Tailored 

The need to tailor design based on user requirements and preferences requires us to work with business users to gather their wants and needs, then project those into the data. Most of the time we have to create some sort of reporting, query or front-end application to easily display the data for these users – we want to document their preferences and business requirements in a format that's easily understood. The details should be presented at a level that makes sense to the business user, with technical documentation attached or added in comments.

I use spreadsheets to share this type of information. A spreadsheet gives me the flexibility to create everything in one place but display it the way I need to for technical versus business users. For example, let's say the objective is to demonstrate an understanding of the requirements. I usually do this by presenting a PowerPoint presentation to enhance group discussions. These usually end up being very "healthy" discussions as we make sure everyone is clear about the requirements.

Data-driven design: Interactive, engaging

Most of the projects I've been involved with engage our users in different ways. For example, when we speak with some of our business users, high-level diagrams that are centered on the subject at hand seem to work the best. But when we meet with technical users or designers, we usually have to create detail at a level that can influence the design (in a good way). Some of us may need to meet with other functional groups that may be impacted by the project, too. These people could reside anywhere across the organization. Don’t forget all these different users!

Data-driven design: Suited to Agile

Doing data-driven design fits Agile methodology perfectly. With Agile, we can work incrementally and iteratively with our business users. Agile methodology usually breaks work into small increments that minimize the amount of up-front planning and design. Iterations, or sprints, are usually between one and four weeks.

Technology, process, mindset

All of this begs the question: Is being data-driven more about your technology, your processes or your mindset? I believe it is all three. Here's why:

• Technology has finally allowed us to do what we thought about years ago. We used to only dream about being able to connect disparate data sources with software. Now we can do it. We thought that metadata should be easier to obtain, and now it can be. We hoped that all data could be available as fast as the speed of light – and now we can stream data.
• When we think processes now, we don’t just think batch. We think about how we can get the data to the decision-making processes faster. Processes that can make our corporation top of the heap. Processes that can make a huge financial difference for a corporation.
• Our mindset about data is changing – that is, what to do with the data and how to use it. The fact is our business users want and need data faster than ever before. So all of us who have lived and breathed data management and governance over the last 10 years need to rethink some of the same principles, but in a faster way. We can still govern data usage, and we can still manage our data. We just have to do it faster.

I enjoy looking at new ways to get data to our business faster. In Part 2, we'll concentrate on lessons I've learned and things that could go wrong as we start to use data-driven design.

Download a paper to learn how SAS provides a comprehensive platform for data-driven businesses