Curating the data layer architecture the right appropriate way

The argument between Open Standards Data Architecture and Proprietary Ecosystems of Application and Hardware has been heating up recently, especially as we now have more options to choose and customize the facility’s technology stacks. 

Similarly this argument resembles the one we all witnessed, when Google came up with android to compete with the Apple ecosystem, and that turned out beneficial for both the competitors, and more importantly for the users, as it clearly laid aspects such as security, connectivity, exclusivity and functionality for everyone to choose as they want. 

Well, when it comes to commercial building space, the term ‘separate data layer’ has been at a central point of many discussions recently.

In a typical building, one has systems like BMS, BAS, Energy monitoring, and metering systems to collect energy and asset-related data. Then the integration layer where a set of hardware communicates and transfers the data from individual sources to a designated location. Further historian layer stores time series and metadata on the database. Then the individual 3rd party tools in the application layer fetch the read-only data from the historian layer, processes it (Edge/cloud), and provide insights in the dashboard. Users then make decisions whether to stop there or put in the control system for complete automation.    

Now there are some limitations when one chooses to go with the above stack. That is, the entire stack often comes with the vendor ecosystem, and if you are not getting the expected results from the application and choose to move on with another, one might lose all the data that has been tagged before and restart the cycle once again from the scratch.   

Addition of data layer

Addition of the data layer is a way to make the stack open and available for the data lake. That’s separating the historian layer from the application layer and maintaining the raw data tags in the data layer. This way one need not follow the vendor’s ecosystem for one application only but can prefer another set of applications as per their requirements evolve with the period of time.

How does this work?

Whenever data is stored in a historian layer, it comes with a common auto-tagging so that one will have the complete library of asset and location-specific datasets ready at all times (It need not be structured with a proprietary application). 

Later one can add applications to it that will fetch in required data from the data lake and provide the insights. If not satisfied with the insights or the capabilities then one can be moved to another application without disturbing the data set up.

Key Benefits of Having the Data Layer:

1- Reducing the dependencies on vendor ecosystem:

One can have the flexibility to look into the data whenever you want something that’s difficult with the vendor’s stack. You would not need to subscribe to another application or tool to access your data. 

2- Easy to switch:

Don’t find the insights useful anymore? Or have you Identified the loopholes in the application which the vendor is ignoring or are not able to fix? With the new stack, you can move on with the new application whenever you want without losing the data structure. 

3- One data model for all:

It creates a single source of truth by applying the one data model for all the applications promoting interoperability.

For a facility manager, one of the important tasks is to keep the asset and operational data accessible to the O&M team for retro or predictive analysis. And with the separation of the data layer he can share it with the team as well as use it for any 3rd party asset performance management application trials. 

Sounds perfect and easy right?
Well, that depends on some critical decisions and aspects you should consider before selecting. 

1- Increased Complexity:

As you are customizing your tech stack it will increase the data complexity as your dedicated IT team would need to get involved in commissioning or decommissioning of the third-party applications. Needless to say, it will also increase the time to get started with the new application.

2- 3rd party application’s use of data:

If the application is expecting a different set of metadata or tagged data then your standardization would not work. There are few applications available that can follow the standardized asset tagging. 

Well, every facility management team has different goals, capabilities, budget and technology roadmap to follow and as far as the tech stack is concerned, tenant’s expectation, contract terms and team’s vision to create an ideal facility plays an important role. All the insights shared in this article including the pro and cons of a separate data layer should be evaluated thoroughly with the team and then the decision should be taken. 

Introducing a separate data layer will improve the ability to experiment with various use cases and applications (such as analytics, which leveraged the existing data layer and sit on the top of the value chain) ultimately adding greater flexibility and scalability to the tech stack.