Understand InfoSphere Master Data Management Server Product Domain, Part 1: An introduction to MDM Server Product Domain

Architecture and product domain feature overview

IBM® InfoSphere™ Master Data Management Server (MDM Server) Product Domain (introduced in MDM Server 8.0) provides the ability to manage an operational view of product master data. It also provides the single source of truth of product data to the enterprise. In this article, get an overview of the features specific to the Product Domain, including product type hierarchy, product structures, product relationships, product categories, terms and conditions, and localization. A new extension mechanism called "specs" was also introduced with MDM Server 8.0 and is a key feature for providing the flexibility required for managing product data. The article describes the specs feature and provides guidance on when to use it.


David Borean (dborean@ca.ibm.com), MDM Server Architect, IBM

David Borean David Borean has over 13 years of experience working on the architecture and development of mission-critical enterprise applications in both the product and custom development spaces. David joined DWL and led the architecture of DWL Customer (now MDM Server), a product that helped define CDI/MDM. The Service-Oriented Architecture of the product has withstood the test of time and remains strategic in the development of MDM Server. David took a sabbatical from DWL to drive the architecture of legacy modernization initiatives in the public service and then joined IBM shortly after the acquisition of DWL in 2005. David is now the lead product architect for MDM Server and manages the lab advocate program. Prior to joining DWL, David worked for Castek in developer and architecture roles on various projects within financial services.

Martin Oberhofer (martino@de.ibm.com), Senior Technical Consultant for MDM, IBM

Martin Oberhofer photoMartin Oberhofer joined the IBM Silicon Valley Lab as a developer for IBM database technology. After returning to Germany, he joined the IBM Boblingen Lab, where he is a technical consultant and member of the World-Wide IBM Software Group Master Data Management Center of Excellence. His areas of expertise include database technologies, Java software development, MDM architecture, and IT system integration. His special focus area is integrating MDM systems into the operational IT landscape by synchronizing and distributing master data with SAP application systems. Martin also provides architecture workshops to customers and system integrators. He holds a Masters degree in mathematics from the University of Constance/Germany.

developerWorks Contributing author

Dr. Thomas Schwarz (schwarzt@de.ibm.com), Senior Technical Consultant for MDM, IBM

Thomas Schwarz Thomas Schwarz is a technical consultant for Master Data Management in the Center of Excellence for MDM based in the IBM Boeblingen lab in Germany. He is an expert on integrating the IBM InfoSphere MDM Server with application systems, especially SAP. Furthermore, he is an expert on data migration and consolidation using the IBM InfoSphere Information Server, especially for SAP systems. Thomas also consults customers on MDM architecture and integration issues. Prior to that, Thomas has been a research assistant at the University of Stuttgart working on the integration and federation of location-based data in loosely coupled data services. He received his Ph.D. from the University of Stuttgart, Germany in 2007.

02 April 2009


This article is the first of three articles in a series. It provides a functional overview of the various features of the IBM InfoSphere Master Data Management Server (InfoSphere MDM Server), targeting the Product Domain. Step through the capabilities of defining the product model, then review the capabilities of managing products according to the product model.

Anyone familiar with MDM Serve's Product Domain (formerly WebSphere Customer Center) will see some similarities and patterns but will also see some key differences that are required in mastering product master data for an enterprise.

This article focuses on the features specific to the Product Domain. It does not address the features of the other domains nor does it address the multitude of features of the underlying platform of MDM Server. Some platform features include security, transaction auditing, extension mechanisms, notification mechanisms, business rule enforcement, and so on. The subsequent articles in this series dive deeper and provide implementation examples. The second article describes with full code samples how to extend the Product Domain using the traditional extension mechanisms in MDM Server by creating "hard product types." The third article describes how to extend the Product Domain using the new specs feature by creating "soft product types."

MDM Server at a glance

MDM Server helps companies gain control over business information by enabling them to manage and maintain a complete and accurate view of their master data. MDM Server enables companies to extract maximum value from master data by centralizing multiple data domains and providing a comprehensive set of pre-built business services that support a full range of master data management (MDM) functionality.

MDM Server maintains master data for multiple domains, including party, account, and product. MDM Server integrates data from different domains using business services that interact with all applications and business processes that consume master data.

