Experts Talk is an interview series with technical leaders from across our transportation program. 

Data-Driven Modeling and Design for Improved Efficiency and Decision-Making

From accelerated alternatives generation to a tighter linkage between geometry and analysis, model‑centric workflows are changing how complex bridges are designed and delivered. Instead of treating 3D models, analysis files and plan sheets as separate artifacts, this approach turns one digital model into the living “source of truth” that drives design, documentation, coordination and visualization. 

Senior Bridge Engineer Jeff Svatora has developed and applied model‑centric workflows on our most complex bridge projects, including cable‑stayed and long‑span steel structures. He focuses on unifying CAD, parametric design and analysis so that geometry, calculations and deliverables move together. In this interview, Svatora explains how our model-centric workflows are moving bridge design forward, how they improve efficiencies and quality and what may be next for the approach.

Q. How do model‑centric workflows differ from building information modeling (BIM) or the parametric approaches many bridge engineering teams already use?

A. Over the past decade, the industry has moved from paper to PDFs to BIM, but model-centric workflows take it to a new level: the 3D model doesn’t just represent the design, it serves as the foundation. Geometry, analysis, design intent and documentation are integrated so the same model feeds calculations and sheet production, not just visualization. 

A hallmark of model-centric workflows is interoperability. For example, HDR created software translators that can take a model from Open Bridge Modeler (OBM) and generate an analysis model in other programs — a capability that’s not available out of the box. We’ve also successfully integrated teams working simultaneously across different CAD platforms when that was required by the project. 

Parametric tools are also still essential, but instead of living in isolated scripts or project corners, they connect CAD and analysis into one cohesive workflow. The result is an integrated process that merges our prior BIM, parametric and design tool initiatives into a faster, unified system. 

A single source of truth model in Rhino/GH (top) and geometrically identical derivative models in CSi bridge (bottom left) and LARSA (bottom right). 

Q. Sounds complicated. Why bother using model-centric workflows?

A. First, speed with substance. On a recent project on the West Coast, for instance, we templated a tied arch structure with model, analysis, design and sheets. When the client requested a dozen alternatives, we produced each set of analysis models, design calculations, and CAD deliverables in a matter of hours. That kind of fast iteration expands options without sacrificing rigor. 

Second, tighter analysis integration. Our workflows automatically generate consistent analysis models from the design geometry, including specialized cases like nonlinear time history seismic analyses, eliminating the old practice of rebuilding a second model that must be painstakingly checked to perfectly match the first. Instead, when geometry changes occur, all analysis models automatically stay in sync, which verifies quality. 

Model-centric workflows aren’t about chasing novelty; they’re about delivering quality with fewer disconnects, surfacing better choices sooner, and equipping clients with clearer, context-rich information. That’s how we design smart, push boundaries responsibly and create infrastructure that serves communities for decades. 

Q. What are the implications for quality when using a model‑centric approach?

A. Quality improves when there’s one authoritative model. Because the analysis model is generated from the same geometry that drives the sheets, we remove the “drift” that could happen when separate files evolve out of sync. Changes propagate through the pipeline by design, and geometric errors in the analysis models are eliminated. 

Version control, using tools such as GitHub, strengthens checks and reviews. Every change is documented and attributable, which reduces the risk of accidental edits and makes peer review more efficient. Multiple engineers can test ideas in branches and merge them when validated — a capability that analysis programs don’t natively support, but that our text-based workflows enable. 

Finally, the more we automate translation steps, the more we shift effort from remodeling to engineering judgment. That means our quality time is spent interrogating behavior and performance, not reproducing geometry. 

Q. Beyond more efficient analysis, how can model-centric workflows benefit other aspects of project delivery? 

A. The primary benefit is 3D multidisciplinary coordination to validate that the bridge design does not conflict with other existing and proposed elements. Beyond that, there are numerous other benefits. 

