This post was in response to someone asking us about OpenRoads, and it was then subsequently issued as a “Footsteps”. I felt the content was worthy of posting here to increase the odds of someone finding it.

First, I’ll say that this is the topic of the day for anyone running the Bentley Civil software (InRoads, GEOPAK or MX) and is exactly what ‘someone’ has to be thinking about. And I guess that’s you.

Okay, where do I start? …and I wish that it was a quick easy answer, but unfortunately it’s not (due to the dramatic nature of the changes in the software).

Relative to OpenRoads in general – you really need to be considering a larger master plan to roll out OpenRoads, and training is only one piece of it before we feel that you can move into any level of production.

In a nutshell, before I get into where Zen is, here are the key stages or areas that we feel you should be thinking about:

  • Why?: First you need to ask yourselves (internally) “Why should we move to OpenRoads?” And there should be a very good reason with specifics, not a general “because it was just released.” …or “everyone is doing it.” I wrote a general response to an article From the Editor in the magazine called Informed Infrastructure related to this subject. The original editorial and my response are posted here on my personal blog:  
  • Client Requirements: Who are your clients, and will they be using OpenRoads? Right now, full backward compatibility between OpenRoads and InRoads doesn’t exist. The two software versions are just too different. So if your clients aren’t using OpenRoads, I would not recommend that you use it in production and expect to deliver InRoads files to either your clients or other offices.
  • Standards: If your clients are requiring OpenRoads, or are moving to OpenRoads, then they may be developing the standards to be used within the software. This configuration is significantly more than just the simple XIN that InRoads used. And, configuration-wise, there is no easy migration path from InRoads to OpenRoads regardless of what anyone else tells you. If your clients are not driving your move toward OpenRoads, and it is internally driven, then you need to factor in how your software standards will be developed. Again, this is no small task, and although Bentley delivers some standards “out-of-the-box”, I have personally found those standards ‘wanting’. Aside from the quality of those standards, they are most assuredly not your standards (Survey alpha / numeric coding, Levels, Line Styles, or Cells / Symbols for example). Prepare yourself to invest some time and / or money into developing a good set of OpenRoads standards.
  • Workflows: OpenRoads is a quantum leap in software technology and warrants a review of your existing workflows. Be prepared; moving to this software will not be ‘business-as-usual’ so don’t expect it to be. This includes how you post-process survey data, how you create terrains (surfaces) from various sources, how you layout your Geometry, how you approach a complex modeling project, how you construct your final drawing package and individual sheets, and how you annotate those sheets, just to name a few areas. This will include ‘who’ does ‘what’ and who is using OpenRoads versus simply just using MicroStation. This can affect the number of software licenses that you have, or will need. You will have to adjust your workflows and how you accomplish your work as it relates to your interaction with this software. And I can tell that you are already aware of some of this since you mention the fact that you will now be managing DGNs instead of the traditional InRoads data files. And that is just the tip of the iceberg.
  • Documentation: This is the formal extension of the Workflow piece. The reason that this is so important with OpenRoads Designer, and wasn’t as critical with InRoads, is because of the “Rule-based” nature of the new software. Gone are the days when you can just haphazardly throw out construction lines in MicroStation and delete them when you don’t need them anymore. With the OpenRoads rules and “Design Intent” the software is remembering everything that you do so it can recreate the design should something change. That means that if you delete something that has established a “parent-child” relationship (that would be done after having placed a construction line and then removing it later) the software won’t know how to dynamically update the design due to the ‘broken’ relationship. The bottom line here is that your users will need to know what they can and cannot do relative to this new “Rule-based” design mentality.
  • Training: This will be critical to anyone who wants to get up on the learning curve quickly. This is obvious to some people, and I feel sorry for the users that work in an environment where the value of training is unacknowledged. And one final point on this is that all training is not created equal. Our training classes are being developed with OpenRoads in mind, not a regurgitation of an older model of training that fit InRoads. With OpenRoads, there are areas of the software that are much more important than others and our training will reflect that. And lucky for the trained InRoads user, our training will leverage that legacy InRoads knowledge and use it to anchor the new OpenRoads concepts and functionality to the various design tasks.
  • Pilot: Before putting the software on an actual project where the schedule and budget will be adversely impacted if something breaks down, it is highly recommended that you do a pilot project (or 2) on the software. There is no better way to know that you can actually use the software to get a project completed. In the past several years I’ve known too many places that had to abort a project on the software due to the fact that they could not accomplish what they ‘assumed’ that it could do. Don’t make that mistake, this is not InRoads anymore. For instance, the current version of OpenRoads cannot do End Area Volumes. In many cases that method of producing quantities goes back for decades and decades. Not having that functionality directly available in the software could blind-side you if you didn’t find out until it was too late. And then you’ll find yourself frantic and scrambling for a work-around. But a pilot project will reveal things like that and provide you an opportunity to have a well thought out contingency plan, or opt out of using the software until it was more developed in those areas.
  • Support: OpenRoads places a heavy requirement on the need for a CADD Manager, and CADD Support staff for a number of reasons. 1) Not only will there be more questions and issues due to using different software, but there will be less available answers simply because the software is so new, world-wide. 2) The way that the software is designed, many of the commonly accessible settings from InRoads (like the Project Options and Survey Options) are now located in either DGNLIBs or Configuration Variables or Design File Seed standards. These locations are historically not available in a Read-Write location for the average user, nor are they generally familiar with those Workspace level settings. This will need to be addressed before moving this software into production. And 3) the software is still evolving, and in some cases dramatically. For instance, Annotation set up in Update 2 doesn’t work quite right in Update 3. But Update 3 provides needed fixes that users need and want. That means that your configuration and standards will have to be revisited every time a new update is released. And be prepared for a new update every 3 months. Yes, 4 times a year.