The need for managing party and account master data within MDM Server is well-known and includes business drivers, such as better customer service, and insight and technical drivers, such as reduced operational costs. Likewise, managing product master data can aid in compliance or meeting regulatory requirements, identifying cross-sells and up-sells, and offering true product bundles that are not just limited to within a business line but span multiple business lines. Consistent product master data also improves revenue reports and simplifies exchange with suppliers and resellers.

MDM Server provides an operational view of product master data to the enterprise. In contrast, the IBM InfoSphere Master Data Management Server for Product Information Management (InfoSphere MDM Server for PIM, formerly known as WebSphere Product Center) provides for the collaborative authoring of product master data. In a simple view, products are authored in MDM Server for PIM and then operationalized in MDM Server.

MDM Server Product Domain features

The makeup of products varies greatly across and within industries. In financial services, credit facilities are different from deposit products. In the telecommunication industry, cell phone services are different from internet services. And in retail, music devices are different from plasma TVs.

The Product Domain provides you the ability to define the types of products you are interested in managing and their elements in order to account for this variability (for example, a music product that contains elements such as artist name and release date). These features are described in the "Defining the product model" section.

You can then create and manage products (instances of product types) once the product model has been defined (for example, a compact disc entitled The Beatles – White Album with an artist name of The Beatles and release date of 1968). The features related to this are described in the section "Creating your products".

Defining the product model

In order to create products in the Product Domain you have to first identify the types of products in the form of a product hierarchy and for each type define their elements. You also have to determine the possible structures that products are, such as stand alone or bundle. These features are described in the following sections.

Defining the product type hierarchy

The product type hierarchy defines the types of products you wish to manage. MDM Server provides the product type hierarchy, as shown in Figure 1, out of the box:

Figure 1. Product type hierarchy
Product type hierarchy

This product type hierarchy is defined in a metadata structure and has an associated set of database tables and business services. The intention is that you will extend it further to classify the types of products you will manage. For example, a bank may sub-type Financial Product to Deposit Product then further sub-type to Checking Product, Savings Product, and Term Deposit Product. Similarly, an online retailer may sub-type GoodsProduct, as shown in Figure 2:

Figure 2. Sample of an extended product type hierarchy
Sample of an extended product type hierarchy

When creating a new type in the hierarchy you have the choice of declaring the type as being either a hard type or a soft type.

A hard type implies that there is an associated database table and set of services for managing that type. For example, AddMusicProduct is a service that writes data to a musicproduct database table. The musicproduct table can contain columns such as artist name and release date.

On the other hand, a soft type implies that there is no associated database table and related services. For example, the existing AddGoodsProduct service would be used to add a music product if the music product type is a soft type.

Defining the elements of product types

After you have defined the product type hierarchy, you can then define the data you wish to capture for each type in the hierarchy. There are a number of product elements, such as relationships, identifiers, category hierarchies, and conditions, that are provided out of the box and are associated to the root product type in the underlying model, and therefore apply to all product types. But you may want to add additional elements that are not in the model. For example, with music products, you may want to capture elements such as artist name and release date. There are two approaches for accomplishing this. The first is to use the well-known MDM Server data extension mechanism, which alters the physical data model. The second is to use a new extension mechanism called specification, which does not require you to physically alter the data model. Both approaches support full backward compatibility on MDM Server upgrades.

Using the traditional data extension mechanism

The MDM Workbench can be used to create a data extension. The existing product tables representing the product type hierarchy provided out the box can be extended with additional elements.

Similarly any new product types you added in the product type hierarchy can be added into the model with a related set of services if required. These product types are described as hard types because they are hardened in the model. The Developer’s Guide describes the steps to create hard types, and the second article in this series describes the steps to accomplish this using the MDM Workbench. For example, if the Music Product type is declared as a hard type, then there will be a musicproduct database table, and you can define the artist name and release date elements as columns. Instances of the Music Product product type are accessed using dedicated services like AddMusicProduct.

Product types that are not declared as hard types can be declared as soft types, and there will be no associated database table and services for managing elements specific to those types. Instead, the specification mechanism and the existing services for the out-of-the-box product types are used.

Using the new specification mechanism

A new extension mechanism was introduced in order to address the variability in different types of products when there is no need to harden them in the database by creating physical tables as would be done when using the traditional data extension mechanism. This new mechanism is called specifications (or specs).

