Seven characteristics of MDM business services

Transcription

1 IBM Software White Paper Information Management Seven characteristics of MDM business services How to spot the real thing when evaluating master data management systems

2 2 Seven characteristics of MDM business services Introduction Who are our best customers? What do they want? Can our supply meet demand? The questions that an organization asks itself can often make the difference between success and failure. To get the right answers and create the best business outcomes, decision makers need information that is accurate, timely and actionable. Master data management (MDM) solutions gather and reconcile information from data sources throughout the enterprise, providing line-of-business applications with consistent, comprehensive information and enabling managers to adapt to evolving opportunities. To drive rapid time to value at the lowest cost, market-leading MDM solutions offer predefined, extensible business services. Business services are web services that enable applications to access and act upon master data. In contrast, standard data services simply provide access to the underlying database; they do not deliver the business logic that acts upon the master data. Without business services, organizations must build custom code for each application, in order to provide the necessary business logic. Custom coding increases time to value, implementation risk and overall project cost. Through business services, an organization can simply let each application pass parameters into a central set of intelligent services on the way to the database. The implication is clear: instead of creating 50 different sets of code for 50 different use cases, one business service can deliver a nearly infinite variety of outcomes. The maturity of MDM To date, most of the MDM focus has been on the database and how to populate it. It was enough for an MDM solution to deliver a synchronized, centralized view of data. But as organizations information management capabilities have matured, it has become clear that the most important concept in MDM is actually management. A truly effective MDM solution is much more than just a static repository it s an active solution that maintains the integrity of master data and administers its consumption by multiple business processes and applications. There is a significant value to purchasing an MDM application with out-of-the-box business services versus buying an MDM tool with which you have to custom-build business services. Our costs were approximately 50 percent lower due to utilizing IBM s MDM business services versus building them with another MDM tool. Sushil Golani, Architect, Bank of America However, not all MDM solutions are created equal. It is important to understand whether a solution offers the appropriate functionality and flexibility of business services. This paper defines the key characteristics of effective MDM business services, explains why they are essential to a costeffective approach, and illustrates how they are a differentiating factor in successful MDM strategies.

3 IBM Software 3 With this understanding, we are now able to see two distinct categories of functionality in an MDM solution: Data services: These services are like the forklift equipment in a brick-and-mortar warehouse, providing the vital but largely mechanistic operations required to move data in and out of the system from source to destination. Business services: These services are analogous to the warehouse supervisors and forklift drivers who interpret incoming requests and make sure they are carried out according to the business rules of the organization. For example, the same query often requires different responses depending on any number of factors, such as who is asking the question. A request to view data from the wealth management department might be fine if it s coming from a wealth management salesperson, but is a financial services employee in the retail banking department allowed to see that data? The value of business services Business services offer significant value to MDM projects. A critical component of that value is reusability. To integrate an application with MDM, the organization does not have to create expensive custom code. It can simply tune existing prebuilt business services at a much lower cost. In other words, business services enable enterprise-wide MDM deployments in a cost-effective and consistent manner. Other benefits of business services include cost savings from automation of manual processes, higher data quality and integrity, enhanced customer service, improved customer retention and increased sales (see Table 1). MDM business service Add a contract with a new policyholder to the database Change a customer s address Get a customer profile and previous contact history Client-specific business logic If the policyholder is less than 18 years old, create a separate minority-aged owner alert on the record for servicing purposes If the person is a high-value customer and is moving to an area we service, send an alert to the branch manager to acknowledge the change and retain the business Retrieve the previous three interactions for a customer (across all channels) and try to deduce why the customer is calling based on profile and history data Business benefits Single business service replaces multiple data services, providing significant cost savings Logic within the service automates certain decisions, enabling a higher overall level of data quality and integrity, and greatly reducing the potential for human error in the process Enables fast response to a relatively low-level data service transaction Enables a higher level of customer service by employees, helping to increase customer satisfaction and reduce churn Presents additional opportunities for product up-sell and cross-sell Enables smart routing connecting the agent best suited to answer the potential customer question Helps reduce the cost of transferring clients from one agent to another to resolve an issue, cutting down several minutes per call on a high percentage of the call center volume Helps improve customer satisfaction and retention through improved service levels Table 1: Business benefits of MDM business services logic.

