Software Architecture: The Hard Parts

Chapter 14. Managing Analytical Data

Tuesday, May 31, 13:23

Logan and Dana (the data architect) were standing outside the big conference room, chatting after the weekly status meeting.

“How are we going to handle analytical data in this new architecture?” asked Dana. “We’re splitting the databases into small parts, but we’re going to have to glue all that data back together for reporting and analytics. One of the improvements we’re trying to implement is better predictive planning, which means we are using more data science and statistics to make more strategic decisions. We now have a team that thinks about analytical data, and we need a part of the system to handle this need. Are we going to have a data warehouse?”

Logan said, “We looked into creating a data warehouse, and while it solved the consolidation problem, it had a bunch of issues for us.”

Much of this book has been concerned with how to analyze trade-offs within existing architectural styles such as microservices. However, the techniques we highlight can also be used to understand brand-new capabilities as they appear in the software development ecosystem; data mesh is an excellent example.

Analytical and operational data have widely different purposes in modern architectures (see “The Importance of Data in Architecture”); much of this book has dealt with the difficult trade-offs associated with operational data. When client/server systems became popular and powerful enough for large enterprises, architects and ...