A spec is made up of different constructs but at its core is an XML schema. Therefore, specs are a way of extending the data model by using XML schemas and then managing some product data elements in XML form.

A spec can be crafted in the MDM Workbench and then deployed to a running instance of MDM Server, as the deployment tooling uses the administration services for managing spec data. The spec can then be attached to a product type (hard or soft type) and, if required, cascaded down to its subtypes. This defines elements specific to the product type, and values for those elements can be provided when creating a product of that type. A simple view of this model is shown in Figure 3:

Figure 3. Specification overview
Specification overview

Figure 4 expands on the example of a product type hierarchy with music product types and introduces specs in the model. It shows specifications attached to hard and soft types. Furthermore, with the specification LogisticsSpecs, Figure 4 shows how specs are cascaded down along the product type hierarchy.

Figure 4. Specifications attached to hard and soft types
Specifications attached to hard and soft types

There are certain factors that guide you towards a decision of taking a traditional data extension approach of hardening elements in a physical data model as opposed to using the new spec mechanism. Table 1 presents some questions for consideration and provides guidance on what approach to take based on a simple yes or no answer to the question. (The questions are further elaborated in the sections following Table 1.) Ultimately, you will have to weigh the answers to the entire set of questions, along with other questions specific to your implementation, to determine the best approach.

Table 1. Decision factors influencing the decision between hard and soft types
Might the extensions evolve over time?Soft types - Specification mechanismHard types - Extension mechanism
Do you introduce new types of products regularly?Soft types - Specification mechanismHard types - Extension mechanism
Will product data be in multiple languages?Soft types - Specification mechanismHard types - Extension mechanism
Do you need to search against the data using DB2 8 on z/OS?Hard types - Extension mechanismSoft types - Specification mechanism
Do you have many levels in the product type hierarchy?Soft types - Specification mechanismHard types - Extension mechanism
Can all of the consumers of the data tolerate XML?Soft types - Specification mechanismHard types - Extension mechanism
Do the extensions have a complex structure?Soft types - Specification mechanismHard types - Extension mechanism
Are you using specs in other features?Soft types - Specification mechanismHard types - Extension mechanism

Might the extensions evolve over time?

If the product elements (or extensions) are dynamic or volatile and may change over time, then specs is a good option. Specs contain one or more versions (or formats). The product values are based on a version of the spec. You can therefore evolve a spec with new elements and constraints without impacting or forcing a migration of product data.

On the other hand, if the product elements are very static and long-lived (such as elements in the Party Domain), then consider using the traditional extension mechanism and harden the elements. This provides benefits such as a well-known service interface that may be easier to consume in integration middleware and presentation logic.

Do you introduce new types of products regularly?

If extending the product type hierarchy becomes a regular occurrence because you are constantly introducing new types of products (based on a phased MDM implementation or as dictated by business), then consider utilizing specs. Specs can aid in minimizing the time it takes to introduce the new types of products, as no data model or application level changes are required to support the new types and their elements. However, some development effort is required if there is specific business logic required that is associated to the new types.

If the product type hierarchy is relatively static, including the elements of the type, then consider hardening the type.

Will product data be in multiple languages?

One of the features within the Product Domain is the ability to manage product data in multiple languages. This feature is supported by both hardened data and by the spec infrastructure. If you need to extend the model with language sensitive elements, then utilizing specs is a simpler solution since it gives you built-in capabilities for managing and querying the data in multiple languages.

Employing the traditional extension mechanism can be done, however it is slightly more work. For example, introducing a new entity results in two new entities with a one-to-many relationship among them, as shown in Figure 5:

Figure 5. NLS support if hard types are used
NLS support if hard types are used

In this example, the PRODUCTNLS table holds the language-sensitive elements and has a language id as key field.

Do you need to search against the data using DB2 8 on z/OS?

Simply put, searching through XML data (the spec values) is not fully supported in MDM Server 8.5. However, a sample is provided that supports searching through XML data using DB2 9.x on AIX®.

It is possible to extend MDM Server to search through XML data using the sample as a basis, assuming the version of the database you are using supports the XML type. However, if that is not desirable or if the version of the database does not support the XML type, then using the traditional extension mechanism for elements that need to be searched on may be required. For example, the XML data is stored in CLOBs with DB2 8 on z/OS®.

Do you have many levels in the product type hierarchy?

