Solution Patterns

Within the IT/Software space, the concept of patterns has emerged as a practical tool to design complex systems. Patterns help categorizing solutions and avoid re-invention of the wheel as much as possible. They help keeping the focus on the similarities between solutions, and isolate the differences necessitating customized development. Pattern-derived solutions are deemed more efficient during implementation time as well as support time for two major reason:

1. Time & effort is saved in "trying out what works" (establishing proof-of-concept models)
2. The common underlying patterns help stake holders communicate with common terminology, decreasing the risk of miscommunication during requirements gathering and acceptance testing.

Between the various sets of patterns, one can generally distinguish between the following pattern types:

• Structure (architecture)
• Behavioral (process)
• Data (content)
• Usage (presentation, interaction)

Within the Business Intelligence space there have evolved a couple of architectural patterns that recur in a broad range of solutions.

Structural (data models):

• The Operational Data Store (ODS) first proposed by Inmon
• The Kimball-inspired Dimensional Model (Fact & Dimension Tables)

Behavioral (processing):

• ETL, the process of extracting source data, transforming it, and loading it into a target data warehouse
• ELT, extracing and loading first, then transforming it locally in the data warehouse

Data (content)

• Time grain (date vs. timestamp)
• Measure (quantitative business metric) 
• Criteria (qualitative, for grouping, filtering, sorting)

Usage (presentation & interaction):

• OLAP (multi-dimensional cubes, drill-down, drill-through/across, rollup)

But these are just the means. These patterns help implement a technical infrastructure, but they do not solve the business challenge of having proper intelligence (actionable insight) at hand.

So what are the application patterns, from a business perspective? Business solutions that directly correlate to one of the key success factors, such as for instance increase organizational efficiency, increase customer satisfaction, or risk management. Some examples coming to mind:

Increase Customer Satisfaction:

• Recommendation Engines (e.g. Amazon's suggestions)
• Stock Market Alerts (stock price trends triggering threshold events, notifications)

Risk Management: 

• Fraud Detection (trigger alerts at unusual credit card activity)

Organizational Efficiency:

• Web Site Path Analysis (identify most commonly taken browsing paths, correlate to purchases)
• Search Engine Marketing (keyword spend vs. conversion events)

The reason why this understanding is useful before getting into the details of a B.I. project is that there may already be a standard pattern for what you try to achieve. Perhaps not a canned solution, but something you can adapt and build on, instead of having to reinvent the wheel.

When you hire seasoned B.I. specialists, you inadvertently get some pattern knowledge, based on how they solved similar challenges in other environments before. That's why it is helpful to focus on not only technical or tool expertise when staffing, but also leverage candidate's industry background as applicable.

Solution patterns are useful to communicate and collaborate on complex business intelligence aspects across functional and technical roles, as well as across companies.