In my blog Digitization - Who pays for it? Who earns? I already discussed the motivation and business cases of the various stakeholders for digitalization.

It became clear:

The asset manager has an intrinsic motivation to digitize its portfolio.

E.G.

ESG-based scoring for portfolio valuation is becoming increasingly relevant and may also have tax relevance in the future.
Continuous transparency of energy consumption values in the direction of the tenant is a requirement of the Energy Efficiency Directive of the EU has been partially mandatory since 2020.
Data on the 'health' of all systems in a building, the maintenance cases on these and predictions from 'preventive maintenance' help to minimize downtimes and recourse claims.

An approach that involves 'gluing' a few sensors together and storing their data in an IoT platform for dashboarding and alarm messages seems attractive, but falls short.

The asset manager needs a digital development plan for the necessary investments and the resulting system landscape and, above all, its direct and indirect monetization. The central component of such a system landscape is a building operating system such as Thing-it.

A very significant advantage of an approach via a building operating system: the investment immediately provides digital readiness of the building for possible tenant requirements and thus the immediate possibility of enabling tenants to use digitalization functions. Initially - in the standard case - via the app of the building operating system, which the asset manager can offer through its digitalization initiative and which provides tenants without their own infrastructure and app with functions such as

Workplace and room booking,
COVID-19 prevention via booking-based tracing or limiting aerosol density in e.g. meeting rooms via CO2 measurements,
Access control,
Management of looseners for flex desking or
Parking management and e-mobility.

is available.

But what if the tenant wants to access the building operating system with their own/another Workplace Experience app or other software systems?

We want to address this question in this blog.

What language is spoken? - 'It is a Brick House'

Any software that is integrated with a digitized building must understand what structure the building has and what elements, functions and data it provides.

This applies, for example, to

a tenant's own Workplace Experience app,
for connecting building data with the tenant's ERP systems, e.g. for billing charging station data or
for integration with the FM service provider's CAFM system to implement preventive maintenance functions.

To display this information, the brick scheme. The brick schema is a description of all elements and data of a building in a so-called graph structure, in which different objects are connected with relationships. It sounds very theoretical, but quickly becomes concrete when you look at how a building structure with floors and the location of floor counters are described here, for example:

The corresponding configuration and runtime data are the building's famous digital twin.

Software that communicates with the building now makes use of this information, as we will see in three examples.

Example 1: Meter data

While the tenant may want to visualize the meter data of the meters that affect him in an app or enter it into his ERP system, the asset manager wants to evaluate data for the elevator flow across all properties in the portfolio in order to compare costs by manufacturer, age and the like.

With the knowledge of the corresponding brick schema, both now access the runtime data for the counters described above, which are available, for example, in a time-ordered database - the famous data lake.

The data for meter G-5 therefore belongs to the data for the elevator current.

Example 2: Data from presence sensors

Even if a tenant has its own Workplace Experience app with functions for booking meeting rooms across all its locations, room usage can be optimized here by automatically 'checking in' for a booking via presence and if this 'check-in' does not take place, the room is quickly released again for further use.

In this case, the tenant may not want to constantly query ('poll') a database made available to them. It is much easier if the asset manager's digitization platform, i.e. the building's operating system, publishes events to a so-called publish/subscribe queue to which the tenant can register in order to process these events further.

Example 3: Room operation

Of course, the above approaches can be used not only to query data, but also to call up services on the elements of the brick scheme. For example, a tenant's app can query lighting scenes for a room and then set them or adjust the setpoint for the temperature of this room.

This shows how the mechanisms interlock:

From the point of view of the building operating system, the option to set the temperature setpoint or adjust the lighting scene is basically available. However, the tenant app may decide that this operation is only possible if the user is in the room in question. And the tenant app may be able to determine this using its own mechanisms for determining the indoor location. Or the tenant app cannot determine the indoor location at all, but uses the positioning mechanisms of the building operating system and makes the aforementioned decision to enable the operating functions in the room itself. And so on.

What can we talk about? - Authorization

Even if the brick scheme represents the entire building, the asset manager naturally wants to restrict information and access via the roles of the respective users:

The tenant may view the data from its sub-meters and the presence sensors in the rented space. The tenant may also, for example, release the access control elements to the rented space. And they can do this for their own employees or for guests.
The FM service provider may collect data in the primary systems in order to detect malfunctions. The FM service provider may also give its own employees access to these systems for maintenance purposes.

In the brick scheme, it looks like this:

Not too much talk and not for nothing - throttling and billing

In order for the building operating system to function smoothly, access by the various systems and stakeholders must of course be limited. This is referred to as throttling or the allocation of quotas. These are particularly important to ward off hacker attacks from/via the third-party systems through so-called Distributed Denial of Service (DDOS) attacks.

In addition, the asset manager may want to be financially compensated for the added value that he provides via his building operating system and in which he has invested - and not via service charge invoices that are only suitable for this to a very limited extent, but rather depending on what the tenant and service provider wants to discuss with the building and the added value that arises from this.

The asset manager therefore needs a billing system for the services used for all users. And possibly with flexible pricing models, as the same service call or data access does not always have the same added value. This is also the task and functionality of the building operating system.

Conclusion

Digitizing your own real estate portfolio can pay off in several ways. But most of all through the use of a powerful digitalization platform. So: get it right now.

Do you want to talk to my building?

Get in Touch

Newsletter