CM: THE NEXT GENERATION - Building Reliable Applications

just expanding
its foot-hold.  There were no File System standards to adhere to (i.e. make the design architecture mimic file system architecture).  As a result, our first releases of CM+
focused on a complex Folder/Module/Section paradigm, where each Module, which
shared a common base name, was composed of several Sections, identified by the
file Suffix.  For example a C-module had a .h and a .c component, and in our case a .x component as we preferred (and still do) to keep "externals" separate from all other header definitions.  An Oracle form had a different set of sections.  An Assembler
language module had a .inc and a .asm component.

Although the product let you define your own module types (called groups), and this was
a selling feature for some shops, we soon realized that every shop worked differently - and it wasn't always easy to package things into neat module groups, especially because the groupings overlapped.  As a result, it became nearly impossible to automatically load in a new project.  Even if all of the module groups were defined up front, when the system
encountered an overlapping section (i.e. one that could be part of several different groups), it didn't know which group to assign to it. 

As well, in the old days, apart from Unix, executables were often built from all of the
files in one directory.  There was no overlapping name space and it was easy to go from a file name to exactly what executable, or executables if it were shared, it belonged to. This flat name space made things very easy and a few of the older CM tools adopted it.  But in the end, as the Hierarchical File System took precedence and users wanted the same name in different products, and, especially with O-O Design, the same name in different subsystems of the same product, we had to admit that our design was inadequate.

Our first attempt to fix the problem was to allow a flat name space per product.  But this was inadequate.  This resulted, in the mid-1990's, in Neuma having to, not only completely re-do it's product file-handling architecture, but also in having to improve its context specification ability.  In a flat name space, some aspects of context aren't as important from a file management perspective. In a hierarchical, product-based, overlapping name space, it was crucial.  Furthermore, through all of this, we had to
ensure that our existing customers would have the option of continuing with the flat name space or moving to an overlapping name space.

The point is, it was not easy to get the requirements right.  And requirements continue to evolve.  So what's the solution?

Solution Architecture

One of the main reasons we were able to weather the storm is that we focused on
architecture at different levels.  We did not need to know what the CM requirements were to understand what a NG Database must look like to support a general set of engineering applications.

On top of that, we knew from the start, that automation and zero administration were
important goals.  Even after completing the initial NGDB architecture, we took the time to understand what potential clients said was number one in our target market requirements - customization - making the tool work the way the customer wanted.  This molded most of our efforts beyond the NGDB design.  We would seriously consider
whether or not customization would be required for each feature and err on the
"yes" side.  But we would also consider how to build an architecture that was easy to customize. 

And when GUIs came along, this became a priority as well. If every site had different
customizations, we did not want to get into customers having to paint forms, create dialogs, etc.  We wanted the tools to do the tedious work, while the