Having a very deep product hierarchy, for example, seven or more levels deep, and employing hard types for all product types along this hierarchy leads to a complex table join across seven or more tables when inquiring on a product that is a leaf product type. This is because each hard product type along the hierarchy stores the new attributes introduced by this type in a separate table. If some of the types deeper in the hierarchy are soft types and not hardened in the model, then that may prevent the number of tables that is accessed, keeping in mind that there is a small table structure that needs to be accessed to get spec values from.

If your product type hierarchy is relatively flat (only three or four levels deep), then there is less of a concern with database access.

Can all of the consumers of the data tolerate XML?

Spec values in XML mesh nicely in service requests and responses if the consumers of MDM Server are using the Web services interface or using the XML format with the RMI and messaging interfaces.

However, if the consumers are using different interfaces with non-XML formats (for example, using the delimited or COBOL copybook parsers), then the spec values don't mesh very nicely, as there will be snippets of XML in a non-XML message. In such a scenario, hard product types are favorable. Hardening the types also provides a well-known service interface that is easy to consume in integration middleware and presentation logic.

It is feasible to consider plugging in a new parser/constructor to transform the spec values in XML to the desired format, but this offsets some of the benefits of using specs, such as reduced development time. Also, not all third-party tools, such as reporting tools, provide support for XML in the database. If they are used in the MDM implementation, then they may preclude the possibility of using specs.

Do the extensions have a complex structure?

When defining elements of a product type, it is possible those elements may decompose into multiple objects. This would imply multiple database tables, if hardening the type. For example, if you wish to capture a listing of the tracks on CD products, then it would force a one-to-many relationship from a CDPRODUCT table to a TRACK table.

There is the ability to define a complex hierarchical structure of elements within a spec since the heart of a spec is an XML schema. This is one way of keeping the data model simpler and eliminates the need of joining many tables when inquiring on the products.

Are you using specs in other features?

Specs are used in other features throughout MDM Server (for example, in party demographics, agreement attributes, and product category attributes). Product category attributes is a feature that provides the ability for a product to inherit additional specs as a result of being placed into a category. The feature is described in more detail in the "Product category hierarchies" section.

The point of this section is that you have to also look across the whole of the solution when considering specs. If specs have been embraced in other areas of the MDM Server, then it makes it easier to embrace with product types. On the other hand, you have to also consider if the elements you are defining in specs are more appropriate to be managed elsewhere, such as product relationships, terms and conditions, and other features that are described in the "Creating your products" section.

Defining the structure of products

A product is of a certain structure. The structure type is simply a code table value from a data perspective. However, it can be utilized when extending the product, such as creating composite services, to add additional functionality. MDM Server provides a starting point for a list of structures in its code tables that can be further extended. Provided are structures of:

  • Stand-alone product: Example products include a No Fee Checking product, a High Speed Broadband Internet service, and a No Frills MP3 Player product.
  • Product bundle: A product bundle is itself a product (of the root product type). An example bundle is a Student Banking Package that bundles together a No Fee Checking product, Regular Savings product, and a Standard Credit Card product, perhaps with a condition of a lower interest rate on the credit card. The linkage to the actual component products is established using the product relationship feature (see the "Product relationships" section for more details on this feature).

Additional structures can be defined, such as:

  • Product template: This would be a product that can be used as a template or starting point for creating new products.
  • Product variant: This is a product that is based on another product but with some different characteristics. An example is an MP3 player that has red, green, and blue variants.
  • Product component: This is a product that is used as a component in building other products. An example is an auto insurance product that is made up of physical damage and liability components.

Creating your products

You can create products once you have defined the product type hierarchy and elements for each product type. A number of features can be utilized when creating products, and they are described in this section. The features include:

These are considered functional features. The other standard features of the MDM Server platform can certainly be utilized with the Product Domain as well. However, they are not discussed in this article.

Product identifiers

MDM Server manages two forms of product identifiers. The first form is business identifiers that are used for describing and searching for products. The second form is system identifiers for recording the primary key used in other applications that store the product.

Business identifiers uniquely, or relatively uniquely, identify a product. You have the ability to define the types of these identifiers you wish to capture with your products. Examples include product codes, such as the Global Trade Identification Number (GTIN), ticker symbols, and bar code numbers. These are used for more fully describing the product and are often important search criteria for finding products. The identifiers provide for a very efficient product search when they are relatively unique for a product.

