Data is the currency of your Digital Transformation

This is a scary time for a company. But the state of play creates the potential for mass and creative disruption.
—¬†$1 Billion for Dollar Shave Club: Why Every Company Should Worry @ NYTimes

Every company is a digital company. No longer is it a question of if your product will become digital – as was the case with music, newspapers, TV, movies, etc. – it is a question of how the experience of your product (and your company) changes even if your product isn’t digitized.

eCommerce, digital marketing, social, CRM, and content technology and strategies are critical. You will need to invest in those technologies – but underpinning all of those technologies is data – that data is the currency of your digital transformation.

Continue reading “Data is the currency of your Digital Transformation”

The future of data is still Polyglot…

… but vendors will fight you every step of the way.

Remember – every vendor wants to get as much of your data in their database as possible. And every data approach (Relational, Document, Key/Value Store and Graph) can be forced to do just about anything; and given the opportunity the vendor will tell you their solution is the right choice. 

The challenge for the modern Enterprise Data Architect is maintaining a cogent point of view about assembling a polyglot solution to make each use case (or micro service) less complex, more scalable and easier improve/enrich over time.

Polyglot Persistence – Benefits and Barriers

21828243446_136614fc89_o
Photo Credit: Christophe BENOIT

Polyglot persistence is simply the notion that one should leverage multiple data storage technologies chosen based upon the way the data will be used by the application.

In short, use the best tool for the job.

Benefits

  1. Attempting to make a single data store (or database if you prefer) encapsulate all your application contexts breeds complexity. When each context, entity or value object can tune the data store leveraged to the unique requirements of that domain complexity is reduced and feature velocity is increased.
  2. Polyglot enables in data store transformation, materialized views and projections of the data into alternate stores for the purpose of enabling specific application features. Simply put, you can have multiple representations of the same data where and when it is convenient in your application context.
  3. Data store spend is targeted toward the features and contexts in the application which actually require the investment.

Barriers

  1. Joins – perceived complexity due to the inability to create a single “query” joining multiple contexts, entities or value objects.
    1. Understanding the benefits of composition allows us to see this as a false barrier – it is simply an issue of changing from the old way of doing things.
  2. Maintenance cost – expertise and management of multiple data stores adds to the overall cost of operating the application.
    1. In a monolithic data store system extensive effort is put into the “tuning” of the data store. This is always due to either the massive complexity of data stores that try to do everything or the need to make a single data store solve too many disparate persistence models. When we use data stores which are “natural” to the domain, context or entity this overhead is massively reduced.
  3. Developer Complexity – finding and staffing developers that can work with multiple data stores is impossible.
    1. When transforming from a monolithic data store architecture this will absolutely be problematic. However, as your polyglot practice matures this issue will diminish with time.

All of the above relies on having a solid domain driven design and flexible, adaptable architecture for your application.