4 4 Seven characteristics of MDM business services Seven primary characteristics of business services MDM business services contain important business logic needed to govern the use and maintenance of master data among many applications. Because applications vary in their requirements, architecture and information needs, business services play a key role in providing master data in the most efficient manner. A true MDM business service will provide some or all of the seven capabilities described below. These seven characteristics can be valuable in evaluating MDM solutions as well as in establishing an MDM strategy to deliver master data to consuming applications. The seven characteristics of business services are as follows: 1. Sequential 2. Contextual 3. Governed 4. Associative 5. Proactive 6. Evaluative 7. Secure To illustrate the importance of these characteristics, we ll use an example MDM service: Update Address. We will demonstrate that a seemingly simple action like updating an address is actually quite complex, once you consider all of the applications, business units and permission logic involved in making an address change. 1. Sequential Business services mimic human decision-making A business service that is sequential with a series of steps and decision points represents the flow of human decisionmaking. These steps can include database interactions as well as applications of business logic. At some of the steps, the business service may call out for additional business logic from MDM engines. Decision points require the business logic to determine the outcome of each step before proceeding to the next. For example, does the requesting user have the necessary permission to perform the service request? If not, the process will terminate. The sequential nature of the process allows for many potential business outcomes depending on the decisions made at each step. While a business service should have a predefined sequence, it may also be customized by the organization and have customizable behavior that is external to the business service itself. The sequence and insertion of business logic decision points is designed to mimic the way a human mind might evaluate the master data request and relevant factors.

5 IBM Software 5 Example: Sequential decision making in the Update Address business service 1. Is the data provided intact? If so, perform basic validation functions (such as checking for mandatory fields). 2. Did the person actually move, or did they change some attribute of the current address such as contact preferences? If they did not move, apply the update as required, audit the change and exit the service. 3. Do I have to put the address in standard form? Standardize the address to postal standards. 4. Do I have to normalize address fields? Normalize the address fields into their granular components. 5. Do I have to confirm that the address is a real address? Validate and correct address fields. 6. Is this a postdated address change? If the change is postdated, end the current address as of the start date of this new address change; otherwise, make the new address active immediately. 2. Contextual Business services respond differently depending on the situation An MDM business service is designed to recognize the context of a service request and respond appropriately. There are five primary types of context: context passed within the request message, derived context, multi-data domain context, multistakeholder context and time-based context. Context passed with the request message Message-based context may be passed explicitly through an attribute such as language, or it may be implicit in the type and volume of data passed in the request. Examples include: Language: The request is presented in English, and the MDM business service responds with the appropriate language data set. Time zone: The requesting application/user passes in their time zone so all time zone sensitive fields can be adapted as required. Filtering: A filter value is passed in the request message, such as retrieve only active records or retrieve all objects of a certain type. The business service filters the content accordingly in its response message. Business views: The requesting application passes a context for a particular business viewpoint. If the requesting application belongs to Business Unit A, the business service adaptive interface will tailor the response for Business Unit A. Multiple data within the service request: The requesting application sends multiple data objects related to another object. The business service responds in context: for example, if there is only one child object, it adds one object. If there are N child objects, it adds N objects, and relates them to the parent object. Inquiry levels: The requesting application sends an inquiry level along with the request, allowing the response to include some objects but not others. The business service will retrieve data objects that correspond to that inquiry level, such as object A, B and D, but not C.