System identifiers uniquely identify products in other systems. This is referred to as the product equivalency feature. Even though the product is mastered in MDM Server, it likely exists elsewhere in the enterprise, and this feature provides the traceability from the product in MDM Server to the equivalent product in your other systems. For example, if a product is stored with a primary key of 383732XX in a legacy system called Account Management System (AMS), then the product with a product code 47118888 in MDM Server will have a product equivalency that indicates the product also exists in AMS with a key of 383732XX. The product equivalency can then be used as the identifying key when working with the product in MDM Server.

Product relationships

A product can be related to other products for various reasons. MDM Server allows you to manage these relationships, whether they are relationships that are simple in nature or more complex relationships that impact the make-up of the product.

Examples of simple relationships include:

  • A cross-sell from a No Fee Checking product to a Regular Savings product.
  • An up-sell relationship from a Dial Up Internet service to a Broadband Internet service.

Examples of relationships that can impact the structure of the make-up of a product include:

  • A variant relationship that identifies the red, blue, and green versions of the No Frills MP3 Player are all variants of a Base No Frills MP3 Player.
  • A component relationship that identifies the Email service is part of the Dial Up Internet and Broadband Internet services.

As you can see with the examples above, the structure type of the product is used with the relationships structure when the structure type implies that other products are involved for a given product.

As with most constructs in MDM Server, relationships are type-driven and you therefore have the ability to define the types of relationships of interest.

Product category hierarchies

Products are usually organized into hierarchies for different purposes in order to provide different views into a set of products for different users. Example usages include:

  • A consumer hierarchy that organizes products into categories that are then presented to customers on a Web site for navigation. This is common with retailers where you can navigate through a hierarchy on their Web site to see the products within various categories and sub-categories. Similarly, it is common on a banking Web site that allows you to drill down different categories to find products and services. In the music product example, you can place products into categories that represent different musical genres.
  • A location availability hierarchy that contains a hierarchy of locations such as country -> state/province -> city. Each category represents a location, and a given product grouped in a category indicates the product is available for sale in that location.
  • An internal merchandising hierarchy that groups products in different levels, such as division, department, category, brand, and so on.

With MDM Server you can create multiple category hierarchies for different purposes. Products can be placed into multiple hierarchies as well as into multiple categories within a given hierarchy. You can navigate through a hierarchy to find products, or, for a given product, you can navigate to all related categories and their hierarchies using available services.

Figure 6 illustrates a simple Music Catalog category hierarchy with a single music product associated to two categories.

Figure 6. Category hierarchy example for a Music Catalog
Category hierachy example for a Music Catalog

A category hierarchy can be used as an inheritance hierarchy in order to provide a product with additional elements (in the form of a spec) based on its categorization. These additional elements are referred to as product category attributes and have these characteristics:

  • Multiple specs can be attached to a category and cascaded to sub-categories, if desired, for the purpose of defining additional elements of products.
  • When a product is associated to a category with such spec attachments, it inherits the specs.
  • Values can then be provided for the attributes defined in the specs. These are values for the product and not the category.

Additional business rules can be plugged in to the existing services using the available extension mechanisms. For example, new or changed products can be automatically categorized into applicable hierarchies based on their attribute values.

A category hierarchy provides the ability to organize products for different purposes. It should not be confused with the product type hierarchy. Here are some points to differentiate the two:

  • There is only a single product type hierarchy, whereas there can be many category hierarchies
  • Any given product is of a single product type. Any given product can be placed into many categories within and across many hierarchies.
  • The product type hierarchy is intended to be relatively static. New types are expected to be added over time and some types expired. However, the general structure of the type hierarchy is not expected to change often. In contrast, a category hierarchy is expected to go through structural changes both with products being recategorized as well as categories moving to different places in the hierarchy.
  • A product type provides a set of base attributes (in other words, specs) to all of its products. In other words, a product inherits a set of attributes as a result of being of a certain product type. These are attributes of the product and are applicable to all products of that type. A category can provide a set of attributes (in other words, specs) to products. These are also attributes of the product but only applicable to the products that are associated to the category.
  • A product type hierarchy is a strict tree, whereas a category hierarchy can be a directed acyclic graph.

Product terms and conditions

