Architectural Considerations when Democratizing Data – Part 2


In part 1 we saw the results of a TDWI study which reports on why business wishes for self service access to data. The results are below.

  • Constantly changing business needs (65% of respondents).
  • IT’s inability to satisfy new requests in a timely manner (57% of respondents).
  • The need to be a more analytics-driven organization (54% of respondents).
  • Slow or untimely access to information (47% of respondents).
  • Business user dissatisfaction with IT-delivered BI capabilities.

We continue, looking at what data consumers need.

Data Consumer Needs

The data consumer needs to get the data, often from multiple sources and combine it, refine it, and report on it – today. That means the ability to complete your work without having to wait for IT to get involved. Architecturally, what is needed to satisfy the data consumer need?

  • Consumable data
  • Findable data
  • Consolidated, clean, timely and trustworthy data
  • Tools which match the skills of the consumer

Consumable enterprise data might be in one or more data warehouses. Tables and columns should be named whatever the business calls them, rather than what IT might name something. Although necessary in the past, short, cryptic IT names are no longer required and should not be tolerated. The data should be modeled simply and flat. This means the data model should be something like a dimensional model, and definitely not a normalized data model. This data exists to be easily, simply consumed by non-technical people.

Findable data sounds like what it is – what devices exist to allow the consumers to find the customer records, the inventory records, etc. Although the problem is easily described, the solution is often difficult and failure prone. A large enterprise might incorporate a meta-data management (MDM) solution. An MDM might list all of the data available with field definintions and locations. Solutions like this often fail because they can easily become out-dated due to lack of maintenance. Perhaps something as simple as a document, contact person or data steward for each type of data is enough to satisfy. However, you must be able to find the data.

Consolidated, clean, timely and trustworthy data is also necessary. Consolidated means data from multiple sources or systems, which contain the same kind of data, should be consolidated. For instance, a single global customer table or invoices table. Data should be clean enough for its intended purpose. While the data may be clean enough for the source systems in which they live, other uses may find the cleanliness lacking. So even if you are convinced that your inventory system has perfectly clean data, you will learn that it is not clean enough. As you move the data into a data warehouse, or analytics repository, you will find that the new analytic use brings new data cleanliness requirements.

Data GovernanceTimely actually means recency – how up-to-date is the data and how will consumers know when the data was last refreshed? Does someone certify this data? Is it trustworthy? If the business folks do not trust that the data is accurate – the data will not be used.

Combined, these topics are called, “data governance.” An additional source of information can be found at the Data Governance Institute.

Although the biggest issues are related to data, tools also matter. The tools that are available to the consumer should be capable of providing the functions that are needed. Functions might include reporting, mobile apps, analytics and data mining. You should also consider dependent funtions like the query builder within the tool. Can the query builder provide whatever filtering, joining, and calculations the consumer needs? Must you provide a tool which can generate queries for people who do not know SQL? Probably – make sure your tools match the needs, are readily available, with training, examples and best practices to help the ad-hoc user complete his task.

Architecture Considerations

You will need to recommend or create an architecture which encompasses all of these needs. Your architecture should include a holistic view of the world. Of course that means describing:

  • How data will flow from the sources to the destinations.
  • Where and how cleansing will occur.
  • How data from different sources be found, tagged with proper metadata, named, cleansed, consolidated and made available.
  • What can be done to assist business with data access and use?  Other than proper tools, in the Microsoft BI world – you can create re-usable report templates, provide shared data sources, saved queries and report parts. You can make SSAS tabular and dimensional models available. These models are a semantic layer for the business and provide fast access to data.

Will your busines folks need to save versions of reports or data? This is a common requirement for regulatory reporting, but the requirement often goes unnoticed until near delivery. Your architecture should provide means to get this done if it is a business need.

You have a great opportunity to provide value to the business which can really mean something to the bottom line.

In the next part, we take a look at the world as it relates to Information Technology (IT) people.

 

 

 


Please share your thoughts on this post:

Your email address will not be published. Required fields are marked *

About Mariner

Call Us Email Us

How Can We Help You?

Mariner © 2018. All Rights Reserved.