6 6 Seven characteristics of MDM business services Derived context Context can also come from surrounding data, either in the message request or in related areas of the master database. For example, an Add Account business service can add multiple parties related to the account. Depending on their role (account owner, emergency contact person, and so on) the party will be subjected to different data validation rules. A Get Party Address business service will look at the start and end dates for an address and return the one valid for today s date. Time-based context If a time or date is included in an inquiry, the MDM business service knows whether to retrieve data from the current operational database or the historical audit database. If a range of dates is passed, it will provide multiple historical images of the data object. The business service can also deal with global time zones and will store all transaction dates and time/date data universally, regardless of the time zone of the requesting application. Multi-data domain context MDM business services can maintain different contexts based on the data domain of the service request. For example: View a party to get a full profile, returning all data associated with that party. View a party in a role context such as customer or prospect where the business service will retrieve only the data collected in the customer or prospect role. View a party in an account context, where the business service will only return data associated to a party s accounts (such as checking, savings, money market, brokerage). Multi-stakeholder context The business service can recognize various stakeholders and their individual needs, while aligning those needs to the requirements of the overall enterprise and recognizing which data must be resolved at an enterprise level. The business service can also manage a temporary state of having multiple, conflicting data entries. For example, when two business units have two different dates of birth for a customer, the business service holds one in a pending state, processes the service request and then determines which date is correct. 3. Governed Business services enforce the rules A business service must govern the integrity and individuality of all master data. The primary objective is to actively govern data to ensure that the requesting system or business process receives data of high quality. A business service must be capable of enforcing the uniqueness of all master data objects it manages. In other words, it must store unique data once and only once it should not create a second record for an object if a record already exists. The business service may automatically recognize an object as unique, or the service may include a degree of automatic processing augmented by a manual remediation process. This remediation is often required for complex business objects, such as a customer. Seemingly duplicate identities can be identified automatically, and any actual duplicates can be eliminated through a manual data stewardship process. Business services also enforce the integrity of all master data and relationships through the following methods: Mandatory input: This method determines the minimal input that is necessary before a business service will add a data record. Validations: These range from basic validations, such as ensuring that start dates come before end dates, to validating data across database entry fields.

7 IBM Software 7 Defaults: Business services contain logic enabling them to use default settings for certain data attributes. For example, if a start date is not provided in a request, the logic may default to the current date. Overrides: Business services can provide requests with the ability to override certain processing or logic, if they are entitled to do so. For instance, a requestor may choose to override address standardization to store a vanity address, such as using a small township name in place of the standardized postal service address. Verification: Business services can also enforce compliance. For example, before adding a customer record, the business service may require that an employee confirm the customer s identity by viewing their passport. Example: Enforcing business rules in the Update Address business service Mandatory Input: Are elements such as address usage type and city provided? Validations: Are fields such as country and state/province valid? Is the start-date field less than the end-date field, and is the last verified date in the past? Defaults: Has the start date been provided? If not, then set it to the current date. Override: Bypass address standardization if requested to do so and track the decision as part of the person s record. Verification: Record how the person complied with identification rules for the address change business process. Address Uniqueness Rule: If the person s physical address has changed, then does that physical address already exist in the database? If so, associate the person to the existing address. Otherwise, create a new address and associate the person to it. Person Uniqueness Rule: If address is a matching element, are there duplicate person records that must be resolved? 4. Associative Business services understand relationships An MDM business service is associative; in other words, it can relate business objects to one another. This associative capability is often required to make logical business sense of a data model: object A may be related to B only if A does not already relate to C. This is difficult to represent in data model relationships, so the association must be managed by the business service. For example, the Delete Party business service checks to see if the party has an active Do Not Delete flag. It will also check whether the party has any active alerts, active relationships or is playing an active role in an agreement/ account. If any of those conditions are true, the service will halt and will not delete the party. With these types of associations, there must be the option of customizing logic to change definitions and service actions, as each organization will have different business rules. Example: Understanding relationships in the Update Address business service Does the person s new address make them part of a new household? If so, end their current household role and add them to a new household. 5. Proactive Business services think ahead Proactive business logic and triggering capabilities are essential characteristics of MDM business services. The completion of a business service may trigger other MDM processes, such as business event detection based on the changed data, or even processes outside of MDM in other applications, by publishing change notifications. Examples of these processes include cross-sell and up-sell attempts, customer retention attempts and additional service for high-value customers.

