1 / 28

SWIFTStandards (UNIFI – ISO 20022) “MDA-like” approach

SWIFTStandards (UNIFI – ISO 20022) “MDA-like” approach. Frank Vandamme Tools, Products & Methodology SWIFTStandards. OMG, Montreal, August 2004. OMG_SWIFTMDA_200408_v2.ppt. Agenda. Introduction. Development methodology. Development infrastructure. Implementation infrastructure.

lorna
Download Presentation

SWIFTStandards (UNIFI – ISO 20022) “MDA-like” approach

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. SWIFTStandards(UNIFI – ISO 20022)“MDA-like” approach Frank VandammeTools, Products & MethodologySWIFTStandards OMG, Montreal, August 2004 OMG_SWIFTMDA_200408_v2.ppt

  2. Agenda Introduction Development methodology Development infrastructure Implementation infrastructure

  3. IntroductionWhat is SWIFT? • Society for Worldwide Interbank Financial Telecommunication • Community of +7,000 financial institutions in +200 countries: • Payments (e.g. cross-border, domestic, corporate) • Securities (e.g. equity, fixed income, funds) • Treasury (e.g. foreign exchange, swaptions) • Trade Services (e.g. letters of credit) • Mission: “To enable interoperability between our members, their market infrastructures and their end-user communities” • Concrete activities: • Establish secure and reliable network application • Standardize information flows (messages)

  4. IntroductionWhat is UNIFI (ISO 20022) • Standard developed under ISO/TC68 (financial arm of ISO) • Modelling-based approach to develop standardised messages • Used in the financial industry • Described in 5 parts: • Part 1: overview of the main components • modelling-based approach • repository • Part 2: registration bodies • Part 3: modelling guidelines • Part 4: XML design rules • Part 5: Reverse engineering approach

  5. IntroductionDrivers for the MDA approach • Stability • Business-driven approach • Interoperability and convergence • End-to-end based on common semantics • Neutrality • Acceptable common description for existing standards • Flexibility • Cater more easily for market practices and market evolution • Predictability, consistency and speed • Foster reuse and automation capabilities Note: not used by SWIFT for application generation

  6. Understand the business Business Analysis What is the communication problem Requirements Analysis Define the solution Logical Analysis Refine the solution Logical Design Technical Design Physical implementation (automated) Technical Implementation Standards development methodologyOverview • Three layered approach • Business-oriented • Communication needs • End-to-end view • Formal notation (UML) • Representation-neutral • Implementation-neutral • Foster reuse (dictionary) • Involve industry experts

  7. Understand the business Business Analysis What is the communication problem Requirements Analysis Define the solution Logical Analysis Refine the solution Logical Design Technical Design Physical implementation (automated) Technical Implementation Standards development methodology Business analysis • Understanding the business • Processes: what activities are happening • Roles: who (functionally) is involved • Data: what information is used • Results of business analysis • Business activity diagrams (roles & activities) • Business component diagram (data)

  8. Understand the business Business Analysis What is the communication problem Requirements Analysis Define the solution Logical Analysis Refine the solution Logical Design Technical Design Physical implementation (automated) Technical Implementation Standards development methodology Requirements analysis • Identifying communication requirements per activity • Who owns the information • Who can provide the information • What are the required information flows • Identifying additional requirements and constraints • Which types of physical actors can play which roles • Market specific information requirements • Results of requirements analysis • Activity diagrams with required information flows • Requirement description documents • Business test scenarios (high level)

  9. Understand the business Business Analysis What is the communication problem Requirements Analysis Define the solution Logical Analysis Refine the solution Logical Design Technical Design Physical implementation (automated) Technical Implementation Standards development methodology Logical analysis • Identifying the transactions (collaborations) • Sequence of messages • Pre- and post-conditions, triggers, … • Identifying the messages • Message granularity guidelines • Message content (based on business elements) • Message usage authorisation / restrictions • Business cases for “variants” • Results of logical analysis • Sequence diagrams • Message scope & content • Business test scenarios (refined)

  10. Understand the business Business Analysis What is the communication problem Requirements Analysis Define the solution Logical Analysis Refine the solution Logical Design Technical Design Physical implementation (automated) Technical Implementation Standards development methodology Logical design • Identifying the message structure • Identify message components • Include required “technical” elements • Define structural message organisation • Formalise required business rules • Results of logical design • Message definitions (structure) • Message components • Business & technical test cases (detailed)

  11. Understand the business Business Analysis What is the communication problem Requirements Analysis Define the solution Logical Analysis Refine the solution Logical Design Technical Design Physical implementation (automated) Technical Implementation Standards development methodology Technical design & implementation • Preparing the physical implementation • Add syntax-specific information (e.g. tags) • Applying the syntax-specific design rules • UML-to-XML generation • Results of technical design & implementation • XML Schemas • XPL rules • Message samples

  12. BUSINESS CONCEPTS are described with BUSINESS AREAS are derived from MESSAGE CONCEPTS support execution of use BUSINESS TRANSACTIONS DATA TYPES Standards development infrastructureStandards repository ISO 20022 Standards Repository BUSINESS PROCESS CATALOGUE DATA DICTIONARY

  13. Business Association relates is derived from Business Component Message Component is derived from Business Element Message Element Rule Rule Code is of type is value of is of type Business Actor Data Type is based on plays role Business Role Data Type Representation Standards development infrastructureData Dictionary DATA DICTIONARY Business Concepts Data Types Message Concepts

  14. Business Area Business Process supports execution of Business Transaction Business Transaction Business Transaction uses Message Flow Diagram Message Flow Diagram Message Flow Diagram Message Definition Message Definition Message Definition Syntax Message Scheme (s) Syntax Message Scheme (s) Syntax Message Scheme (s) uses Standards development infrastructure Business Process Catalogue Business Process Catalogue

  15. Standards development infrastructureUML profile: used diagrams • Which diagrams are used (business layer)? • Business Analysis • Use Case diagram: highest level decomposition in business processes • Activity diagram (swim lanes): details of business processes: activities & roles • Class diagram: dictionary (business components, data types, actors) • Requirements Analysis • Activity diagram (swim lanes): required information flows • Complemented by textual information: e.g. links with business components

  16. Standards development infrastructureUML profile: used diagrams • Which diagrams are used (logical layer)? • Logical Analysis • Sequence diagram: description of message flow (business transactions) • Class diagram: messages • Logical design • Class diagram: dictionary (message components, data types) • Class diagram (hierarchical): message structure • No additional diagrams used in technical/physical layer

  17. Standards development infrastructureUML profile: stereotypes identify concepts • Some examples of stereotyped concepts: • Classes • <<BusinessComponent>> • <<MessageComponent>> • <<ChoiceComponent>> • <<DataTypeRepresentation>> (<<Text>>, <<Identifier>>, …) • <<Message>> • <<Actor>> • Associations • <<IsVersion>> • <<IsVariant>> • <<IsAlternativeFor>>

  18. Standards development infrastructureUML profile: tagged values add information • Some examples of tagged values • Synonyms (business terms) • Business components • Business elements • Messages • Administrative information • Requestor • Registration status • Supplementary information for data types • Code list owner • Format (facets) • Traces between “business layer” and “message layer” • Business components to Message components

  19. Standards development infrastructureUML profile: platform specific information • Through stereotypes, tagged values or properties • Some examples • Operations • “Injectable” in validation engine (via “export control property”) • SWIFTNet error code (tagged value) • Message elements • XML tags (tagged value) • Data types • <<XMLAttirbute>> (to be included in Schema) • <<Property>> (for documentation only)

  20. Standards Workstation Standards development infrastructureTool (“Standards Workstation”) • UML modeling tool for modeling activities • Add-ins to support and enforce methodology & guidelines • Traceability between “business layer” and “logical layer” • Formal rules • Conformance checking • Completeness checking • Link with data dictionary • Import and export of sample data

  21. Standards development infrastructureGUI for formal rules

  22. Standards development infrastructureGUI for formal rules

  23. Standards development infrastructureSupporting process • Continuous quality control • Check non-automated rules & guidelines • Check conformance with approval process • Freeze models for audit purposes • Check consistency across phases • Are all requirements covered • Are all messages based on approved requirements • … • Mandatory review activities • By registration authority • By business experts • Change log entries for dictionary components

  24. SWIFTNet Standards implementation infrastructureAutomated generation: overview Internal Repository Documentation XML Schemas “Publication” Financial Dictionary Business Process Catalogue Standards Workstation Message samples “Injection” Repository instance (XML) More to come … • XML Schemas • Validation rules • Samples

  25. Standards implementation infrastructureAutomated generation: documentation • HTML (available) and PDF (in development) • User view and implementer view • Combines model information with “auxiliary documents” (= text) • “Click-able” sequence diagrams • Message tree structure (expand / collapse) • Dictionary information (data types, …) • Delta documentation (for versions and variants) • Generated sample messages

  26. Standards implementation infrastructureAutomated generation: XML Schema • Consistency in XML • Business information  XML element/value • Metadata information  XML attribute (usually not in instance) • ComplexTypes are globally unique / elements are local • Traceability from XML to repository (based on XML element name and/or XML type name) • Message identifier = aaaa.bbb.ccc.dd (business area - message number – variant – version) • Character encoding = UTF-8 • Data types: Text, Code, Identifier, Amount, Rate, Quantity, Indicator, DateTime • XML facets: Pattern, Length, MinLength, MaxLength, TotalDigits, FractionDigits, MinInclusive, MaxInclusive, MinExclusive, MaxEclusive

  27. Standards implementation infrastructureAutomated generation: repository • UML repository is converted to: • Relational database • Basis for web query tool on “www.swift.com” and on “www.iso20022.org” • Also used for impact analysis • XML instance • Prototype

  28. uestions & Answers frank.vandamme@swift.com

More Related