How to create a Data Strategy for your Workplace

Formulating a data strategy for your workplace will make your customers happy, potentially unlock revenue and help you get to your sustainability goals. This blog gives you useful information and tips on how to build and implement a successful data strategy that will help your organisation succeed.

Lets dive in!

---

If you’re a system integrator, you’ve probably been asked by customers about your data strategy (or alternatively, you’ve been pitching a data strategy to them).

You need to make data from multiple places available, not just for today’s use cases but for potential future use cases as well.

If you’re running a building or precinct, you’re probably looking to formulate this strategy as well.

What is a ‘data strategy’? What does that even mean?

If we un-peel all the layers, it’s just a fancy way of answering these questions:

1. What kind of data can you collect?
2. How do you collect this data?
3. Where do you store this data?
4. What insights can you get from this data?
5. Who is this data useful for?
6. How do you protect this data?

What kind of data can you collect?

This is really easy to answer. It’s basically whatever you have your BMS layer and IoT head-ends.

But, you can really get more clever with this and this is where you need to think about what you want to do and whether you will be allowed to do it.

What if you can get tenant or employee data also into the mix?

Are there useful insights you can generate from that? What kind of data can you get?

Sustainability and ESG are one of the key drivers around this. Travel data, commute data, leased assets, capital assets, there’s a long list of data that goes into ESG metrics and calculations.

Where can you get that data from? Can you tap into the single source of truth?

Or do you need someone to manually copy it out of an excel spreadsheet or an email attachment like some unfrozen caveman?

Are you allowed to hold that data? Do you have to deal with privacy policies when you collect it? Is anything PII?

Now you need to start getting into the nuts and bolts.

Collecting your points and IoT data is straightforward.

If you are doing it the simple way, find your Niagara box and your IoT web services, write some duct tape and wiring code and slap it onto a machine running some python web server that Claude or ChatGPT spat out for you in 10 minutes and call it a day.

This will either work flawlessly for years as long as no one touches it, or it will crumble to the ground before you even deploy. There’s no in-between.

If you’re going the IT services enterprise route, you can create a schematic and architecture with data flow diagrams, add an expensive Java middleware library and get consultants who still use phrases like ‘enterprise service bus’ to…. write some duct tape and wiring code – and slap it onto a middleware enterprise-broker-thing and you’re up and running in about 6 months. This will be expensive but you have someone to blame when it’s slow and stops working.

The middleground is a platform (cough iviva) that does the heavy lifting in a lightweight and composable way.

Whatever way you decide, you need to think about how and where you store this data.

Storage is cheap but access to it can get surprisingly expensive if you’re not careful.

You have a lot of choice here though. A traditional relational database, a no-sql database, a data warehouse or a data lake.

There are plenty of options here with different tradeoffs that need their own article to get into.

The other question is where do you store this data?

Where do you store this data?

Depending on where you are, ‘us-east-1’ may not be the default answer.

You need to think about where your customer is and whether the data is allowed to leave that country.

You need to see what data management services are offered by the cloud providers in that region.

(Unless you enjoy setting yourself on fire, you do not want to be doing your own database administration).

You need to think of your backup and data archival strategy.

They are not the same thing!

They solve very different problems.

Backups – ‘Someone accidentally deleted the entire database and I need to bring it back’

Archival – ‘This system is really slow – if we agree that I don’t need to see CO2 levels in the basement on Jan 3rd 1998, can we make it faster?’

Backups are to solve emergencies and problems.

Archives are to make the live system faster by removing old data from it.

Pick something sensible as your strategy and you can tweak it later.

A sensible strategy that customers are mostly ok with:

Backups: Take one backup of everything once a day and put it in S3

Archives: Take anything older than 2 years and move it somewhere else

Again – you really want to just decide what your backup and archiving strategy should be – your platform layer should be managing it for you.

What insights can you get from this data?

Your BMS already gives you nice trend graphs and AHU graphics that were fashionable during the Clinton administration.

Why do you need anything more than that?

There are the obvious reasons:

1. People who don’t know what a BMS is need to see this data
2. I need to show data that isn’t published as points
3. Customers need to see some custom analytics beyond what I can configure in N4.

Some less obvious ones:

1. Customers want to be able to access raw data so they can give processed versions of it to their own customers (energy data, other utility data, but also access control logs etc…)
2. It needs to be used for compliances and certifications like WELL or Ashrase or NABERS
3. Customers want to access this on the move on their mobile

