More Than a Design Tool: The Data Problem No One Was Solving

About This Series

BIM Substation Designer (BSD) is a new kind of substation design tool, but understanding why it matters requires more than a standard product overview. This is the second entry in a three-part series about this new solution, informed by the perspectives of two of the people most responsible for bringing it to life.

Kevin Whyte, SBS Vice President of Substations, and Anthony Contino, SBS Director of Substations, bring an extraordinary depth of experience to the software industry. They have both worked for utilities, managed large-scale projects, and felt the friction that comes from tools that weren’t designed for the problems they’re being asked to solve. That depth of expertise has shaped everything about BSD: why it exists, how it was designed, and where it is headed.

Be sure to read Part 1 of this series, “Why We Built BSD on Revit, and Why It Was the Right Next Step,” for the full context on what BSD is and why SBS built it.

Part 2: The Data Problem No One Was Solving

If you ask most substation engineers where they experience the most inefficiency in their work, they probably won’t say design. It’s far more likely they’ll bring up the issue of gathering information from scattered phone calls, emails, or spreadsheets that get updated in one system and forgotten in another. Or they might talk about the moment a crew arrives at a substation to replace a breaker and discovers that three adjacent pieces of equipment also need attention. That’s information that existed somewhere in the organization, but it never made it to the people who needed it.

This is the data problem. And for all the progress the utility industry has made in design tools and workflows, it remains largely unsolved.

Kevin Whyte spent more than 15 years inside utilities before joining SBS. He watched the data problem play out at every level of the organizations he worked in.

“Let’s say someone from operations tells you a breaker needs to be replaced,” Whyte offered as an example. “The crew goes out to the site, and they notice that the switches on either side also need attention, and the neighboring breaker has the same issues. It just wasn’t reported correctly. That information goes into a system somewhere, but by the time the next job comes through, no one has connected the dots. It leads to making decisions without the full picture.”

The costs are real: truck rolls that could have been combined, equipment ordered too late or incorrectly, and construction change orders that trace back to a design that didn’t have access to all of the known information. In a capital-intensive industry where substation projects run into the millions of dollars, those gaps are expensive.

Data Lives Everywhere, and Connects Nowhere

A typical substation project touches a dozen groups (or more) within a utility: engineering, operations, maintenance, construction, procurement, finance, real estate, environmental… the list goes on. Each of those groups has data relevant to the substation, including equipment history, maintenance records, financial forecasts, and site constraints. In most organizations, that data lives in separate systems that don’t talk to each other.

Unfortunately, many design tools have contributed to this fragmentation rather than offering complete solutions. A design will get completed, a drawing set will get issued, and the data embedded in that design (the precise specifications of every component, their relationships to each other, their history) doesn’t flow anywhere useful. Instead, it simply sits in a file. Operations works from their system, and finance works from theirs. The connections that would make everyone’s job easier simply don’t exist.

“There’s a plethora of data in this industry, and it’s all siloed,” Contino explained. “You have data spread across many different groups within a single utility, and it’s all relevant. It all relates to the components in a substation, their relationships to each other, the metadata between them. The opportunity is bringing it together in a way that’s actually useful.”

This is the problem BSD was designed to address. Not just as a side benefit of better design tooling, but as a deliberate architectural choice made at the foundation of the product.

A Common Language for Substation Data

In the early days of computing, every technology vendor built their own networking systems. IBM, DEC, Xerox: each optimized for their own hardware and assumptions. Networks couldn’t easily communicate with each other. Every connection required custom integrations that were fragile and expensive to maintain. Innovation slowed because so much effort went into compatibility rather than progress.

TCP/IP changed that. It didn’t replace computers or force vendors to redesign their hardware. It defined a shared set of rules for how machines communicate, regardless of who built them. Once adopted, any computer could talk to any other. Vendors began competing on performance and capability rather than compatibility. The result, ultimately, was the internet.

The substation industry faces a version of the same problem today. Every software vendor builds their own data model. Every system speaks its own language. Moving information between them requires custom integrations that are expensive to build and brittle to maintain. The cost of this fragmentation falls on utilities, engineering firms, and the engineers who spend their time bridging gaps that shouldn’t exist.

BSD is built on an open data standard aligned with CIM, the framework the industry already uses. It serves as a common language for substation data and incorporates additional standards like IEEE C37, IFC 4×3, IEC 61850, and utility-specific standards to add more semantic depth and insight to the substation model.

“Every vendor builds their own data model for their own software,” Contino said. “What we’re building is different. It’s an interchange format that allows data to move between any application within an organization. We’re defining the grammar of a substation: the meaning of each component, its relationship to other components, its alignment with industry standards. So instead of mapping word by word between systems, you’re translating meaning. You don’t have to do pairwise mapping anymore.”

Critically, this standard is open, based on frameworks controlled by the industry, as opposed to a proprietary model that creates vendor dependency. The value SBS delivers is not in owning the standard. It is in building the best tools on top of it, and in being the team that understands it most deeply because they designed it.

Value From Day One, and Growing Over Time

One of the important things to understand about BSD’s data architecture is when the value begins. It doesn’t require a multi-year implementation or a data migration project before it starts delivering. The moment an engineer begins working in BSD, the data they produce is structured, connected, and ready to move.

“The minute you start using BSD, you have that data,” Whyte explained. “It’s all part of how the product is set up. You can start moving it now. The connections to every downstream system aren’t all built yet. That’s work that happens over time. But the data is there, and it’s in the right format. That’s the starting point no one in this industry has had before.”

As more data accumulates, as more projects are completed in BSD, as more equipment histories get connected, and as more of the organization’s systems begin to speak the same language, the value compounds. The picture of a substation’s full lifecycle gets clearer. Decisions that used to depend on a veteran engineer’s memory or a manual reconciliation of three different spreadsheets start to happen automatically, with data that can be trusted.

“The CFOs I’ve talked to about this would love to have all this information at their fingertips, to be able to get what they’re looking for in the format they need, and to trust what it’s giving them,” Whyte said. “That trust is the hard part, but good data infrastructure makes it possible.”

The Bigger Picture

First and foremost, BSD is a substation design tool. It makes engineers faster and more accurate. It eliminates the manual reconciliation that drives rework. It delivers real productivity gains on day one.

But the data architecture underneath it is designed for a bigger vision: a future where the full lifecycle of a substation asset, from initial design through decades of operation, is connected, accessible, and useful to every part of the organization that needs it. This is about planning for what’s coming, when AI can surface insights that no analyst could find manually, and a utility’s capital planning, rate cases, and operational decisions are grounded in data they can actually trust.

“If you want to get into AI and digital twins, which is what everyone is working toward, you need data structured in a way that’s consumable,” Contino said. “You can’t just throw it in a database. It has to be formatted correctly, with the right semantic meaning, and extensible enough to grow. If you’re going to build a new product, you have to build a data model. We decided to do it right.”

In other words, the design tool is the entry point, but the data strategy and structure are what’s leading to the destination. In Part 3 of this series, Whyte and Contino explain what that destination looks like and why SBS is uniquely positioned to help utilities get there.

Next in the Series

In Part 3, “Building for the Utility of the Future: AI, Digital Twins, and the Long Game,” Whyte and Contino explore what it means to design software not for the moment, but for the decade ahead, and why the decisions SBS made in building BSD will position utilities for a future their current tools can’t reach.