Terms and conditions can be managed and related to both products and relationships among products. Terms and conditions can contain descriptive verbiage, but more importantly, they and their sub conditions can capture data in a structured form that can be provided to external rules or systems for evaluation. The external content management reference feature, for example, can be used to relate the terms and conditions to an image or document in a content management system. Examples include:

  • Terms and conditions for a product bundle
  • Eligibility rules for product purchase
  • Eligibility rules for behavioral rewards
  • Disclosures
  • Rate and fee conditions

The basic construct of TermConditions is:

  • A TermCondition is of a certain usage type (such as eligibility and rate) and has a target type of entity that it is attached to (such as a product, product relationship, and account).
  • A TermCondition can contain child TermConditions (or subconditions), which results in a hierarchy of TermConditions. A subcondition is itself a TermCondition.
  • A TermCondition can have a number of condition attribute values, as defined by its usage type. For example, condition attributes for an eligibility condition may be age, net worth, and geographical location. Values for these attributes can be provided as part of the TermCondition, which are all managed in a relational structure.

Figure 7 shows an example of a Student Banking product bundle and the terms and conditions of the bundle:

Figure 7. Example of terms and conditions for a student banking product bundle
Example of terms and conditions for a student banking product bundle

In this example, a bundle is defined that contains a checking, savings, and credit card product. This is purely definitional data within the product domain. In other words, the figure is simply describing the product bundle. Storing and managing the fact that a student purchases the bundle is the responsibility of the Account Domain within MDM Server, and, in this case, the student would have a checking account, savings account, and a credit card account. There are two distinct conditions of the bundle:

  • The will receive a rate discount on the credit card condition is the first benefit of the bundle. It contains a condition attribute that describes the actual rate discount. The actual rate discount would have to be applied in the credit card management system.
  • The accounts within the bundle must be in a valid status condition contains subconditions that describe the possible statuses the accounts must be in for the bundle to remain intact and keep its integrity. Each subcondition contains a list of condition attributes that are the valid statuses for both the deposit (checking and savings) and checking accounts. This data can be leveraged by the Account Domain, for example, as part of the rules that evaluate if the bundle is still intact when the checking, savings, and credit card account statuses change.

Product localization

Product data may need to be managed in multiple languages since it is considered definitional data. All string-based data, whether it be data hardened in database tables or managed using the spec mechanism, can be managed in multiple languages and is supported by the services. For example, the name of a product can be maintained in multiple languages. In this example, an english, french, german, and italian version of the name is provided when adding the product.

From an inquiry perspective, the service control header information (DWLControl) can be used to indicate what languages product content are to be returned in for inquiry services. For example, when inquiring on the product, return back content in english andgerman.

For anyone familiar with the Party Domain of MDM Server, this concept expands on its capabilities. Within the Party Domain, a given service will return back code table values in the requester's language. The Product Domain takes it one step further by also returning back product content in multiple languages.

Product services

A complete set of services are provided out of the box to support all the functionality (and more) outlined in the sections above. This includes a set of fine-grained and coarse-grained services for adding, updating, inquiring, and searching products.

The services follow the same pattern as other MDM Server services, such as those within the Party Domain. Some key points include:

  • The add and update services allow you to provide the full set of child elements. For example, you can add a new product with values for attributes defined in specs, identifiers, relationships to other products, associations to category hierarchies, terms and conditions, and all in multiple languages.
  • The inquiry services allow you to inquire on products by its product id or by an equivalency identifier. There is support for inquiry levels that define how much content to bring back, and new inquiry levels can be added simply by configuring meta data. There is also the ability to filter values by specs. For example, you can inquire on a product and ask only for LogisticSpec and MusicMediaSpec values.
  • The search services provide a variety of criteria, including elements of product and category hierarchies for finding products, and support the same frameworks in the Party Domain, such as the pluggable search framework. A sample for DB2 on AIX supports searching for spec values.


You should now have a basic understanding of the various features of MDM Server's Product Domain. This includes:

  • The capabilities for defining the different types of products and their attribution you want to manage. This can be thought of as the product model.
  • The capabilities for physically creating the products and managing them.

In the next two articles of this series, learn how to implement the features introduced with full code samples.



Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Information management on developerWorks

Zone=Information Management
ArticleTitle=Understand InfoSphere Master Data Management Server Product Domain, Part 1: An introduction to MDM Server Product Domain