(This is the second blog in a two-part series.
In the final part of the series, we look at the four-step approach to designing a user-centric analytics environment. Note that throughout this process, business stakeholders’ involvement is key.
Step 1: Define the analytical domain.
The analytical domain identifies the perimeter that will drive the design of the solution. It corresponds to the scope of the solution: its users, functions, semantics, etc. For example, an analytical domain could correspond to the needs of an insurance actuarial group responsible for a company's product rating program. Given the nature of the analytical domain, it must be defined by the business.
The main business and IT stakeholders of the project need to agree on the definition of the analytical domain. It will drive everything else that is to follow. It is at this step that we define what needs are to be addressed, even if only at a high-level. It’s worth noting that that this definition will serve to validate the success of the final deliverables.
Step 2: Collect business questions.
Instead of looking at the operational systems to see how we can integrate their content, in this step we want to look at how the information will be used by the business. This is key to the design of a successful, business-centered analytics solution, and is the opposite of the data integration approach discussed earlier.
At this stage, we examine the questions the business wants answered with operational data. For this, we need to look at the already existing analytical applications, reports, queries, data extractions, etc. We talk with the business about the limitations of the existing methods and about interrogation requirements that can't or are not yet being fulfilled and why. We want to build a list of business questions that is as comprehensive as possible without being exhaustive.
In insurance, for example, a business question can be as precise and as simple as “How many premiums were earned by broker XYZ’ in 2012 by month, product and coverage?”
At this stage, we need to work closely with the business to gather all the business questions and make sure we understand them. At the end of this step we will have produced a comprehensive list of business questions that will be used to discover fundamental analytical patterns.
Step 3: Identify analytical patterns.
Here we want to identify the common analytical patterns that underlie the business questions already gathered. To this end, we take as input the list of business questions, and subject them to analysis. We need to derive from them knowledge of what is needed in terms of information, the kind of facts or metrics that are sought and the conditions used to find them. A good knowledge of the business domain is a must to complete this step, so tight collaboration with the business is absolutely necessary.
We can consider an analytical pattern as more general or abstract representation of a business question. It is represented as a unique association of one or more entities. A pattern can be understood as having a tabular form with two or more dimensions. The simplest way to represent an analytical pattern is in the form of a user-story. The basic form of the user story is as follows:
We need to see: 1, fact2 2, fact 3n>?
By: 1, condition 22, condition 3n>
Thus, the first thing we need to do is find the analytical pattern underlying each business question. For example, with the question stated as, “How many premiums were earned by broker XYZ’ in 2012 by month, product and coverage?” we would derive the following analytical pattern: ??
We need to see: earned premium?
By: broker, calendar-year, calendar-month, product, coverage??
Once we have produced the list of analytical patterns, we can go on to design the analytical data model, or data mart.
Step 4: Design analytical data model.
Recall that our starting point has been the business needs and not the operational systems themselves. We have focused on looking at what information is needed and not at what data is available. We are now on our way to designing a data mart data model based on what the business itself needs, not on what we can make available in a data model that has been designed arbitrarily.
In this step, we take the list of analytical patterns that have been produced and design the target analytical data model. To do this, we consolidate the patterns together according to dimensional normalization principles. It is beyond the scope of this series to describe what these principles are in detail, but we need to say that functionally coherent analytical patterns give rise to a single, star-schema design. Each star-schema corresponds to a specific number of entities, or dimensions, related though a single relationship known as a fact table.
From a business user’s point of view, a star-schema resembles a spreadsheet where each column represents a different entity (or entity attribute), and each different cell represents a fact, or metric, under analysis. This also is how business users are accustomed to working with information.
The combination of all star-schemas amounts to what we consider a data mart. We can see how a single data mart can contain multiple analytical contexts, or star-schemas, which, in turn, can address multiple analytical patterns, which, in turn, can address even more business questions.
The analytics solution produced following these steps has the added value of addressing many more business questions than those that were used to define it to start. And those questions that originally were used as a starting point can still be answered in a natural way because it is from them that the whole design was produced. One of the most beneficial effects of an analytical context is that it multiplies the number of analytical patterns that can be supported. It is not limited by what was used to define it.
If we follow the approach described in this series when we undertake a new analytics project using existing reports and analytical functions as a starting point, we invariably deliver more value than what we started with in the first place. Remember that the objective of an analytics solution is to offer a coherent view of information for analysis, the bulk of which is unknown at the time of its design — it is not simply to support a set of predefined reports, extracts and queries.
Jean-Stephane Faubert is a senior solutions architect at InEdge.
Readers are encouraged to respond to Jean-Stephane using the “Add Your Comments” box below.
This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.
The opinions of bloggers on www.insurancenetworking.com do not necessarily reflect those of Insurance Networking News.
