Header 1 Integrating Disparate Data with Model-Driven Data Services IONA Technologies May 2008 Integrating Disparate Data with Model-Driven Data Services 2 Table of Contents Executive Summary ......................................................................................................................................... 3 Messaging and SOA Data Interoperability Challenges ................................................................................... 4 Semantic Data Interoperability .................................................................................................................... 5 How Does This Impact the Business?.......................................................................................................... 7 Creating A Data Services Layer ....................................................................................................................... 8 Data Services Classifications....................................................................................................................... 8 Open Tooling............................................................................................................................................... 10 Using A Model-based Approach................................................................................................................. 10 Leveraging A Common Data Model ........................................................................................................... 10 Centralized vs. Distributed Architecture ................................................................................................... 11 Lifecycle Management ............................................................................................................................... 12 Common Use Cases....................................................................................................................................... 13 Benefits of Messaging Data Services ............................................................................................................ 13 Introducing IONA Artix Data Services............................................................................................................ 15 Leading European Fund Manager Speeds Securities Processing ............................................................ 16 About IONA ................................................................................................................................................. 17 Integrating Disparate Data with Model-Driven Data Services 3 Executive Summary Global 2000 companies have made significant investments in messaging and service-oriented architecture (SOA) projects to integrate disparate systems and gain control of complex, heterogeneous IT environments. Unfortunately, many of these projects have not efficiently addressed a fundamental component of integration—normalizing the disparate data sources used by system endpoints. Failure to manage the data component of application integration has significantly diminished the success of many integration projects. Each connected endpoint in an application integration project typically has a data source. This could be structured data, such as a database or XML file, or semi/unstructured data, such as an Excel spreadsheet or binary object. Because each data source has unique syntax and semantics, it is very costly and time consuming to integrate and maintain relationships between the data sources, while ensuring the data’s integrity as messages flow from system to system. The amount of data that IT teams need to manage is doubling every two years. In fact, many large companies have deployed over 15,000+ data sources and 100,000+ business processes. With the increasing volume of data and growing number of disparate data sources, it is no longer cost effective to use the current method of hand coding data transformations and validation rules between systems. Business initiatives aimed at empowering the customer, integrating channels and launching products and services to market faster are driving the need to remove latency and manual processing from end-to-end business processes. It is no longer acceptable to batch process and synchronize records overnight. Other business drivers such as compliance with regulatory requirements or partner demands are forcing companies to adopt evolving industry standards including SWIFT, ACORD, SID, HL7, FIX, NEIM, SEPA – and the list goes on. Even though the number of data mappings is growing exponentially as more systems and partners are integrated, over 80% of developers still hand code data mappings, and data normalization can take up to 50% of new application roll out effort. Sometimes referred to as the “missing link in application integration”, data services are reusable data interoperability tasks performing a range of data mediation functions and are loosely coupled from the data sources they serve. Companies are building a “data services layer” that sits between data consumers and data producers, similar in concept to building a set of reusable services for an SOA. Both the syntax and semantics of each connected data source are abstracted using standards-based XML and Web services technologies. Data services can be registered, discovered and reused across local and remote projects. Open, standards-based, model-driven tools are now available to build a data services layer, allowing organizations to more efficiently implement and manage heterogeneous data models, while vastly improving the quality of data flowing between applications and partners. This paper reviews the technical and business challenges companies will encounter when integrating disparate data sources as part of their application integration projects, while distinguishing the different types of data services technologies available, reviewing key components when building a data services layer, and providing a high-level overview of an open, standards-based, model-driven development tool and runtime that facilitates data interoperability of in-flight messages. This modern approach to data interoperability can reduce integration effort and time-to-market by 50% by using data about data to drive efficiency and reduce risk. Integrating Disparate Data with Model-Driven Data Services 4 Messaging and SOA Data Interoperability Challenges Data integration is the process of combining various data sources, either structured, semi-structured or unstructured, for projects that need to synchronize, share or combine data across multiple systems. An example project might be creating a single customer view of purchases across multiple product lines. Data integration is not a new concept, and many established products exist to address common use cases—Extract, Transform, Load (ETL); Master Data Management (MDM); Data Synchronization, and Customer or Product Data Hubs. What has created renewed interest in data interoperability is related to the increased priority for integrating disparate applications, i.e. messaging and SOA projects. As “siloed” applications are connected, it becomes critical to build a flexible and efficient architecture that addresses evolving business and data demands. Some of these demands include: • More data to manage. New, more complex business processes require integrating more disparate data sources with unique data formats. Large firms have more than 100,000 processes and 15,000 databases, and with increasing business process automation the amount of data that a company needs to manage is doubling every two years. Recent analyst reports indicate that more than 30% of data in databases is duplicated since many repositories contain shared master data, such as customer address. Any change to one of these duplicated data stores creates a quality issue if it is not quickly replicated.1 Data needs to move in real-time. Business initiatives such as empowering the customer, channel integration, and launching products and services faster require companies to remove latency and manual processing from end-to-end business processes. For example, if a customer calls a company, the customer service rep (CSR) should have an up-to-the-minute history of all purchases and support issues across all product lines—and even be able to predict why they are calling! In the airline industry, airline staff should immediately know who their best customers are when they check in so they can offer enhanced levels of service. For example, if a passenger’s luggage misses a connection, airline staff should quickly notify the customer and offer delivery alternatives. More data consumers. In addition to requiring data updates sent to systems in real-time, more departments want “segments” of incoming messages for real-time analysis, e.g. the auditing group needs a copy of transactions for regulatory compliance and the risk management group needs to see real-time settlement exposure. Even within a company there are subtle differences between what each department requires, so oftentimes the data format needs to be customized for each request. For example, a “single customer view” for a CSR rep would be different from the detailed report that a technician requires for an on-site visit. Adopting and managing industry standards. External pressures for partner collaboration or regulatory requirements mean firms need to support industry standards such as SWIFT, FIX, • • • 1 The Forrester Wave: Information-As-A-Service, Forrester Research. January 23, 2008 Integrating Disparate Data with Model-Driven Data Services 5 FpML, ACORD, HL7 and TMForum SID. Standards are open to interpretation, so adopting one does not mean that all partners or even internal users using a standard will send messages in the same format. Additionally, standards are very complex and typically change every quarter or year, so companies need to support multiple versions for each channel using a different version of the standard. For example, with FpML there are 22 schemas, 600 simple types, 700 complex types and 3800 elements—with several releases each year. • Need to secure and govern in-flight data. Message documents which were “secured” for one application are now being distributed throughout the enterprise and even externally with partners. This requires authentication, access and encryption policies for the data. In summary, as more and more previously siloed systems are integrated, the problem of managing data inconsistencies increases. Traditional methods of addressing these inconsistencies, often with ETL solutions which involve batch processing into centralized hubs, are not acceptable due to the time delay of data updates between producers and consumers. Additionally, there is significant redundancy as these static processes were not designed as reusable services. Subsequently the time to normalize data in new integration projects has been reported to take up to 50% of the development effort! “If data models are still inconsistent, integration costs can still be as high as in a point-to-point situation” Dr. Lorien Pratt, Stratecast Semantic Data Interoperability As IT embarks on building more flexible architectures, they must address the unique syntax and semantics between each application which were developed for a specific project or acquired via a packaged application. Syntax (or schema), refers to the data field name, such as Name, Address or ZipCode. Semantics refers to the information about the data, or metadata, such as that the BirthDate must be before TodaysDate. There are a variety of different metadata formats representing items such as images, video, audio, tables, arrays, graphics, algorithms procedures, and documents. For many applications metadata is used primarily to describe information or rules about message documents. It would be simple if all message documents were published in a consistent, machine-readable format that could be interpreted directly by the applications that need to support them. The reality, however, is that many different formats are in use and many organizations complicate the picture further by extending formats to accommodate particular needs. Metadata serves to bridge the gap between these various message formats. By describing the structure of message documents, diverse applications can participate in a common process by using the metadata to interpret message documents passed between entities. When a developer creates a unified view of the customer by connecting all applications which hold customer data, they will most likely find syntax and semantic mismatches. For example, a Customer, Order or Product is often defined differently in each application that holds this data, such as in a CRM or ERP system. Reconciling the syntax differences, for example FirstName = FName is straightforward; Integrating Disparate Data with Model-Driven Data Services 6 however, normalizing the semantics can be very complex, and this complexity varies greatly by application and industry. Consider the following validation rule for a financial services SWIFT MT103 message: • C3: If field 23B contains the code SPRI, field 23E may contain only the codes SDVA, TELB,PHOB, INTC (Error code(s): E01). If field 23B contains one of the codes SSTD or SPAY, field 23E must not be used (Error code(s): E02). The above rule is just one of 19 conditions for this message, which is actually one of the simpler SWIFT messages! The diverse set of data models across a company make the simple task of integrating a few systems quite complex—a change to one schema or validation rule requires changes to all connected services. Custom coding transformations and validation rules between multiple data models is not an effective use of time, leads to higher development and testing costs, and significantly increases the risk of transaction failure. In fact, a recent Forrester Research report found that over 80% of developers write code to integrate data sources, increasing the cycle times and costs to maintain these applications. Furthermore, each time a new application is integrated into an existing SOA or messaging project, there is also an 80% probability that the resulting schema and semantic change needs to be made to the business process. Finally, 66% of responders to this report stated that there are unforeseen problems due to manual data integration. ORDER MANAGEMENT Data CRM PARTNER TRANSFORM TRANSFORM Data Data TRANSFORM TRANSFORM TRANSFORM TRANSFORM TRANSFORM TRANSFORM TRANSFORM TRANSFORM INVENTORY FUFILLMENT BILLING Data Data Data As application connectivity increases so does the issue of normalizing the syntax and semantics of disparate data Unfortunately for most companies, the issue of semantic interoperability appears too late into the development life cycle and either delays the project, adds unplanned costs, or worse, is ignored. Architects and developers alike who thought the messaging or SOA project was almost “QA ready” or even “Production Ready” now need to address the data interoperability issue. This can lead to code Integrating Disparate Data with Model-Driven Data Services 7 rewrites, unplanned new databases and data stores, and service redesign with the accompanying testing and maintenance repercussions. Tightly-coupled data transformation and validation rules that are duplicated across systems also limit the benefits of service reuse and impair the de-coupling of services (business logic around a message) and data (the message payload). Data descriptions begin to look redundant, threatening the integrity of the transactions they fuel. Ignoring these data inconsistencies impacts the quality of data flowing through the company. Quality and completeness of the data is just as important as being able to deliver data in a timely manner. How Does This Impact the Business? From a business perspective, organizations have a very difficult time getting their “single version of the truth” as semantic differences get lost in translation between organizational business domains. For example, the report for “Which products did customers discontinue service for?” could have different results depending on which systems are queried. Furthermore, it takes a long time to implement change requests, such as rolling out new business services, since IT spends time reconciling the syntax and validation rules between integrated endpoints. Organizations also risk not executing the business process with data integrity which can lead to lost customers, lost business and regulatory fines. For example, if an invalid message is sent to a partner and subsequently rejected, the partner may lose faith in the organizations’ ability to execute, not to mention the cost of the failed transaction. Integrating Disparate Data with Model-Driven Data Services 8 Creating a Data Services Layer Many companies are in the investigation or early adoption stages of SOA. They are beginning to get greater reuse from their IT infrastructure by building an application abstraction layer using services and moving away from hardwired connections between systems. Significant gains are achieved when the next project can reuse a service that was previously developed and tested. More importantly, when there is an update to a connected system, only one service interface needs to change instead of all connecting interfaces. Unfortunately, many of these projects focus on the application service interfaces and do not address the quality and semantics of the underlying data. Recognizing this problem, companies are leveraging SOA principles at the data level. They are creating an abstraction layer using data services as a method to efficiently deal with the myriad and constantly changing data models they must deal with. While there are many definitions of a data service and its purpose, there is common agreement that a data service has the following properties: • • It performs a data integration task, such as data transformation or data validation. It is loosely-coupled between consumers and producers of data, which can be data sources (structured or unstructured), applications, reporting tools and dashboards. Through loose coupling, a change can be made to the service or an endpoint without impacting all other connected endpoints. It has a well-defined interface. This interface contains the properties of the service independently of the specific implementation and includes the format the data consumes and produces along with any qualities of service. It is coarse-grained and modular and can serve static and dynamic applications, such as in-flight messages, bulk data imports and exports, transactions or analytic reports. It can be nested as part of larger data service transactions. It is designed for reuse. It is discoverable and available to be reused within a single project as well as across multiple projects. • • • Data Services Classifications There is significant hype regarding data services today. Vendors are pitching their solutions as a cure for all data integration problems, making it confusing for a buyer to determine the right tool for the job. Although the term data integration and data service (and many others including Information-as-aservice, data services platforms, data-as-a-service, data services architecture, virtual data grid, etc.) are being used, the problem being addressed is primarily driven by the data team (it’s data process-centric), or the application team (it’s messaging-centric). • Data process-centric. The data administrator (DBA, BI, Data architect) uses tools to synchronize, share, and combine data. They are dealing with hundreds to thousands of data sources, primarily for master data management, customer and product data hubs, and operational data store solutions. Due to the typical batch processing and centralized nature of these solutions, they are seeking distributed data services for data profiling, data transformation, data movement, data Integrating Disparate Data with Model-Driven Data Services 9 cleansing, data governance, data lineage, data federation and metadata analysis. Typically, this data services layer will sit between the data source and application middleware or a reporting solution. • Messaging-centric. The architect or developer building a messaging or SOA project is looking for a more efficient way to develop, deploy and manage messages as they flow between systems. Their project may have created services that addressed the application interfaces, but did not reconcile the different data formats. Or, they could have a project that has an industry standard library like HL7 that they want to use as a service to validate incoming and outgoing messages between partners. Both cases need data services, and although there might be some overlap in the functionality between them, these functions typically complement each other. For example, data cleansing is a task that a DBA is interested in, but an application architect building a messaging project would not be interested in. Similarly, the DBA may not be involved in the building the business logic validation rules. As an example of applying messaging (messaging-centric) data services, a telecommunications provider receives orders from multiple partners each using a different data format, one uses the Share Information/Data (SID) model, one uses Amdocs, and a third uses a modified SID model. The service provider can map their internal data model to these data formats, validate that they are syntactically and semantically correct, and reuse a core set of processing services rather than create multiple separate processes for each partner. When a new partner is added, or if an existing partner changes the format of the data they are sending, it becomes an easier task to implement. Example of Messaging Data Services The remainder of this paper will review best practices for building messaging data services and review the important components for their success, including: • • • Open Tooling Model-driven Design Common Data Model • • Distributed Architecture Lifecycle Management Integrating Disparate Data with Model-Driven Data Services 10 Open Tooling An open, intuitive and graphical toolset to import and export data models, define transformations and validation rules, then deploy them as runtime data services improves the ability of a company to develop and manage data services, and results in a significant savings over hand coding. True openness requires open tooling, an open model and an open deployment. Ideally, the tool does not lock organizations into a particular vendor’s framework and is built from the ground up to support standards such as Java, XML Schema, Database Definition Language (DDL), and XML Metadata Interchange (XMI). Open tooling also enables companies to import and map any binary or ascii data, whether it’s XML DTD, XML Schema, relational databases, fixed format, delimited, or existing code components. Regarding deployment, organizations should look for a code generator that generates standard-based objects such as plain old java objects (POJOs) and provides multiple options for deploying in existing frameworks. Using A Model-based Approach A model-driven architecture (MDA) is a method used in application integration where relationships are modeled and run-time components are generated from the models. The main benefit in using MDA tools is the reduction in coding and testing cycles, which leads to a more responsive IT department. In a data services context, model-driven data services can model any data source, whether it’s a delimited, tag/value, database schema, XML or an industry standard such as SWIFT. In addition, an existing model or industry standard can be specialized, i.e. inherit the base model and restrict or extend it based on the needs of the partner or company practice. If the base model is updated, the changes can be automatically applied to the specialized versions. This approach improves an organization’s ability to adapt to changing models and standards. Allowing departments to customize the data model to create their own view and version, while retaining the associated relationships of the base model, facilitates the adoption of the model companywide. An additional advantage of model-based development is the high quality code that is generated. How many times has a team had to run a full set of tests for code that was slightly changed? For example, one leading institution spent twice as much time testing their code compared to developing the code whenever there was a change to the industry standard data model. By moving to a model-driven data services environment, they were able to reduce both implementation and testing time by 50%. Leveraging a Common Data Model IT is starting to see the benefits of data normalization across projects, but they need a consistent way to describe data. A data model may define the schema and semantics of a single data source, or it could be the model based on an application that references several data sources, e.g. the CRM data model. A common data model is in reference to the model that is used (and agreed upon) by company, department or project-wide–a universal schema and set of semantics across all applications and systems. Often thought of as a “boil-the-ocean” type approach, companies are incrementally implementing common data models, but allowing them to be federated across departments. A common data model helps significantly in application integration as data ambiguity is removed, for example eliminating the differences between postal code and zip code, or standardizing on the Integrating Disparate Data with Model-Driven Data Services 11 appropriate validation rules for risk management systems. As new applications are integrated, there is now a lingua franca for data interoperability. Other systems and partners do not need to use same format, mapping the new system to the common data model means that messages between the two will have the same meaning and carry less of a risk that invalid data (either syntax or semantics) will be communicated between the two. By no means is adopting a common (or canonical) data model an easy task, as departments want to remain autonomous. It is also difficult to agree on a single standard. However, if steps can be made to move from tens or hundreds of models to a few abstracted models, a company will certainly become more responsive to change. Additionally, it is typically the in-flight data which is included in the model, rather than legacy data which does not change. A popular trend is to at least agree on adopting an industry standard model, typically based on an XML schema definition (XSD), e.g. ISO20022, ACORD-XML, FpML, TMForum SID, etc., and specializing the model based on a company’s specific needs. A recent poll from Forrester Research reported that 39% of enterprise architects are working on a canonical model (39% are not, and 19% did not know)2. Centralized vs. Distributed Architecture There are two approaches one can take to building a data services layer, using either a distributed or centralized approach. The centralized approach is common with most ETL and MDM solutions, where changes are sent to a central processing hub which then processes each transaction, including the transformation, validation and enrichment, as well as sending the message to subscribing consumers. With the growing amount of data that Global 2000 organizations must manage, the centralized hub approach is becoming a bottleneck for IT. With a distributed approach to data interoperability, transformation, normalization and validation are completed at the endpoint either when the message is received, sent or both. Developing a distributed architecture is an efficient way to achieve greater scalability, because the data normalization function can be performed on the existing hardware running the application. Centralized data interoperability approaches are becoming a bottleneck of IT, whereas distributed data interoperability improves scalability and eliminates a central point of failure 2 “Canonical Information Modeling is Key to Many Information-As-A-Service and SOA Strategies”. Forrester Research. November 15, 2007 Integrating Disparate Data with Model-Driven Data Services 12 Lifecycle Management When dealing with diverse and distributed data models that are constantly changing, it is important that tools manage the entire lifecycle (develop, test, maintain, retire). The following illustration highlights how complex the problem is in managing data relationships and the need for lifecycle management tools. Each project adds to the complexity of data management – where the number of data mappings and rules that needs to be supported grows exponentially. Each line in this diagram represents work for an impact analysis, development and test effort. In addition to the specialization features mentioned previously, the tool should have a change impact analysis component that allows users to visually see the differences when updating models, and even multiple derivations of a base reference model. The ability to manage versioning of changes within the data model by integrated version stamping and change control management within the development environment is also important. Interoperation with existing change management systems is obviously desirable. Integrating Disparate Data with Model-Driven Data Services 13 Common Use Cases Two common scenarios are being used today for messaging data services; oftentimes a project will combine both scenarios. 1. Intra-firm Data Interoperability For companies that standardize on a single data model (company-wide, LOB, or project-based), they need a data services tool to manage its development, deployment and lifecycle. Typically, each department and/or project will need to extend or restrict the model. 2. Inter-firm Data Interoperability For companies that need to efficiently map a multitude of incoming and outgoing message formats from business partners to internal data models or industry standards. Typical use cases may be receiving Excel spreadsheets that need to be mapped to an application data format, or B2B message flows based on industry standards such as SWIFT. Benefits of Messaging Data Services By abstracting metadata from an application into data services, it becomes easier for other projects to correctly reuse and access the data. This type of architecture has the following benefits: • Flexible architecture facilitates change: When a data source is updated, instead of making n*(n1)3 updates as in a tightly-coupled, point-to-point scenario, only one update needs to be made between the changing data source and the service. Provides greater reuse, minimizing data duplication: Other processes and applications can reuse data services, reducing the time it takes to code to a specific data source. Model-driven design provides the ability to inherit and specialize models, so there is less coding and less testing. Proven, high quality services are reused, not recreated. For example, if there are several partners sending messages using an industry standard, the data service can normalize the differences with internal models rather then making direct changes to the underlying systems. Provides a common tool and language across the company and partners: A single development tool and documented data model that can be shared across the enterprise (developers, architects and business analysts) increases collaboration between departments. Improves data integrity: Implementing real-time data validation services as messages flow between endpoints improves the quality of information in the data sources and minimizes the amount of fixing failed transactions or inconsistencies caused by batch processing. Validation • • • 3 Where n is the number of endpoints, e.g. 3 systems each with unique schemas and validation rules, could mean 3*(3-1) or 6 data mappings Integrating Disparate Data with Model-Driven Data Services 14 services also eliminate the “silent failures”—when invalid data is passed between systems—that are not found until later, for example when a report is created. A good system provides an early warning when connected data models change, making it possible to track where invalid data is coming from. • Enables data to flow in real-time: It becomes easier for other consumers to subscribe to a data service, whereas it may have been difficult to get the time and resources to work with the owners of the data source. Data can be accessed regardless of its data format or location. A published data service becomes a ubiquitous resource similar to a Web service on the Internet. Improved scalability and availability: Distributed data services significantly improve scalability and availability, and a distributed approach reduces the risk of a centralized bottleneck and single point of failure. If one endpoint is down (either by accident or for routine maintenance), the other services continue to run. Enhanced security: Data services can have set policies and governance, so consumers can only access the information they are entitled to. Rather then managing the security of hundreds or thousands of data sources, policies can be implemented on a set of central data services. Lower total cost of ownership and improved organizational capacity: Below are some of the real metrics that have been recorded by customers implementing data services: o o o o 20% reduction in the initial design phase by using a graphical IDE designed for managing data models over hand coding transformations and validation rules. 50% reduction in cost to develop and test updates by using model-driven tools that generate high quality code 50% reduction in the time to implement changes, by leveraging change impact analysis, versioning and specializations tools, since there are fewer iterations required Ability to double the number of mappings handled (either partner or internal) using the same resources • • • In summary, data services support a more efficient architectural model that enables reduced development and maintenance costs through reuse of data services, better rates of automation, and more flexibility to accommodate change. Furthermore, this technology is already being used in some of the most demanding business domains and has been proven to reduce the risks of transaction failure and vastly improve the overall efficiency of the IT organization. Integrating Disparate Data with Model-Driven Data Services 15 Introducing IONA Artix Data Services Artix Data Services provides highly reliable and scalable messaging data services across heterogeneous applications. Rather than spend costly time reconciling data inconsistencies, developers use a modeldriven graphical development tool to import or build data models, configure transformation and validation rules, and deploy reusable data services which parse, validate, enrich and transform in-flight or bulk messages. Artix for Data Interoperability With Artix Data Services, organizations can • Improve data integrity through real-time, reusable, data services – the solution provides data validation and semantic mediation of in-flight messages or bulk data sent between systems or partners Increase developer efficiency through model-driven code generation – the solution eliminates costly, error-prone, manual development and maintenance of data relationships through modeldriven, reusable data services Reduce cost of operations through distributed deployment – Artix Data Services is the single solution addressing your multi-platform, multi-protocol, multi-data format integration requirements connecting diverse endpoints without an expensive and cumbersome centralized server • • Unlike centralized, hub-and-spoke integration tools, Artix Data Services is deployed as smart endpoints, either locally or across a WAN, providing a distributed approach to data interoperability. For more information about Artix Data Services, visit www.iona.com/products/artix/data_services or email info@iona.com Integrating Disparate Data with Model-Driven Data Services 16 Leading European Fund Manager Speeds Securities Processing Seeing an opportunity to expand into the business of lending the securities it owned to other financial institutions, a leading Fund Manager in Europe wished to maximize the revenue opportunity through first mover advantage. As a new market opportunity, the key driver for this initiative was time to market—each week the project was delayed, the Fund Manager would lose its chance to recognize millions of dollars in additional revenue. Messages sent between backend systems, including SunGard Global One, and the SWIFTNet network needed to conform to several different formats. Based on the mission-critical nature of these transactions, validation rules between systems needed to be implemented. As they expanded their securities lending application, the amount of maintenance and testing of SWIFT messages increased. The requirement to implement and test SWIFT-mandated changes meant the company would have to spend five days of development and fifty days of test time, per application, per annum. The Fund Manager evaluated both building and buying a solution before ultimately selecting IONA Artix Data Services for their data services layer. The IT department was given a period of six weeks to implement and deploy the initial set of equity trade messages. After applying specializations based on requirements for SunGard Global One, they built transformations to and from their internal data model deploying as Java objects which parse, validate, and transform messages. The securities lending practice has been a huge success for the company, earning tens of millions of dollars in additional revenue in the first year of implementation. What previously took on average 55 days of testing and development for a SWIFTNet FIN upgrade per application, can now be accomplished in just half the time. The company relies on the benefits of model-driven code generation and a single tool to mange the syntax and semantics of disparate data sources. This example can be applied to any vertical process, e.g. provisioning a wireless phone service, to ordering a book online, to booking an airline reservation. The same stress point plays in the front office with diverse market data and order flow standards, the middle office in post trade matching, and in the back office with clearing, settlement and reconciliation functions. It is all about data – lots of data! Integrating Disparate Data with Model-Driven Data Services 17 About IONA IONA was founded in 1991 in Dublin, Ireland. We have a history of providing distributed, standardsbased solutions to IT organizations with complex, heterogeneous computing environments and challenging integration problems. We have a proven record of industry leadership and continuous product improvement. We make software and data work together so our customers can make better decisions, run their businesses more efficiently and improve their business results. Our software products enable customers to modernize and streamline their IT environments while at the same time lowering total operating costs and ultimately achieving greater return on investment (ROI) on their existing and future IT investments. For more information, please visit www.iona.com or email info@iona.com. IONA Technologies PLC The IONA Building Shelbourne Road Dublin 4 Ireland Phone +353 1 637 2000 Fax +353 1 637 2888 Support: support@iona.com Copyright IONA Technologies Inc. 200 West Street Waltham MA 02451 USA Phone +1 781 902 8000 Fax +1 781 902 8001 Training: training@iona.com IONA Technologies Japan Ltd Kioicho-Building 3-12 Kioicho Chiyoda-ku Tokyo Japan 102-0094 Phone +813 5212 8011 Fax +813 5212 8012 Sales: sales@iona.com WWW: www.iona.com IONA, IONA Technologies, the IONA logo, Orbix, High Performance Integration, Artix, FUSE and Making Software Work Together are trademarks or registered trademarks of IONA Technologies PLC and/or its subsidiaries. CORBA is a trademark or registered trademark of the Object Management Group, Inc. in the United States and other countries. All other trademarks that may appear herein are the property of their respective owners. COPYRIGHT NOTICE. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, photo- copying, recording or otherwise, without prior written consent of IONA Technologies PLC. Copyright © 1999-2008 IONA Technologies PLC. All rights reserved. Any trademarks, service marks, or product names that may appear herein are the property of their respective owners Job Ref: Date:May 2008