The first one is big – this is a potential revenue generating stream from data that you already did the hard work to configure and record.

But wait, there’s more

Sustainability reporting is a really important thing that everyone cares about. And the core of that sustainability reporting is getting accurate data.

Really, the hard part of it is gathering all that data and having it in one place. So creating a strategy around getting this data into your system and delivering analytics on it is an easy and powerful win.

The good part is that the volume of data you have to collect is not high.

Sustainability reporting is not very granular and is usually done on a monthly basis at most.

So you don’t need to collect 5-second resolution energy consumption data for this purpose.

The bad part is that there’s more to ESG than just energy. There’s a lot of other bits of data you need to collect that you may not even know how to get right now. That’s ok – it’s good to have a strategy in place – even if the way you currently collect the data is manual.

Who is this data useful for?

Building owners and operators is the straightforward answer.

More valuable – the occupants who, you know, pay the building owner and occupy the building.

If you can give them data they wouldn’t normally have access to and wouldn’t normally be able to easily get, you’ll be relieving a massive pain point for them and ‘solving pain points’ is always a good business to be in.

How do I give them this data?

It’s not enough to just think about who should access this data but also what form should this data be delivered in?

The answer is ‘it depends’.

There’s a spectrum of sophistication your customers are on and you need to know where they sit and likely you need to cater to multiple points on the spectrum.

You can divide the data consumers into 4 categories:

Level 1 – I just need some see some da This is the most common. Just give them a monthly generated pdf or email summary of their access data or energy consumption. Better – give them a login to your portal and a dashboard so they can see this data in real-time. They will be happy to have this. Once you have them on your dashboard, you can give them more information and services easily.

Level 2 – I need to present this data to someone who signs my paycheck If your customer is a workplace manager or works for the property management team, they need to do weekly or monthly or quarterly reports to their senior management. This is, sadly, done most of the time by logging into your dashboard, taking screenshots, pasting it into a Keynote/PPTX and adding some text. You can do better – just create the slide deck for them and email it to them. They’ll thank you for this.

Level 3 – I need to analyze this data in some way and present it to someone who signs my paycheck Sometimes, the workplace manager needs to do their own analysis and they have the skill set to do it. They will ask you to provide all the raw and summarized data as csv or excel exports so they can dump it into Excel and create their own analysis and charts for creating presentations. This is someone you need to talk to. They will have specific ideas on what to do with the data and you should look at incorporating that into your data strategy. They’ll be happy if you do. They will still want the raw exports in case they want to do further analysis so you need to have raw data exports as part of your strategy.

Level 4 – I have a team of people who need to run automated analysis for our own purposes Sometimes this ‘team’ is only one person – but what they really want is some kind of programmatic API. They want this because they have the skillset to use it (and the skillset to even ask for it) and want to make sure they can get all the data they want whenever they want it. They may not even have any firm requirements around what to do with the data – they just know that they can use an API if they have one and so they will ask for it. The API can sometimes be a wrapper around a csv export but you can do better – give them a RESTful endpoint to make it easy, or a GraphQL endpoint if you want to confuse them.

How do you protect this data?

n general, you need to give your customers assurances that their data is safe in your hand.

They are really looking for two things:

1. Don’t embarrass me in front of my customers by selling the data or leaking it in some way
2. Don’t be a weak point in any audit done on our security and privacy controls

Those are actually two different problems with two different solutions!

For (1) you need to know what you’re doing in your implementation. Rely on software stacks that have enterprise-grade security, run on trusted cloud providers and generally take data privacy and security seriously. You need to make sure your own implementation doesn’t do anything silly with the data.

In general, this is another reason to keep your own implementation as thin as possible and rely on a platform to do the heavy lifting.

For (2) you need to make sure you have certifications or the vendors you rely on have certifications. Look for ISO27001 or SOC2 as a starting point. Those are for security.

There are no strong privacy certifications right now but ask them about GDPR compliance and any country-specific PDPA. Make sure you get something in writing.

Where does iviva fit in

iviva gives you a lot of these out of the box.

• Default connectors to pull data from different standard systems.
• A toolkit to pull data out of all the weird holes and non-standard systems that they sit in.
• Tools to publish the data to all users in the spectrum.
• Tools to deal with sustainability and ESG data.

In Conclusion

This should give you the main headings you need to come up with your data strategy.

tl;dr:

• Think of your customer’s customers
• Your data strategy should cover more than just BMS and IoT
• Include sustainability in your strategy.
• Don’t try to manage your own data stack.
• Use iviva