On the surface, it seems like there should be some connection between the C/JMTK and SDSFIE.
Both of these were developed to help with either Department of Defense, or other national security initiatives. In the case of C/JMTK, the primary government agency is the NSA.
SDSFIE was developed to provide a common data model/schema for all government agencies. It started with a focus on the Navy and Marine Corps, but other agencies have definitely been involved. The latest version, 3.0, was designed from the ground up as a means of finally integrating all of the offshoots that were created by the different agencies.
SDSFIE is very comprehensive, covering data types from utilities, to environmental, to now include Levees and a Real Property Inventory. In many cases, the changes between versions were not a reduction in information being stored, but instead how it was stored.
Example:
Version 2.6
wastewater_mainline_gravity
wastewater_mainline_forcemain
Version 3.0
Wastewater_mainline - Subtype: Gravity; Forcemain
The reason I bring this up is to show that Subtypes are being used. This is a relatively ESRI specific nomenclature, and leads to my next point: While the SDSFIE data model is designed in a way that I think could be used in different database structures, it was developed using ESRI data objects and terminology. Some specific objects that are utilized are Relationship Classes, and Network Classes.
Since the C/JMTK was developed on a DoD mandate, I would imagine at some point that it is going to be set up to use data in the SDSFIE schema. It would be worth checking now, as you might be surprised to find that it already does.
If not, then there definitely won't be a software/data conflict, as they are all based on ESRI products.
The challenge that I could see you encountering in starting to use SDSFIE with your current work, would be the amount of customization and automated processes that exist in the C/JMTK software. If there are many automated processes, like assigning particular attributes when a new feature is added, or geoprocessing models that are dependent on specific fields, these would have to be modified to match the attribute fields of the SDSFIE schema.
I will say that if you have the opportunity, to try out the SDSFIE schema. From the time that I was using it, which was with the 3.0 version at the end of the development cycle, it was very comprehensive, as I said previously. If there was a feature that you needed to enter, there was likely a layer already set up, with relevant attributes and domains already defined. As well, relationships were defined between feature classes, thus allowing you to add a logical link between features, such as between an electrical sub-station and the switches that were contained within.