First, visualization and communication. Once we have a robust 3D model, we can use it for all sorts of things: architectural renderings, wind tunnel consultant coordination, public-facing exhibits and even immersive “walkthrough” reviews that convey scale in ways 2D drawings can’t. We’re working to automatically tie in GIS so models can sit within full site context — terrain, adjacent infrastructure and city fabric — to improve planning and client communication. Even simple geospatial pull-ins can elevate alternatives discussions and better reflect how a bridge lives in its environment. 

Seeing a retaining wall or a long span in context changes how teams and stakeholders prioritize design decisions. It’s one thing to see a wall on a page; it can feel very different to see how large it would be from the perspective of people walking by. Similarly, engineers and our clients often think about a bridge based on the views on a sheet (elevation or plan view). Quite often, though, there is no way for a person to physically see that bridge from that view. That’s a second benefit of a “walk through” — everyone is forced into the same reality.

Improved operational insight is also a major benefit. On these complex structures, a model can help teams think through maintenance access, clearances and sequencing. Pairing reality capture with model-centric coordination can answer practical questions early (e.g., equipment access) without overproducing geometry.  

Q. What did it take to create these workflows? 

A. This hasn’t been simple, but the hard work on interoperability is now paying off. It took us at HDR about five years to develop the pieces — the software infrastructure, the quality controls, and the translators that mean designs can interact with 3-plus CAD/BIM programs and 4-plus analysis programs required by our clients. But we’re now at the point where the workflows are efficient and we can contribute to real projects. Each “obvious” step hides thorny details, and developing small tools with uncertain payoff is difficult to justify until you knit them together at scale. 

The code base is collaborative by design. We’ve combined contributions from roughly a dozen colleagues across offices, drawing on BIM and parametric specialists and learning from building engineering peers even when our tools differ. That broad bench is what makes the approach sustainable beyond a single champion. It’s not something that every firm can do and it’s been exciting to see HDR’s expertise rise to the challenge. 

A native OBM model (top) imported into Rhino (bottom left) and the geometrically similar flat deck LARSA model (bottom right) developed from the OBM model. 

Q. Where does this model-centric approach go next? 

A. Two tracks. First is wider adoption: on projects that need complex analysis the goal is a full 3D model as the single source of truth, with parametric capabilities and robust interoperability so geometry, analysis and sheets stay aligned. And those capabilities are also already moving into medium complexity work, with appropriately scaled tooling for simpler bridge types. 

Second is computational design layered on top of digital design. Imagine tools that iterate on the model to optimize member sizes or explore viable girder layouts automatically. We demonstrated the ability to do this for large structures under full influence live loadings and complex staging in 2022-2023 as part of an HDR fellowship. We’re moving effort from manual loops (run model, export, edit spreadsheet, repeat) to high value engineering decisions with richer insight into structural behavior. 

Inspiration and Advice

Q. How did your career lead you to this specialty?

A. During my internship at HDR, I worked with some amazing engineers in Omaha who were pushing the limits of programming, computer hardware, and available analysis tools to model steel bridges. I decided that was what I wanted to do because it was fun and cool, and during grad school, I focused heavily on developing the knowledge base needed to do that. Now I find myself in exactly that position, but with a new generation of technology and challenges. Just like the people I learned from, I do this because it makes work fun and I can’t resist the urge to tinker with a good challenge.

Q. What advice do you have for someone else considering a career in this area of bridge engineering?

A. Even the most stereotypical engineers have creative needs. Make sure you have a way to meet those needs. That could be anything from writing or woodworking to building homemade robots. A healthy side effect of that is getting used to “failure” (it’s not really a failure if you had fun). Not every painting is perfect and not every program ends up working as you intended and that’s ok. In my opinion, this is a great way to develop the resilience needed to take on a complex and open-ended project like developing model-centric workflows.

Each Experts Talk interview illuminates a different aspect of transportation infrastructure planning, design and delivery. Check back for new insights from the specialized experts and thought leaders behind our award-winning, full service consulting practice.