Abstract: Here’s the thing about data: it’s sticky, often rigid, and rarely feels agile. Yes, there are patterns that help increase the agility of data. Ruby on Rails, for example, has data migrations that not just allow but actively encourage incremental schema design. However all too often we hear about relational databases becoming a defacto API between subsystems, and thus resistant to change. It’s not just relational databases. Even supposedly unstructured data stored as key value pairs can be difficult to change if every piece of code that uses the data has duplicated logic to manage the semantic meaning of the data. Further, in-database logic such as rules, stored procedures, or user defined functions can be remarkably difficult to unit test. Finally, there are the often strict data governance requirements that necessitate keeping tight authorization control. Application developers have a wealth of tools and practices available to support incremental delivery. System administrators have DevOps tools and practices to support repeatable, automated operations. Where are the equivalents for data-centric work? Bringing agility to your data strategy may feel like an impossible goal, but it is possible. In this talk we consider the various ways in which data can impede agility, and how to make data strategies more agile-friendly.
Learning Outcomes: - * The myriad ways in which data can make change difficult and expensive
- * How to think about breaking apart the monolith in the context of data
- * How to lower the cost of change curve for data schemas by applying agile / devops principles to data-related practices