And a few other things to consider:

  1. There are aspects of the software that are incomplete, like the Survey piece. Right now you cannot use OpenRoads to replicate what was possible in InRoads. OpenRoads Survey just isn’t fully developed yet. For example, the capability of Custom Operations to use Attributes in InRoads Survey does not yet exist in OpenRoads Survey.
  2. There are tools within OpenRoads that aren’t fully developed yet. These tools present themselves as “Technology Previews” and may or may not be fully functional yet.
  3. The tools that you may have become accustom to, like the Check Integrity tool for Geometry within InRoads, don’t all exist in OpenRoads. This is a primary reason to make sure you are very familiar with the capabilities of the software before your roll it out on a live project with a defined schedule and budget.

Now, as far as Zen goes – We have been buried in OpenRoads for some time now and are just finishing up our internal “Configuration Phase”. Starting next month we’ll move into the “Workflow and Documentation Phase”. We expect that we will be working on this next phase until at least the end of the year. We’ve already started to build some training around some of the OpenRoads topics, like Terrains, but we don’t have a full OpenRoads class ready yet. And it’s likely that we won’t until closer to the end of the year. We’ll probably start releasing material for public consumption in the Fall, and it will continue from here on out until we’ve completed our material line up. Our plans are to initially create smaller booklets on the various topics, and then in the future, package them into a more complete volume if it makes sense. But we’ll make that final decision after we see how our smaller books are accepted.

I know this is a lot to digest, but here we are, more or less at the mercy of the software developers who drive our tools. All I can say is don’t make this particular move unprepared.

I hope this helps you understand what you’re up against, and if you need or want any additional clarification on anything I said above, just let me know. You know we exist to help folks like you address areas like this that are sometime outside of your wheelhouse.

Feel free to contact us as needed. We’re here for you.

Civilly yours,

- mark

I was reading the March / April 2018 issue of an industry magazine called Informed Infrastructure and felt compelled to respond to something on page 8, in the From the Editor piece, titled Old Habits Die Hard.

Here’s a link to the magazine website:

Here’s a link to the digital online copy of that issue:{%22issue_id%22:485588,%22page%22:8}

My response was published in the May / June 2018 issue that can be found here:{%22issue_id%22:499933,%22page%22:10}

