By using tdwi.org website you agree to our use of cookies as described in our cookie policy. Learn More

TDWI Upside - Where Data Means Business

Toppling the MDM Project Monolith with Agile Methods

Couldn't master data management practitioners tackle MDM as a series of small iterative projects like agile coders would? Instead of enterprisewide efforts, why not start with pragmatic projects that deliver immediate value?

Rightly or wrongly, master data management (MDM) has a reputation for being something of a consulting boondoggle. Commercial off-the-shelf MDM is basically unheard of.

MDM deployments are almost always highly customized and (for this and other reasons) usually involve professional services support in some capacity. This doesn't have to be the case, however.

Should MDM Become Agile?

MDM could benefit from an agile infusion. I don't just mean that companies could (or should) adopt agile software development or project management tools and methods for use in MDM projects. Sure, that's worth considering, but pull back a bit and look at the bigger picture.

Couldn't MDM practitioners, like agile coders and project managers, tackle MDM as a series of small project chunks? Instead of starting with massive, enterprisewide MDM efforts -- focused on customer data, product data, or (less advisedly) both at once -- why not start with doable, practical, strictly time-bound efforts -- projects that deliver immediate value in a specific subject area?

"Traditional master data management is for long-term planners. We work with a lot of smaller shops ... that understand that it makes more sense to focus on making their customers immediately successful in one iteration rather than committing to a 24-month project with 10,000 human-days of work," says Salah Kamel, founder and CEO of "evolutionary" MDM specialist Semarchy.

The Advantages of Agile Methods

The genius of agile is that it toppled -- or at least established itself as a viable alternative to -- the IT project monolith. In response to massive IT project efforts, budgeted at millions or tens of millions of dollars and projected to take 12 months, 24 months, 36 months, or more, Kent Beck, Alistair Cockburn, Ron Jeffries, and other agile champions said, in effect: "Enough. Stop the madness."

Agile champions a people- and results-centric approach to software development and project management. It has forced IT to come to terms with the facts: change happens and the business requirements codified at the outset of a 12-month project probably will change, perhaps significantly, by the time that project finishes.

Agile's impact was even more basic than this, however. Agile attacked IT's established practice of building massive projects that -- as a function of their cost, complexity, protracted duration, and ambition -- were almost always completed late, almost always ran over budget, and almost invariably failed to satisfy all the needs or requirements of the line of business.

If this last scenario sounds suspiciously reminiscent of one or more MDM projects you're familiar with -- or worse, been part of -- there's a reason. MDM is the new project monolith.

Why Dysfunctional MDM Dominates

Traditional approaches to MDM take an only slightly less monolithic approach to project management than the once-dominant waterfall software development model. Even if an MDM project is confined to a single domain (e.g., customer data), its scope is typically enterprisewide. Unfortunately, it usually takes some level of business dysfunction for MDM to reach critical mass as a problem.

MDM-style dysfunction isn't just any dysfunction, either: it's often the product of mergers and acquisitions, new application development or integration efforts, and other disruptions. As a result, MDM projects almost always involve complicated data, application, and process integration issues. A monolithic approach is a recipe for delay, cost overruns, and (in all likelihood) project failure.

There's a paradox in doing MDM, Salah argues: business vendors and software vendors alike depend on system integrators and consultants to customize generic MDM software to the requirements of a specific business. Integrators and consultants have little incentive to change this; as a result, he argues, many will fight (consciously or unconsciously) efforts to reduce MDM complexity, accelerate MDM delivery, and reduce MDM costs.

"The problem that we're facing is that the ecosystem has to change. System integrators have a vested interest in having big projects," he says. "Everybody focuses on the technology. We need to focus on changing the methodology, changing the process itself -- and having tools that actually support the reality of the business, which is that [the business reality is] going to change."

Agile-Like MDM Coming

Change could be afoot. Vendors such as Semarchy, along with Liaison Technologies, Reltio, and RedPoint Global, among others, all espouse agile-like takes on MDM.

Semarchy even offers a service that it dubs "proof of value" that's based on agile concepts and methods. "One thing we've done recently is we've released ... targeted [MDM] solutions that basically define the value [by defining] a specific business outcome that you want to get out of this [specific project] and then iterating in an agile way to achieve that," Salah explains.

"We're finding more [companies] are receptive to this agile [pitch], focused on value as quickly as possible and making sure that we deliver as quickly as possible."

About the Author

Stephen Swoyer is a technology writer with 20 years of experience. His writing has focused on business intelligence, data warehousing, and analytics for almost 15 years. Swoyer has an abiding interest in tech, but he’s particularly intrigued by the thorny people and process problems technology vendors never, ever want to talk about. You can contact him at [email protected].


TDWI Membership

Accelerate Your Projects,
and Your Career

TDWI Members have access to exclusive research reports, publications, communities and training.

Individual, Student, and Team memberships available.