TLDR; Each business domain should have a subject matter business intelligence member embedded within its domain

Most organizations have a centralized data team which caters to the data requirements of all business domains.

This helps users get business data from a central reliable hub. All business data gets ingested and integrated into this central hub. Business Intelligence reports are subsequently built from the datastore in the central hub. There are many reasons why this is an appealing choice to businesses not least the elimination of siloed reporting, each domain/subject area can get on with what they know how to do best- the activities in their area such as Underwriting, Actuarial projections, Pricing, Accounting, Financial Planning to name a few.

However, the expectation is that the data view of each subject area has been captured by the central data team. Often when this is the case, there is a data mart catering to the relevant subject area. A technical SME in the central data team services this data mart.

The data is coming from a central repository and therefore has less chance of it being misinterpreted by users. This approach presumes that the business has carried out it’s data management activities such as data modeling, master data and metadata management. These activities help to identify business data, their definitions, the context and applications across the various business domains.

Following the data management activities, the responsible data team is then able to develop a list of conformed data terms across the business. This supports the data engineers in building the datawarehouse and data marts which will serve respective business areas.

The problem I have seen in many organisations is that the centralised view of the data does not always cater for the required view of the business subject areas. Often, not because of negligence but simply because a dedicated subject area expert was not consulted on what various terms actually mean to their subject area. A lack of data marts to provide subject area data perspective is often a glaring indication.

Occasionally, following the implementation of a new data storage platform, a generic data field name identified by the central team as a critical data item inherits a new definition which lacks context for the respective teams. This term is then applied to cross business reporting. This causes a misunderstanding of the data. A lack of flexibility then ensues because the data team is trying to force the centralized data view to tell a different story. The central data hub believes all requirements have been covered but the business users are adamant that they do not have the required information. This causes no end in frustrations and delays in getting business metrics out to the respective team . This can lead to teams using complex queries and methods which are not flexible to expand and cannot easily accommodate even the slightest change to user requirements. The various business areas are unable to get the data required due to the rigid structure of the underlying business data. I can write pages and pages on this but hopefully I have been able to paint a picture in your mind.

The good news is ; It doesn’t always have to be this way. An example, I was at a client who had a centralized data reporting function as most organizations do, but was not able to satisfy the requirements of a key domain within the business. I was brought in to be the dedicated resource for this domain. What I found was that there was no data mart for subject areas and the data which was coming from the centralized team, although had been designed to cater to the entire business functions, did not align with the view of this subject business domain. Hence the problems in getting the correct business information. It did not stop there, the data function had restrictions in place which prevented remodeling the data to obtain the required information. Views and complex stored procedures were used to restructure the data within code. The data warehouse could not be modified – this is understandable given the magnitude of making changes to a centralized repository, in a highly regulated sector, which was required. There would need to be a business case and buy in from the Executives for initiating an entirely new project on its own to address this issue. There are pros and cons with this lack of flexibility. Ultimately, in order to satisfy all business domains, the whole Enterprise architecture needed to be reviewed and future proofed to allow progressive modifications to subject area reporting requirements.

In adopting a new data storage application, all “subject area business intelligence experts” must be consulted to obtain the required data for the respective domains and conform these as much as possible. Essentially, there should be a domain BI SME who describes the view of the data their domain requires. This SME is best placed within the domain/subject area giving direct access to the business users and regularly speaking the team lingo. This domain expert should not be a pure subject matter expert but one who has in addition to subject area knowledge, expert knowledge of data terms and relationships within the subject area. This may need to be two individuals from this domain sharing knowledge. Modeling of each subject area view should be incorporated into the decisions that drive the new data storage platform.

Understanding the various subject area terms is vital because Domain data requirements may need to be more descriptive than the conformed field across the enterprise. The definitions may need to be amended to correctly identify the field required by a domain. Business users should be enlightened on the accurate and appropriate business term definition which applies to their data needs. This is usually driven by industry standards , taxonomy or consensus with key stakeholders.

Business terms can have identical generic names but are essentially a different field /definition within the business. An Enterprise BUS matrix is useful here to identify fields used across the business domain. This will help streamline the requirements for data warehouse build. Clarity should be sought from the subject area SME, to ensure appropriate suitability and understanding of data terms.

Each business domain should have a subject matter business intelligence member embedded within its domain

Benefits; Better understanding of domain data, documented business context, efficient processing of information, quicker time to delivery, potential quicker returns on investment

Connectbatch services include data modeling, data management, data maturity assessment, data analytics, business intelligence and helping businesses and data warehouse teams achieve streamlined reporting. We can help with the various difficulties presented above.

Are you experiencing bottlenecks in your reporting? Our team can help!