Why implement the full Model?

In MISMO V2 implementing organizations were faced with a number of challenges.

• DTD did not lend itself well to producing object models automatically
  
• There were multiple conflicting definitions for the same object (15 different definition of BORROWER, 17 different definitions of PROPERTY)
• Reuse was almost nonexistent across the collection of individual transaction definitions, sometimes even within the transaction definitions from a single Work Group.

Now that V3 is here these issues have been addressed. There still are some design questions.

• Should we implement the full model or just the subset that matches a V2 transaction?
• If we implement the full model how deep should we go?

We will discuss the first question here and the second one in Part 2.

Should we implement the full model or just the subset that matches a V2 transaction?
This question is kin to the classic development conundrum "The users say they will never ever use this feature, but I think we should build it." Is this insightful development or scope creep? The debate over this has gone on from the very beginning of software development. Each system has a differnt balancing point between being insightful and being scope creepy.

To understand the balancing point for MISMO V3 we need a little background on how it is designed.

Separation of Object structures
There are two kinds of objects in the reference model, Objects with properties and Objects that contain other objects. In XML terms the messages will have elements of two kinds. Some elements will have children elements that hold data and others will have children that are other non data carrying elements.

All or Nothing
If a Work Group (WG) includes a data carrying element they MUST include all the data points. On the other hand a WG may trim the non data carrying children in defining their subset of the Reference Model (RM) tree.

Contain unbounded data
Whenever there is a multi-instance element, give it a singular noun name and wrap it in a plural noun element (PARTIES/PARTY, LOAN/LOANS, ASSETS/ASSET)

No Recursion
At no place in the model may there be a child that is defined with the same complex type as one of its ancestors. This prevents cycles and recursion. The automated tools that make Objects out of XML types have sever problems with recursive designs.

These designs are documented in the MISMO Engineering Guidelines (MEG) and enforced by the Core Data Structures (CDS) committee.

Together these rules conspire to provide make implementing across V2 "Process" boundaries easier.

• Persistence models and object models will almost always map one-to-one with data carrying XML elements. This DOES NOT mean the table models have to match. It DOES mean that every data point in the XML will map to a unique column in the persistence model and a unique property in the object model.
  
• Plural elements can almost always be left out of a persistence model. SQL Tables are by their very nature containers for many rows of the same design.
• Non plural non data carrying elements can be kept or not as driven by the requirements of the system under design.

Now we can see our way to an answer to the question "Should we implement the full model or just the subset that matches a V2 transaction?" Here is what I would call the best practices.

• If implementation needs any fact from a data carrying element implement ALL the data points in the element. an acceptable alternative would be to define all the data points an comment out the ones you will not use. Documenting what you left out will make source code searches for all MISMO data points work. When a request comes along to add something you left out you will know immediately where it should go.
  
• Have a way to match the cardinality along the XPATH between data points you need to the Root node MESSAGE to a foreign key chain in your persistence model. Cardinality mismatches will cause grief and work around techniques. For example if you receive messages but your persistence model only can support one LOAN extra effort will be needed to overcome the cardinality mismatch.
  
• I would make place holder objects for all the data carrying siblings of the data carrying element I am implementing. Again I would add the list of MISMO names in comments. When the request comes to add a closely related data point you will know where it goes by a simple search. The MISMO normalization tries to place related things close together.

Requirements are fluid under any circumstances. Our industry is particularly fluid right now. a project faced with a user community that is willing to say "We will never need that." can be rebutted with a simple question "What if regulation changes?"

• What if regulation changes and copies of Credit eports must be returned with AUS responses, both data and document?
• What if Flood certificate number are no longer enough and the entire Flood response id needed?
• What if Investor Services want the entire Appraisal report?

V3 provides a robust model for a variety of future changes the more you leverage your development to prepare for future unstated requirements the faster you will be able to react. The changes will have more predicable impact as well.