8 8 Seven characteristics of MDM business services Example: Thinking ahead in the Update Address business service At the time of the address update, has the customer experienced any recent life events, such as marriage or retirement? If so, alert a Branch Manager to welcome the customer to the new neighborhood and provide offers appropriate to newly married or retired customers. Does the customer have a household? If so, provide the option to change the address for all members in the customer s household. 6. Evaluative Business services can tell what happens next Evaluative behavior is another hallmark of MDM business services. Evaluative logic can preview and predict the outcome of a business or data service before actually processing the service. In some cases, this capability can be essential to demonstrate due diligence and prove compliance with datamanagement regulations. In other instances, it can help predict when additional sales could be made based on significant events in a customer s life, such as a marriage or retirement. For example: The Preview Collapsing Parties business service will apply data survivorship rules and show the effect of automatically combining two customer records. This is useful in datastewardship applications to show that the system ensured due diligence by generating a combined party before deciding to collapse party duplicates. The Get All Party Potential Events business service will predict all future events for a party within a specified date range. For example, it may predict that five years from now, the party will retire after turning 65 and may be interested in financial services such as estate planning. 7. Secure Business services help keep data safe A true business service is designed to ensure the security and privacy of all data. Security is maintained by means of two key business service capabilities: transaction security, and rules of visibility and entitlement. Transaction security: A business service must understand the user credentials and authorization required before proceeding with the process. The business service will halt if the user does not have proper authorization. Rules of visibility and entitlement: During an inquiry or search, the business service will retrieve only the data that the user is authorized to see. This is often called intra-service security. The user is permitted to request the business service, but is allowed to access only the permitted data. To use an example cited earlier in this paper, a financial services employee working in the retail banking department may not be allowed to see data from the wealth management department. Similarly, a user may be permitted to add or update master data only under certain client-defined conditions. Example: Handling security in the Update Address business service Transaction security: Does the user have permission to execute the Update Address business service? If not, record and return a security violation. Rules of visibility and entitlement: Does the user have permission to update this particular address for this particular customer? Examples of entitlement rules that can be configured include: The customer is a high-value customer and only a small subset of users can change the address. The user can work only with customers who live within certain geographies. The user can work only with customers who belong to a certain department or line of business.

9 IBM Software 9 MDM business service architecture The hallmark of an MDM business service is business logic. Business services do not represent an MDM database or structure, nor do they move data in and out of a database. They manage the use, creation, updating of and access to master data among multiple applications and processes. An MDM business service provides the overall context for all possible outcomes and uses of the service. At a functional level, this flexibility takes two primary forms: providing master data in context and allowing client-specific unique logic. Context includes the application and user making the request, as well as any context that is spelled out in the request itself. A business service will have various outcomes depending on these factors. This contextual flexibility allows the business service to respond intelligently to all consuming applications, eliminating the need to write new code for each application. The business service must also enable clients to enter their own rules and logic for example, should an event notification be sent out when a high-value customer registers a complaint? Each organization has unique rules and processes that affect the way master data is treated, and those rules must be factored into the organization s business services. Customizing prebuilt business services through easily accessible interfaces is less costly and time-consuming than creating new services. Ultimately, a flexible architecture allows organizations to reuse business services for multiple processes, which drives the cost of adoption down and enables more successful MDM implementations. The MDM business service environment An MDM business service environment has several key architectural elements (see Figure 1). These include the database, data services, business services, business logic engines and interfaces. Flexible integration and customization capabilities are built into every level to ensure that these elements are relevant to multiple use cases, and that organizations can incorporate their own specific business logic as needed. At a high level, both business services and data services should have multiple interfaces, enabling those services to be used by multiple integration points. Interfaces also allow business and data services to combine and form composite business services as necessary. Business services may range from large, multi-step (coarsegrain) services to small, single-step (fine-grain) services. They contain prebuilt business logic that enables them to define decision points, defaults, overrides and many other functions. Business services must also be able to accommodate clientdefined business logic.

