All Throttle: Build the Building Around the Technology

Building around technology means deciding how systems, data, power, networks, safety, operations, and experience must work together before the physical design makes those decisions harder to change.

A technology-led destination begins with a different kind of decision. Not: What software should we add later? But: What must the building make possible from day one?

That question is at the center of Richard Madeira’s LinkedIn essay, All Throttle | Build the Building Around the Technology. Madeira writes about the moment when a project has to choose whether technology will be forced to adapt to a finished plan or whether the plan will make room for the systems, people, and evidence that technology needs to do useful work.

The point is not to make technology the headline. The point is to make a complicated place feel considered when people actually use it.

RJ Hunt put the thought plainly in the essay:

“We want the technology now, and we want to build the building around it. Not adapt technology later.” — attributed to RJ Hunt by Richard Madeira [1]

That sounds obvious until you follow it all the way through.

Most projects meet technology late. The building is planned. The mechanical systems are specified. The rooms are allocated. The walls are drawn. Then somebody asks how the controls, connectivity, security, access, energy, operations, and future digital services will work together.

By that point, technology is trying to catch up with a series of decisions it did not help make.

A technology-first approach asks different questions before that happens. Where does the data come from? Which systems need to exchange information? What should remain separate? Who owns the data? What happens if a network goes down? Where do control rooms, equipment, conduit, edge devices, and maintenance access belong? How will a team test the whole thing before it is asked to perform in a real operating environment?

These are not questions for a futuristic demo. They are questions for architects, engineers, operators, cybersecurity professionals, and the people expected to run a place day after day.

Siemens makes the point in direct language. Its work on IT/OT convergence describes the challenge as bringing physical building equipment and devices into the digital environment while maintaining cybersecurity. That is not simply a software exercise. It is the careful design of data flows, network boundaries, permissions, and operating responsibilities. Siemens specifically calls for planning around use cases and involving IT, cybersecurity, architects, consultants, engineers, and the construction team early. [2]

That is the distinction worth keeping in view. A building can have smart devices and still not have a coherent operating strategy. It can have dashboards without having clear data governance. It can have connected equipment without knowing which system is responsible when one part of the environment changes.

When people hear “smart building,” they often think of a screen on the wall, an app in a phone, or a room that adjusts when someone walks into it. Those are the visible edges of a much larger operating question.

Operational technology, often shortened to OT, includes the systems that interact with the physical world: building automation, HVAC, lighting, fire safety, access control, physical security, power, meters, and other equipment that monitors or changes conditions. Information technology, or IT, includes the networks, computing, applications, data services, identities, and governance that allow people and systems to exchange information.

Bringing those two worlds together creates useful possibilities. It also creates responsibility.

The National Institute of Standards and Technology identifies building automation, physical access control, physical-environment monitoring, and other programmable systems as forms of operational technology. Its guidance is clear that OT security has to account for performance, reliability, and safety—not just conventional information-security concerns. [3]

That is why early integration work should not be confused with simply making more systems talk to one another. The goal is not maximum connection. The goal is intentional connection.

A useful architecture distinguishes between data that needs to move and data that does not. It defines who can make changes. It plans for safe failures. It makes room for maintenance. It avoids creating an environment where a convenient new feature quietly opens a problem somewhere else.

In a considered destination, those choices should be almost invisible to the person having dinner, arriving at an event, walking through a gallery, or meeting a friend. But invisible does not mean simple. It means the complexity has been dealt with in the right places.

The most consequential output of an early technology conversation is often not an app, a product, or a render. It is a list of decisions that gets made before those things become difficult to change.

That work is unglamorous. It is also where a technology story becomes credible.

At Siemens’ Wendell, North Carolina Electrification and Automation campus, the Customer Experience Center and Power Academy were created as part of a $36 million facility investment announced in 2024. Siemens describes the setting as a place where visitors can engage with power-distribution equipment and explore protection, control, and automation solutions. [4] Its 2026 microgrid announcement described the campus as a live example of connected energy infrastructure, combining generation, storage, building management, cloud analytics, charging, and training environments. [5]

