I had a consulting manager at Bentley say to me once, "I had no idea that you knew roadway." I KNOW Roadway really well, but when I'm pulled from my Bentley "day job" to provide consulting services, it's for drainage "hot projects" or to consult with leadership teams to plan OpenRoads Drainage Implementations.
I think I defensively answered "I'm roadway first" (because Bentley Civil is roadway first), but upon reflection I'm not sure that holds up to scrutiny. In the three-way split between Roadway, Site, and Drainage Engineering, Drainage does, in fact, get the edge.
I may be the same sized Big Fish, but the Pond of Drainage Experts is much smaller than the Great Lake of Roadway Experts.
OpenRoads Drainage (it's currently called "Subsurface Utlities") is a full implementation of StormCAD and CivilStorm within the OpenRoads Designer environment. I've been deeply involved in its development and rollout since its early days at Bentley. The Product Manager and I developed most of the training (until recently when I moved to promoting all Engineering Applications).
After getting a full complement of Drainage Training published, I started with Virginia DOT extensively. I developed additional training material per their needs and delivered multiple weeks of training at their headquarters and regional offices. I worked with hydraulic managers to address their concerns (they were less about the software than being able to assure the quality of projects submitted by staff and consultants. StormCAD and CivilStorm are considerably more sophisticated than the software they were replacing. We worked to develop customizations of in-software tools to help flag issues and automate review).
I most recently spent weeks with the Hydraulic Leads at ALDOT, TxDOT, OrDOT, and WSDOT, and a top 5 Design Company going over details of the product's spatial and hydraulic capabilities and how to meet their detailed design criteria (see The Surprise Barrier to OpenRoads Drainage Acceptance).
The last drainage course I authored prior to my current position was Placing a Ditch and Culvert Networks. A direct result of writing that course is a series of enhancements to the software to allow easy layout of ditches whether the terrain reflects the ditch or not. This is an example of where the code was sufficient for "standalone" Haestad workflows, but required enhancements because of the level of spatial accuracy one expects in the OpenRoads BIM/Digital Twin-ready modeling environment.
This is actually a major consideration when implementing OpenRoads Drainage: because you can be extremely accurate spatially (even photorealistically), how much do you let that capacity "distract" you from your contracted deliverables. There is a tendency to chase spatial perfection even though it is not required hydraulically or even contractually. What is the balance? Balancing this question is especially true for agencies setting up their standards.
Drainage Headwaters
I started my career doing site and drainage engineering in Central Florida. 7.4 inches/hr is seared into my brain, still. It was the 5-minute 25-year storm intensity.
My first big site job was a 30-acre shopping center with some interesting drainage challenges. "Spring Creek Square's" creek was replaced with two 60-inch pipes and, of course, there was only a few feet of fall across the property.
Later I was the design engineer working with Orange County Public Schools additions: grading and drainage permits for new Media Centers and Bus Loading loops.
When I worked at Intergraph, I helped them develop InFlow. When I got there, the software stopped working if the pipes got surcharged. "Well, that rules out using it in Florida. We rely on up to 6 inches of head above an inlet throat to compensate for our flat terrain." I worked with the Water Resource Manager to develop the algorithms to model surcharged systems (and basic pump HGLs in InSewer). This was prior to the publication of HEC-22 (ask me about our "whiteboard sessions" sometime). Soon I was the Water Resources Certification and Support lead. This work led to relationships that would lead me to San Diego a couple of years later.
At the City of San Diego, I helped integrate InSewer with Intergraph's GIS to meet the EPA's requirement in waiving Secondary Water Treatment. I implemented InFlow/InSewer and Storm&Sanitary at the City of San Diego, developed the training, and trained the City staff in InSewer (and InFlow and InRoads).
I authored, sold, and trained Mastering Storm&Sanitary in 2000. This was my lead-in and my differentiator within the independent InRoads Consulting community. InRoads manuals and consulting followed.
When I worked for CalTrans District 11, I designed both roads and drainage systems. Their processes were some of the most chaotic I'd seen (lots of retyping). At a meeting near the end of my stay there, I showed how I Automated CalTrans D11 Drainage Deliverables. All were impressed (but only a private contractor followed up to see how he could use the tools). The takeaway here: don't let your client's backwards deliverable requirements cripple the much longer design (and re-design) process.
In something of a return to my (consulting) roots, I recently met repeatedly with the City of San Diego to help secure the contract to upgrade from InRoads Storm&Sanitary to OpenRoads Drainage. In a moment of pride - and horror - I saw that the department computers had a link to a "hydraulic wheel" I wrote for them in 1999. "Are you still using FlowMonster?!" "Yes, we are."
