1 / 0

Using the Reference Model Internally: Enterprise Systems

This resource focuses on the internal application of reference models in enterprise systems, highlighting methods for incorporating them seamlessly into existing legacy systems. It covers critical tasks such as mapping to legacy approaches, utilizing tools like XSLT, and building object models for efficient data management. The document emphasizes the importance of thorough verification and testing procedures to ensure accuracy and reliability in the transition from legacy systems. Utilize this comprehensive guide to enhance your understanding and implementation of enterprise system frameworks.

louis
Télécharger la présentation

Using the Reference Model Internally: Enterprise Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using the Reference Model Internally: Enterprise Systems

    Jim Metzger, Harland Greg Alvord, RealEC
  2. The Tasks Mapping to Legacy Approach Tools Converting to/from legacy XSLT Object Model
  3. Mapping to Legacy Build a spreadsheet Lots of people know how No way to verify/test Artifact disconnected from final process Use a tool I like Altova Mapforce Test map Document Map Produce XSLT 1.0 , 2.0, Xquery, C#, C++, Java Code generation has it own issues. Other tools available
  4. Converting To/From Legacy XSLT -- Map is Data Fast to do Interpreted or Compiled Changes by changing a file (good/bad) Unpredictable memory usage Can be slow
  5. Converting To/From Legacy Object Model – Map is compiled code Development cycle to do Less developer experience available Changes by good process Known memory model Fast!!!!
  6. What do Developers Say? Developers with relational data background love MISMO 3.x Team background is important
  7. What do Developers Say? The multidimensionality and repeatability of sections of the model needs to be well understood. The repeatability of containers was a significant change for developers who had only previously worked in a fixed length flat file environment. People used to 2.x service messages and flat data models are skeptical. Team training in model important.
  8. What do Developers Say? Legacy systems that reserve memory for every possible data point have a hard time with 3.x Legacy system using new model Needs optional field implementation Legacy system using old models Middle system filters to data to Legacy
  9. What do Developers Say? “Floppy-disk syndrome” occurs with people who coded to Intel 8086 memory limits and see the big new messages. I coded before Floppy Disks and 8086 Grow with the times Train for the times
  10. What do Developers Say? Best to dedicate a team with the responsibility of mapping legacy data models to the new model. BA or Developers? Both!! Crosses legacy management lines.
  11. What do Developers Say? Provide funding for the effort by applying it to visible software projects that will generate revenue.
  12. What do Developers Say? An internal “global lexicon” became essential for us, because it insulated the internal model from MISMO release changes. LDD is a best Practice Must digest MISMO releases to internal needs
  13. What do Developers Say? The benefits of a single standard do eventually start to show themselves – multiple products can talk to multiple third-party services after writing one interface.  SOA is a best practice Canonical XML within a the design essential MISMO 3.x as Canonical candidate leverages 100 thousand man hours
  14. What do Developers Say? Developers need to be aware that constraints and conditions may be placed at both a data point level and at a container level by the trading partner. These may be more restrictive than the MISMO schema. Developers may not be attuned to thinking about conditionality at a container level, in addition to a data point level. ULDD uses model ULDD limits field sizes Freddie Mac data constraints different from Fannie Mae
  15. What do Developers Say? MISMO LDD breaks data into lowest component pieces. Legacy systems may not store and process data at the same level of granularity. This can provide some challenges and require changes to legacy systems or translation layers between MISMO and legacy data. Legacy proprietary code translation into MISMO data can be complex, actually breaking down into 3 or more MISMO data points. Data normalization a best practice
  16. What do Developers Say? The model may seem overly complex to those who are implementing to support simpler business use cases. Any use case is a subset of the model. MISMO needs to publish the Use Case driven IGuides Yes there are many alternate designs. Compatibility across use cases has value. Real measurable $ and time value. If pushed to a simple one off get a blood oath. Accountability flows up and down the org chart. NOT just down.
  17. What do Developers Say? There was a steep learning curve on the concept of Loan States. There was nothing similar that had existed before, so working with it the first time was difficult. Having some MISMO examples of its usage would have been helpful. MISMO needs to publish the Use Case driven IGuides
  18. What do Developers Say? Trading partners seem to like the immediate feedback that a parser provides letting them know if their file is not well-constructed which is a plus with the common MISMO XML. Schema validation is good Business validation is better
  19. What do Developers Say? In general, the lack of written materials explaining the reference model and its usage was seen as a negative. Developers are looking for more guidance. One particular area that was called out was on the usage of EXTENSIONS. MISMO needs to publish the Use Case driven IGuides
  20. What do Developers Say? Large number(unmanageable) of objects share the same namespace when code is generated…it would be better if the schema was sub divided a bit more. MISMO uses W3C strategy for Namespace management Confusing XML Namespace with Code Namespace. Need to be managed differntly Arch WG MAY break up the schema more.
  21. What do Developers Say? Some defined types (like Integer) might be better as “Int” as they convert to generic strings when generated The xsd:integer issue Arch WG to consider solution
  22. What do Developers Say? Choice Groups when cast into Object Model need additional code to enforce the choice on deserialization. Deficiency of XSD.EXE? May be a missing option setting
  23. What do Developers Say? Enumerations should have a separate file Wants file per enumerated type. Arch WG will consider
  24. What do Developers Say? It would help if a base datatype was defined so we could extend it as needed 3.2 Now has a base type for each data type Including enumerated types.
  25. Conclusion Developers comments positive Still some MISMO improvements needed MISMO needs to publish the Use Case driven IGuides
More Related