This is the contents of the From the Editor piece by Mark J. Scacco, P.E., (with my reply following after it):

I have a theory, and I wonder what you think about it. It has to do with ancient pyramids, spaceships, artificial intelligence, robots and self-driving cars. No, this doesn’t have anything to do with “ancient astronauts” or Chariots of the Gods; it’s a bit more mundane and a lot more serious.

The Other 1%

Without getting bogged down in the numbers, many studies have found that since the 1950s, manufacturing (which includes automobiles, aerospace and electronics/microchips, along with nearly everything else) has enjoyed a nearly 8% productivity increase, and the overall U.S. economy has seen increases of about 4%. In the same time period, the construction industry has increased by only 1% and has actually decreased since the mid 1990s. What’s going on here?

The Blame Game

There are a number of reasons frequently tossed about for why construction lags so far behind manufacturing. These include shortages in skilled labor and lack of adequate training; incomplete or inadequate designs resulting in rework, extras and delays; and an overall resistance to change or adopting new technologies. Although each is a valid reason—and discussions of them could and do fill many pages of journals and magazines—I want to use the next couple paragraphs looking at the last one: resistance to change.

Babies and Old Timers

The industries that experienced such dramatic increases in productivity all have existed for less than 200 years. In the long history of commerce and industry, cars, computers, rockets and robots are all babies, relatively new to society and civilization. Construction, however, stretches back nearly 200,000(!) years, with the earliest structures found in France dating back about 176,000 years. “Newer” construction such as Adam’s Calendar (also referred to as the “African Stonehenge”) is at least 75,000 years old, and the pyramids in Giza, Egypt, are 5,000 years old. Anatomically modern humans, Homo sapiens, arrived on the scene about 200,000 years ago and, based on the sites in France, began construction shortly thereafter.

Building things such as shelter is as natural as our drive for food and reproduction. Just look at kids: from their earliest years, they build forts out of anything they can find, and then crawl inside and eat snacks! Everyone—without any engineering schooling or a construction background—knows how to build a bridge: chop down a tree and lay it across whatever obstacle you need to traverse. Of course, these are very basic construction examples, but what basic airplanes or electrical circuits can nearly every human build as a child?

So here’s my theory: construction is so old, it’s in our DNA, making the industry’s habits very old and very difficult to break, resulting in the incredible resistance to change.

An Engineer, Not an Anthropologist

As an engineer, I’m licensed to do a lot of complicated tasks, but one of them is not to analyze culture, society and genetics. In other words, I’m not an anthropologist, and these are simply my musing on the topic. However, to solve the 1% productivity problem, we need different ways of looking at the issue, and I’d love to hear your thoughts. Please comment or drop me an email.


Hi Mark!

I receive the hard copy of your magazine and read your ‘From the Editor’ article a while back. As I was reading it I had some thoughts running through my head that prompted me to reply, albeit late. So, onto my thoughts:

Okay, I’ve read Chariots of the Gods (and many other similar books) and in fact, did my “graduate thesis” on the subject in 8th grade, so I think that’s a valid hypothesis that warrants further investigation. I would expand more on that here but I left my copy at my parents’ home in Pennsylvania and will have to get it first.

As to your statistics on productivity increases, I’ve never investigated those numbers so won’t comment on their validity, but I have heard similar statements and commentary by others.

Now, onto the meat of this. Personally, I think “lack of training”, “inadequate designs”, and “extras and delays” hits the productivity mark more squarely, but let’s take up this “resistance to change” item that you focused on.

Have you considered that your premise that ‘newer’ industries have experienced greater productivity increases than the ‘older’ construction industry actually points to the root answer of your “productivity” quandary? If something has been done for eons, successfully, why change? We have all heard “if it ain’t broke, don’t fix it.” So, you better give me a pretty darn good reason to change what I’m doing.

As you state, there seems to be an innate construction skill ingrained in us. But I disagree with your supposition that it’s the “hard to break old habits” that generate resistance. I believe our intelligence can overcome that (especially as engineers), and my experience has disproved the classical suggestion that you submitted for this resistance. And forget about the complexities of anthropology, just look at it logically …which is the only way to analyze man, a rational being.

