Learn about NexusCon!
I first met David Blanch through an introduction from Jon Clarke, Head of Smart Building Technology at Dexus in Australia.
Jon reached out after I published our roundup podcast on the Master Systems Integrator role and said I needed to hear Davidâs (and his firm Bitpool's) approach.
Since then, David has become a valued member of the Nexus Pro community and has shared brilliant insights (members only) with the community on what it takes to become an MSI.
This free interview unpacks those insights in hopes they can be helpful to the wider smart buildings industry. Here's an overview of what we covered below:
And more! David was extremely generous with his time and insights for this one. Please enjoy!
James: Can you start with some context and background on Bitpool?
David: Bitpoolâs startup is an interesting story. It was originally founded about 9 years ago, then purchased by VAE Group. At the time its purpose was to solve a very simple problem: simplified access to data from the Cloud. Bitpool was well ahead of its time, probably too far ahead as the market still saw cloud-based SaaS as a new technology. The upfront costs to connect data easily inhibited most customers from wanting to make the investment into using the platform. No business had really solved the âsimplified access to dataâ issue that existed back then.
As the CTO of VAE Group, I was responsible for leading the technology team and pivoting our BMS business into large scale MSI work. As a Tridium integrator, we were beginning our journey of deploying large scale converged systems.
As the market matured, we too needed to mature, and quickly, as we found ourselves needing more and more skill sets in the business. This was driven by our customers' needs and our desire to provide truly open systems. At this point we converged the two businesses and Bitpool would build all of the product needed to deliver the heavy integration work that was so quickly expanding. As the CTO for both VAE and Bitpool, it gave me a unique opportunity to actually build products that benefited both the end customers and the MSIs.
Bitpool brought in Software Developers, UI Designers, User Experience and cloud foundation expertise that when applied correctly would go on to solve big problems with access to data. We focused our product development cycles on solving a key fundamental problemâsimplified access to dataâbuilding out the tools and architectures needed by the MSI to meet the growing demand in the market. Coming from a software development background I could see the skill sets that the MSI would need around them to support the successful delivery of these large scale technology solutions, and Bitpool had just those skill sets.
For the past 6 years I was directly responsible for overseeing both businesses' transition to enable them to develop, build, and deploy some of Australia's largest and most technical converged systems. We focused on creating new ways of building and deploying technology within buildings to support the sheer scale of what we were doing in the compressed timeframes we would be given to do it.
In 2021 we spent the COVID-19 pandemic repositioning and relaunching Bitpool as a new independent business. VAE realized that the MSI market was limited and for it to be sustainable there would need to be businesses like Bitpool that could help customers and companies transition into this space.
Bitpool has embarked on a brand new journey, with a new found purpose: taking the knowledge, technologies, and expertise that we had created over the past 6 years and offering that to companies and customers transitioning into this integrated world.
In summary: Weâre a technology company that understands buildings, not a buildings company that understands technology. Our purpose is to create more Master Systems Integrators.
Today, Bitpool provides a range of products, expertise, and solutions from Edge to Cloud, specifically designed for integrating separate Building technologies and delivering converged platforms. We have an extensive partner network with Dell, AWS, Tridium and the Open Source communities that we build with.
James: Weâve been chatting since I released our podcast summarizing the role of the MSI. MSIs seem to be having a moment right now. As you say, people seem to think itâs the silver bullet for enabling smart buildings. Why do you think that is?
David: I believe MSI is a proxy for the real issues we're all experiencing. The momentum we are actually seeing is that end users and clients want to innovate and push the boundaries with new technologies and ways of doing things.
Over the past 2 years I have witnessed an exponential increase in scale, volume, and complexity when it comes to converged systems along with the technologies that are connected and integrated to these platforms. I believe the reason MSIs are having a moment right now is customers believe they are the only ones that can do this type of work⌠and in some respects they may be right.
The real issue we have is that the technical skill sets available in the industry canât meet the growing demand, and in effect neither our industry or the MSI role is sustainable long term.
If we can't open up the building technologies landscape to new markets and skill sets, I feel that progression will simply stall as the current industry won't be able to meet the demand. We need to do this whilst we continue to transition our traditional skills that are invaluable to our progression.
James: I was surprised to learn that you, as an expert in systems integration, see MSIs as a symptom, not a final solution. Can you explain that?
David: I feel like the MSI role has been created as the âflex tapeâ for connecting building tech in the industry. Itâs easier to create a new role than to actually solve the real problems that exist in the industry today.
The real issue, if I were to summarize it, is the industry is absolutely confused with how to move into the modern digital world and has failed somewhat to go through its own digital transformation.
We have failed to grow with our customerâs needs as we often just focus on the tech, trying to put scopes of work in specific silos.
We ignore new ways of doing business. Building owners and developers want to do business with modern companies who bring new ways of deploying and applying technology. They want to get the best technology outcome for them, not just something out of the box.
The fact is that anyone who wants to be an MSI can be, there is no school you go to to learn how to be an MSI. MSIs are just individuals and businesses who remained agile with technology and adopted an open mindset to applying it.
The MSI is a symptom of having too many Product Providers and not enough Solution Providers.
James: So what do you think is the final solution that would negate the need for an MSI?
David: First, I believe the majority of the industry works with a zero sum mindset, i.e winning projects or solutions by virtue of someone else losing. Product X is better than product Y hence product Y loses. This then drives the fundamental human nature to retain information or technologies to continue winning and remain competitive in a cost plus market.
We need to work towards how the industry solves problems togetherâhow do we open systems and access to tooling so it draws in people and innovation?
The intrinsic nature of open source builds communities of people and businesses around the technology frameworks and code base, to which those communities go away and innovate and create business models of their own, offering their own unique value propositions.
We can't be naive to the fact that if companies don't make money then they don't exist. I simply propose that with open frameworks and communities, this accelerates innovation and demand, to which individual profits can be generated, but only generated by the value they provide. Not by virtue of locking customers into their technology stack.
When we talk about tooling and people, our industry is pretty much closed off from the rest of the modern tech world, or at least there are alot of barriers to entry. This has a magnitude of impacts but mostly it negatively affects people.
How this impacts people is by limiting either their ability to participate or to apply new technologies and innovate. We also isolate the building technologies industry by limiting the abundant amount of skill sets that exist outside it. This has the adverse effect of slowing down progression in our industry.
The best example is Github. Github has over 200 million code repositories with over 73 million software developers, varying through all different domains and skill sets. If anyone has an idea they can lean on a community of people, knowledge and code to create that idea, the barrier to entry is zero.
Imagine if this was the case with buildings. Imagine if the technology we used in buildings was built on these frameworks, we would instantly have access and be able to attract new talents into the industry to help solve some of our most complex problems.
The challenge that is in front of us is: how do we attract the next generation of talent into our industry, whilst also upskilling and transitioning our existing talent? We do this by enabling a market of free floating ideas and the complete democratization of access to technology and data.
James: How are todayâs tools holding us back?
David: When it comes to building technologies itâs no secret: Iâm a massive advocate for open source, modern software development frameworks and platforms. I'm also a massive advocate for the open source movement, more so for the community based approach to solving problems. I feel that this approach has seen the greatest result in the modern software devolvement world. It has really changed the whole paradigm by literally allowing anyone to learn how to code or deploy technology.
The industry as a whole has really grappled with transitioning to nonproprietary and modern technologies. In the past 5 years especially, the industry has really had their hand forced to adopt new modern technology frameworks, commonly at the protocol layer and data warehousing layer. This has come about with the end userâs insatiable appetite for innovative technologies from the edge to the cloud.
Most of the large OEMs build out-of-the-box products that solve perceived problems, very few have extensive open frameworks that allow people to develop applications and solutions on top of their direct technology stack, so this results in a lack of community and tribes for each walled garden, i.e you have your Tridium guru or your Honeywell guru, etc.
To get into these products it is usually accompanied with dealer fees, regional or geographical limitations, and extensive product training just to begin to use the product. This absolutely hinders collaborative innovation whilst also limiting access to building technologies for skills sets outside the buildings industry.
Typically the common tools that are used have evolved from the Building Automation space. Â Whilst great tools in their own right, these tools have not been adapted to large scale data storage or open access to data.
Integration Platforms (converged data warehouses) today can be responsible for storing and transiting hundreds of thousands of data points. Typically we see anywhere from 600,000 to 1,000,000+ data points in the integration space on premise. Traditional Building Automation technologies simply don't scale to these levels nor operate on widely available platforms.
If we look at Big Tech, there are numerous open source technologies that solve these problems and are more conducive to open access to data for any industry rather than just Buildings. We need to understand and provide more lateral access to the right tools, understanding that these systems aren't Building Automation systems and are actually Data Warehouses.
James: Follow up question on the MSI being tech agnostic: why not pick the best Independent Data Layer platform and standardize on that?
David: This is a great question, I would draw a contrast to Linux, MAC OS, and Windows, all great operating systems. There is a natural friction between operating systems that drives innovation and we don't want to lose that.
LINUX is one of the most popular operating systems amongst developers. It has an open source core to which variants / distributions are created with specific value propositions. Innovation continues to accelerate because of the ability to build off the core with new distributions coming to life creating value for the users.
This doesn't exclude MAC OS or Microsoft Windowsâthese operating systems too have user bases that love the system. This is a really important point: you could consider Microsoft to be a proprietary system; however there is a dedicated user base that loves to use it. It comes down to flexibility of choice, the more choice we have the more natural friction occurs that creates innovation.
If we look at most modern software applications that are being built today outside of our industry, the majority of companies are offering cross platform compatibility. This has taken off in the online gaming industry allowing people to simultaneously play the same game online across different hardware platforms.
I believe in the ideal world we would have both open source and closed source platforms existing together allowing users to choose what the best technology is to apply and what the best pathway is for the end customer based on their specific problems they are trying to solve both now and into the future.
Separating yourself from specific products, features, or brands and being truly agnostic is extremely liberating for solving problems. It empowers people to find the best solution for the problem.
This then allows Solution Providers to simply use the best of breed technology for the problem in front of them, and not having to make sacrifices like using product (a) that only solves 80% of the problem because they don't have access to product (b).
James: What open source efforts should the Nexus community know about?
David: It's important to note the numerous efforts that are out there, the most important thing is the ideology itself. See the following extract from opensource.com:
Community. Open source software often inspires a community of users and developers to form around it. That's not unique to open source; many popular applications are the subject of meetups and user groups. But in the case of open source, the community isn't just a fanbase that buys in (emotionally or financially) to an elite user group; it's the people who produce, test, use, promote, and ultimately affect the software they love.
Control. Many people prefer open source software because they have more control over that kind of software. They can examine the code to make sure it's not doing anything they don't want it to do, and they can change parts of it they don't like. Users who aren't programmers also benefit from open source software, because they can use this software for any purpose they wishânot merely the way someone else thinks they should.
Training. Other people like open source software because it helps them become better programmers. Because open source code is publicly accessible, students can easily study it as they learn to make better software. Students can also share their work with others, inviting comment and critique, as they develop their skills. When people discover mistakes in programs' source code, they can share those mistakes with others to help them avoid making those same mistakes themselves.
Even if there is hesitance to adopt the technologies, there is a lot we can learn from this ideology.
We focus on the following to note a few, of late we have been extremely focused on building our product on top of Node Red as we look to bridge the gap between BAS/BMS and âMSIâ, focusing on tools that will enable people to transition.
Letâs walk through the stack:
James: Fascinating. That list should really help people swallow that red pill! This makes so much sense, but I canât help but think about all the procurement barriers. How will technology procurement need to change to enable this future?
David: One of the fundamental issues when innovating in buildings is actually not technology. Yeah I know, right?! đ
The fundamental challenge that is often faced is the commercial contracts to which technology is procured. These contracts have not changed in decades and they are typically designed on area-based rate structures that were originally intended for procuring concrete, walls or physical systems. Typically, principals will send out requests for pricing based on per point, per device or lump sums of work, which leaves no room for context resulting in a lot of gray areas in relation to pricing.
The building owner engages a principal contractor who then engages a provider. So if you picture the client saying to the principal contractor âwe want this building to be smartest building in the worldâ and then the principle contractor saying âok we need 1 x smart building, so we need to put this out to open market and want the most competitive price that existsâ, the process of tendering and securing pricing can often occur with very little involvement from the MSI to the actual end client, rather dealt through proxies like the consultants and contractors.
We have managed to solve this problem by negotiating directly with the customer and getting novated to the builder however this is still very uncommon.As your podcast with Jon highlighted, there has been very little innovation with how these complex projects are procured or delivered. The process of procurement all the way through to the operational phase of the property is often forgotten, leaving the end customer receiving a product that may not align with their original vision or strategy.
We need to procure technology differently in buildings, in a way where the end client can interact and deal directly with the providers to ensure their end vision can be achieved and that the providers actually understand what the vision is. We need the ability for more transparency in pricing so solutions or products donât just get dismissed because they are 20% higher than a rule of thumb that the principle or consultants have.
James: Can you explain how the MSI delivery model differs from traditional BAS/BMS procurement?
David: The delivery model is what really differentiates a so-called MSI. Some âMSIâs will fundamentally believe it's all about the technology and just delivering their specific solution. However, we treat this differently. Our approach is to ensure the customers end goal is met by bringing all the providers together.
The MSI is really a support service helping other subsystems providers navigate the technology landscape and supporting them to enable them to connect to the converged network.
Also, the MSI when procured well will have technical oversight and involvement with the subsystem provider selections, taking a role of peer review over the proposed technology solutions for the project. Essentially, the MSI ensures that the technology is conducive to the customers vision and strategy. We do this as often specifications are done in silos for the subsystems, which can create confusion or gray area based on how they are perceived by the people trying to interpret them.
The MSI also acts in an independent nature with pricing analysis so the best value and outcome for the customer is achieved rather than the lowest or most âeconomicalâ price to meet specification.
On projects we are engaged on, we create individual âstart-up packsâ and âstart-up workshopsâ for each subsystem provider. This ensures a smooth onboarding for the subsystem providers where we literally extract all of the technology requirements from their specification and walk them through how that plays a role in the wider technology vision and how that ties in with the central platform.
James: As Iâve written about, the tech tools and the people are intertwined. What are the ways we need to change our approach to building the workforce for smart buildings to scale?
David: Not to throw another analogy out there but we use the Digital Sherpa analogy. Why? Well we fundamentally believe that as the Sherpa, our role is to share experience and act as a support service to enable others to reach the summit. Whilst in most cases we are leading the group, we are only leading them to ensure they achieve their goals, not ours.
The success of the MSI is a proxy to how well they share experience and guide the group. This is a key mindset we look for in new people looking to join our business as this is the mindset we offer our customers.
I will be straight up: I hate the traditional corporate hiring style, it's like:
âWe are looking for a System Integrator to change the world and you must have 10 years experience in x,y,z BMS systems, network infrastructure deployment experience, cyber security, a mechanical engineering degree and experience in financial project management then [insert here whatever other corporate spew you would like here]â.
Everyone then waits for the resumes to roll in and discounts anyone who doesn't have those unicorn credentials.
If they make it to an interview the interviewer is typically asking pre-scripted questions from HR that really anyone can tell a good story about. After all of the above the âhiring managersâ gather around and say âman thereâs literally no one out there!â
When hiring, people want to have real conversations with companies who are passionate about what they are passionate about. If those passions align then it's good for both the company and the employee.
We seldom look at credentials. To be honest I very rarely look deeply at resumesâI tend to initially call and have a conversation. We look for people who have skills, are passionate, and  who are willing to learn and solve problems with technology.
Great companies will have the ability to impart knowledge on any willing person. What we should be focused on is how we create UNICORNS not how to find them.
James: I totally agree. As you say, this is really how anyone applying technology within buildings should operate. Whatâs holding everyone back from operating that way?
David: At the core itâs two key elements: the commercial culture of the industry and the traditional OEMs not having the tooling or the speed to market with development cycles.
I believe it's similar to what Morpheus said in the Matrix, âUnfortunately no one can be told what the Matrix is, you have to see it for yourself.â
We have become addicted to doing things the way they have always been done. Why? Because that's how we have always done things, so we simply just try to re-invent ways of doing the same things slightly differently. Like the MSI.
This problem has largely been exacerbated by the commercial terms that are imposed on providers delivering these solutions. The risks are real for MSIs having to innovate in such short time frames.
This has contributed in creating a culture that simply forces most providers and technologists to take limited risks with technology, curbing everyone's and our industries ability to innovate quickly. This also has the adverse effect of people not being able to innovate in the ways they do things or how they apply technology.
We all then simply stay jacked in, waiting for the OEMs to release their latest box, software or platform that solves problems in a predefined way with predefined rules, that poses the least possible risk to the company when solving customers problems.
But what if all the LinkedIn posts from the OEMs are wrong? What if they don't understand the problems of tomorrow ?
It was about 5 years ago that I was really red-pilled. At the time, a common solution would consist of 250,000 points across 12 services. We were in a similar cycle to the above, this was the time we began to see the exponential growth in what customers wanted and needed from these converged systems to not only meet their own technology goals but that of their tenants.
At the time we began to see client solutions scaling up to 1 million data points across 40 services and wanting integration to tools that were common to them, platforms like Azure, Google Cloud Platform, even Sharepoint and Microsoft Teams.
We quickly realized that the tools did not exist in traditional building technologies that would support these large scale converged systems and this would be a massive limiting factor for us to scale.
We re-architected our core solution and took a hybrid approach, taking what was great in traditional building tech (for us that was Tridium and Haystack) and converging that with open source, modern technologies such as NGINX, VerneMQ, Apache Kafka and Docker to name just a few. This enabled us to scale on prem seamlessly and allowed us to work with any customers at any scale to provide access to data.
Applying open source technologies and embracing the ideology allowed us to not be limited by the slow development cycles of the traditional providers. Instead leveraging the development cycles of millions in the community. It gave us access to incredible technology that was being developed at an incredible pace.
Our inability to let go of the past and the traditional ways of applying technology will only inhibit the next generation of technologists, not accelerate it. Those who today come from a world with no limitations with access to software. A world where the best ideas win, not the ability for you to access a particular technology.
Time to fly!
James: What are your thoughts on the future of the MSI role?
David: The future is bright for MSIâs, but maybe not for the reasons everyone will expect. The MSI role has the opportunity to show the industry what our future workforce of technologists will need to look like.
What it shows today is that end users and customers are looking for real technologists who want to solve their problems and don't just focus on the raw technology itselfâthey focus on how ideas are brought to life and how technology can be deployed to enable a community of ideas.
The MSI is the pathway for the industry to go back to being Solution Provider focused first rather than second, and not just Product Providers. This in turn will force OEMs to focus on how they build and interact with more robust tools rather than boxed products that only allow innovation to occur around their subset of features.
We are now entering a time where people are scarce, customers are wanting to push the boundaries and it's really the perfect storm. We need to be focused on attracting new talent whilst also upskilling our existing talent.
I believe in the future, the MSI role will be remembered as the catalyst that sparked the change that was needed to transform and open our industry.
â
James: Thanks so much David, this has been super insightful and inspiring!
Will you stick around for a few more questions from our Pro members?
David: Sure!
James: Given your enthusiasm for open source, why do you still use Tridium?
David: Firstly, contrary to the above it may seem like we don't like proprietary software. That is not the case. What we advocate for is open access to data and tools at the integration layer, the application layer can be a different case however we do look to ensure the application has OPEN APIs and as many open methods as possible to be able to bring data in and out.
Anyone should be able to freely access data from devices and converged systems in buildings, this in turn speeds up innovation and development at the application layer⌠if anyone can access data and then create applications which create value from the data, that's great news for everyone. This results in end customers and users having ultimate control of choice as to what application best solves their problems.
I would be lying if I said I wasn't a big fan of Tridium, however I'm a bigger fan of what open source has to offer and how it can change our industry. What Tridium did for the industry I believe was very disruptive at the time. The original founders clearly saw the problem we still face today and built a product that has stood the test of time. I still believe today it has one of the most extensible frameworks that exist in the building's space. They strike at the heart of my commentary and remain open minded to how technology solves problems for customers.
With this being said, we still need to be clear on what it is. It's extremely important to be transparent and clear on the facts.
We often get, âwe want Tridium because it's open source, anyone can work on itâ. This statement is flawed and not fact. This doesn't mean it's not a great product, it's simply the client needs to be informed about what they are purchasing and how it's applied.
Tridium is a proprietary product and has predetermined rules set out by the company. The rules I speak of are not technology related, they are commercial. To have access to the Tridium product line you need to meet the following requirements:
Now, there is absolutely nothing wrong with this. This is a very traditional dealer model that's been around for years. But this is not open source. And is this model conducive to enabling the next young entrepreneur?
So why do we use Tridium? Simply put, we find it to be a great solution for the right clients, when applied in the right way for the right outcome. It has a framework that can be developed upon to solve problems that we face, as I mentioned above it did pose limitation problems scaling, as most building centric technologies do.
Today we typically apply Tridium at the application level in a hybrid configuration with the other open technologies we deploy. We offer multiple options at the integration and data warehousing layer dependent on the solution.
Recently we delivered a project that would see multiple buildings converged into a portfolio layer platform, the customer already had a well established development team very familiar with the technologies shown in the above stack.
It made no sense for us to introduce Tridium into their technology ecosystem, both technically or commercially. We delivered an integrated solution using pure open source tech that was really familiar to them, that they could support moving forward and that enabled them to bring in the skills set that suited their business.
We feel that presenting the raw facts and aligning the technology with our customers' goals nets the best result.
James: Can you talk more about how you use Node Red? What should other members know about it? Â
David: So firstly checkout Node Red here: https://nodered.org/
Bitpool builds its Bitpool Edge product off NodeRed, we have found this to be an invaluable piece of the puzzle when solving integration challenges in buildings and allowing skills sets from all walks of life to participate.
NodeRed is completely open source and both a low code platform and development framework. This means that it supports both entry level integrators all the way through to software developers looking to extend on the framework by building connectors or front end elements.
NodeRed already has in excess of 3600 open source community driven connectors and modules. It can be run on just about any environment, single hardware device, server, cloud and even clustered environments.
NodeRed is hardware agnostic meaning, people have the flexibility of choice when deciding what hardware platform to run on. This has allowed us to remain extremely agile over the past 12 months as supply chain issues from traditional vendors have been impacted.
We choose to run NodeRed on Moxa UC8200 or Dell Edge Gateways. Currently we are in the process of testing on Distechs new APEX controller.
Commonly used buildings protocols that are available today are as follows:
Currently there is one contributor in the community working on BACnet, we are in the process of building out a suitable BACnet connector built off an open source BACnet JS library that we will be open sourcing along with a heap of other connectors we have been building.
Database integration to name a few
Common Stuff
Common Cloud Connectors
Here's just a few companies already building on it
James: Thanks again!
Members can find David on Nexus Connect.
James: Thanks so much David, this has been super insightful and inspiring!
Will you stick around for a few more questions from our Pro members?
David: Sure!
James: Given your enthusiasm for open source, why do you still use Tridium?
David: Firstly, contrary to the above it may seem like we don't like proprietary software. That is not the case. What we advocate for is open access to data and tools at the integration layer, the application layer can be a different case however we do look to ensure the application has OPEN APIs and as many open methods as possible to be able to bring data in and out.
Anyone should be able to freely access data from devices and converged systems in buildings, this in turn speeds up innovation and development at the application layer⌠if anyone can access data and then create applications which create value from the data, that's great news for everyone. This results in end customers and users having ultimate control of choice as to what application best solves their problems.
I would be lying if I said I wasn't a big fan of Tridium, however I'm a bigger fan of what open source has to offer and how it can change our industry. What Tridium did for the industry I believe was very disruptive at the time. The original founders clearly saw the problem we still face today and built a product that has stood the test of time. I still believe today it has one of the most extensible frameworks that exist in the building's space. They strike at the heart of my commentary and remain open minded to how technology solves problems for customers.
With this being said, we still need to be clear on what it is. It's extremely important to be transparent and clear on the facts.
We often get, âwe want Tridium because it's open source, anyone can work on itâ. This statement is flawed and not fact. This doesn't mean it's not a great product, it's simply the client needs to be informed about what they are purchasing and how it's applied.
Tridium is a proprietary product and has predetermined rules set out by the company. The rules I speak of are not technology related, they are commercial. To have access to the Tridium product line you need to meet the following requirements:
Now, there is absolutely nothing wrong with this. This is a very traditional dealer model that's been around for years. But this is not open source. And is this model conducive to enabling the next young entrepreneur?
So why do we use Tridium? Simply put, we find it to be a great solution for the right clients, when applied in the right way for the right outcome. It has a framework that can be developed upon to solve problems that we face, as I mentioned above it did pose limitation problems scaling, as most building centric technologies do.
Today we typically apply Tridium at the application level in a hybrid configuration with the other open technologies we deploy. We offer multiple options at the integration and data warehousing layer dependent on the solution.
Recently we delivered a project that would see multiple buildings converged into a portfolio layer platform, the customer already had a well established development team very familiar with the technologies shown in the above stack.
It made no sense for us to introduce Tridium into their technology ecosystem, both technically or commercially. We delivered an integrated solution using pure open source tech that was really familiar to them, that they could support moving forward and that enabled them to bring in the skills set that suited their business.
We feel that presenting the raw facts and aligning the technology with our customers' goals nets the best result.
James: Can you talk more about how you use Node Red? What should other members know about it? Â
David: So firstly checkout Node Red here: https://nodered.org/
Bitpool builds its Bitpool Edge product off NodeRed, we have found this to be an invaluable piece of the puzzle when solving integration challenges in buildings and allowing skills sets from all walks of life to participate.
NodeRed is completely open source and both a low code platform and development framework. This means that it supports both entry level integrators all the way through to software developers looking to extend on the framework by building connectors or front end elements.
NodeRed already has in excess of 3600 open source community driven connectors and modules. It can be run on just about any environment, single hardware device, server, cloud and even clustered environments.
NodeRed is hardware agnostic meaning, people have the flexibility of choice when deciding what hardware platform to run on. This has allowed us to remain extremely agile over the past 12 months as supply chain issues from traditional vendors have been impacted.
We choose to run NodeRed on Moxa UC8200 or Dell Edge Gateways. Currently we are in the process of testing on Distechs new APEX controller.
Commonly used buildings protocols that are available today are as follows:
Currently there is one contributor in the community working on BACnet, we are in the process of building out a suitable BACnet connector built off an open source BACnet JS library that we will be open sourcing along with a heap of other connectors we have been building.
Database integration to name a few
Common Stuff
Common Cloud Connectors
Here's just a few companies already building on it
James: Thanks again!
Members can find David on Nexus Connect.
James: Thanks so much David, this has been super insightful and inspiring!
Will you stick around for a few more questions from our Pro members?
David: Sure!
James: Given your enthusiasm for open source, why do you still use Tridium?
David: Firstly, contrary to the above it may seem like we don't like proprietary software. That is not the case. What we advocate for is open access to data and tools at the integration layer, the application layer can be a different case however we do look to ensure the application has OPEN APIs and as many open methods as possible to be able to bring data in and out.
Anyone should be able to freely access data from devices and converged systems in buildings, this in turn speeds up innovation and development at the application layer⌠if anyone can access data and then create applications which create value from the data, that's great news for everyone. This results in end customers and users having ultimate control of choice as to what application best solves their problems.
I would be lying if I said I wasn't a big fan of Tridium, however I'm a bigger fan of what open source has to offer and how it can change our industry. What Tridium did for the industry I believe was very disruptive at the time. The original founders clearly saw the problem we still face today and built a product that has stood the test of time. I still believe today it has one of the most extensible frameworks that exist in the building's space. They strike at the heart of my commentary and remain open minded to how technology solves problems for customers.
With this being said, we still need to be clear on what it is. It's extremely important to be transparent and clear on the facts.
We often get, âwe want Tridium because it's open source, anyone can work on itâ. This statement is flawed and not fact. This doesn't mean it's not a great product, it's simply the client needs to be informed about what they are purchasing and how it's applied.
Tridium is a proprietary product and has predetermined rules set out by the company. The rules I speak of are not technology related, they are commercial. To have access to the Tridium product line you need to meet the following requirements:
Now, there is absolutely nothing wrong with this. This is a very traditional dealer model that's been around for years. But this is not open source. And is this model conducive to enabling the next young entrepreneur?
So why do we use Tridium? Simply put, we find it to be a great solution for the right clients, when applied in the right way for the right outcome. It has a framework that can be developed upon to solve problems that we face, as I mentioned above it did pose limitation problems scaling, as most building centric technologies do.
Today we typically apply Tridium at the application level in a hybrid configuration with the other open technologies we deploy. We offer multiple options at the integration and data warehousing layer dependent on the solution.
Recently we delivered a project that would see multiple buildings converged into a portfolio layer platform, the customer already had a well established development team very familiar with the technologies shown in the above stack.
It made no sense for us to introduce Tridium into their technology ecosystem, both technically or commercially. We delivered an integrated solution using pure open source tech that was really familiar to them, that they could support moving forward and that enabled them to bring in the skills set that suited their business.
We feel that presenting the raw facts and aligning the technology with our customers' goals nets the best result.
James: Can you talk more about how you use Node Red? What should other members know about it? Â
David: So firstly checkout Node Red here: https://nodered.org/
Bitpool builds its Bitpool Edge product off NodeRed, we have found this to be an invaluable piece of the puzzle when solving integration challenges in buildings and allowing skills sets from all walks of life to participate.
NodeRed is completely open source and both a low code platform and development framework. This means that it supports both entry level integrators all the way through to software developers looking to extend on the framework by building connectors or front end elements.
NodeRed already has in excess of 3600 open source community driven connectors and modules. It can be run on just about any environment, single hardware device, server, cloud and even clustered environments.
NodeRed is hardware agnostic meaning, people have the flexibility of choice when deciding what hardware platform to run on. This has allowed us to remain extremely agile over the past 12 months as supply chain issues from traditional vendors have been impacted.
We choose to run NodeRed on Moxa UC8200 or Dell Edge Gateways. Currently we are in the process of testing on Distechs new APEX controller.
Commonly used buildings protocols that are available today are as follows:
Currently there is one contributor in the community working on BACnet, we are in the process of building out a suitable BACnet connector built off an open source BACnet JS library that we will be open sourcing along with a heap of other connectors we have been building.
Database integration to name a few
Common Stuff
Common Cloud Connectors
Here's just a few companies already building on it
James: Thanks again!
Members can find David on Nexus Connect.
I first met David Blanch through an introduction from Jon Clarke, Head of Smart Building Technology at Dexus in Australia.
Jon reached out after I published our roundup podcast on the Master Systems Integrator role and said I needed to hear Davidâs (and his firm Bitpool's) approach.
Since then, David has become a valued member of the Nexus Pro community and has shared brilliant insights (members only) with the community on what it takes to become an MSI.
This free interview unpacks those insights in hopes they can be helpful to the wider smart buildings industry. Here's an overview of what we covered below:
And more! David was extremely generous with his time and insights for this one. Please enjoy!
James: Can you start with some context and background on Bitpool?
David: Bitpoolâs startup is an interesting story. It was originally founded about 9 years ago, then purchased by VAE Group. At the time its purpose was to solve a very simple problem: simplified access to data from the Cloud. Bitpool was well ahead of its time, probably too far ahead as the market still saw cloud-based SaaS as a new technology. The upfront costs to connect data easily inhibited most customers from wanting to make the investment into using the platform. No business had really solved the âsimplified access to dataâ issue that existed back then.
As the CTO of VAE Group, I was responsible for leading the technology team and pivoting our BMS business into large scale MSI work. As a Tridium integrator, we were beginning our journey of deploying large scale converged systems.
As the market matured, we too needed to mature, and quickly, as we found ourselves needing more and more skill sets in the business. This was driven by our customers' needs and our desire to provide truly open systems. At this point we converged the two businesses and Bitpool would build all of the product needed to deliver the heavy integration work that was so quickly expanding. As the CTO for both VAE and Bitpool, it gave me a unique opportunity to actually build products that benefited both the end customers and the MSIs.
Bitpool brought in Software Developers, UI Designers, User Experience and cloud foundation expertise that when applied correctly would go on to solve big problems with access to data. We focused our product development cycles on solving a key fundamental problemâsimplified access to dataâbuilding out the tools and architectures needed by the MSI to meet the growing demand in the market. Coming from a software development background I could see the skill sets that the MSI would need around them to support the successful delivery of these large scale technology solutions, and Bitpool had just those skill sets.
For the past 6 years I was directly responsible for overseeing both businesses' transition to enable them to develop, build, and deploy some of Australia's largest and most technical converged systems. We focused on creating new ways of building and deploying technology within buildings to support the sheer scale of what we were doing in the compressed timeframes we would be given to do it.
In 2021 we spent the COVID-19 pandemic repositioning and relaunching Bitpool as a new independent business. VAE realized that the MSI market was limited and for it to be sustainable there would need to be businesses like Bitpool that could help customers and companies transition into this space.
Bitpool has embarked on a brand new journey, with a new found purpose: taking the knowledge, technologies, and expertise that we had created over the past 6 years and offering that to companies and customers transitioning into this integrated world.
In summary: Weâre a technology company that understands buildings, not a buildings company that understands technology. Our purpose is to create more Master Systems Integrators.
Today, Bitpool provides a range of products, expertise, and solutions from Edge to Cloud, specifically designed for integrating separate Building technologies and delivering converged platforms. We have an extensive partner network with Dell, AWS, Tridium and the Open Source communities that we build with.
James: Weâve been chatting since I released our podcast summarizing the role of the MSI. MSIs seem to be having a moment right now. As you say, people seem to think itâs the silver bullet for enabling smart buildings. Why do you think that is?
David: I believe MSI is a proxy for the real issues we're all experiencing. The momentum we are actually seeing is that end users and clients want to innovate and push the boundaries with new technologies and ways of doing things.
Over the past 2 years I have witnessed an exponential increase in scale, volume, and complexity when it comes to converged systems along with the technologies that are connected and integrated to these platforms. I believe the reason MSIs are having a moment right now is customers believe they are the only ones that can do this type of work⌠and in some respects they may be right.
The real issue we have is that the technical skill sets available in the industry canât meet the growing demand, and in effect neither our industry or the MSI role is sustainable long term.
If we can't open up the building technologies landscape to new markets and skill sets, I feel that progression will simply stall as the current industry won't be able to meet the demand. We need to do this whilst we continue to transition our traditional skills that are invaluable to our progression.
James: I was surprised to learn that you, as an expert in systems integration, see MSIs as a symptom, not a final solution. Can you explain that?
David: I feel like the MSI role has been created as the âflex tapeâ for connecting building tech in the industry. Itâs easier to create a new role than to actually solve the real problems that exist in the industry today.
The real issue, if I were to summarize it, is the industry is absolutely confused with how to move into the modern digital world and has failed somewhat to go through its own digital transformation.
We have failed to grow with our customerâs needs as we often just focus on the tech, trying to put scopes of work in specific silos.
We ignore new ways of doing business. Building owners and developers want to do business with modern companies who bring new ways of deploying and applying technology. They want to get the best technology outcome for them, not just something out of the box.
The fact is that anyone who wants to be an MSI can be, there is no school you go to to learn how to be an MSI. MSIs are just individuals and businesses who remained agile with technology and adopted an open mindset to applying it.
The MSI is a symptom of having too many Product Providers and not enough Solution Providers.
James: So what do you think is the final solution that would negate the need for an MSI?
David: First, I believe the majority of the industry works with a zero sum mindset, i.e winning projects or solutions by virtue of someone else losing. Product X is better than product Y hence product Y loses. This then drives the fundamental human nature to retain information or technologies to continue winning and remain competitive in a cost plus market.
We need to work towards how the industry solves problems togetherâhow do we open systems and access to tooling so it draws in people and innovation?
The intrinsic nature of open source builds communities of people and businesses around the technology frameworks and code base, to which those communities go away and innovate and create business models of their own, offering their own unique value propositions.
We can't be naive to the fact that if companies don't make money then they don't exist. I simply propose that with open frameworks and communities, this accelerates innovation and demand, to which individual profits can be generated, but only generated by the value they provide. Not by virtue of locking customers into their technology stack.
When we talk about tooling and people, our industry is pretty much closed off from the rest of the modern tech world, or at least there are alot of barriers to entry. This has a magnitude of impacts but mostly it negatively affects people.
How this impacts people is by limiting either their ability to participate or to apply new technologies and innovate. We also isolate the building technologies industry by limiting the abundant amount of skill sets that exist outside it. This has the adverse effect of slowing down progression in our industry.
The best example is Github. Github has over 200 million code repositories with over 73 million software developers, varying through all different domains and skill sets. If anyone has an idea they can lean on a community of people, knowledge and code to create that idea, the barrier to entry is zero.
Imagine if this was the case with buildings. Imagine if the technology we used in buildings was built on these frameworks, we would instantly have access and be able to attract new talents into the industry to help solve some of our most complex problems.
The challenge that is in front of us is: how do we attract the next generation of talent into our industry, whilst also upskilling and transitioning our existing talent? We do this by enabling a market of free floating ideas and the complete democratization of access to technology and data.
James: How are todayâs tools holding us back?
David: When it comes to building technologies itâs no secret: Iâm a massive advocate for open source, modern software development frameworks and platforms. I'm also a massive advocate for the open source movement, more so for the community based approach to solving problems. I feel that this approach has seen the greatest result in the modern software devolvement world. It has really changed the whole paradigm by literally allowing anyone to learn how to code or deploy technology.
The industry as a whole has really grappled with transitioning to nonproprietary and modern technologies. In the past 5 years especially, the industry has really had their hand forced to adopt new modern technology frameworks, commonly at the protocol layer and data warehousing layer. This has come about with the end userâs insatiable appetite for innovative technologies from the edge to the cloud.
Most of the large OEMs build out-of-the-box products that solve perceived problems, very few have extensive open frameworks that allow people to develop applications and solutions on top of their direct technology stack, so this results in a lack of community and tribes for each walled garden, i.e you have your Tridium guru or your Honeywell guru, etc.
To get into these products it is usually accompanied with dealer fees, regional or geographical limitations, and extensive product training just to begin to use the product. This absolutely hinders collaborative innovation whilst also limiting access to building technologies for skills sets outside the buildings industry.
Typically the common tools that are used have evolved from the Building Automation space. Â Whilst great tools in their own right, these tools have not been adapted to large scale data storage or open access to data.
Integration Platforms (converged data warehouses) today can be responsible for storing and transiting hundreds of thousands of data points. Typically we see anywhere from 600,000 to 1,000,000+ data points in the integration space on premise. Traditional Building Automation technologies simply don't scale to these levels nor operate on widely available platforms.
If we look at Big Tech, there are numerous open source technologies that solve these problems and are more conducive to open access to data for any industry rather than just Buildings. We need to understand and provide more lateral access to the right tools, understanding that these systems aren't Building Automation systems and are actually Data Warehouses.
James: Follow up question on the MSI being tech agnostic: why not pick the best Independent Data Layer platform and standardize on that?
David: This is a great question, I would draw a contrast to Linux, MAC OS, and Windows, all great operating systems. There is a natural friction between operating systems that drives innovation and we don't want to lose that.
LINUX is one of the most popular operating systems amongst developers. It has an open source core to which variants / distributions are created with specific value propositions. Innovation continues to accelerate because of the ability to build off the core with new distributions coming to life creating value for the users.
This doesn't exclude MAC OS or Microsoft Windowsâthese operating systems too have user bases that love the system. This is a really important point: you could consider Microsoft to be a proprietary system; however there is a dedicated user base that loves to use it. It comes down to flexibility of choice, the more choice we have the more natural friction occurs that creates innovation.
If we look at most modern software applications that are being built today outside of our industry, the majority of companies are offering cross platform compatibility. This has taken off in the online gaming industry allowing people to simultaneously play the same game online across different hardware platforms.
I believe in the ideal world we would have both open source and closed source platforms existing together allowing users to choose what the best technology is to apply and what the best pathway is for the end customer based on their specific problems they are trying to solve both now and into the future.
Separating yourself from specific products, features, or brands and being truly agnostic is extremely liberating for solving problems. It empowers people to find the best solution for the problem.
This then allows Solution Providers to simply use the best of breed technology for the problem in front of them, and not having to make sacrifices like using product (a) that only solves 80% of the problem because they don't have access to product (b).
James: What open source efforts should the Nexus community know about?
David: It's important to note the numerous efforts that are out there, the most important thing is the ideology itself. See the following extract from opensource.com:
Community. Open source software often inspires a community of users and developers to form around it. That's not unique to open source; many popular applications are the subject of meetups and user groups. But in the case of open source, the community isn't just a fanbase that buys in (emotionally or financially) to an elite user group; it's the people who produce, test, use, promote, and ultimately affect the software they love.
Control. Many people prefer open source software because they have more control over that kind of software. They can examine the code to make sure it's not doing anything they don't want it to do, and they can change parts of it they don't like. Users who aren't programmers also benefit from open source software, because they can use this software for any purpose they wishânot merely the way someone else thinks they should.
Training. Other people like open source software because it helps them become better programmers. Because open source code is publicly accessible, students can easily study it as they learn to make better software. Students can also share their work with others, inviting comment and critique, as they develop their skills. When people discover mistakes in programs' source code, they can share those mistakes with others to help them avoid making those same mistakes themselves.
Even if there is hesitance to adopt the technologies, there is a lot we can learn from this ideology.
We focus on the following to note a few, of late we have been extremely focused on building our product on top of Node Red as we look to bridge the gap between BAS/BMS and âMSIâ, focusing on tools that will enable people to transition.
Letâs walk through the stack:
James: Fascinating. That list should really help people swallow that red pill! This makes so much sense, but I canât help but think about all the procurement barriers. How will technology procurement need to change to enable this future?
David: One of the fundamental issues when innovating in buildings is actually not technology. Yeah I know, right?! đ
The fundamental challenge that is often faced is the commercial contracts to which technology is procured. These contracts have not changed in decades and they are typically designed on area-based rate structures that were originally intended for procuring concrete, walls or physical systems. Typically, principals will send out requests for pricing based on per point, per device or lump sums of work, which leaves no room for context resulting in a lot of gray areas in relation to pricing.
The building owner engages a principal contractor who then engages a provider. So if you picture the client saying to the principal contractor âwe want this building to be smartest building in the worldâ and then the principle contractor saying âok we need 1 x smart building, so we need to put this out to open market and want the most competitive price that existsâ, the process of tendering and securing pricing can often occur with very little involvement from the MSI to the actual end client, rather dealt through proxies like the consultants and contractors.
We have managed to solve this problem by negotiating directly with the customer and getting novated to the builder however this is still very uncommon.As your podcast with Jon highlighted, there has been very little innovation with how these complex projects are procured or delivered. The process of procurement all the way through to the operational phase of the property is often forgotten, leaving the end customer receiving a product that may not align with their original vision or strategy.
We need to procure technology differently in buildings, in a way where the end client can interact and deal directly with the providers to ensure their end vision can be achieved and that the providers actually understand what the vision is. We need the ability for more transparency in pricing so solutions or products donât just get dismissed because they are 20% higher than a rule of thumb that the principle or consultants have.
James: Can you explain how the MSI delivery model differs from traditional BAS/BMS procurement?
David: The delivery model is what really differentiates a so-called MSI. Some âMSIâs will fundamentally believe it's all about the technology and just delivering their specific solution. However, we treat this differently. Our approach is to ensure the customers end goal is met by bringing all the providers together.
The MSI is really a support service helping other subsystems providers navigate the technology landscape and supporting them to enable them to connect to the converged network.
Also, the MSI when procured well will have technical oversight and involvement with the subsystem provider selections, taking a role of peer review over the proposed technology solutions for the project. Essentially, the MSI ensures that the technology is conducive to the customers vision and strategy. We do this as often specifications are done in silos for the subsystems, which can create confusion or gray area based on how they are perceived by the people trying to interpret them.
The MSI also acts in an independent nature with pricing analysis so the best value and outcome for the customer is achieved rather than the lowest or most âeconomicalâ price to meet specification.
On projects we are engaged on, we create individual âstart-up packsâ and âstart-up workshopsâ for each subsystem provider. This ensures a smooth onboarding for the subsystem providers where we literally extract all of the technology requirements from their specification and walk them through how that plays a role in the wider technology vision and how that ties in with the central platform.
James: As Iâve written about, the tech tools and the people are intertwined. What are the ways we need to change our approach to building the workforce for smart buildings to scale?
David: Not to throw another analogy out there but we use the Digital Sherpa analogy. Why? Well we fundamentally believe that as the Sherpa, our role is to share experience and act as a support service to enable others to reach the summit. Whilst in most cases we are leading the group, we are only leading them to ensure they achieve their goals, not ours.
The success of the MSI is a proxy to how well they share experience and guide the group. This is a key mindset we look for in new people looking to join our business as this is the mindset we offer our customers.
I will be straight up: I hate the traditional corporate hiring style, it's like:
âWe are looking for a System Integrator to change the world and you must have 10 years experience in x,y,z BMS systems, network infrastructure deployment experience, cyber security, a mechanical engineering degree and experience in financial project management then [insert here whatever other corporate spew you would like here]â.
Everyone then waits for the resumes to roll in and discounts anyone who doesn't have those unicorn credentials.
If they make it to an interview the interviewer is typically asking pre-scripted questions from HR that really anyone can tell a good story about. After all of the above the âhiring managersâ gather around and say âman thereâs literally no one out there!â
When hiring, people want to have real conversations with companies who are passionate about what they are passionate about. If those passions align then it's good for both the company and the employee.
We seldom look at credentials. To be honest I very rarely look deeply at resumesâI tend to initially call and have a conversation. We look for people who have skills, are passionate, and  who are willing to learn and solve problems with technology.
Great companies will have the ability to impart knowledge on any willing person. What we should be focused on is how we create UNICORNS not how to find them.
James: I totally agree. As you say, this is really how anyone applying technology within buildings should operate. Whatâs holding everyone back from operating that way?
David: At the core itâs two key elements: the commercial culture of the industry and the traditional OEMs not having the tooling or the speed to market with development cycles.
I believe it's similar to what Morpheus said in the Matrix, âUnfortunately no one can be told what the Matrix is, you have to see it for yourself.â
We have become addicted to doing things the way they have always been done. Why? Because that's how we have always done things, so we simply just try to re-invent ways of doing the same things slightly differently. Like the MSI.
This problem has largely been exacerbated by the commercial terms that are imposed on providers delivering these solutions. The risks are real for MSIs having to innovate in such short time frames.
This has contributed in creating a culture that simply forces most providers and technologists to take limited risks with technology, curbing everyone's and our industries ability to innovate quickly. This also has the adverse effect of people not being able to innovate in the ways they do things or how they apply technology.
We all then simply stay jacked in, waiting for the OEMs to release their latest box, software or platform that solves problems in a predefined way with predefined rules, that poses the least possible risk to the company when solving customers problems.
But what if all the LinkedIn posts from the OEMs are wrong? What if they don't understand the problems of tomorrow ?
It was about 5 years ago that I was really red-pilled. At the time, a common solution would consist of 250,000 points across 12 services. We were in a similar cycle to the above, this was the time we began to see the exponential growth in what customers wanted and needed from these converged systems to not only meet their own technology goals but that of their tenants.
At the time we began to see client solutions scaling up to 1 million data points across 40 services and wanting integration to tools that were common to them, platforms like Azure, Google Cloud Platform, even Sharepoint and Microsoft Teams.
We quickly realized that the tools did not exist in traditional building technologies that would support these large scale converged systems and this would be a massive limiting factor for us to scale.
We re-architected our core solution and took a hybrid approach, taking what was great in traditional building tech (for us that was Tridium and Haystack) and converging that with open source, modern technologies such as NGINX, VerneMQ, Apache Kafka and Docker to name just a few. This enabled us to scale on prem seamlessly and allowed us to work with any customers at any scale to provide access to data.
Applying open source technologies and embracing the ideology allowed us to not be limited by the slow development cycles of the traditional providers. Instead leveraging the development cycles of millions in the community. It gave us access to incredible technology that was being developed at an incredible pace.
Our inability to let go of the past and the traditional ways of applying technology will only inhibit the next generation of technologists, not accelerate it. Those who today come from a world with no limitations with access to software. A world where the best ideas win, not the ability for you to access a particular technology.
Time to fly!
James: What are your thoughts on the future of the MSI role?
David: The future is bright for MSIâs, but maybe not for the reasons everyone will expect. The MSI role has the opportunity to show the industry what our future workforce of technologists will need to look like.
What it shows today is that end users and customers are looking for real technologists who want to solve their problems and don't just focus on the raw technology itselfâthey focus on how ideas are brought to life and how technology can be deployed to enable a community of ideas.
The MSI is the pathway for the industry to go back to being Solution Provider focused first rather than second, and not just Product Providers. This in turn will force OEMs to focus on how they build and interact with more robust tools rather than boxed products that only allow innovation to occur around their subset of features.
We are now entering a time where people are scarce, customers are wanting to push the boundaries and it's really the perfect storm. We need to be focused on attracting new talent whilst also upskilling our existing talent.
I believe in the future, the MSI role will be remembered as the catalyst that sparked the change that was needed to transform and open our industry.
â
Head over to Nexus Connect and see whatâs new in the community. Donât forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up
Nexus Labs exists to move the smart buildings industry forward, without the fluff.
On Wednesday, we send out the renowned (and free) Nexus Newsletter.