When starting your Big Data/Analytics journey, there are many project characteristics to consider. The first, before considering analytics, is how to integrate all of the data into a “single source of truth.” That is, how to design a data warehouse that will fulfill your needs and integrate all the necessary disparate data sources at your credit union.
A true enterprise data warehouse requires a significant amount of planning and a robust architecture to meet the needs of the end users. The architecture seen most fit for the complex nature of credit union data sources is the star schema developed by Ralph Kimball. While this might be one of the best solutions for credit unions, architecturally speaking, it presents a few challenges that hinder the desired end result, reporting and analytics.
For most credit unions, there is a lack of personnel equipped with the expertise needed to build reports and analytics directly from a complicated data warehouse. Although Kimball’s star schema is one of the most robust architectures, it is also one of the most difficult to work with given its complexity. Thankfully, however, it offers access to the development of abstract layers often referred to as aggregates. In turn aggregates can be leveraged to develop application programming interfaces (APIs). Without aggregates and APIs, report/analytics development requires a great level of expertise into the complexity of the data warehouse. With aggregates and APIs, however, end users can build reports/analytics with ease, regardless of expertise.
APIs and aggregates provide extensive functionality with minimal user training and:
- Allow users to access business data without needing to be a data warehouse or programming language expert.
- Enable both detailed (transactional) and summary (high-level) analysis.
- Work with common data visualization tools including Tableau, iDashboards, Excel and SAS, among many others.
- Provide cross functional data analysis by collating data from the core system and numerous ancillary systems including Meridianlink, Digital Insight, FICS, PSCU, CRIF, SAIL, Criterion, Servicing Director, MCIF, OnBase and more.
- Allow for distinct modules for lending, deposit and investment portfolios, loan delinquency, credit risk, branch productivity, member demographics analysis, etc.
APIs and aggregates enable end users to easily develop customized/ad hoc reporting and analytics. Rather than looking at analytics developed solely by the credit union’s “power user”, any end user can customize views and dashboards with minimal programming. Also, since the end user is working with the abstract layer rather than data warehouse, the data will never lose the integrity of key versions/definitions assigned in the complex yet robust data warehouse architecture.
APIs are an often overlooked feature of Big Data/Analytics solutions. Often, Big Data/Analytics solutions are developed with the assumption that the end user will possess the skills needed to build reports directly from the architecture of the data warehouse. Many solutions neglect APIs because of this assumption, resulting in a data warehouse that dissatisfies end user’s needs: reporting and analytics that support fact-based decision-making.
It is necessary to consider the end user when starting the Big Data/Analytics journey. Does your credit union have resources that possess data warehouse or programming language expertise or does it require an architecture that supports an API layer for end users to successfully execute a Big Data/Analytics program?