10 10 Seven characteristics of MDM business services Some business logic functions, such as error messaging, are common to many different business services. These serviceoriented architecture (SOA) enabled components are built into the MDM engines, and can be accessed by any business service as needed to process a service request. Like business services, the engines are open to customization and can be adapted to each organization. Common types of business engines include: Matching Event management Business rules Visibility and entitlements Data validation Notifications Standardization Error messaging Audit logging Task management New composite business services to manage unique business processes Matching Notifications Business services Data services Coarsegrain Event management Standardization MDM services Business rules Error messaging Finegrain Visibility and entitlements Audit logging Business logic defines decision points, defaults, overrides and other actions within a business service Are all objects mandatory when adding this parent object, in a specific context? Business logic engines define specific behavior and outcomes of business services Data validation Task management Resolving the buy or build question Today s rapidly growing master data management market began as a build market organizations saw no commercial alternative and began to build their solutions. The question of whether to buy or build an MDM solution is still being considered. One of the reasons for this query is because the concept of business services includes an organization s unique logic its intellectual property for how to treat its customers and sell its products. Newcomers may be skeptical: Should I buy an MDM tool that requires me to build my own business services? Can I really purchase an MDM solution with that capability out of the box? Figure 1: In an MDM business services architecture, business services and data services combine to deliver composite services for unique businessprocess demands; the business logic engines serve as a library of common functions that can be reused and customized as necessary. Organizations can now buy MDM software with prebuilt business services that factor in the proper context and support pluggable or customizable logic. In essence, business services have been designed by thinking out all of the possible ways clients will use and customize the logic, and then providing easy-to-use methods to tune the services for each organization and customer situation. That is why business services can offer significant cost, time and risk savings compared to building a one-off solution.

11 IBM Software 11 Many organizations report that previous in-house projects required millions to build only a handful of business services often representing more than half of the entire MDM project cost. Others have saved significant costs and time to market by leveraging the value of prebuilt MDM business services. Predefined business services can also greatly lower risk. When a service is built from scratch, it is extremely difficult to future-proof against all eventual business requirements within the time constraints of a tactical project. Predefined business services that have been proven to work in multiple user deployments can significantly reduce the risk of failure with an MDM program, because they are designed to satisfy the needs of many applications. Plus, prebuilt business services can continue to extend and change based on business requirements. IBM InfoSphere Master Data Management: Accept no substitutes When it comes to business services, there is no substitute for intelligence. IBM InfoSphere MDM offers capabilities that have the intelligence to govern data and recognize the context in which an organization s business rules are to be applied. As the examples in this paper demonstrate, that built-in intelligence is a vital element in business service functionality and MDM project success. The InfoSphere MDM SOA Business Services Library offers approximately 800 intelligent, prepackaged web services that can be used to seamlessly integrate MDM into existing business processes and technical architectures. The Library is a tremendous resource of ready-to-use and extendable components, APIs and services that deliver advanced business logic capabilities. Together, they can eliminate the need for costly custom application development and help to accelerate the project s time to value. As part of InfoSphere MDM solutions, these business services have been proven in a wide range of real-world deployments. Too often, solutions focus exclusively on the data side of MDM. But the most important element of MDM is management governing master data and integrating MDM processing with existing business processes and applications. That is the role of IBM MDM Business Services: enabling organizations to deploy MDM faster, at lower cost and risk than is possible with data services alone. An organization can make the decision to build business services out at the application level, but that means building them over and over again for each application. A smarter approach is to deploy reusable business services from IBM that work for a wide variety of applications as part of a true enterprise-wide MDM system.

12 For more information To learn more about MDM business services and IBM MDM solutions, please contact your IBM representative or visit: ibm.com/software/data/master-data-management About the author David Corrigan is currently director of product marketing for the IBM InfoSphere portfolio. He has led the product management and product marketing teams for IBM Master Data Management, and has worked in the information management space for over 10 years. David holds an MBA from York University s Schulich School of Business and an undergraduate degree from the University of Toronto. Copyright IBM Corporation 2011 IBM Corporation Software Group Route 100 Somers, NY U.S.A. Produced in the United States of America July 2011 All Rights Reserved IBM, the IBM logo, ibm.com and InfoSphere are trademarks of International Business Machines Corporation in the United States, other countries or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the web at Copyright and trademark information at ibm.com/legal/copytrade.shtml Other company, product or service names may be trademarks or service marks of others. References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates. Offerings are subject to change, extension or withdrawal without notice. All statements regarding IBM future direction or intent are subject to change or withdrawal without notice and represent goals and objectives only. Please Recycle IMW14571-USEN-00