MDM Catch – 22: Plain Vanilla versus Customization

MDM Catch – 22: Plain Vanilla versus Customization

In the lingo of computer software and hardware, we often use the phrase ‘Vanilla version of the product’ to refer to something which came straight out of the box.

Coming to MDM, there are many reasons why customers want to use vanilla version. Some of the key considerations are –
[icon_list style=”arrow-1″]

Upgradability
Time and effort required for customization work
Complexity and lack of knowledge there off about how to customize
Support issues from the vendors
Little or complete absence of best practices

[/icon_list]

Above all, why customize if product can meet all the requirements?

While above list tells you why you want to stick to Vanilla, in reality there are more reasons why you may need to customize a vendor product.

MDM products available in market today are designed and developed to support different industry verticals and domains. They are generic in nature and designed to solve multiple styles and architectures. Added to this, are the varying nature of business rules and requirements around master data in every organization. And then there are platform and technology aspects which affect the outcome of your solution. As a consequence, many companies will end up doing extensive customizations to create a solution which will fit into their business processes.

So how do we bridge this gap?

What is required is a helping hand from the vendors and an open mind on the customer end. I am huge fan of best practice documents and I think every MDM product should be delivered with as much detailed documentation as possible around customization. This will help in altering the product in a way that does not interfere with upgrade and support issues; a win-win for both parties.

Complexity may be inherent to MDM products due to nature of different features such as data matching. Using knowledgeable consultants, following techniques that have shown superior results, keeping the customizations to minimum are the key ingredients to ensure your MDM solution is future proof.

[pullquote_right width=”30%”] Using MDM products off-the-shelf without any customization is the best thing which can happen. But in reality, do not expect this miracle.[/pullquote_right]

A careful balance of customizations and out of the box features will help in meeting your schedule and budget requirements. Added to this, here are some of the key questions you should be asking as an organization buying MDM software –

[icon_list style=”arrow-1″]

How easy it is to customize the product I am buying?
Is the MDM data model easily extendable?
Is this software support an advanced code generation and code migration framework which can upgrade custom code to newer version quickly?
Are there extension points where I can easily hook in my custom business rules using standard, non-proprietary languages? If so, are these skills easily available in the market?
Will the product easily integrate into my existing IT infrastructure?

[/icon_list]

Using MDM products off-the-shelf without any customization is the best thing which can happen. But in reality, do not expect this miracle to happen in today’s dynamic master data management environment.

How do you handle this dilemma? Share your thoughts via comments.

Image courtesy of phanlop88/FreeDigitalPhotos.net

COMMENTS

7 Thoughts on MDM Catch – 22: Plain Vanilla versus Customization

Shobhit Bagga

8 Jan 2014

1:37pm

Great Article. You touched on some very key and important issues, vendor support and customer having an open mind. Very critical.

Show Replies

Seth Young

9 Jan 2014

4:28am

I think all clients have a requirement to customise the MDM product they are using, whether that is limited to just extending the data model or more extensive customisations such as providing complex additional services or integrating with another system (web services / jms / etl / custom adapters).

I think that the big question is whether the time invested in customising will provide the necessary benefits / ROI. In my opinion it is worth considering a vanilla MDM solution if it can satisfy a majority of the requirements. The MDM technologies are also flexible, so configuration can achieve a lot of the common project requirements.

In summary, don’t rush into a *large* customisation if the MDM technology can already provide many of the benefits out the box.
– Don’t reinvent the wheel by trying to make the MDM technology work ‘a little differently’ if it does the job perfectly well already.
– Look at the roadmap to see what enhancements are in the ‘next release’ because the client may be trying to create a customisation that is already in the product development pipeline.

All the best
Seth

Show Replies

Rich Jarvis

27 Jan 2014

6:48am

I’m going to add a cautious opinion to Seth and Matt’s comments, whilst configuration of vanilla MDM to meet a customer’s requirements is often a good solution, by being better supported etc, it can introduce its own issues if taken too far. A configuration that is very contorted to achieve the customers needs may on paper appear to be a more attractive solution to risk adverse customers but can easily develop into a maintenance nightmare due to complexity and through the usual changes introduced with new versions. At times developing customisations may end up with a simpler overall solution that is more maintainable and potentially a more valuable educational excerise for the customer going forward as they inevitably increase the scope of their solution.

There is no simple answer and it is a ROI analysis situation as Seth suggested. For many customers, sadly time is their critical factor and convoluted configuration is the default reaction to that at the expense of maintainability. Equally so there’s the other side, customers who customise everything to the point that you wonder why they purchased an off the shelf solution.

In between there’s the question of customers who developed a custom solution due to a product lacking a feature only for it to be developed later (and it was not in a roadmap as per Seth’s suggestion). Is it worth migrating them to the vanilla features or maintaining a custom solution? Obviously it depends on the customer, the complexity of the customisation, how much it differs to the vanilla solution and the impact on external systems.

Matt Gagan

9 Jan 2014

5:07pm

Nice article Prashanta.
I think that there’s a world that exists in between Vanilla and Customization. Let’s call it the world of Configuration. When done correctly, this can be the best of both worlds.
The Configuration world is supported when your approach to providing Vanilla (as a software vendor) is to accommodate flexibility e.g. in the logical data model, in the data rules model, in the governance process model, and in the data access layer (integrations, user interface).
You can now plug in pre-validated, best practice or industry standard Configurations (templates – collections of definitions of those flexible dimensions of MDM) that give Vanilla the ability to be adapted to specific sets of needs.
We should also recognise that even these standard Configurations are not sufficient to completely solve a typical set of MDM requirements, and that some tuning and augmentation of the Configuration itself is necessary, for example to accommodate some proprietary attributes, company specific rules or standards, or unique process steps. An integrated modeling Studio needs to exist to support this requirement, which can then hot-deploy new configurations, iteratively where necessary, to the MDM server runtime environment.
This approach facilitates a new MDM paradigm, “Agile MDM”, of building out and deploying MDM in shorter sprint-like phases, each providing business value, and with successive deployments building on the existing solution.

Show Replies

MDM – A GEEK'S POINT OF VIEW