That does not mean another project should copy the campus. It means a working environment can make the tradeoffs more concrete. Conversations become less abstract when you are standing in a facility that has to operate as a facility.

There is a temptation to describe integration as if it were a single line on a technology plan: “connect the systems.” The real work is more specific.

An open building-management platform may help teams bring diverse systems into a shared operating view. Siemens describes Desigo CC as an open, multi-discipline platform for systems including HVAC, lighting, fire safety, security, and other building functions. It says the platform is designed for IT/OT convergence through northbound and southbound integration and can support third-party-system engineering. [6]

The important word is can.

A platform does not eliminate architecture. It does not settle governance. It does not make a complex environment secure by default. It does not guarantee that systems from different manufacturers will work together exactly as imagined. It gives a team a framework that still needs to be designed, integrated, tested, commissioned, monitored, and maintained.

The same is true of open standards. The BACnet Testing Laboratories listing for Siemens Desigo CC Workstation 9.0 shows certification across multiple profiles, including the BACnet Cross-Domain Advanced Operator Workstation profile, or B-XAWS. [7] That is meaningful technical context. It helps explain why a shared language and a tested interoperability profile matter. It is not a substitute for project-specific engineering.

The distinction may feel academic until a project changes. A new operator arrives. A supplier updates a controller. A security policy changes. A room changes its use. A system reaches end of life. A building that was designed around closed assumptions becomes expensive to adapt. A building designed around clear interfaces, authority, and evidence has a better chance of evolving without losing its bearings.

There is a difference between technology that is impressive during a tour and technology that is useful on an ordinary Tuesday.

The more complex the environment, the more important that difference becomes. The aim should not be to force every interaction through a device or announce intelligence at every turn. It should be to reduce avoidable friction while leaving people in control.

That is why the best technology stories are often stories about restraint. A well-planned system does not ask the guest to understand the building. It gives the operating team the information and control it needs to make the experience feel composed.

The same restraint applies to the way a development talks about technology before it opens. There is a good reason to be specific about methods and cautious about outcomes. A project can say it is doing the work early. It can say it is examining systems architecture before making late-stage constraints permanent. It can say that cybersecurity, operations, integration, and commissioning are part of the conversation.

What it should not do is turn an early design conversation into an operating promise.

Building X, for example, is described by Siemens as a platform built on secure, real-time data for building operations, with applications across energy and sustainability, safety and security, and operations and maintenance. Siemens says its platform includes open APIs and AI/ML capabilities for analytics and forecasting. [8] Those are useful reference points for the broader field. They do not confirm that a particular development has selected, installed, or operates the platform.

Keeping that line clear is not cautious copywriting. It is good practice.

Madeira’s essay is valuable because it starts with a design question, not a finished operating model. The technology-first position is not a claim that every system has been chosen or every outcome has been guaranteed. It is a commitment to do the difficult coordination work before physical decisions harden around incomplete assumptions.

A credible technology path looks like this:

Intent → requirements → system architecture → design coordination → commissioning → operating evidence → public reporting

Every step matters. Skipping from intent to public certainty is how a technology narrative gets ahead of its evidence.

The building industry has no shortage of promises about artificial intelligence, digital twins, automation, and seamless experience. What is rarer is the willingness to start with the systems work: the interfaces, permissions, rooms, data boundaries, maintenance realities, test plans, and human accountability that make those terms useful.

That is the useful takeaway from “build the building around the technology.” It is not a reason to make grander claims. It is a reason to ask better questions sooner.

This article was informed by Richard Madeira’s original LinkedIn essay, All Throttle | Build the Building Around the Technology, which provides his firsthand framing of the technology-first design question.

The Fast Town Journal feature is an independent, public-facing editorial adaptation. It uses separately cited sources for general technology context and does not represent an engineering specification, vendor selection, partnership announcement, operational assurance, or future-performance statement.