At the root of the NCS system is the concept of Standard Keys. These are most often connected to the NCS rules of Standard Layers and the way drawing information is published. The concept and implemented practice of Standards Keys can do a lot more than that. We employ Standard Keys all over the place in the Production Solution products to increase consistency.
Here are the links to all the Standard Keys posts in this series. What came before bears significantly on the subject of this post.
- NCS Key Discipline Relates to Workflows
- Human Factors and the NCS
- Blatant Flatulent Software Keys
- Organizational Standard Keys
- Some Views are Related
- Too Many Dang Layers
For the moment let’s stick to Layers and Keys to keep it simple.
Ok. Maybe it’s not so simple (grin). We break the complex problem of Standard Keys and their relationship to Standard Layers into three distinct sets of typical workflow mechanics that we commonly run into.
- Discipline Keys and mechanics
- System or Software Keys and mechanics
- Organizational Keys and mechanics
The employment of all the types of Standard Keys occurs more often in larger institutions, but even if you work alone they all may all matter.
In the prior posts above we talked about
- The details of Discipline based Major and Minor Keys.
The word Discipline here should not to be confused with the formal NCS discipline keys. - We followed up with Software or System Keys (like VIEW keys for Civil 3D) that are practically forced upon us by how the software we employ works or even by our own customizations.
More on that in just a minute…
What is an Organizational Key?
The idea is simple and usage was once common practice in CAD. We want to compartmentalize the information we are working on by the responsible department, workgroup, or person. We employ and special department code in the layer scheme to accomplish this. For example the design sanitary sewer dept puts its information on SS layers and the survey dept puts the collected data on SV layers.
In practical terms there’s nothing wrong with employing Organizational Keys. In modern practice these tend to replace the formal NCS discipline Keys in most implementations (e.g. the NCS “C” becomes “SS”). The Keys are usually a single or most often a two-digit code to conform with current NCS and ISO Layer Pattern requirements. Many Microstation using organizations employ Organizational Key schemes as their systems evolved from numerical level schemes in larger organizations.
Commonly Organizational Keys are employed when drawings that are produced apart are then combined together for formal publication. They are a way of organizing the basemap by organizational accountability so to speak.
Organization Keys and the NCS
Truth be told, the NCS Standard Key methodology pretty much replaces the need for Organizational Keys. The NCS certainly seems to ignore them. Why? First, we should always remember the NCS is about plan set publication not how the plan came to be. Secondly, the NCS was built to aid in the construction and documentation of buildings and multiple building projects. Division of information in the NCS is about the Systems and specific trade disciplines performing the work. Arguably, all civil projects share these same concepts of System and “trade” discipline too.
Finally, Organizational Keys can effectively be replaced by NCS discipline keys and the careful usage of professional discipline related Major and Minor Key pairings instead (e.g. C-ROAD-EDGE). Hence why I call these Key pairings Discipline Keys. By in large, the departments, workgroups, or people are working on specific Major Key and Minor Key “systems” anyway.
Practically, organizational accountability can be divided by NCS discipline Key, Major and/or Minor Key combinations with little effort. In effect the Organizational Key then becomes redundant. The idea of the Organizational Key expressed in layer schemes often simply moves up into drawing naming conventions.
People Conversion Issues
Try and tell that to multiple departments or companies who have done nothing but employ Organizational Keys for a long time. The arguments may become Legion. Yes. I have personally seen demonic possession seem to manifest itself in Standards meetings. Have you?
Hence why I always try to talk about Major Keys and Minor Keys as Discipline Keys that specifically relate to the SYSTEM>>STRUCTURE>>PART>>CLASSIFICATION methodology expressed in the NCS, current Information Modeling, and that is built into model-based software. Read the posts above.
The organizational accountability is almost always related to the discipline specific Systems. The department may be responsible for multiple systems but these can still be easily identified in an NCS like replacement Layer scheme.
Exceptions
Layer schemes that employ Organizational Keys also have some built-in problems. What happens when the design people have to correct or add data to the data of another department? Typically, you find CLASSIFICATION code systems (last or even intermediate Keys) built into these layer schemes to deal with these and other similar exception problems.
Organizational Key layer schemes also tend to be more part centric and/or about the management of CAD primitives. CAD software can be customized to automatically put symbols (parts) and/or primitives by menus into the right place in the scheme. Technically these would become Software Keys by our definition. These would be coupled to the scheme as also discussed earlier in this post series.
Often Organizational Keys are coupled with specific PART codes in the scheme (e.g. SS-MHOL-EXST). Note that often additional CLASSIFICATION Key codes handle conditions like existing, proposed, demo, remove, etc. Where these appear in the Layer Pattern may move around.
Many Organization Key based layer schemes tend to fail right to left and right to left reading consistency tests. The layer name may only makes sense read in one direction. This isn’t bad, just more likely to increase confusion about object placement and increase information management issues for users. Hence why such schemes tend to be employed in larger organizations with a greater reliance on their own internal customized Software Keys and ridgid management systems.
Key Creep
Organizational Key and especially departmental schemes all tend to seem to gather more specificity over time. The Keys in use behind the Organizational Key tend to differ and diverge more and more. This reflects the professional discipline differences that can often be better expressed in Major and Minor Key pairings as discussed previously in the posts about Discipline Keys.
Department Key creep tends to expand the necessary quality control man-hours and over all publishing time required by users when combining drawings and publishing them. Of course, Key creep isn’t specifically the fault of Organizational Key schemes. It just seems to be a more likely occurrence.
Change Happens
Organizational Key based schemes also obviously suffer from organizational change adaptive problems. Over time work and workflows must change for a lot of reasons. Departments may be combined or separated etc. One of the better things about the NCS is that it is project centric. This more often than not better reflects the realities of the real AEC world.
There Can Be Only One
The use of Organizational Keys in your Standard Keys tends to do little more than muddy the waters. This begs the question, “Is organizational management an illusion of our own expectation and manufacture?” Huh? Ok. Management theory and change management is fun…but only to some. Don’t worry about it.
Certainly you’ll never hear from me that you need an AutoCAD Civil 3D template with the NCS layers for all potential occurrences of all design Discipline Key scenarios in it. There must be more than one. That is manageable. Our products prove it in production every day.
Civil Standard Keys Do More
You can get the Open Civilized Standard Keys for free. You can put them to work today.
Get Jump Kit and Get to Work
Thanks to the attentive readers of this blog. I apologize and have made a note to myself:
In the future please remember to publish the posts you’ve written when you refer to them elsewhere. Dooh!