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: http://thezendude.com/blogs/74-old-habits-die-hard-a-zen-retort.html  
• 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