Cloud platforms like the ones offered by Google, Amazon, Microsoft and vendors like Snowflake have revolutionized marketing measurement. The advantages are numerous and range from low capital investments, pay-as-you-go pricing, on-demand scalability, high availability, and robust monitoring to name just a few capabilities. However, with this simplification, comes a plethora of technology implementation options and it takes a blink to get overwhelmed with technology options and loose focus from desired business outcomes.

So how do we streamline technology planning for implementing cloud-based business intelligence for marketing?

For experienced Enterprise Architects, the concept of breaking down a desired solution into conceptual and logical components and then designing each in a decoupled manner from other components should be familiar. The idea is to abstract out functionality from technology choice. We focus on defining the functionality and the various building blocks that make up that functionality and then shop for technology that can best implement the capabilities in terms of time/resource constraints.

In this article, we worked with the Enterprise Architecture team of a leading marketing technology consultancy to prepare marketing collateral for a component based architecture solution that consisted of four building blocks

• The hosting layer
• Data storage (staging, reporting, replication)
• ETL and data integration from various sources into the storage layer
• Data visualization

Each of the layers were mapped out in a manner that would be high-level enough to convey the value proposition to potential customers but yet, not be giving away too much. For example,

• The architecture for the hosting layer compared Google and Amazon Clouds around considerations like instance costs, bandwidth costs, cost of storage with replication, challenges in automating build pipelines, ease of scaling, level of customer service and compatibility with other projects within the company.
• The data storage layer involved architecture of staging, aggregating and reporting databases along with options for physical implementation (Amazon RDS, Redshift vs. Google BigQuery)
• The ETL layer involved due diligence for how data would be extracted from various source systems and moved to the staging area. This included detailed discussions around frequency of updates, change data capture, need for implementing any canonical mappings etc.
• The visualization layer involved discussing options for various self-service BI tools including Tableau, Microstrategy and Jaspersoft. Key considerations involved ease of embedding into internal apps, ease of business use, query response times, row-level security considerations and in-built support for running complex calculations with minimal need for external data prepration.

The report involved working with client staff to develop case studies on how this conceptual architecture was implemented with various technologies for each layer for different clients.