Now, my suppositions include nothing about the potential for irrationality to rear its ugly head, and we all know that it does with some individuals, but you can’t form a premise with an assumption of total chaos and random behavior. So let’s assume that we can maintain our wits about us. With that said, I believe that ‘resistance’ is not inbred, but consciously determined based on one thing – added value. Added value as determined by the individual from where he stands (or sits).

So how do we look at this topic of “change” and “resistance”?

By finding the added value in anything that attempts to change what I’m doing. The yardstick is what I’m currently doing, and any ‘change’ is benchmarked against that. For example, should I move to the latest version of any software? The questions that need to be asked are “What value does it offer me?” and “Is any ‘added value’ worth the effort?”.

Why do people upgrade their phone? Their TV set? Their car? Early-adopters aside …it’s done because there is an added value. That value is more often than not, an ‘individually’ perceived value, not a societal one.

Let’s take Civil software for example. Just because something new hits the streets, does it automatically mean that everyone should dump their old software and immediately upgrade. Everyone needs to be asking themselves the question, “Why?”. This question requires a good, meaningful, applicable, honest, technically complete answer. Not a superficial, financially driven, mandate from someone who isn’t qualified to make that call (like is often done).

Resistance to change? Why would anyone keep changing their calculator every 3 months just because a new one came out? Every decision needs to be properly assessed and the positives as well as the negatives need to be cataloged. Then, and only then, can the true value be determined.

Resistance to change? I don’t think people are really resistant to change, they are resistant to poor, inappropriate, improper decisions that adversely affect their ability to get their jobs done.

Resistance to change? Expect resistance if you ram something down someone’s throat without consulting them, or providing proper training, while expecting them to just ‘make it work’.

Resistance to change? Show these ‘resistant’ individuals (or industries) something that makes sense (and prove the added value) and I’ll bet you’ll find the agreement, acceptance and adoption that’s desirable.

And lastly, as an engineer, surveyor, or construction practitioner, we can all benefit from a greater interpersonal understanding of society and the people that we are constantly engaged with on a day-to-day basis. And I believe that if we did, we would see those elusive productivity gains.

Civilly yours,

- Mark “Zen” Ditko

I found myself saying that “I’m old-school” quite a bit lately.

Is that good or bad?

I hadn’t really thought about it much until this moment. I think what makes Zen Engineering strong is that we ‘are’ old school in many ways, with ‘new school’ methods and objectives. Some things really do have to change with the times.

I saw a question on the Bentley Forum the other day where someone was asking how a complex Component / Template worked. Their post went something like this:

Just when I got InRoads SS3 under control I'm looking at OpenRoads Designer... Wow. My question is that we're using the delivered template library.

First let me say, “Welcome to my world …enter cautiously”.

The question is “do I know what I’m doing?” …Not when it comes to writing a blog, I’ll tell you that much. But these days I’m not necessarily one to run from new things either, so here it goes.

Excuse me for being too direct at times but this goes out to all the managerial dinosaurs; those stuck in the ‘old school’ ways; those wondering how to ‘force’ their staff to follow standards; all new college grads; those looking for advancement in this technologically driven world but are just generally confused about it; and to those simply wanting to be more productive but are unable.

To be successful in the survey, engineering, and construction business thirty years ago all it took were some ‘smarts’ and a good calculator. Those ‘smarts’ could have come from a good education, experience in the industry, or working closely with someone who had racked up a winning combination of either of those two elements.

Fast forward to present time.

Okay mom, I don’t suggest that you read this blog entry :)

I seem to be talking about this subject a lot these days so I figured that it would be a good topic for my blog.

Now where do I begin?

Some may believe this is a very trivial topic.

Some may say that it’s not really even an issue worthy of mention.

Some may not even be aware that this problem exists.

Some simply don’t care and therefore make it someone else’s problem.

Well, I’m here to say that this IS a problem. …and it’s simple math … Geometry actually.