My third data warehousing tip is to build thin slice.  Deliver subsets of valuable functionality. Get feedback and buy in, and use this to drive the next release.

Thin slice development is the process of incremental delivery.  Where you build only the functionality necessary to deliver the one requirement that you’re currently focused on, but where that requirement is driven by end-user functionality, not something in the back end that nobody will see.  In my experience this way of working not only drives continuous improvement, but it also drives improved stakeholder and end user engagement.

Thin slice development gives stakeholders something tangible to focus on, which in turn gives the project direction.  It drives clear requirements, and it builds momentum.  And with clear requirements and stakeholder engagement, it gives you every chance of delivering real value to the business.

With thin slice development you are delivering a version of the solution that is ready to be deployed to a production environment if desired.  This means that you are building functionality that should stand the test of time.  You are following your development best practice to deliver a subset of the final solution.  For example, if you had a requirement to report on sales revenue per month you would build:

• The subset of the ETL to load this data
• The subset of the data warehouse model to hold this data
• The final version of the report or dashboard to visualise the data

Requirements, what requirements?

I’ve seen a number of data warehousing solutions where the reporting requirements weren’t clear.  In some cases they were non-existent.  This results in a model that can be really challenging to work with for both the developer and the end user.  In this scenario, developers don’t have any reporting requirements to base the model on.  It can be difficult for them to envision how the solution is going to be used by the end user, so they can end up building something that resembles the source system structures because that’s all they have to work with.

End users that are trying to interact with the model then require assistance to build reports, or have to write complex queries to get the data that they need in the way that they need it.  Their queries can end up being very long and difficult to understand and maintain.  They can also end up being slow to run.

Requirements can be really hard to come by.  They can be pretty vague such as “delivering change for the business”.  Some are just a tick in a box to build a “new reporting solution”.  However, it is the detailed reporting requirements, the questions that need answering that must drive the design of the solution, and thin slice development can really help here.

Show something tangible

By showing the end users and decision makers a finalised report, it gives them something tangible to look at.  Sometimes when talking conceptually it’s difficult to visualise the end product.  Giving users and decision makers an actual report to look at and play with really helps them to give you what you need.  Feedback.  They might not like the colours, they might not like the style, you could have completely missed the point.  But this is all great – honestly.  They are engaging with you about what they want and what they need and this is exactly what you need as a designer or developer.  Critical feedback.

The massive win with thin slice development is that you aren’t getting this feedback once you’ve delivered the shiny new full solution.  You are getting feedback when you’ve delivered one small piece of functionality.  This feedback will not only enable you to refine or rework what you’ve already delivered, but it will also drive what you build next.  It will inform your future decisions and the future direction of the solution.

Engage the stakeholders

By showing something tangible you are doing something else.  You are engaging the stakeholders.  Those that have a vested interest in what you are delivering.  You are showing them that this thing isn’t coming in six months, it’s here now.  And if they want their say, now’s the time.  They don’t have to have a clear vision, or try to see yours.  They can see it all on the projector screen in front of them.

Seeing something tangible can really start to make people see the direction that a project is taking and what’s possible.  It can lead to more focused and creative thinking and asking what else could be achieved.

De-risk the solution

Another benefit of thin slice is that by building thin slice you are touching multiple areas of the solution straight away.  You aren’t building the entire ETL and data warehouse before thinking about the reporting requirements.  You aren’t leaving the tricky bit until later on.  You are tackling a small part of each area of the solution immediately.  You are connecting to the data sources, building the ETL, building the data warehouse, building the reports.

You are implementing your security model, ensuring that end users have access and the correct level of access.  You are answering a lot of questions early on in the process, rather than at the end where traditionally “everything comes together”.  You are finding the problems early on.  If you need to re-think something then you can either tackle it now or make a plan, but you are in a much better place by knowing about the issues and risks.

No need to wait

You don’t need to wait to have all of the answers.  You don’t need to wait to have access to all of the data sources.  Just get started with the requirements that you do have.  It’s up to you whether you pick the highest value requirement or the simplest requirement, just get started.  Even if you only have one requirement that’s detailed enough to deliver against, get building.  De-risk the solution.  Get invaluable feedback.  Start delivering value straight away.  Not in six months or a year, but now.  Value every bit of feedback that you get, and use it to drive your future decisions and the future path of the solution.