You can find tangible know-how, tips & tricks and the point of view of our experts here in our blog posts
With Openflow, Snowflake fundamentally simplifies data integration: extraction and loading happen directly as part of the Snowflake platform — no external ETL tools required. This significantly reduces integration effort and streamlines the entire pipeline management process.
Long waiting periods are an irritation and a cause of much frustration when working with Tableau. In this case study, we look at how to get the performance of your Tableau data source back under control - even if you're using a live connection or a complex data model.
If your company is ever to master the challenges of the Internet of Things, the one thing you must know is your IoT maturity level. Does your company have a large number of connected devices and valuable hidden data? Have you already successfully implemented IoT data analytics to create value from your processes? Do you have sufficient expertise in data storage and the management of high-performance cloud databases? All of these questions influence how you should best approach the Internet of Things.
Congratulations, you’ve managed to get through previous sections of our reference architecture model unscarred! The most tedious and cumbersome part is behind us now. However, it’s no problem if you're just getting started with part 3 of our blog series! Simply click on the links to part 1 and part 2, where we take a closer look on ingestions and data lakes as well as the entire reference architecture.
As stated in part one of this blog series on the reference architecture for our cloud data platform, we will share and describe different parts of this model, and then translate it for the three major cloud providers – Google Cloud Platform, AWS, and Azure. In case you just came across this blog post before seeing the first one about the ingestion part of our model, you can still read it here first. For all others, we’ll start by looking at the data lake part of the b.telligent reference architecture before diving deeper into analytics and DWH in part 3.
Ever thought about what the architecture of a cloud data platform should look like? We did! In our free webinar series Data Firework Days, we introduced our b.telligent reference architecture for a cloud data platform, a blueprint of how to build a successful data platform for your analytics, AI/ML, or DWH use cases. And we went a step further. Since we all know there’s not just one cloud out there, we also translated our model for the three major cloud providers – Google Cloud Platform, AWS, and Azure. In this blog series, we intend to describe the reference architecture in the first three blog posts and then, in parts 4–6, we’ll look into implementation options for each of them. So, do join us on our journey through the cloud.
I had just arrived at b.telligent with a PhD in pure mathematics and a mixed bag of programming and IT skills in my pocket. My goal: to become a certified Azure Architect within 4 months. The learning pathway: a professional development program from Microsoft and a lot of support from b.telligent.
In our series titled "The next generation of CRM – May the MarTech be with you", we have already explained the marketing technology trend's actual sustainability, the dos and don'ts to be observed during introduction, and the means of identifying one's own MarTech maturity level.
In this article, we will next take a look at the MarTech architecture – our map on the mission through the MarTech universe. Because precisely this aspect is becoming increasingly technical, complex and confusing. In our digital world, customers have numerous options at their disposal – and their demands in terms of customer experience are rising. But digitization is also bringing changes for marketers. Though the traces which customers leave behind along digital contact channels such as an online shop, app or website allow very versatile use – they also increase the complexity of marketing.
The use of marketing clouds is growing rapidly – driven by changing customer needs and the desire for more effective and more efficient data-based dialog with customers. At the same time, marketing clouds are becoming increasingly complex. Consequently, many of those responsible for selecting and implementing a marketing cloud platform lack the experience to do so. This can cause a number of problems and ultimately lead to the failure of the project.
Digital transformationin the Interet of Thing (IoT) pose a major challeng to many companies. The IoT apdoption framework supports transformation through a structured and technologicaly independent approach.
MarTech - what is it really? And how does it differ from CRM, KMS & Co.? We have already answered this in Part 1 of our series titled "The next generation of CRM – may the MarTech be with you". In this article we ask the question: Which setup do I need to actually make my MarTech stack operational?
As a consultancy, we are asked this very often. Admittedly, selecting marketing technologies can make marketers quickly feel like a kid in a confectionery store: You'd love to have a little bit of everything! However, both situations are also similar in terms of outcome: An excessive appetite usually ends in a stomach ache. At the end of the day, the objective shouldn't be to obtain as many features as possible within the allocated budget, or obtain the most recent, "cool" tool, but to achieve as much added value as possible - isn't that so? But how do I "assemble" the MarTech stack which is optimal for me?
Microsoft Power BI is one of the most popular BI tools on the market, and offers numerous ways to process and visualize data. For even greater flexibility, you can also extend standard functions extensively by using Python and R scripts. This article describes how to integrate Python scripts, what they enable, and what to keep in mind.
In business intelligence, "quality" is always a key topic but dealt with in a variety of ways. This is due to a lack of a consistent understanding in this area, and consequent absence of a standardized approach to BI quality.
That this is becoming increasingly problematic is also signified by renaming of the current Gartner Quadrant. Data quality "tools" are now called data quality "solutions". The reason: Whereas many manufacturers now proclaim to be bearers of "quality", the common denominator for this is usually infinitesimally small: To find, understand and solve problems. To their credit, this is still the source of all technical progress according to the philosopher Karl Popper. However, it does not yet necessarily have anything to do with data quality per se. In this article, I will therefore sort out and structure the topic of BI quality somewhat, and accordingly call the whole thing "BI quality management". This leaves plenty of scope for "total BI quality management", as applied and taught in the engineering disciplines for some time now.